Fase 1 en producción · verificado en vivo

AutoFix Zymplo — Centro de comando

La página única del proyecto de auto-reparación 24/7 de Zymplo: qué está corriendo ahora mismo en producción, dónde ver a los agentes trabajando, qué le toca a cada humano, y qué viene después. Todo lo que dice esta página fue medido en vivo (SSH a la caja de prod, API de GitHub, endpoint /health) — nada declarado sin verificar.

📅 Verificado 2026-07-28 17:22 UTC 🏭 Prod git_sha 179db46a = HEAD de main ✓ (18:57Z) 👥 Carlos ⇄ Victor ⇄ Luz

1 · Dónde ver todo funcionando

4 superficies
🖥️ Dashboard operativo (EN VIVO) requiere login

Acá se ven los agentes trabajando en tiempo real: cola de issues detectados, botones Aprobar/Rechazar/Diagnosticar/Promover a PROD, diffs propuestos, y la card nueva de costo LLM con barra contra el cap diario.

agents.zymplo.com/dashboard#autofix agents.zymplo.com/dashboard#avance — funnel + costos
📋 Plan consolidado de Victor público

El documento de convergencia Carlos ⇄ DevOps con la atribución de cada idea. Sus 2 correcciones de estado fueron verificadas en vivo y resultaron exactas.

agents.zymplo.com/plan-autofix
📖 Runbook de mejora continua repo HQ

El ritual semanal, la Fase 0 humana paso a paso, las respuestas a las 5 decisiones y el scorecard L1→L2 viven en el comando central del repo HQ.

zymplo-hq/01-comando-central/2026-07-28_AUTOFIX-MEJORA-CONTINUA.md
🐛 Reportes que originaron todo público

La auditoría "gusano" del chat (14 bugs, la clase que el autofix no veía) y el batch mobile — el material de origen de los 7 detectores nuevos.

chat-fixes.zymplo.com mobile-fixes.zymplo.com

2 · Fase 1 — desplegada hoy, pieza por pieza

8 PRs merged · deploy verificado
PRQué haceVerificación en vivo
#2829 Cuenta Anthropic dedicada para todo el gasto LLM del autofix (juez, proposer, diagnósticos). Fallback seguro: sin el secret en Doppler, comportamiento idéntico. ✓ merged 16:23Z
#2830 CONTIQ entra al registro de componentes fixeables (solo su módulo contiq-portal, denylist dura heredada, arranca detect-only). ✓ merged 16:23Z
#2831 Juez de IA a 2x/día (06:30 y 18:30 UTC). Antes juzgaba en cada scan de 2h = 12x/día. Mismo alcance, ~6x menos gasto. ✓ job en scheduler prod (log 17:13Z)
#2834 7 detectores regex ($0) de "respondió bien pero dijo algo mal": template sin renderizar, doble moneda, mezcla de idioma por campo, UUID crudo, monto sin moneda, decimal US, muro de texto. Los bugs reales de ayer son los tests. ✓ merged 17:01Z · 35 tests
#2836 Contabilidad de costo + cap diario US$17 (subido de $5 por decisión de Carlos 28-jul): ledger en Postgres, cada call LLM registrada, batches se saltean al alcanzar el cap, card de gasto en el dashboard, y el mapa de arquitectura entra al prompt del proposer. ✓ tabla creada en DB prod (verificado SSH)
#2817 Runner de propose en CI para crm-api (de Victor/DevOps) — el proposer genera diffs donde vive la fuente del monorepo. ✓ merged 14:39Z
#2808 Mobile quick-wins: regla no-color-literals activada (estaba instalada y apagada) + 42 tests dormidos ahora corren en CI. ✓ merged 12:53Z
#2832 Release → main + deploy (incluye todo lo anterior + fixes mobile de otras sesiones). ✓ /health = 0bd324aa (17:14Z)
#2846 Cap diario de gasto subido a US$17/día (decisión de Carlos 28-jul; era $5). El techo mensual US$25 del Console de la cuenta dedicada sigue siendo el freno duro. Release #2847 → main. ✓ vivo en prod: container reporta cap=17.0 (18:57Z)

3 · El pipeline que corre 24/7 (hoy, no promesa)

2 gates humanos · rollback automático
Detectar
Señales baratas + 7 detectores nuevos + Loki/Sentry multi-componente
Juzgar (IA)
Haiku lee conversaciones "sanas" y caza lo confidently-wrong
Proponer
Sonnet genera el diff, acotado por policy + arch-map
👤 Aprobar
Humano en el dashboard (Carlos/Victor/Luz)
Test + PR
pytest/tsc en runner · draft PR (o review-ready si alta confianza)
Verificar
Replay del mensaje original contra QA + juez compara
👤 Promover
Click "Promover a PROD" en el dashboard
Deploy
smoke → swap → healthcheck → rollback automático

