Director–Implementer Loop R4.6-AG: fronteras semánticas para agentes y delivery sin ambigüedad

20 de septiembre de 2026

La Revisión 4 fijó quién decide. La Revisión 4.1 dio hogar al handoff y gate al humano. R4.3-AG afinó la operación agent-first. R4.4-AG eliminó dos formas de orquestación accidental: CI redundante al pasar a Ready y networking manual para validar lo renderizado.

R4.6-AG no inventa un loop nuevo. Hace explícitas fronteras que, en trabajo real con agentes, se mezclaban con demasiada facilidad:

development
≠ qualification
≠ integration
≠ delivery
≠ release
≠ closure

La forma corta de ownership sigue igual:

Implementer:
builds → validates → launches → shows → stops

Human:
reviews → accepts

Director:
audits → interprets → merges → verifies → closes

Lo que cambia es el vocabulario operativo. Cuando un agente no distingue «HEAD calificado» de «sigue desarrollando un poco más», o «CI despachada» de «CI aceptada», el fallo no suele ser de inteligencia: suele ser de semántica.

Por qué la terminología importa más en loops agénticos

En un equipo humano, mucha precisión vive en el contexto compartido. «Ready» puede significar cosas distintas según quién habla, y alguien corrige al vuelo.

Un agente no corrige al vuelo con el mismo criterio. Si el protocolo usa la misma palabra para:

• «el humano ya miró localhost»,
• «el Director ya audita»,
• «la CI del HEAD es verde»,
• «podemos mergear»,
• «podemos etiquetar un release»,

el agente tenderá a colapsar capas. La solución no es más automatización. Es nombrar con más cuidado.

Aquí conviene distinguir dos clases de vocabulario:

conceptos establecidos de software delivery
vs
vocabulario específico de DIL, elegido por precisión operativa

Deployment, release, integration o CI pertenecen al primer grupo. Workspace Identity, Implementer Delivery Pack, Acceptance Surface, READY como Mutation Boundary o Post-Audit Delivery Flow pertenecen al segundo: no pretenden ser estándares de industria; son contratos de este loop.

De dónde venimos

R4
ownership
↓
R4.1
GitHub handoff + localhost + human gate
↓
R4.2
REJECTED EXPERIMENT: automatic wake-up
↓
R4.3-AG
fresh context + CI without waiting + rendered validation + verifiable closure
↓
R4.4-AG
one feature CI per HEAD + canonical Playwright facade
↓
R4.5-AG-rc*
RETIRED EXPERIMENT: Vercel Preview + Neon branch-per-PR identity
↓
R4.6-AG
semantic execution boundaries + Delivery Pack + READY mutation boundary

R4.2 permanece rechazado. R4.5 permanece retirado. R4.6 avanza sin resucitar preview-provider identity ni convertir el loop en un orquestador que espera solo.

Workspace Identity

Antes de mutar, el Implementer debe saber dónde está trabajando:

Workspace Identity
=
repository root
+ remote
+ branch
+ HEAD

Suena obvio. Deja de serlo cuando existen checkouts hermanos, worktrees, clones con el mismo nombre de carpeta o un HO que habla de un repositorio mientras el agente tiene abierto otro.

Para este adapter, la ejecución local sigue siendo el modo por defecto. Un mismatch entre el HO target y la Workspace Identity activa es blocker. No se implementa «cerca» del sitio correcto.

Implementer Delivery Pack

R4.4 ya pedía Evidence Pack, Acceptance Checklist y localhost. R4.6 nombra el contrato completo:

Implementer Delivery Pack
├─ Evidence Pack
├─ Acceptance Checklist
├─ Acceptance Surface
│  └─ Local Preview when viable
└─ Implementer Harness Feedback

Evidence Pack vs Acceptance Checklist

El Evidence Pack es evidencia técnica exact-head, principalmente para el Director: SHA, diff, validaciones ejecutadas, estado de dispatch de CI, pruebas renderizadas.

No debe decir «CI pasó» sólo porque CI fue lanzada.

La Acceptance Checklist es para el humano. No resume el pipeline: dice qué mirar, por qué importa y qué se espera ver.

URL / COMMAND / SURFACE
WHY
CHANGE / PROOF
REVIEW
EXPECTED

