Orquestrador de Aceptación

¿Qué hace Orquestrador de Aceptación?

Descripción General

Orquesta el trabajo de codificación como una máquina de estados que termina solo cuando los criterios de aceptación se verifican con evidencia o la tarea se escala explícitamente.

Regla central: no optimices para "código modificado"; optimiza para "DoD probada".

Cuándo Usarlo

• La tarea ya tiene un issue o criterios de aceptación claros y debe ejecutarse de punta a punta con mínima reintervención humana.
• Necesitas una transferencia estructurada entre implementación, revisión, despliegue y verificación final.
• Quieres condiciones de parada explícitas y escalamiento en lugar de una finalización parcial silenciosa.

Sub-habilidades Requeridas

• create-issue-gate
• closed-loop-delivery
• verification-before-completion

Habilidades de apoyo opcionales:

• deploy-dev
• pr-watch
• pr-review-autopilot
• git-ship

Entradas

Se requieren estas entradas:

• id del issue o cuerpo del issue
• estado del issue
• criterios de aceptación (DoD)
• entorno objetivo (dev por defecto)

Valores predeterminados fijos:

• rondas de iteración máximas = 2
• sondeo de revisión de PR = 3m -> 6m -> 10m

Máquina de Estados

• intake
• issue-gated
• executing
• review-loop
• deploy-verify
• accepted
• escalated

Flujo de Trabajo

1. Ingesta

   • Lee el issue y extrae el objetivo de la tarea + DoD.

2. Compuerta del issue

   • Usa la lógica de create-issue-gate.
   • Si el issue no está ready o la compuerta de ejecución no está allowed, detente de inmediato.
   • No implementes nada mientras el issue permanezca como draft.

3. Ejecutar

   • Entrega a closed-loop-delivery para implementación y verificación local.

4. Bucle de revisión

   • Si los comentarios del PR son relevantes, agrupa las ventanas de sondeo como:
     • esperar 3m
     • luego 6m
     • luego 10m
   • Después de la ronda de 10m, deja de esperar y procesa todos los comentarios visibles juntos.

5. Despliegue y verificación en tiempo de ejecución

   • Si el DoD depende del comportamiento en tiempo de ejecución, despliega solo en dev por defecto.
   • Verifica con registros/API/comportamiento de Lambda reales, no con suposiciones.

6. Compuerta de finalización

   • Antes de cualquier afirmación de finalización, requiere verification-before-completion.
   • Sin afirmación de éxito sin evidencia fresca.

Condiciones de Parada

Pasa a accepted solo cuando cada criterio de aceptación tiene evidencia coincidente.

Pasa a escalated cuando ocurre cualquiera de estas situaciones:

• El DoD sigue fallando después de 2 rondas completas
• faltan secretos/permisos/dependencias externas que bloquean el progreso
• la tarea necesita una acción en producción o aprobación de operación destructiva
• las instrucciones de revisión entran en conflicto y no pueden cumplirse ambas

Compuertas Humanas

Detente siempre para confirmación humana en:

• despliegues a prod/stage más allá del alcance acordado
• operaciones destructivas de git/datos
• cambios en la facturación o postura de seguridad
• criterios de aceptación faltantes proporcionados por el usuario

Contrato de Salida

Al informar el estado, incluye siempre:

• Estado: intake / executing / accepted / escalated
• Criterios de Aceptación: lista de verificación pasa/falla
• Evidencia: comandos, registros, resultados de API o prueba en tiempo de ejecución
• Riesgos Abiertos: cualquier cosa aún incierta
• Necesita Entrada Humana: la decisión más pequeña siguiente, si está bloqueado

No informes "terminado" a menos que el estado sea accepted.

Limitaciones

• Usa esta habilidad solo cuando la tarea coincida claramente con el alcance descrito anteriormente.
• No trates la salida como un sustituto de la validación, pruebas o revisión de expertos específicos del entorno.
• Detente y pide aclaración si faltan entradas requeridas, permisos, límites de seguridad o criterios de éxito.