Skip to content

Executable acceptance criteria

An acceptance criterion in SDLC Studio is not just prose. It carries an executable Verify: line, and the Done gate runs it.

### AC1: dropping a unit removes it from the open batch
- **Given** an open run whose batch contains a unit
- **When** `sprint batch drop <id> --reason "..."` runs
- **Then** the unit leaves the batch and the change is recorded
- **Verify:** pytest tests/test_run_state.py::BatchMutationTests::test_drop_removes_unit
- **Verified:** yes (2026-07-26)

The Given/When/Then states the behaviour a human reads and edits. The Verify: line is what the machine runs.

A Verify: line names a check the tooling executes - a pytest/jest/vitest/go test, a shell command, an HTTP probe, a grep for a required string, and more. verify_ac run executes them and writes a report:

/sdlc-studio verify_ac run --id US0433
[APL] US0433: ac=3 pass=3 fail=0 manual=0 unspecified=0

A criterion can be manual when a human must observe the outcome - but the tooling names the manual ones honestly rather than counting them as proven.

transition -> Done is not a free edit. It reads the verify report, and a story whose executable criteria have not passed is refused. That closes the gap between “someone wrote Status: Done” and “the deliverable actually meets its criteria” - a hand-edited status walks round the tool, and conformance re-checks it as a backstop.

Because a test spec maps every criterion to a named test case, coverage is built in, not reverse-engineered at the end. The acceptance criteria are the oracle that closes the build loop: the agent builds until they pass, and the close proves they did.