Appendix C. Applied SDD Checklists

This appendix can be used as a quick reference during the applied cycle. It builds on appendix C from the first volume: the basic checklists before specification, implementation, and merge are not duplicated there. The process templates (merge request, retrospective, minimum prompts for /clear and replanning) have been moved to [examples/templates/](examples/templates/): pr-template.md, retrospective.md, clear-prompt.md, replan-prompt.md.

Before starting the applied volume

• [ ] Read part 0 and select one training incident-case.
• [ ] Understand which commands in the chapters are marked as [runnable] and which are marked as [project script].
• [ ] Created or planned a capstone/ directory for the final package.
• [ ] From the first volume, understand requirements.md, plan.md, validation.md, QWEN.md, and the evidence package.
• [ ] Selected a reading mode: training minimum or full production track.

Before restoring a specification from a legacy system

• [ ] All sources are listed with an owner and a link.
• [ ] Event times are normalized.

• [ ] Requirements are separated from background context.
• [ ] Every statement has evidence or is marked as a hypothesis.
• [ ] Disputed points did not make it into the approved contract.

Before launching a poisoned specification

• [ ] Exactly one defect has been introduced.
• [ ] The expected failure symptom is described.
• [ ] A recovery criterion exists.
• [ ] The fix should change spec/plan/validation, not only the explanation.

Before enabling the specification gate (Spec CI)

• [ ] Requirements have stable REQ-* identifiers.
• [ ] Plan items reference the requirements.
• [ ] The scope check relies on the domain model or API contract.
• [ ] JSON examples from validation.md are validated by the schema.
• [ ] The CI error contains file, line, rule, reason, and action.

Before the file-based arbitration of a disputed change

• [ ] The Coordinator, Implementor, and Verifier roles are described in advance.
• [ ] The Verifier accepts only verifiable evidence.
• [ ] The dispute is resolved by file diffs, not by chat arguments.
• [ ] Repeated decisions are recorded in precedents.md.
• [ ] A stop condition for manual review exists.

Before optimizing production metrics

• [ ] The target metric is separated from the quality invariants.
• [ ] A red-button rule exists for the Goodhart scenario.
• [ ] The replay checks not only aggregates but also behavioral drift.
• [ ] The trace contains the decision source, policy version, prompt hash, or another reproducible identifier.
• [ ] A threshold change goes through as a risk change, not a cosmetic YAML edit.

Before auto-remediation

• [ ] The blast radius is known.
• [ ] A dry-run or a safe pre-check exists.
• [ ] The rollback condition is recorded before execution.
• [ ] Manual confirmation is triggered on uncertainty, repeated failure, or expansion of the blast radius.
• [ ] The incident is not closed until two independent confirmations of recovery are received, if the risk is high.

Before auditing the applied cycle antipatterns

A full breakdown of symptoms and causes is in part 12. Here are 12 questions as a quick checklist.

• [ ] constitution.md acts as a gate before execution, not only as a post-hoc review.
• [ ] In mutable_rules there are no rules without ttl or with ttl greater than 90 days.

• [ ] After a poisoned specification failure, at least one artifact is changed (requirements.md, plan.md, validation.md), not only the explanation.
• [ ] The Verifier uses a counterexample, a hook log, or JSON Schema — not free text.
• [ ] In governance_protocol there is a Safety veto and a deterministic tie-breaker.
• [ ] Runnable commands ([runnable]) are clearly separated from [project script] interfaces.
• [ ] Every target metric is paired with an anti-Goodhart metric.
• [ ] When CI fails, the code is fixed, not validation.md weakened.
• [ ] Switching between tiers has a budget ceiling and an emergency mode.
• [ ] Every entry in QWEN.md has an author, evidence, and ttl.
• [ ] manual_review_floor is preserved regardless of the KPI value.
• [ ] The evidence_ref field is filled in for every trace entry.

If three or more items are answered negatively — do not add new automation layers; first close the gaps in the current loop.

Before the final production exam

• [ ] capstone/README.md explains the case without relying on chat history.
• [ ] genealogy.md contains the requirement, sources, confidence level, and an open question.

• [ ] The poisoned/fixed pair contains one defect and one verifiable fix.
• [ ] validation.md references at least one actually runnable example or its project analogue.
• [ ] judgment.md contains a verdict, reason, evidence_ref, and the next step.
• [ ] The budget and anti-Goodhart layers have at least one blocking invariant each.
• [ ] The readiness output separates blockers from improvements.
• [ ] The diagnostic checklist from part 12 is passed; negative answers have an owner and a next check.