Separar ambas piezas evita un error clásico: entregar un informe brillante al Director y dejar al humano sin instrucciones accionables — o al revés.

Implementer Harness Feedback

El Delivery Pack también puede reportar fricción real del entorno: tooling, discoverability, Serena/GitNexus, devx, workspace.

Ese feedback no amplía automáticamente el scope de producto. Se registra. El Director decide si vive en otra Issue.

Acceptance Surface y Local Preview

Acceptance Surface es la capa concreta e inspeccionable donde el humano valida el comportamiento afectado.

Local Preview es una realización local transitoria de esa superficie cuando es viable.

Ejemplos:

web/UI        → localhost
API           → endpoint local + request/response esperados
CLI           → comando reproducible + resultado esperado
data/DB       → superficie operatoria read-only o desechable
artifact      → artefacto generado + instrucciones de inspección

Localhost no desaparece. Para trabajo web/runtime, localhost READY sigue siendo el contrato preferido. Lo que desaparece es la presión de fingir que todo cambio es una página.

Si el cambio material tocó varias capas, el Delivery Pack debe exponer las superficies relevantes, no sólo la más fotogénica.

Human Acceptance sigue siendo un gate

El camino visible preferido es:

Implementer Delivery Pack
+ Acceptance Surface / Local Preview READY
↓
IMPLEMENTER STOP
↓
Human inspects Acceptance Checklist
↓
HUMAN_ACCEPTED

Estas capas no son sinónimos:

local validation
≠ Human Acceptance
≠ Director Audit
≠ CI Acceptance

Un agente puede tener tests verdes y seguir debiendo detenerse. Un humano puede aceptar localhost y el Director puede aún rechazar arquitectura o evidencia. Una CI verde no convierte sola un HEAD en candidato de integración.

CI DISPATCHED no es CI_ACCEPTED

R4.3 y R4.4 ya separaban hechos. R4.6 los deja escritos con el quinto término explícito:

expected CI
≠ CI DISPATCHED
≠ observed CI
≠ interpreted CI
≠ CI_ACCEPTED

El Implementer:

valida localmente
→ publica evidencia exact-head
→ confirma CI DISPATCHED una vez
→ no hace polling
→ prepara Acceptance Surface / Local Preview
→ STOP

El Director observa e interpreta la CI del HEAD aceptado. Confirmar dispatch no es cerrar el juicio sobre CI.

READY como Mutation Boundary

Esta es una de las piezas centrales de R4.6.

READY
=
exact feature HEAD authorized for integration

READY es un integration candidate. No es, por sí solo, un Release Candidate.

Inmediatamente antes, cuando aplique:

HUMAN_ACCEPTED
+ DIRECTOR_AUDITED
+ CI_ACCEPTED
+ expected HEAD unchanged

Después:

READY
════════════════════════════════
MUTATION BOUNDARY
DEVELOPMENT ENDS FOR THIS HEAD
════════════════════════════════

A partir de ahí no hay «ya que estamos»:

no functional mutation
no editorial mutation
no architecture mutation
no opportunistic changes

Sólo quedan operaciones de integration, delivery y closure.

La intuición es simple: si el HEAD puede seguir mutando, no estaba listo. Si estaba listo, no debería mutar.

Requalification

Cuando aparece un defecto material sobre un candidato ya calificado, el protocolo no improvisa un parche silencioso sobre la misma evidencia:

ABORT DELIVERY
↓
return to IMPLEMENTATION
↓
new HEAD
↓
proportional revalidation
↓
fresh Evidence Pack
↓
fresh CI
↓
renewed Human Acceptance where affected
↓
Director Audit
↓
CI_ACCEPTED
↓
READY again

Eso se llama requalification.

La evidencia exact-head de A no califica B. Un cambio visible o de comportamiento humano-aceptado exige nueva aceptación humana. Una corrección invisible y localizada puede conservar la aceptación previa sólo si el Director puede demostrar que la superficie aceptada no cambió; la evidencia técnica se renueva igual.

El dogfood real: v0.6.0 / PR #158

R4.6 no se promovió por elegancia documental. Se dogfoodeó sobre trabajo de producto:

PR #158
v0.6.0 — Canonical Bibliographic Resolution (Read-only)
main@52b1110…

