Specs as a first-class unit of agent work

A spec is bounded, reviewable, and auditable. A vibe-coded change is none of those. The unlock of M1 was treating every agent intervention as a spec with a lifecycle the agent can drive but cannot bypass.

When you tell an agent “fix the auth bug”, three things happen:

The agent guesses what “the auth bug” means.
It tries something.
You realize 40 minutes later it edited 18 files across 3 modules.

A spec breaks this loop. A spec is a bounded statement of what changes, what doesn’t, and what the success criterion is. The agent reads it, audits it, executes it — and you see the verdict at each transition.

The lifecycle

draft  →  audited  →  executing  →  done
                ↘            ↘
                  conditional   abandoned

draft — the spec exists. It came from fnd spec new, from a Linear/Jira/Asana ticket via fnd spec from-ticket, or from the agent itself via the spec.create MCP tool.
audited — the architect (your own Claude Code, with the foundry-ai MCP loaded) has read the spec, the master context, and the relevant memory, and emitted a verdict. pass auto-promotes from draft. fail or conditional keeps you in the loop.
executing — you (or the agent) is mid-work. The captured events of the session are linked to the spec.
done — the work landed. The verdict + reasoning + event chain are persisted with HMAC chain coverage, so the audit history is tamper-evident even if someone edits .fnd/echo directly with sqlcipher.

Why this matters

Vibe-coded changes have no audit trail. A spec-shaped change has all of it: the intent, the verdict, the events, the chain.

The bet of M1: if you make the spec the unit, the rest of the governance falls into place. No spec → no work. Done spec → reviewable artifact. That’s the whole shape of foundry-ai.