Director–Implementer Loop R4.3-AG: CI sin espera, contexto fresco y cierre verificable
La Revisión 4 fijó la propiedad del trabajo: el Implementer construye y aporta evidencia; el Director observa, interpreta, decide y cierra. La Revisión 4.1 convirtió esa separación en un protocolo cotidiano: el handoff vive en GitHub, localhost sirve como gate humano y el Implementer sabe cuándo detenerse.
R4.1 funcionó. R4.3-AG no nace para corregir un fracaso, sino para incorporar lo que aprendimos al repetir el loop en repositorios, plataformas y agentes distintos. El resultado es una evolución agent-first: contexto fresco antes de tocar el código, CI lanzada sin espera, un runtime visual que ya no se redescubre en cada tarea, historia de producto separada del diff y un cierre que llega hasta producción verificada.
La forma corta sigue siendo la misma:
Implementer:
builds → validates → launches → shows → stops
Human:
reviews → accepts
Director:
audits → interprets → merges → verifies → closesLos verbos nuevos afinan la ejecución. No cambian quién decide.
Por qué R4.3-AG y no R4.2
La numeración conserva una historia deliberada. R4.2 fue el experimento de despertar automáticamente al Director mediante Tasks, webhooks o agentes dedicados a vigilar CI. La idea parecía ahorrar una intervención pequeña, pero añadió opacidad, nuevos puntos de fallo y consumo de agentes para hacer polling.
El experimento se rechazó. Borrar ese número o reutilizarlo haría desaparecer un aprendizaje útil:
no toda automatización que elimina un gesto humano mejora el sistema.
Por eso R4.2 permanece como REJECTED EXPERIMENT. R4.3-AG avanza desde R4.1 por otro camino: mejora el trabajo del agente sin reactivar el wake-up automático ni convertir la observación de CI en una flota de watchers.
La genealogía queda así:
R4
ownership
↓
R4.1
GitHub handoff + localhost + human gate
↓
R4.2
rejected automatic wake-up experiment
↓
R4.3-AG
agent-first operational refinementEl sufijo AG identifica ese foco agent-first dentro de jesuserro.com. No intenta sincronizar la numeración con otros proyectos.
CI sin espera
R4 ya distinguía la CI esperada de la CI observada. En la práctica faltaba un estado intermedio: confirmar que el pipeline realmente arrancó.
R4.3-AG lo llama CI DISPATCHED.
expected CI
≠ CI DISPATCHED
≠ observed CI
≠ interpreted CICada concepto responde a una pregunta distinta:
| Estado | Pregunta | Propietario |
|---|---|---|
| expected CI | ¿Qué gates debería activar este diff? | Implementer |
| CI DISPATCHED | ¿GitHub ha lanzado el pipeline? | Implementer, una comprobación |
| observed CI | ¿Qué resultados y logs produjo? | Director |
| interpreted CI | ¿Qué significan y qué hacemos ahora? | Director |
CI DISPATCHED no significa CI superada. Significa únicamente que la entrega ya está en manos del sistema remoto.
Esta precisión permite que el Implementer detecte un error obvio —por ejemplo, una PR que no lanzó ningún workflow— sin volver al patrón caro:
checking CI...
waiting...
checking again...Una comprobación razonable basta. Después, el agente continúa con la validación renderizada, prepara localhost y entrega. El Director observará e interpretará los resultados cuando entre en su turno.
La distinción parece pequeña, pero elimina una ambigüedad real: launch CI ≠ wait for CI.
Contexto fresco antes de implementar
Un agente no trabaja sólo con archivos. Trabaja también con una representación mental —o indexada— del repositorio: módulos, relaciones, rutas, tests, decisiones y nombres del dominio. Esa representación envejece.
R4.3-AG incorpora un gesto normal de pre-flight en el adapter personal:
devx gitnexus analyzeEl comando refresca el grafo de contexto antes de la implementación. No demuestra que el cambio sea correcto ni sustituye leer las fuentes relevantes. Su papel es más humilde y más útil: reducir decisiones basadas en una topología caducada.
La frontera de autoridad queda explícita:
Git / tests / DB / runtime = evidence authority
GitNexus = context/navigation supportSi GitNexus afirma que una relación existe pero el código actual, los tests o el runtime dicen otra cosa, manda la evidencia actual. Context freshness mejora la navegación; no crea una nueva fuente de verdad.
También importa la forma de operar la herramienta. Se usa el comando personal canónico, no una implementación interna descubierta por casualidad. Y sólo se ejecutan comandos de recovery cuando existe una condición diagnosticada. La familiaridad con una herramienta no justifica tocar todos sus botones.
Reutilizar el runtime visual canónico
La misma disciplina se aplica al navegador. Una tarea con superficie visual no debería empezar instalando Chromium, descargando otro Playwright o inventando un wrapper porque el agente no recordó el existente.
En este entorno ya existe un runtime canónico:
playwright-ui-validation
+
playwright-dockerLa skill define qué comprobar. El wrapper Docker aporta un navegador reproducible sin contaminar WSL. Juntos convierten la validación visual en una capacidad del entorno, no en una improvisación de cada PR.
El principio general es sencillo:
reutiliza infraestructura funcional antes de instalar o redescubrir herramientas.
No se trata de prohibir alternativas para siempre. Si el runtime canónico falla de verdad, se diagnostica. Mientras funciona, crear devx playwright por simetría o instalar otro browser sólo multiplica estados posibles.
Backend success no equivale a rendered success
Una build verde demuestra que Astro pudo producir archivos. Un 200 OK demuestra que un servidor respondió. Ninguna de esas señales prueba por sí sola que el lector vea la página correcta.
Una superficie renderizada puede fallar de maneras que el backend no detecta:
- el título esperado no aparece;
- la portada se rompe o se recorta mal;
- un bloque de código desborda en móvil;
- la tarjeta no entra en el índice
/blog/; - el enlace histórico apunta a una ruta inexistente;
- la página carga, pero su contenido está vacío.
Por eso R4.3-AG exige validar la página real cuando hay UI:
backend success
≠ rendered-surface successLa comprobación busca señales visibles y concretas: el título, la portada, la estructura, los enlaces y la aparición del artículo en el índice. Una captura sirve como evidencia; no reemplaza las aserciones, pero deja una fotografía útil para el Director y para el gate humano.
Issue, PR y ADR cuentan historias distintas
Un diff explica cómo cambió el repositorio. No siempre explica por qué existía el problema, qué se probó antes o cuándo puede considerarse cerrada la evolución.
R4.3-AG formaliza tres superficies:
Issue = WHY / product history
PR = HOW / implementation audit trail
ADR = durable architectural decisionLa Issue conserva el problema, los aprendizajes y la evolución. La PR contiene implementación, diff, validación, Evidence Pack, CI y aceptación. El ADR se reserva para una decisión arquitectónica duradera; no hace falta escribir uno para cada cambio con contexto.
En trabajo significativo, la PR usa:
Refs #NNo Closes #N. La implementación no cierra por sí sola la historia de producto. El Director cierra la Issue después de comprobar:
implemented
+ merged
+ deployed
+ verifiedAsí, una Issue abierta después del commit no representa trabajo olvidado. Representa honestidad sobre el estado real.
Core + Environment Adapter
El Director–Implementer Loop necesita principios comunes y adaptadores concretos. Si mezcla ambos niveles, una decisión útil de un proyecto puede convertirse en una receta equivocada en otro.
DIL Core
El Core conserva la secuencia independiente de plataforma:
HO
→ implementation
→ local validation
→ Draft PR
→ handoff
→ CI dispatch
→ preview
→ STOP
→ human acceptance
→ Director audit
→ CI interpretation
→ expected-head merge
→ deployment verification
→ closureAdapter jesuserro.com
Aquí ese Core se expresa con piezas concretas:
GitHub
Vercel
localhost
WSL
devx
GitNexus
playwright-dockerEl cierre de producción sigue el comportamiento real del sitio:
merge
→ post-merge CI
→ Vercel production deployment
→ production verificationOtro entorno puede tener registros, promociones o plataformas distintas. Copiar literalmente Deploy DEV → Promote PROD a un proyecto que no opera así no hace el Core más reusable; sólo oculta la realidad detrás de vocabulario ajeno.
La separación permite conservar lo importante —ownership, evidencia, aceptación, expected-head y cierre— mientras cada adapter usa sus herramientas reales.
El estado del trabajo debe poder nombrarse
R4.3-AG no introduce un state manager. Introduce un vocabulario para no confundir momentos distintos:
PLANNED
↓
IMPLEMENTING
↓
LOCAL_VALIDATED
↓
PR_DRAFT
↓
CI_DISPATCHED
↓
PREVIEW_READY
↓
IMPLEMENTER_STOP
↓
HUMAN_ACCEPTED
↓
DIRECTOR_AUDITED
↓
CI_ACCEPTED
↓
READY
↓
MERGED
↓
PROD_DEPLOYED
↓
PROD_VERIFIED
↓
CLOSED
↓
CLEANNo todos los cambios necesitan una máquina que persista cada transición. Sí necesitan un lenguaje que impida afirmar demasiado pronto que algo está «terminado».
implementation complete
≠ human accepted
≠ mergeable
≠ merged
≠ deployed
≠ production verified
≠ closedEsta lista también aclara los límites del Implementer. Su turno termina en IMPLEMENTER_STOP, después de entregar evidencia, confirmar dispatch y dejar el preview listo. El producto todavía no está cerrado; ahora empieza el trabajo del humano y del Director.
Cierre verificable
En muchos flujos, el verbo «terminar» se usa para momentos incompatibles: hice commit, abrí PR, mergeé o vi el deployment. R4.3-AG reserva el cierre para una cadena completa.
El Director entra con un head_sha exacto. Audita ese HEAD, respeta la aceptación humana, observa e interpreta CI, enruta fallos y sólo entonces marca Ready. El merge usa expected-head: una auditoría de A no autoriza B.
Después del merge todavía quedan hechos que comprobar:
post-merge CI
↓
Vercel production deployment
↓
production verification
↓
product-history closure
↓
remote cleanup
↓
single local/WSL syncUna tag o release sólo aparece cuando añade valor real. No se crea por ritual. La Issue de historia se cierra cuando producción está verificada. La rama remota y el workspace se limpian al final, no antes de perder una referencia necesaria.
El objetivo no es alargar ceremonias. Es evitar que el sistema llame «cerrado» a algo cuyo estado todavía depende de una suposición.
El HO declara también cómo se ejecutará
Hasta ahora un HO podía explicar perfectamente el trabajo y dejar implícita una decisión importante: qué agente debía ejecutarlo y con qué configuración.
R4.3-AG hace explícita esa decisión mediante una cabecera mínima al inicio de cada HO:
Agente: Codex
Modelo: Sol
Modo: build
Esfuerzo: highCuatro ejes:
- Agente → quién implementa.
- Modelo → qué capacidad concreta se selecciona.
- Modo →
planobuild. - Esfuerzo →
low,mediumohigh.
No todas las tareas necesitan el mismo implementador ni la misma profundidad. Un cambio pequeño y determinista como incorporar esta misma regla puede delegarse a Big Pickle con esfuerzo low. Una refactorización arquitectónica pertenece a un agente con mayor capacidad de navegación y razonamiento.
El catálogo de modelos evoluciona sin necesidad de versionar el protocolo. Lo que importa es que la selección sea explícita.
El primer dogfooding de R4.3-AG
Este artículo y el protocolo que describe se entregaron usando R4.3-AG.
Antes de escribir, el Implementer protegió el workspace, comprobó la base y ejecutó devx gitnexus analyze. La evolución recibió una Issue de producto propia. El runbook y la skill se actualizaron sin cambiar el schema v1 del handoff. La portada reutilizó la convención visual de la serie. El contenido pasó schema, checks, build y una validación real mediante playwright-docker.
Después del push, el Implementer confirmó CI DISPATCHED una sola vez, publicó un Evidence Pack ligado al HEAD, dejó localhost disponible y se detuvo. El humano conserva el gate visual. El Director conserva CI, Ready, merge, Vercel, producción, cierre de la Issue y limpieza.
Durante el proceso surgió esta misma mejora. El Director la detectó como delta, seleccionó Big Pickle con modo build y esfuerzo low para implementarla. La demostración es el propio delta:
task complexity → implementer selection → explicit execution profileDogfooding no significa que el protocolo se autoapruebe. Significa que se somete a sus propias fronteras:
el protocolo construye su entrega
pero no se concede su propia aceptaciónR4.3-AG en una frase
R4 separó responsabilidades. R4.1 dio al handoff un hogar y al humano un gate útil. R4.3-AG hace que los agentes lleguen con contexto fresco, lancen CI sin quedarse esperando, usen el runtime visual existente y no confundan una implementación completa con un producto cerrado.
El loop resultante no busca automatizar cada gesto. Busca que cada gesto tenga propietario, evidencia y un final verificable.