Cadencias reales (todas verificadas en el código/scheduler de prod)

ProcesoCuándo correCosto
Scan determinista (regex + los 7 detectores)cada 2h (min :15)$0
Juez de IA (Haiku · cuenta dedicada)06:30 y 18:30 UTC · cap 50/corrida~$0.005/conversación
Proposer (Sonnet · genera diffs)cada 2h (min :45) · solo si hay issues · cap 5$0.05–0.25/issue
Runner "rama-lista" (tests + PR)cada hora (min :20) · solo aprobados$0 (CI)
Verificación en QAcada 15 mincentavos
Promoción a prodcada 10 min · solo tras click humano$0

Techo de gasto triple: cap diario US$17 en Postgres (decisión Carlos 28-jul; era $5) (los batches se saltean solos) → watchdog anti-fantasma del proceso → spend limit US$25/mes en el Console de la cuenta dedicada. Envelope real esperado: US$10–40/mes.

4 · La jerarquía — cada rol es un mecanismo real

nada inventado
🐛 Agentes (obreros)
  • Detectores de señales (signals.py)
  • Los 7 detectores de output nuevos
  • Fuentes: logs prod, Loki (CONTIQ+9 servicios), Sentry (mobile), crm-api
  • Proposer (Sonnet · escribe el fix)
🔬 Subagentes (especialistas)
  • Deep-diagnosis (diagnóstico a demanda)
  • Patchcheck (¿el diff aplica de verdad?)
  • Confidence scorer (¿alta confianza?)
  • Arch-map (blast-radius del AST real)
🚦 Supervisores (solo frenan)
  • Juez de IA (caza lo confidently-wrong)
  • Verifier + CI (replay + tests)
  • Policy de paths (auth/pagos intocables)
  • Cap diario $17 + watchdog + límite Console
👤 Directores (humanos)
  • Carlos · Victor · Luz
  • Gate 1: aprobar propuesta
  • Gate 2: Promover a PROD
  • Ritual semanal 30 min + scorecard L2

5 · Qué le toca a cada humano AHORA

Fase 0 · ~10 min total · nada bloquea
⏳ Carlos (~2 min restantes · workspace creado 19:18Z)
  1. HECHO — workspace zymplo-autofix creado (ID wrkspc_0155tdwjhy61WJF9my7Bn8uJ, verificado 19:18Z, costo $0,00 fresco). Distinto de los 4 ya existentes: Zymplo_mvp (bot), Zymplo-Agents (plataforma ~46 agentes S1), zymplo-auditor (mentor-council) y Default (legacy).
  2. ⏳ Dentro de zymplo-autofix → Límites: spend limit mensual US$25 (pendiente confirmar).
  3. ⏳ Claves de API → crear key dentro del workspace zymplo-autofix, nombre sugerido zymplo-autofix-key.
  4. ⏳ Pasarle la key a Victor por canal seguro (nunca por chat).
  5. Ojo créditos: US$63,79 disponibles (visto 19:18Z) — revisar auto-recarga para que el autofix no corte el bot por saldo.
