Gean C. Perez Gil — Portfolio (plain text)
Canonical HTML: https://geanperez.com/
GitHub: https://github.com/GeanPerez
Contact: gean.perez@icloud.com

Three case studies. Release engineering is a layer inside Trading automation—not a separate project.

---

## Case 01 — Trading Automation Platform
Stack: Python · Linux · pytest · Make · GitHub Actions

What it is:
A Python platform for researching, validating, deploying, and supervising automated trading strategies.

Project status / scope:
Sole engineer on a private repo: architecture, runners, supervisor, desk, and release pipeline.

Architecture:
  1. Research / backtest
  2. Validation gates
  3. Deployment registry
  4. Live runners
  5. Risk / execution
  6. Broker
  7. Monitoring / journal

What I built:
Independent live runner processes, a supervisor that restarts them from a deploy registry, risk and feed guards, a read-only operator desk, and release checks (make ci) on the same repository.

Problem:
When several automated strategies run at market open, a crashed process, stale market data, or code that skipped validation can fail before a human notices.

Result / scope:
Operators can see runner health, feed freshness, and a broker-aligned journal before treating the session as safe to run.

Engineering decisions:
- Separate research promotion from live arming—only registry entries that passed validation may run armed
- Supervisor logic in testable Python without shelling to pgrep in unit tests
- Operator UI is read-only so monitoring cannot place orders
- CI ship gate (472 tests) is a subset of full regression (2143 tests)—see release engineering section below

Validation (test suites):
- 472 tests in the CI-critical suite (make ci / CI_TESTS): runner imports, on-bar guards, supervisor, feed monitor, sizing, and session rules—ship gate on every push (verified 2026-10-09, make test-fast).
- 2,143 tests in the full validation suite (make test): adds research parity, lookahead, and promotion paths before strategy deploy—not run on every commit (verified 2026-10-09, pytest --collect-only).
- Backtest and historical metrics are evidence for arming decisions, not a promise of future PnL.

Verification note:
Ship path: make ci every push. Promotion/deploy: make test and make deploy when changing strategies or live config.

Verification layers:
- Runner import smoke, static on_bar guards, live loop unit tests (no live orders in tests)
- Supervisor, feed monitor, sizing, Topstep session rules in CI slice
- Lookahead / parity suites in full make test before research promotion

Operations / reliability:
- Feed freshness and BLIND state when runners are armed but tape is stale
- Kill switch file and session risk gates shared across runners
- Static tests on runner bar handlers after a production incident (stale bar / EOD window)
- make ci identical locally and in GitHub Actions

Evidence:
- Screenshots: quant desk, feed health panel, Telegram session journal
- CI screenshots in Release engineering section below
- Private repo—architecture and test walkthrough on request

Deep dive (modules & files):
Deep dive names: modelo_a/modelo_b (research), verdict_gate.py and TRUSTED ledger (promotion criteria), combine_deploy.json (what may run live), live_orb* / live_sb runners, no_hedge_gate.json, supervisor_core.py, dashboard_app.py. Historical backtest results are validation evidence for deployment decisions—not guarantees of future PnL.

Implementation steps:
1. verdict_gate → prereg JSON → combine_deploy.json arming rules
2. scripts/live_* runners + live_guards + broker adapter
3. supervisor.py / supervisor_core.py + dashboard_app.py (/quant)
4. Makefile CI_TESTS + hooks; see embedded release engineering section

Source: GitHub (trading-bot — private)


### Engineering deep dive — Release engineering
Stack: Make · pytest · GitHub Actions · git hooks · ruff · pip-audit

Project status / scope:
Same trading-bot repo—release discipline as part of the platform.

Architecture:
  1. git push
  2. pre-commit (secrets, ruff, sync checks)
  3. pre-push → make ci
  4. verify-lock → lint → test-fast (CI_TESTS) → pip-audit
  5. GitHub Actions (same make ci target)

Result / scope:
make ci is the only ship recipe: verify-lock, ruff on scripts/modelo_*, test-fast over CI_TESTS, pip-audit—enforced by pre-push hooks.

Verification note:
Screenshots from local make ci; same trading-bot repo as Case 01.

Verification layers:
- verify-lock / pip-audit on requirements.in
- ruff on scripts/, modelo_a/, modelo_b/
- test-fast — 25 files, 472 tests
- Excluded from slice: many test_orb_*_lookahead and verdict placebo tests (make test)

Operations / reliability:
- CI_TESTS file list in Makefile must match .github/workflows/ci.yml—documented drift failure
- Hooks copied from scripts/hooks/ via make hooks
- test-fast covers deploy imports, on-bar guards, supervisor, feed, guards/sizing—not full research catalog

Evidence:
- Screenshot: local make ci green
- 472-test pytest tail in CI slice capture
- Workflow invokes only make ci

Deep dive (modules & files):
make ci = 472 tests in CI_TESTS (runner-critical). make test = 2143 tests (research parity, lookahead)—required before strategy promotion or make deploy, not on every commit (counts verified 2026-10-09).

