Specs como unidad de trabajo del agente

Un spec es acotado, revisable y auditable. Un cambio vibe-coded no es ninguna de las tres. El gran avance de M1 fue tratar cada intervención del agente como un spec con un ciclo de vida que el agente maneja pero no puede saltearse.

Cuando le decís a un agente “arreglá el bug de auth”, pasan tres cosas:

El agente adivina qué significa “el bug de auth”.
Prueba algo.
40 minutos después te das cuenta de que editó 18 archivos en 3 módulos.

Un spec rompe ese bucle. Un spec es una declaración acotada de qué cambia, qué no, y cuál es el criterio de éxito. El agente lo lee, lo audita, lo ejecuta — y vos ves el veredicto en cada transición.

El ciclo de vida

draft  →  audited  →  executing  →  done
                ↘            ↘
                  conditional   abandoned

draft — el spec existe. Vino de fnd spec new, de un ticket de Linear/Jira/Asana vía fnd spec from-ticket, o del propio agente vía el tool MCP spec.create.
audited — el arquitecto (tu propio Claude Code, con el MCP de foundry-ai cargado) leyó el spec, el master context y la memoria relevante, y emitió un veredicto. pass lo promueve automáticamente desde draft. fail o conditional te mantienen en el loop.
executing — vos (o el agente) está en plena ejecución. Los eventos capturados de la sesión quedan ligados al spec.
done — el trabajo aterrizó. El veredicto + el razonamiento + la cadena de eventos quedan persistidos bajo cobertura HMAC, así el historial de auditoría es tamper-evident incluso si alguien edita .fnd/echo directo con sqlcipher.

Por qué importa

Los cambios vibe-coded no dejan rastro de auditoría. Un cambio con forma de spec deja todo: la intención, el veredicto, los eventos, la cadena.

La apuesta de M1: si hacés del spec la unidad, el resto de la gobernanza cae en su lugar. Sin spec → no hay trabajo. Spec done → artefacto revisable. Esa es toda la forma de foundry-ai.