ACD – Agent-Centric Delivery

ACD is the delivery model aof work implements: work is broken into items that an agent team can take from an idea to an accepted, verified change without a human in every loop, and every claim the process makes is written down where a check can read it. It runs entirely in the repository – Markdown records under wiki/work/, .feature files as the contract, no service, no database.

The model

A milestone groups stories; a story groups tasks. Each is a self-contained folder with a record document and a frontmatter status. Three lighter item types sit beside them: a chore (housekeeping with a ticked checklist as its deliverable), a spike (an investigation whose deliverable is a recorded finding), and a uat session (a cross-milestone human acceptance gate).

wiki/work/125_story_the-loop-graph-gets-a-published-face/
  STORY.md            # the user story, the contract's reads:/files: declaration, status
  PLAN.md             # the build brief – advisory, never the contract
  tasks/00_….feature  # the acceptance criteria: Gherkin scenarios, one file per task
  VERIFICATION.md     # evidence, findings, sign-off, the accept decision
  RETROSPECTIVE.md    # what building it taught
  OUTCOME.md          # what the system now is, stated as product state

The story is the unit of independence: its boundary follows real coupling so stories build in parallel, and a depends: graph orders what cannot. aof work next walks that graph.

The contract is a `.feature`

A task’s acceptance criteria are Gherkin scenarios. Every scenario carries exactly one verification tag, and the tag decides who proves it:

tag	proven by
`@executable`	an automated test, green in the suite
`@manual`	an agent running a procedure and recording the evidence
`@uat`	a human, at accept – the only point a person is pulled in

The litmus: a scenario states observable behaviour, never implementation or visual fidelity. A Then that reads like a design assertion is flagged; design is judged from a rendered screenshot against DESIGN.md, not asserted in a feature. A delivered .feature is never edited – a new rule lands in a new item’s contract.

The lifecycle

Three commands carry an item through, and each is a slash command in Claude Code (/aof:refine, /aof:continue, /aof:verify) or a Codex skill:

Refine – a milestone is broken into independent stories; a story’s tasks are authored by the Three Amigos: the product owner writes the scenarios, QA the example tables, the developer the feasibility check. Architecture decisions land as numbered ADRs with fitness functions (FF-NN) – tests that make a structural rule fail when it is broken. Design and research records appear only when the item needs them.
Continue – the developer builds each task to green against the locked contract, then a structural review (architect) and a behavioural review (QA) run and their findings are fixed in the same round. The item ends in-review.
Verify – the @executable suite and fitness functions run; @manual procedures are run and recorded; a human is brought in for @uat alone. Findings are triaged as blocker or not, the validate gate must pass, and aof work status <ref> done accepts. At the same moment the retrospective is written, OUTCOME.md states what is now true, and both are ingested into memory for the next item’s refine.

Statuses move not-started → in-progress → in-review → done (or blocked), and only the status verb moves them – the transition is checked against the lifecycle, stamped, and published to the board.

The team

The commands spawn a team of scoped subagents: aof-product-owner, aof-architect, aof-developer, aof-qa, aof-designer, aof-researcher, and the conditional aof-security and aof-compliance. Each can read and write only what its role owns; the record documents are authored by the governing session, never by a subagent.

The gates

aof work validate – the stream is well-formed: every item’s record, contract, tags and depends: edges resolve. Refuses to accept a red stream.
aof work doctor – health: unresolved controls, over-budget documents, register duplicates, drift between a record and its folder.
aof work regression-gate <NN> – a milestone is accepted only after the whole suite ran on a clean checkout and the run is recorded; story-scoped greens are never enough.
The drift checks – a generated document (the loop graph, a changelog) is regenerated by a test and compared byte for byte, so it cannot outlive what it describes.

The loops

Since milestone 53 the lifecycle runs as declared control loops – build-to-green, review → fix → re-review, verify → triage → accept, the autonomous cascade – each a registry record naming its reference, measurement, actuator, cadence and ceiling. aof work loop <ref|NN-MM> drives an item or a range through them in code, with the gates, retries and stop conditions enforced by the shell rather than by prompt discipline. The loop graph is that registry, rendered.

Starting

aof work init --runtime claude   # render the commands, agents and templates into the repo
aof work validate                # the stream is well-formed
aof work next                    # the next item the depends graph allows

Then /aof:add-milestone, /aof:refine, /aof:continue, /aof:verify – or aof work loop for the whole run.