Paso 7: Cerrar y continuar
Paso 7: Cerrar y continuar
Objetivos
- Redactar un cierre completo y honesto.
- Distinguir una parada válida de una pausa injustificada.
- Aplicar la continuidad del trabajo autorizado.
- Transmitir un bloqueo a una persona sin perder opciones.
Qué contiene un cierre
El paso se resume en una instrucción: informar el resultado verificado, cada comprobación fallida, omitida o pendiente, y el siguiente paso. Todo cambio de código termina con su línea Risk.
Un cierre con la estructura esperada se ve así:
Agregué la exportación CSV con los filtros activos.
Comprobaciones:
- bun test src/reports: 42 pasan
- RED observado en "filtra por estado" antes del cambio
- Sin ejecutar: prueba end-to-end, requiere credenciales que no tengo
Risk: none
Siguiente paso: decidir si hago push de feat/csv-export.La tercera comprobación muestra lo que se busca: lo que no se ejecutó figura con su motivo.
Parar es la excepción
El proyecto dedica varias reglas a evitar que el agente se detenga por iniciativa propia.
flowchart TD
A["¿Puedo parar con trabajo pendiente?"] --> B{"Motivo"}
B -->|"El usuario lo ordenó explícitamente"| C["Parada válida"]
B -->|"Decisión de alcance o producto sin resolver"| D["Needs your decision"]
B -->|"Falta un consentimiento requerido"| D
B -->|"Acción denegada"| D
B -->|"Falta una prueba necesaria"| D
B -->|"El usuario dijo que quizá pare luego"| E["No es una parada:<br/>notas y commits separados"]
B -->|"Terminó una subtarea"| F["No es una parada:<br/>retomar el objetivo original"]Las paradas válidas
La sección de continuidad las enumera: una decisión de alcance o producto sin resolver con consecuencias, un consentimiento explícito requerido, una acción denegada, una prueba requerida no disponible, o la orden explícita de parar del usuario.
Y añade cómo se detiene: se informa un bloqueo concreto y la decisión exacta que se necesita. Pedir un “continúo” genérico no es una forma válida.
Una redacción tentativa no es una parada
Hedged wording is not a stop: a user saying they may stop you or resume later asks for notes and separate commits.
internal/components/agentguidance/routing.go
Una tarea registrada solo termina pendiente de dos maneras: con tu orden explícita de parar, o con un único resultado Needs your decision que nombre los bloqueos abiertos o la prueba faltante.
Cuando la prueba no alcanza
Una prueba parcial, bloqueada, no disponible o agotada se convierte en ese único resultado, nunca en más verificación. La fuente insiste: ese resultado es una parada válida, y no lo es la redacción ambigua.
Continuidad del trabajo autorizado
La cara opuesta de las paradas es esta sección:
An authorized outcome includes its necessary in-scope implementation, documentation and verification steps. Continue those steps without asking the human to approve each transition. Never end a turn merely announcing an immediately executable authorized next step; execute it instead.
internal/assets/skills/_shared/odd-orchestrator-sections.md
Consecuencias prácticas:
| Situación | Conducta esperada |
|---|---|
| ”Voy a ejecutar las pruebas ahora” al final de un turno | Ejecutarlas en lugar de anunciarlas |
| Se resolvió un incidente durante la tarea | Retomar el objetivo original sin volver a preguntar |
| Hay trabajo en segundo plano | Lanzarlo, terminar el turno si no queda nada independiente y retomar al recibir su finalización |
| Falta información técnica | Investigarla, sin convertirla en decisión humana |
| Una actualización de progreso | No es una solicitud de permiso |
Lo que la continuidad no autoriza
La misma sección marca el límite: no se infiere permiso para publicar, para acciones destructivas, para alcance no relacionado ni para el consentimiento nativo.
Los estados públicos
Estos cuatro nombres son el vocabulario hacia ti. El usuario no elige los detalles internos.
stateDiagram-v2
[*] --> Working
Working --> Checking: implementación normalizada
Checking --> Working: corrección acotada
Checking --> Ready: evidencia suficiente
Checking --> NeedsYourDecision: no converge de forma segura
NeedsYourDecision --> Working: decisión tomada
Ready --> [*]La verificación funcional y la verificación independiente se proyectan ambas como Checking. Un cambio verificado admite como máximo una corrección con alcance, y una segunda solo si la recomprobación muestra el mismo bloqueo fallando.
Comprobaciones al cerrar
Dos reglas del contrato de comprobación afectan al cierre:
- La normalización que modifica el código, como formateadores, generadores o fixers, ocurre antes de la verificación funcional.
- Después de verificar, solo pueden correr formato en modo de comprobación, chequeo de tipos y pruebas. Cualquier cambio de bytes, rutas o permisos obliga a volver a ejecutar las comprobaciones afectadas.
Además, durante la iteración corren las comprobaciones enfocadas, y al cierre de la tarea corren todas las aplicables.
El parent siempre hace una comprobación
En todos los niveles se mantiene la comprobación del parent: volver a ejecutar un comando informado antes de entregar. Un autoinforme no se toma como prueba.
Transmitir un bloqueo sin pérdida
Cuando un subagente o una herramienta devuelve un menú que bloquea, el orquestador debe presentarlo completo. La sección Lossless Blocking Prompts exige:
- Conservar por qué se requiere la entrada, cada grupo y pregunta en su orden, cada opción con su descripción, el modo de selección y el dominio exacto de respuestas.
- Nunca resumir, abreviar, reordenar, reetiquetar, combinar u omitir opciones.
- Si no hay interfaz nativa, emitir el menú completo como texto, con la sintaxis de respuesta, y detenerse.
- No elegir, asumir un valor por defecto ni lanzar trabajo dependiente mientras tanto.
- Aceptar una respuesta solo si pertenece al dominio exacto presentado.
Aunque un worker no debe pedirle a una persona que escriba rutas o comandos como texto libre, sí debe presentar un conjunto cerrado de opciones que se puedan aprobar o declinar.
Hablar menos
La sección de identidad indica que la síntesis es corta por defecto: decisión, resultado y siguiente acción. Solo se amplía si lo pides o la situación lo exige.
Actividad
Toma el último cierre que te dio un agente y compruébalo con esta lista: ¿menciona lo que no se ejecutó? ¿Tiene línea Risk? ¿Propone un siguiente paso que podría haber ejecutado él mismo dentro del alcance? Reescríbelo para que cumpla el formato de este capítulo.
Autoevaluación
-
El usuario dijo “quizá te detenga en un rato”. ¿Qué corresponde?
- A. Detenerse y esperar confirmación
- B. Cerrar la tarea como pendiente
- C. Dejar notas y commits separados, y seguir
- D. Preguntar cuándo piensa detenerlo
-
¿Qué ocurre cuando la prueba de un cambio no está disponible?
- A. Se reintenta hasta conseguirla
- B. Se marca la tarea como completa con una nota
- C. Se simula con una comprobación alternativa
- D. Se convierte en un único resultado Needs your decision
-
Terminaste de resolver un incidente de la herramienta a mitad de la tarea. ¿Qué sigue?
- A. Retomar los pasos seguros del objetivo original
- B. Pedir instrucciones para continuar
- C. Cerrar la tarea como bloqueada
- D. Reiniciar el protocolo desde cero
-
¿Qué se puede ejecutar después de la verificación funcional sin invalidarla?
- A. Un formateador que reescribe archivos
- B. Un generador de código
- C. Chequeo de tipos y formato en modo de comprobación
- D. Un fixer automático
Respuestas
- C. Una redacción tentativa no es una orden de parar.
- D. “Partial, blocked, unavailable, or exhausted proof becomes that one result.”
- A. Resolver un incidente no completa ni cancela el objetivo autorizado.
- C. Cualquier otro cambio de bytes obliga a repetir las comprobaciones afectadas.
Lista de control
- Mis cierres mencionan lo fallido, lo omitido y lo pendiente.
- Sé enumerar las paradas válidas.
- Ejecuto el siguiente paso autorizado en lugar de anunciarlo.
- Normalizo antes de verificar, no después.
Fuentes
internal/components/agentguidance/routing.go, internal/assets/skills/_shared/odd-orchestrator-sections.md, internal/assets/generic/orchestrator.md, internal/assets/opencode/agents/gentle-ai-worker.md, docs/trigger-rules.md.