DNA / Spec-Driven Development
Spec-Driven Development
Specs are contracts, not suggestions.
Spec-driven development treats every task as a formal contract between intent and execution. todo.json is not a to-do list — it is an executable specification. Each item has acceptance criteria, verification steps, and proof-of-done.
Key Principles
- 01todo.json as executable spec: structured JSON with acceptance criteria, not free-form text
- 02Verification before deploy: every feature has a verification document before production
- 03Proof-of-done: handoff docs contain evidence that specs were met, not just "done" checkboxes
- 04Specs compound: a well-written spec from today becomes a regression test tomorrow
Real Examples from Production
WorkFlow/todo.json
The program office backlog. Each task: id, priority, description, acceptance criteria, current_focus flag. Agents pick tasks by reading this file — no ambiguity.
WorkFlow/todo.json →
agent-os verification
Before each phase completes, a verification checklist confirms: tests pass, endpoints respond, HITL gate triggers correctly. Not "looks good" — measurable.
agent-os/docs/checklists/ →
ZZPackage GUARD_01-04
Four hard guardrails enforced before any deploy: product schema valid, price logic intact, wizard flow unbroken, no unauthorized endpoints. Spec-as-guardrail.
zzpackage.flexgrafik.nl/ →
Traditional vs AI Systems Architect
Traditional Developer
"Build a login form." Agent builds something. Developer reviews vaguely. Ships. Bug found in production.AI Systems Architect
"Build login form. Acceptance: JWT returned on valid creds. Error message on invalid. Rate limit 5/min. Verified by e2e_smoke.py." Agent delivers. Spec verified. Shipped.