Verify the increment

The agent reports the rung built. A report is not a closure. The increment is verified only when the human runs the Definition of Done and every check passes.

The workshop's last move is the one that makes the method honest. The Author has run the prompt in task order; it now says the rung is done. The Operator does not accept that — the Operator runs the spec's Definition of Done against the built code: compile clean, the node boots, GET /health is 200, a real courses_of/1 render plus an empty state, an injected %Portal.Error{} rendering 422 not 500, the endpoint self-healing, the invariant grep empty — and the liveness check beyond the suite. Toggle the figure on the right to watch the increment hold, or fail, against the seven DoD checks.

The Definition of Done Verified, not reported On the Portal References

The increment against the Definition of Done · toggle a check

All checks pass: the increment is verified — 7 of 7. Compile, boot, /health, the courses render and empty state, the 422 path, endpoint self-heal, and the invariant grep all pass. Done is a closure over checks, not a report.

The Definition of Done

An increment is done when its Definition of Done is satisfied — not when the agent says so. The DoD is the spec's acceptance checklist made runnable: each line is a check that is green or it is not, and the increment closes only when every line is green. The brief's verify task assembles them. For the Portal's web bootstrap, f6.1.llms.md states the verify step as task T7, and it reads, verbatim:

“Verify (T7 → R7, R8 + DoD). Confirm: mix compile is clean; the app boots; GET /health is 200; GET /courses/:user_id renders a known user's courses and an empty state for none or for an unknown/malformed id; the 422 render path is unit-verified via an injected %Portal.Error{}; killing PortalWeb.Endpoint restarts it (under PortalWeb.Application, :one_for_one) and a later request succeeds. Run grep -rE "Portal\.Engine|Repo|GenServer\.call" apps/portal_web/lib/ and confirm it is empty. Report each result against the F6.1 Definition of Done.”

Each of those is a check the Operator runs, not a sentence the Operator reads. The F6.1-AS4 Acceptance gate closes the same set — the endpoint restarts and a later request succeeds, an unknown id renders the empty state at 200, and the 422 render path is unit-verified via an injected %Portal.Error{} from the closed error set. Run the seven, and the increment is verified; skip them and trust the report, and nothing is.

The principle

Done is a closure over runnable checks. An increment is verified when every check in the Definition of Done is green — not when the implementer reports completion.

On the Portal

f6.1.llms.md's T7 names seven checks — compile, boot, /health, a real render and empty state, the 422 path, self-heal, and the empty invariant grep — each run against the built code.

This is the seam A6 inherits: A5 closes a built increment on its own acceptance, and A6 is the work that makes that increment survive production.

Verified, not reported

A self-report is the cheapest and least trustworthy signal in the workflow. The agent can run the prompt to the end and state the rung complete while a check it never exercised is red. The DoD exists so the Operator never has to trust the claim. There is one more reason the suite alone is not enough: under config/test.exs, mix test runs the endpoint server: false. The F6.7 brief states it plainly, verbatim:

“mix test runs server:false (config/test.exs), so a green suite does NOT prove the dev server boots.”

So the verification carries a check the test suite cannot: the liveness check. Boot the node and curl :4000/health returns 200, and the rung's live two-window update works. Toggle the meter below between trusting the agent's report and running the DoD plus the liveness check, over this real increment.

Verified or reported done · toggle the signal

Run the DoD: the increment is verified only when compile, /health, the 422 path, self-heal, the invariant grep, and the liveness check all pass — the report alone proves nothing.

A green suite is not a live Portal: mix test runs server: false, so the Operator boots the node and checks /health before the increment counts as done.

On the Portal

The Portal's web bootstrap closes on a real Definition of Done. The verify task runs the seven DoD checks against the built apps/portal_web code; the F6.7 liveness gate then boots the node, confirms curl :4000/health is 200, and runs the live two-window update. Together they turn the agent's “done” into a verified increment — or flag the rung that only looked done. A worked example mints a branded id with Portal.ID.generate/1 to exercise the render path; every other surface below is named as it appears in the brief.

# verify the increment — run each check; the increment is done only when all are green
#
# Definition of Done (f6.1.llms.md, T7):
  mix compile → clean
  app boots → tree order store → engine → endpoint
  GET /health → 200 "ok"   (no domain call)
  GET /courses/:user_id → a known user renders; an unknown id renders the empty state (200)
  injected %Portal.Error{} → 422, never 500
  kill PortalWeb.Endpoint → self-heals under :one_for_one; a later request succeeds
  grep -rE "Portal.Engine|Repo|GenServer.call" apps/portal_web/lib/ → empty
#
# liveness check (F6.7 — mix test runs server: false, so the suite cannot prove this):
  boot the node → curl :4000/health = 200; the live two-window update works

The principle

An increment is done when it is provably done, not when the agent says so. The reviewer reads the work against the spec's Definition of Done, never against the agent's self-report.

On the Portal

f6.1.llms.md's DoD and F6.7's liveness gate — the node boots, /health is 200, a live two-window update works — are the checks that turn a self-report into a verified increment.

The workshop ends where every increment should — on a Definition of Done that the human ran, not the agent reported.

Recap — the workshop closes on a verified increment

A5.8 ran the whole method on a real rung: brief it, run the agent, verify the output. The last move is the one that makes it a method and not a hope — the Operator runs the spec's Definition of Done against the built code, and adds the liveness check the suite cannot give, because mix test runs server: false. When compile, /health, the courses render and empty state, the 422 path, self-heal, the invariant grep, and the liveness check are all green, the increment is verified. The brief, written for an agent, has produced running code the human can prove correct — the chapter's claim, made good. The companion Phoenix lifecycle chapter is the rung whose Definition of Done closes this increment.

Next in A5: back to the workshop hub — the full A5 sequence, brief to verified increment, then on to A6 where reliability hardens what the workshop built.

References

Primary sources on verifying work against an explicit acceptance checklist rather than a self-report, and where the rung this dive closes and the companion engine course are defined.

Sources

Anthropic — Building effective agents — why an agent's run needs an explicit acceptance check the human verifies, not a completion claim the human accepts.
Hunt, A. & Thomas, D. — The Pragmatic Programmer — ruthless testing and design by contract: a thing is done when its checks pass, not when it is declared finished.
llmstxt.org — The /llms.txt convention — the machine-readable brief whose verify step lists the Definition-of-Done checks the increment closes on.

Related in this course

A5.8.2 · Run the agent — the run whose output this dive verifies.
A5.8 · Workshop — the full A5 sequence, brief to verified increment.
A5.6 · Running Claude agents well — review against the spec's Definition of Done, not the agent's self-report.
Companion · Functional Programming — the course that builds the engine the workshop briefs.
Companion · Phoenix (F6) — the real chapter whose f6.1.llms.md Definition of Done closes this increment.