Implementation steps:
1. make ci: verify-lock → ruff → test-fast $(CI_TESTS) → pip-audit
2. ci.yml runs make ci only
3. make hooks installs pre-commit + pre-push

Source: GitHub (trading-bot — private)


---

## Case 02 — Andrä Eyewear — B2B wholesale
Stack: Rust · Axum · Postgres · Redis · Stripe · PayPal · Vite · Three.js

What it is:
Personal B2B commerce system designed around a wholesale eyewear workflow—PDF catalogs and manual reconciliation replaced by one deployed stack.

Project status / scope:
Personal product-engineering project: I own the concept, codebase, and deployment—not a client engagement.

Architecture:
  1. Storefront
  2. B2B portal
  3. Orders
  4. Payments
  5. Inventory
  6. Warehouse
  7. CRM / rep workflow

What I built:
Logged-in B2B portal with server-side cart, Stripe/PayPal webhooks with deduplication, inventory reserve/commit, and QR-assisted FIFO picks—plus a 3D storefront as the public layer.

Backend:
- Single Axum binary serves vitrina, /dashboard B2B, /ops, /rep CRM, and admin APIs
- Domain-split routers: catalog, cart, payment, inventory, rep_crm

Commerce:
- Server-side cart and orders in Postgres
- Stripe/PayPal checkout plus webhooks with deduplication before inventory commit

Inventory:
- Reserve → commit / release via inventory_ops.rs
- Warehouse loop: POST /api/inventory/scan with signed QR payloads and FIFO lots

Security:
- Argon2 password hashing and CSRF on mutating routes
- Redis-backed sessions required in production

Deployment:
- cargo build --release, npm run build:storefront, Nginx per docs/DEPLOY_ANDRA.md
- Live demo exposed via Cloudflare tunnel (URL rotates when tunnel restarts)

Problem:
In a wholesale eyewear workflow without integrated software, ordering still depends on PDF catalogs, manual payment reconciliation, and warehouse picks that do not match paid orders.

Result / scope:
One software path from catalog to paid order to warehouse pick, without side spreadsheets.

Engineering decisions:
- Single Axum binary serves vitrina, portal, ops, and APIs—one deployment unit
- Server-side cart and orders; 3D is presentation, not the source of truth
- Webhook deduplication before inventory commit
- Redis sessions required in production; Argon2 + CSRF on mutating routes

Verification note:
CI: cargo test, storefront build, verify-antra-ci.sh (health, security, order-flow smoke).

Operations / reliability:
- payment_deduplication.rs + inventory_ops.rs (reserve / commit / release)
- inventory_scan_routes + signed QR payloads
- Domain-split Axum routers (catalog, cart, payment, inventory, rep_crm)
- verify-antra-ci.sh smoke after cargo test + storefront build

Evidence:
- Live demo via Cloudflare tunnel (URL in Live demo button—rotates when tunnel restarts)
- 48 Rust tests in-tree (cargo test -- --list, 2026-10-09); CI smoke via verify-antra-ci.sh after cargo test + storefront build
- Portfolio screenshots match the deployed vitrina, login, and /dashboard flows
- GitHub (antra) private—code walkthrough on request

Deep dive (modules & files):
Single antra binary serves vitrina, /dashboard B2B, /ops, /rep CRM, and admin APIs. 3D vitrina is presentation layer; commerce logic is server-side. Redis sessions in production; Argon2 + CSRF on mutating routes.

Implementation steps:
1. Axum mounts HTML shells and API routers per domain
2. Storefront built to static assets; Rust serves templates
3. Stripe/PayPal create + webhooks update paid state
4. POST /api/inventory/scan for FIFO warehouse loop
5. Deploy: cargo build --release, npm run build:storefront, Nginx—docs/DEPLOY_ANDRA.md

Live: https://val-bend-stroke-varying.trycloudflare.com

Source: GitHub (antra — private)

---

## Case 03 — ContentCat — Academic Capstone (2022)
Stack: Python · Flask · TensorFlow · BERT · Twitter API

What it is:
Academic capstone (2022): Flask app that fetches tweets and classifies political leaning with a multilingual BERT model.

Project status / scope:
Team capstone (UPR)—my focus was shipping an end-to-end demo, not production ML today.

Architecture:
  1. Web form
  2. Tweepy fetch
  3. Tokenizer + SavedModel inference
  4. Result UI

Problem:
Faculty needed proof of end-to-end ML delivery beyond a training notebook.

Result / scope:
Reviewer enters a Twitter handle and sees classified tweets in the browser, with poster and AWS deployment manual as deliverables.

Verification note:
No repo in workspace—screenshots and poster only.

Operations / reliability:
- Server-side inference path (not client-only ML)
- Documented EC2 + Docker deploy in team manual
- Archived poster and UI captures only—no maintained repo in this workspace

Evidence:
- Faculty poster and UI screenshots on this site
- No public source repo linked today

Implementation steps:
1. Flask: form → Tweepy → Hugging Face tokenizer → TensorFlow inference → template
2. Team poster, SRS, AWS manual pages preserved as images
3. Dated assumptions (Twitter API 2022)—academic history only

---