Hubo implementación sustancial, CI exact-head, aceptación humana en localhost, superficies concretas de Control Center/API, validación Node/TS y Python, Ruff, Pyright, Astro check/build, y una frontera explícita de no escribir aún en Person/Work/Edition canónicos.

También hubo fricción útil: un defecto material apareció tarde. El cierre no se forzó. Se abortó la delivery, se produjo un nuevo HEAD, se renovó la calificación y sólo el HEAD final aceptado progresó a merge, CI de main, verificación en producción y cierre formal v0.6.0.

Esa secuencia es exactamente el valor de nombrar READY como frontera y requalification como reentrada, no como continuación disfrazada.

Post-Audit Delivery Flow

Después de READY, el desarrollo de ese HEAD ha terminado. Empieza el paraguas:

POST-AUDIT DELIVERY FLOW

1. Integration

READY → expected-head check → squash merge → main

El trabajo deja de ser sólo PR y pasa a la rama de integración.

2. Delivery Qualification

main → independent post-merge CI → identity/gates accepted

No lo llamamos genéricamente Release Qualification: no toda entrega a producción es un release versionado.

3. Production Delivery

qualified main → production deployment → verification → PROD_VERIFIED

4. Closure

optional tag/release → close product history → cleanup → local sync → CLEAN

Este adapter no importa la escalera IXATU Deploy DEV → Release Gate → Promote PROD. Usa su propio camino GitHub/Vercel/main.

Deployment vs release

Deployment = poner un estado de software en un entorno
Release    = declarar/versionar formalmente una versión de producto

Por tanto:

production deployment ≠ automatic tag / GitHub Release

A veces conviene etiquetar. A veces basta con haber desplegado y verificado. La proporcionalidad es deliberada.

Qué R4.6 deliberadamente no hace

R4.6 no introduce el Local Mechanical Gate aplazado. El Implementer sigue validando con tests/checks/builds locales; eso no sustituye al humano, al Director ni a CI.

R4.6 no resucita R4.5. Preview provider + Neon branch-per-PR como identidad de aceptación añadió más ambigüedad de la que resolvía para este adapter.

R4.6 no convierte terminología de proyecto en dogma universal. Distingue conceptos clásicos de delivery del vocabulario DIL.

Golden flow R4.6-AG

Director HO
↓
Implementer pre-flight
├─ Workspace Identity
├─ execution-mode sanity
└─ context freshness
↓
Implementation
↓
Local validation
↓
Self-review
↓
Draft PR + exact-head Evidence Pack
↓
CI DISPATCHED
↓
rendered / layer-specific validation
↓
Acceptance Surface / Local Preview READY
↓
Implementer Delivery Pack
↓
IMPLEMENTER STOP

════════════════════
HUMAN ACCEPTANCE
════════════════════

HUMAN_ACCEPTED
↓
Director exact-head audit
↓
observe / interpret feature CI
↓
CI_ACCEPTED
↓
READY  ← mutation boundary

POST-AUDIT DELIVERY FLOW
1. Integration
2. Delivery Qualification
3. Production Delivery
4. Closure

Cómo se promueve R4.6

Como en R4.4, la promoción no es un anuncio: es otra entrega gobernada por el propio protocolo.

R4.6-AG-rc1
↓
dogfood on v0.6.0 / PR #158
↓
requalification exercised for real
↓
promotion slice (this article + runbook/skill)
↓
Human Acceptance
↓
Director Audit + CI_ACCEPTED
↓
READY
↓
Post-Audit Delivery Flow
↓
R4.6-AG stable

Hasta completar ese recorrido, el candidato sigue siendo historia de dogfood. Después, R4.6-AG queda como CURRENT / APPROVED / DEFAULT, con R4.4 como predecesor estable y R4.5 como experimento retirado.

R4.6-AG en una frase

R4.4 enseñó a no revalidar el mismo HEAD sin motivo y a validar lo renderizado sin tutoriales de networking. R4.6 enseña a nombrar cuándo termina el desarrollo, qué debe entregar el Implementer al humano, cómo abortar y requalificar, y cómo separar integración, calificación de entrega, despliegue y release.

Menos ambigüedad semántica. Los mismos gates. El mismo ownership.