Skip to content

English · Español

Fase 39 — Capstone: el sistema de producción en miniatura

Requiere: 38 — Coste, capacidad, operaciones, MLOps Enseña: integration · end-to-end-demo · architecture-diagrams · cost-reporting Salta a cualquier capítulo desde el índice de referencia de fases.

Mapa del capítulo

La fase 39 no añade módulos: compone. Aquí los 38 fragmentos del repo se ensamblan en un único servicio HTTP — el grammar tutor — que arranca en frío con just demo, corrige una frase en inglés en menos de cinco segundos, emite trazas, métricas y coste, y demuestra tres filas del modelo de amenazas. Si Borja consigue que un visitante haga git clone && just demo y vea todo eso en 90 segundos, el currículo ha terminado.

Dónde encaja esta fase en el currículo

  • Anclaje en la especificación: LYNX_CORTEX.md §4 / PHASE 39 (líneas 816–833).
  • Anclaje temático: LYNX_CORTEX_ADDENDUM.md §A13 — grammar tutor sobre 20 verbos × 5 tiempos × 3 personas con traducciones al español emparejadas. La fase 39 es la forma desplegable del tutor.
  • Anclaje de método: §A12 — esta fase está pre-escrita: plan + teoría + enunciados de lab antes del arranque de fase; las soluciones, justo a tiempo.
  • Plan: PHASE_39_PLAN.md en la raíz del repo.

Qué produce el capstone

Un único comando — just demo — ejecuta un escenario guionizado de 90 segundos contra una pila arrancada en frío:

  1. Levanta miniserve + Prometheus + Grafana + Tempo + el servidor de tracking de MLflow vía docker-compose.
  2. Carga el grammar tutor con LoRA de la Fase 28 (el SHA canónico que se promovió en la Fase 38 lab 04).
  3. Envía una secuencia de frases en inglés ("Yesterday I goed to the store", "She have eaten", "I will written it") a través de POST /v1/grammar/correct.
  4. Devuelve las correcciones en streaming con razonamiento por token, rellena el dashboard de Grafana, emite el coste por petición.
  5. Replica tres filas de security/THREATS.md: un intento de prompt injection, un body sobredimensionado, y un payload de argumento de tool malicioso enviado a través del sandbox MCP (Fase 31). Cada uno se atrapa; cada uno queda anotado en el modelo de amenazas con Phase 39 demo: verified.
  6. Emite un informe de evaluación fechado bajo experiments/39-end-to-end/eval-YYYY-MM-DD.json.
  7. Baja la pila limpiamente.

Además, committed al repo:

  • docs/ARCHITECTURE.md — C4 (contexto + contenedor) + diagrama de secuencia.
  • docs/DONE_ENOUGH.md — los ≤ 20 checks binarios del capstone.
  • docs/README.md — el quickstart de cara al visitante.
  • scripts/demo/run.py — el ejecutor narrado de la demo.
  • infra/compose/full-stack.yml — la pila de observabilidad compuesta.
  • infra/grafana/dashboards/capstone.json — el dashboard único de Grafana.
  • PHASE_39_REPORT.md — la reflexión del capstone con la tabla de mapeo por fase.

Cadena de teoría (leer en orden)

  1. theory/00-integration-and-done-enough.md — qué significa realmente "integración"; cómo escribir una lista de DoD cerrada.
  2. theory/01-architecture-of-the-tutor.md — recorrido por el modelo C4; cómo se componen los ocho módulos de building-block; los contratos entre ellos.
  3. theory/02-end-to-end-data-flow.md — una petición, todas las capas, con conteo de bytes; el latency budget; la falacia de sumar percentiles.
  4. theory/03-cost-and-observability-stitching.md — cómo el rastreador de coste por petición de la Fase 34, la tabla CpQU de la Fase 38, Prometheus, Grafana y Tempo se unen en un único dashboard.
  5. theory/04-security-and-threat-model-closeout.md — qué filas del modelo de amenazas ejercita la demo y por qué esas tres; qué queda para la Fase 40.
  6. theory/05-demo-script-and-acceptance.md — anatomía de un buen script de demo; narración, idempotencia, determinismo, exposición de errores; grabación con asciinema.

Cadena de laboratorios (hacer en orden)

  1. lab/00-cold-start-bringup.md — primer arranque en frío desde un checkout limpio; resolver cada error de configuración ausente.
  2. lab/01-end-to-end-grammar-tutor-request.md — una petición recorrida capa a capa; árbol de trace capturado; identidad de coste verificada.
  3. lab/02-load-and-shadow.md — test de carga con 10 clientes concurrentes con la variante shadow de LoRA de la Fase 38 corriendo junto al baseline.
  4. lab/03-security-runthrough.md — tres filas del modelo de amenazas replicadas y anotadas.
  5. lab/04-demo-script.md — finalizar scripts/demo/run.py, grabar el cast de asciinema.

Definición de hecho (binaria)

Enunciada por completo en PHASE_39_PLAN.md §7. Ocho checks, todos binarios, todos automatizados.

Qué NO cubre esta fase

  • Ningún src/<module>/ nuevo. Solo composición.
  • Sin GPU. El vocabulario de GPU de la Fase 35 está documentado; la demo corre solo en CPU sobre el i5-8250U de Borja.
  • Ninguna técnica nueva de aprendizaje automático (machine learning). Sin entrenamiento nuevo, sin nuevo ajuste fino (fine-tuning), sin nuevo sampler.
  • Sin autenticación multi-usuario. Demo local de un solo usuario. Auth ≥ ítem de lista de lectura de la Fase 40.
  • Sin multi-región, sin balanceador de carga, sin service mesh. Un nodo, un proceso.
  • Sin refactors "de pulido". El endurecimiento de la Fase 40 los recoge.

Qué hacer cuando termines

Escribe PHASE_39_REPORT.md según LYNX_CORTEX.md §7.6. Después abre la Fase 40 (el postmortem).

Lecturas recomendadas

Opcional — enriquece pero no es necesario para aprobar la fase.