Spec-Dev — gobernanza de ejecución

Generalización del spec-dev de Aiva (evaluado con evals de skill-creator). La premisa: la planeación es el código fuente real — la ejecución la hacen modelos; el valor humano está en dirigir y revisar. El riesgo #1 es la deriva de contexto, no la velocidad.

Fase 0 — Contexto obligatorio (anti-deriva)

Antes de planear, leer en orden:

1. El spec de la tarea (docs/specs/). Sin spec aprobado → DETENERSE y decirlo; ofrecer redactar el borrador para aprobación — no implementar sobre supuestos.
2. DECISIONS_LOG.md — al menos las áreas que la tarea toca. Las CERRADAS son vinculantes: no contradecirlas ni "mejorarlas"; reportar el conflicto y detenerse.
3. Specs de datos/contratos vinculantes si la tarea toca datos.
4. Verificar el estado real del código con Grep/Glob — la realidad manda sobre los docs.

Para trabajo de módulo entero: usar la skill module-audit.

Fase 1 — Planeación atómica

La hace el agente principal. Produce:

• Tareas atómicas de ≤2 h con criterio de aceptación verificable por tarea.
• Clasificación por la escalera: mecánica→Haiku, estándar→Sonnet, crítica (dinero, stock, auth, webhooks, seguridad de IA)→agente principal, no se delega.
• Orden y dependencias (qué va en paralelo).
• Si el spec resulta incompleto o ambiguo: preguntar ANTES de ejecutar.

Fase 2 — Ejecución

Cada tarea delegada lleva prompt autocontenido (plantilla codex-prompt): contexto, Localiza/Reemplazar, RESTRICCIONES, VERIFICACIÓN, commit. Protocolo de error: 3 intentos → escalar al humano. Registrar telemetría al cerrar cada tarea.

Fase 3 — Cierre

Gate de verificación completo (typecheck + greps + comportamiento + tests), checklist de PR del spec, actualización de documentación y memoria. Spec obsoleto → banner ⚠️ OBSOLETO (fecha) — No usar para codear, nunca borrar.