Step 06 — Sign-off: the §9 verdict
← 05 Check · Index · next: 07 Publish & Act →
Beat: Check, completed by the human. Touch point #2. The bundle is
AWAITING_SIGNOFF; you've cleared §6 (step 05); now you record the
verdict in §9. This single decision is the only thing standing between a built fix
and a shipped one — by design, no model can make it.
The four dispositions
pdca signoff <id> --accept # the fix is good → COMPLETE, ready to publish
pdca signoff <id> --iterate-do # right spec, wrong build → rebuild against same brief
pdca signoff <id> --iterate-plan # the spec itself was wrong → re-author the brief
pdca signoff <id> --discontinue # this doesn't belong in the cycle → abandon
Each maps to a state transition the driver applies the instant you record it:
| Disposition | §9 outcome | New state | What the driver does |
|---|---|---|---|
--accept |
merged-wider |
COMPLETE |
Freezes the bundle; publish can run |
--iterate-do |
iterated-to-Do |
→ PLANNED |
Archives Do+Check into iteration-v<N>/, keeps the brief, re-runs the builder |
--iterate-plan |
iterated-to-Plan |
→ UNPLANNED |
Archives the whole attempt incl. brief, you re-spec |
--discontinue |
discontinued |
DISCONTINUED |
Records §9, no transition, drops from the pending set |
--accept is guarded (the C6 rule from step 05): it's refused
while any §6 item is unchecked. The other three are not — you can redirect or
abandon a bundle with §6 still open. Add --by "Name" to set attribution and
--delta "…" to record the rationale on an iterate.
--discontinueis the disposition this harness version (v0.18.0) unified — the action, thediscontinued§9 outcome, and the terminalDISCONTINUEDstate now all share one word. Use it for work that, on inspection, doesn't fit the cycle (handled out-of-band, duplicate, won't-fix) — a deliberate abandon, independent of §6.
The simple case — accept
For issue 11589 (steps 03–05), the gates proved correctness and the
four §6 items were all cleared, so the maintainer accepted. The real
results/issue_11589/SUMMARY.md §9:
## 9. Check sign-off ← human completes Check here
- Disposition confirmed / overridden:
- Outcome: merged-wider
- Iteration delta (if iterating):
- By / date: Eduard Ralph / 2026-06-06
Outcome: merged-wider ⇒ state COMPLETE. The bundle is frozen and ready for
publish (step 07).
The instructive case — iterate, with a real reason
Acceptance is the boring path. The cycle earns its keep on iteration — when
the human catches something the gates can't. gramps issue 46 (a GraphView
import-safety fix) took two iterations before it was accepted. The brief's
own carry-forward records why the first attempt was rejected — this is a real
--iterate-do rationale, verbatim:
## Iteration 1 — carry-forward (from the previous attempt)
- Sign-off rationale: Reject: the regression test reimplements GTK load/version-
pinning (test_graphview_import.py:80-82, top-level `import gi` +
gi.require_version("Gtk","3.0")). GTK loading/pinning is already owned by gramps
at runtime and by PR 950 in unit testing, so this machinery must not be in the
addon test — it is redundant and is the likely cause of the two T3 addon-unit
exit-2 collection aborts. Rebuild the test without any manual gi/Gtk pinning;
keep the production change (removal of the two import-time raises) as-is.
Re-run T3 addon-unit and E2E ...
What happened mechanically:
- Iteration 1 built a fix whose production change was correct but whose
test carried redundant GTK-pinning machinery. The C4 gate went green (the fix
worked), but the human noticed the test introduced two new
[delta]failures in the T3 addon-unit matrix — a regression the test itself caused. - The maintainer ran
pdca signoff 46 --iterate-do --delta "rebuild the test without the gi pin; keep the production change". The driver archived the attempt intoiteration-v1/, reverted toPLANNED, and re-ran the builder — which got the rejection rationale folded into the brief (above), so it didn't repeat the mistake. - Iteration 2 rebuilt the test without the pin. Accepted:
## 9. Check sign-off
- Outcome: merged-wider
- Iteration delta (if iterating): [iteration 2 — rebuilt test without gi pin]
- By / date: Eduard Ralph / 2026-06-13
The lesson this case teaches about the harness: the deterministic C4 gate said
"correct," and it was right — but "correct fix" is not "good contribution." A
test that pins GTK is correct and redundant and regression-inducing; only the
human reading the §6/§7/review material caught it. The harness didn't prevent the
mistake — it surfaced it cheaply (the [delta] rows), gave the human a clean
"reject with reason" lever (--iterate-do --delta), and carried the reason
forward so the rebuild started smarter. That carry-forward loop is the "Plan
with a better baseline" arrow of PDCA, operating inside a single contribution.
State after accept: COMPLETE. On to publish and the cross-cycle Act review —
step 07.
← 05 Check · Index · next: 07 Publish & Act →