Zymplo · AutoFix — Plan consolidado
Un robot de reparación 24/7 ya existe y funciona — pero caza fallas técnicas, no errores semánticos. La estrategia converge desde dos análisis independientes (el tuyo y el de DevOps): no construir sistemas nuevos, sino activar y extender lo que ya hay, subiendo la autonomía por categoría de riesgo. Este documento es la base para consolidar tu propuesta con el estado real y decidir juntos los siguientes pasos.
1 · Dónde estamos hoy
develop. Cierra el gap de que el proposer in-bot no ve el código de zymplo-api. Inerte hasta el flip del flag.
judge.py)
Prendido en PROD OFF en QA
Es lo único que caza "confidently wrong". Ya corre en PROD (25 issues judge:* recientes). Falta prenderlo en QA + tunear sampling.
El pipeline del bot es el más maduro. crm-api / CONTIQ / mobile se enganchan a las etapas de detección; la generación de fix para crm-api es lo que suma la Fase 2a.
2 · Modelo de confianza
El principio (Google / Meta / Renovate / Sentry): subir la autonomía categoría por categoría de riesgo, nunca automatización total de una. Hoy estamos firmes en L1; L2 es el próximo escalón, y ya tenemos sus primitivos.
max_added_lines + blocked_prefixes (auth / payments / config). Eso ES el criterio de "low-risk". Falta la decisión de auto-merge por categoría + un gate duro de "L1 probado confiable primero" (métrica: % de draft PRs aceptados sin cambios).
3 · Roadmap consolidado
| Ítem | Origen | Estado | Esfuerzo |
|---|---|---|---|
| Activar color-literals + 42 tests mobile dormidosgates determinísticos en CI (no LLM) | Carlos | Hecho · #2808 | 0 h |
| Runner de propose en CI para crm-apigenera el diff donde vive la fuente del monorepo | DevOps | Merged · #2817 | ~1 día |
| Prender juez IA en QA + tunear sampling/confianzaya está ON en PROD; falta paridad + control de costo | Carlos DevOps | Corto plazo | ~1 día |
Validadores determinísticos de output (field-level)idioma por campo, monto presente, sin placeholders {{}}, no-duplicación |
Carlos DevOps | Fase 3 | 2–3 días |
| "Golden conversations" — flujos scripteados en crondetección PROACTIVA: caza el output-exitoso-pero-incorrecto | Carlos | Fase 3 | 1–2 sem |
| Visual regression para pantallas mobile | Carlos | Trimestre | 2–3 sem |
| Tests de flujo E2E de CONTIQ (login→wallet→operación)su gap real (no es CI ni alertas — ver §4) | Carlos DevOps | Trimestre | 1–2 sem |
| Graduar a L2: auto-merge de categorías low-risk | Carlos | Gate de decisión | Post-validación |
La Fase 3 (detección proactiva) es la modalidad que hoy falta: el autofix es reactivo (mira telemetría de fallas), así que el output entregado-pero-mal (recordatorio DAS sin monto, "OUTROS" en portugués, encuesta duplicada) es invisible. Golden conversations + validadores de output lo cubren.
4 · Estado que ajusta el roadmap
AUTOFIX_LLM_JUDGE_ENABLED=true y hay ~25 issues judge:* del 19–27 jul. → El ítem "activar el juez" ya está hecho en PROD; lo que queda es prenderlo en QA + tunear sampling.
CONTIQ Portal · Type-check + tests en ci-quick, y el autofix ya lo monitorea por Loki (9 issues component=contiq). Sentry no aplica: CONTIQ es backend, su telemetría es Loki. → Su gap real es el que vos marcás: tests de flujo E2E.
5 · Alcance
6 · Para consolidar — tu turno
Acá es donde entra tu ida-y-vuelta. Estas son las decisiones que necesitamos alinear para tener algo sólido:
ANTHROPIC_API_KEY (el proposer usa LLM y solo el CI tiene la fuente zymplo-api). ¿Reusamos la key del bot o creamos una workspace-key dedicada, atribuible/revocable aparte? Dependencia operativa para el go-live.Convergimos por caminos separados en el mismo diagnóstico (técnico vs. semántico, el juez, los "confidently wrong", los gates mecánicos). Sumando tus ideas (golden conversations, detector de idioma por campo, la escalera de autonomía) con lo que DevOps ya avanzó (propose-in-CI para crm-api), el plan queda mucho más completo. Ajustemos las 5 decisiones de arriba y arrancamos.