A proposal to evolve Akka Specify (and the Akka CLI) from prose requirements toward exit-condition-based, loop-engineered, self-governing spec-driven development.
You plan a feature, build it, then enter an edit + improve cycle — and the implementation quietly drifts away from the spec. Nobody notices at the moment it happens; you catch it later, by hand, re-reading spec and code side by side. Prose requirements can't detect their own violation, so drift is unbounded manual work.
Stop writing requirements as descriptions of desired output. Write them as exit conditions — binary, machine-checkable finish lines that define when the work is done and stays done.
A requirement is a hope. An exit condition is an evaluable predicate. Divergence stops being something a human catches and becomes a check that goes RED on its own.
The plan (the how) is then free to churn; the exit conditions (the what) are the contract. Refactor fearlessly — as long as the finish lines stay green, nothing drifted.
| Document | Audience | Start here if… |
|---|---|---|
akka-specify-product-brief.md |
Product / leadership | you want the plain-English 2-page summary |
akka-specify-exit-conditions-RFC.md |
Engineering / R&D | you want the detailed requirements, schema, examples, and tooling gaps |
- Exit Condition (EC) — a requirement rewritten as
signal+probe+ binarypass+autonomy+status. See RFC §3. - Collapse specify + clarify — the clarification is just the residue of ECs whose
passcan't yet be made binary. RFC §4.A. - Conform loop — one command runs every probe, updates every status; drift = a red EC;
implementloops until green. RFC §4.B–C. - Harness-agnostic, CLI-first — the durable assets (ECs, receipts) live in the repo and the Akka CLI, not inside one agent tool. RFC §4.E.
- Completion = derived rollup of EC status — no manual "done" checkbox; no bespoke plan-versioning. RFC §4.F.
- Receipts & telemetry — every run appends an immutable, provenance-stamped line; telemetry is a query over it. RFC §11.
- Meta ECs & the metaharness — the same discipline that verifies the product verifies the process (cost, coverage, flakiness, self-improvement guardrail). RFC §10.5, §11.
- Laurie Voss — "What the hell is a loop anyway?" (loop engineering: execution / task / product / system loops; "a loop without feedback is just a for-statement").
- Reuven Cohen — MetaHarness ("models are replaceable; harnesses compound"; run → measure → learn → mutate → verify → promote).
- ShipSmooth — continuous plan versioning and forced closure (what this proposal automates rather than requires humans to babysit).
Draft for R&D review. Nothing here is built yet; the RFC is explicit about what is net-new capability beyond Akka Specify today (RFC §11).