Transiciones de Estado Automáticas

Las specs de Planu avanzan a través de un ciclo de vida gestionado por una máquina de estados. Llamar a update_status con un estado objetivo activa la transición y dispara automáticamente una cascada de acciones de autopilot — sin pasos manuales requeridos.

La Máquina de Estados

         ┌─────────┐
         │  draft  │
         └────┬────┘
              │ update_status(review)
              ▼
         ┌─────────┐
         │ review  │◄──── request_changes
         └────┬────┘
              │ approve_spec / update_status(approved)
              ▼
         ┌──────────┐
         │ approved │
         └────┬─────┘
              │ update_status(implementing)
              ▼
       ┌─────────────┐
       │implementing │
       └──────┬──────┘
              │ update_status(done)
              ▼
          ┌──────┐
          │ done │
          └──────┘

Cualquier etapa → blocked (update_status(blocked))
blocked → etapa anterior (update_status(review), etc.)

blocked es un meta-estado

blocked no resetea el progreso. Cuando el bloqueo se resuelve, vuelve a la etapa activa correspondiente.

Qué se Activa en Cada Transición

Transición	Disparador	Acciones de autopilot
`draft → review`	`update_status(review)`	Validar completitud de criterios, ejecutar `check_readiness`, marcar GIVEN/WHEN/THEN faltantes
`review → approved`	`update_status(approved)` o `approve_spec`	Capturar versión de spec, bloquear spec (`lock_spec`), notificar al equipo
`approved → implementing`	`update_status(implementing)`	Generar scaffold `PLAN.md`, sugerir stubs TDD vía `tdd_scaffold`
`implementing → done`	`update_status(done)`	Ejecutar `validate` contra criterios, generar entrada de changelog, ejecutar `health_check_all`, escanear riesgos de crash
`any → blocked`	`update_status(blocked)`	Registrar razón del bloqueo, pausar cascada de autopilot

Usando update_status

Invoca update_status con el ID de la spec y el estado objetivo:

bash

# Mover una spec a review
update_status("SPEC-659", "review")

# Aprobar después de completar la revisión
update_status("SPEC-659", "approved")

# Iniciar implementación — se activa el scaffold
update_status("SPEC-659", "implementing")

# Marcar como done — se activa la cascada validate + changelog
update_status("SPEC-659", "done")

La herramienta devuelve un resumen de qué acciones de cascada se ejecutaron y sus resultados. Si alguna acción de cascada encuentra un bloqueo o necesita aclaración, devuelve un InteractiveQuestion[] para que el LLM lo transmita.

Acciones Fire-and-forget vs. Bloqueantes

Acción	Comportamiento
`validate`	Asíncrona — se ejecuta en segundo plano, resultado adjuntado al historial de la spec
`generate_changelog`	Asíncrona — se ejecuta cuando validate tiene éxito
`health_check_all`	Asíncrona — independiente de validate
`check_readiness`	Bloqueante — la transición a `approved` está condicionada a una verificación de readiness exitosa
`lock_spec`	Bloqueante — debe tener éxito antes de que se escriba `approved`

Bloqueante vs. approved

Si check_readiness devuelve 0 criterios que pasan, update_status(approved) devolverá un InteractiveQuestion[] preguntando si deseas aprobar una spec incompleta.

Ver también

Preguntas Interactivas — cómo las transiciones bloqueantes solicitan aclaraciones
Formato Lean de Spec — el campo status del frontmatter que impulsa esta máquina
spec.md Unificado (SPEC-630) — donde viven los criterios de aceptación que validate comprueba

Transiciones de Estado Automáticas ​

La Máquina de Estados ​

Qué se Activa en Cada Transición ​

Usando update_status ​