Por qué el cambio: el plan original decía "cuenta nueva" asumiendo que el reporting a nivel org era ruidoso. El Console real de Carlos muestra que filtrar por workspace ya da costo limpio y separado + spend limit propio por workspace — mismo control, sin crear email/billing nuevo. Y por qué NO reusar los 2 existentes: mezclar ahí el gasto de autofix rompe justo la separación que buscamos, y los nombres son tan parecidos (Zymplo-Agents) que se prestan a confusión en la lista. Reversible: si más adelante se quiere separación total de facturación, se crea la cuenta aparte y solo cambia el secret en Doppler — el código ya acepta cualquier key vía AUTOFIX_ANTHROPIC_API_KEY.
⏳ Victor (~10 min)
  1. doppler secrets set AUTOFIX_ANTHROPIC_API_KEY (config prd + qa del proyecto zymplo-langgraph).
  2. Redeploy del bot → confirmar en logs la línea autofix LLM key: dedicated (…xxxx).
  3. Mismo secret como GitHub Actions secret para el runner de propose (#2817) — el código lo toma solo.
  4. Prender el juez en QA (paridad con prod, como planteaste en tu doc).
Resuelve la Decisión 5 de tu plan: key atribuible y revocable aparte, exactamente lo pedido.
⏳ Luz (continuo · ~15 min/día)
  1. Revisar la cola del dashboard (#autofix): aprobar/rechazar los issues judge:* — cada decisión tuya ES el dato de precisión que decide si el sampling del juez sube (ramp: cap 10 → 25 → 50, avanza solo con precisión ≥70%).
  2. Review de los draft-PRs que el pipeline abre (CODEOWNERS ya te los asigna).
Tu criterio de código es el gate humano #1 del sistema — el ramp del juez depende literalmente de tus aprobaciones/rechazos.
✅ Ritual semanal (los 3 · 30 min · lunes sugerido)
  1. Falsos positivos del juez → Luz (dashboard)
  2. Tuning de detectores/policy (nuevos literales, léxico de idiomas) → Victor + Claude
  3. Gasto vs envelope (card del dashboard vs Console) → Carlos
  4. Scorecard L1→L2 (sección 7) → los 3
Escalación: issue severidad-1 → alerta a Carlos · revert de un PR autofix → aviso a Luz + freeze del componente.

6 · Las 5 decisiones del plan de Victor — cerradas

todas implementadas o agendadas
#DecisiónRespuestaEstado
1Sampling/confianza del juez2x/día · ramp cap 10/conf 0.85 → 25/0.8 → 50/0.7 · avanza con precisión auditada ≥70%✓ en prod (#2831)
2Categorías L2 + métrica "L1 confiable"i18n/copy/formato-moneda · ≤40 líneas · nunca auth/pagos. Scorecard en sección 7definido · se mide desde hoy
3Prioridad Fase 3Validadores deterministas PRIMERO ($0, cierran los bugs reales) → golden conversations después✓ deterministas en prod (#2834)
4Sentry en front CONTIQSí, pero SOLO browser-side del portal (backend queda en Loki, como planteó Victor — no duplicar)Fase 2 (PR-8)
5Key Anthropic para el CICuenta NUEVA dedicada (límite $25/mes) — ni la del bot ni la org compartidacódigo listo (#2829) · falta Fase 0 humana

7 · Scorecard L1→L2 — cuándo el robot gana auto-merge

5 criterios simultáneos · ventana rodante
CriterioCómo se mideHoy
≥30 días con precisión del juez >80%issues judge aprobados ÷ (aprobados + rechazados) — sale del audit log del dashboardarranca hoy
≥20 PRs autofix mergeados con 0 revertsun rollback post-deploy resetea el contador0/20
Solo categoría i18n/copy/formato ≤40 líneasgate existente autofix_high_confidence_max_lines + labelgate ya en el código
30 días sin tocar el cap de gastoledger bot_autofix_llm_calls vs cap $17arranca hoy
Digest + ritual sostenidos 30 díassign-off de los 3 directoresdigest = Fase 2

Con 5/5: decisión de Carlos sobre el mecanismo de merge (GitHub bloquea que Actions apruebe PRs — la opción recomendada es una GitHub App con carve-out en CODEOWNERS solo para los paths L2; Luz conserva * para todo lo demás). L3 (auto-deploy) queda apagado hasta que L2 pruebe ser confiable.

8 · Lo que viene — Fase 2 y Fase 3

en orden de ejecución
PiezaQué agregaEsfuerzo
PR-6 · CopilotLogins individuales del dashboard (carlos/victor/luz — cada acción queda firmada con el nombre real; la plomería de auditoría ya existe) + digest diario por email a los 3 (issues nuevos, pendientes de aprobar, PRs esperando review, gasto de ayer)~2 días
PR-7 · Golden conversationsConversaciones guionadas (registrar gasto, dashboard, editar, trilingüe) corriendo solas contra QA cada noche + post-deploy — atrapa el bug ANTES de producción. Las fallas entran como issues normales al dashboard1–2 semanas
PR-8 · CONTIQSentry browser-side del portal + flow-test E2E (login→cartera→detalle→operación) — la superficie de dinero/compliance de 200+ contadores~1 semana
Mobile burn-downLimpiar las 236 violaciones de color hardcodeado → subir la regla de warn a error (bloquea CI)2–3 días mecánicos
Fase 3 · TrimestreMobile proposable en el registro + Maestro E2E (emulador en runner — infra Victor) + canary CONTIQ + primera receta determinista + foto-recibo en golden8–10 días

En simple

El robot que busca errores, los arregla, los prueba y los sube ya corre en producción con todo lo nuevo de hoy: ahora ve los errores "silenciosos" (los que no rompen nada pero dicen algo mal), gasta 6 veces menos en el juez de IA, tiene un freno de gasto de $17 por día, y cada peso queda anotado.

Nada llega a producción sin dos clicks humanos — de Carlos, Victor o Luz. Esta página es el mapa; el trabajo en vivo se ve en agents.zymplo.com/dashboard#autofix.

Los únicos pasos pendientes son humanos y están en la sección 5 — 30 minutos en total, y nada se rompe mientras tanto.