Appendix C. Applied SDD Checklists

This appendix can be used as a quick reference during the applied cycle. It builds on top of Appendix C of the first volume: basic checklists before specification, implementation, and merge are not duplicated there. Process templates (merge request, retrospective, minimal requests for /clear and replanning) are 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, selected one educational incident-case.
• [ ] It is clear which commands in chapters have [runnable] status and which are marked as [project script].
• [ ] Created or planned the capstone/ directory for the final package.
• [ ] From the first volume, requirements.md, plan.md, validation.md, QWEN.md, and the evidence package are understood.
• [ ] Reading mode selected: educational minimum or full production track.

Before restoring specification from a legacy system

• [ ] All sources are listed with owner and link.
• [ ] Event time is normalized.

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

Before running the poisoned specification

• [ ] Exactly one defect is introduced.
• [ ] Expected failure symptom is described.
• [ ] There is a recovery criterion.
• [ ] The fix must change spec/plan/validation, not just the explanation.

Before enabling the specification gateway (Spec CI)

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

Before file arbitration of a disputed change

• [ ] Coordinator, Implementor, and Verifier roles are described in advance.
• [ ] Verifier accepts only verifiable evidence.
• [ ] Dispute is resolved by differences (diff) in files, not arguments in chat.
• [ ] Repeated decisions go into precedents.md.
• [ ] There is a stop-condition for manual review.

Before optimizing production metrics

• [ ] Target metric is separated from quality invariants.
• [ ] There is a red-button rule for the Goodhart scenario.
• [ ] Replay checks not only aggregates but also behavioral drift.
• [ ] Trace contains source of decision, policy version, prompt hash, or other reproducible identifier.
• [ ] Threshold change passes as a risk change, not a cosmetic YAML fix.

Before auto-remediation

• [ ] Blast radius is known.
• [ ] There is a dry run or safe pre-check.
• [ ] Rollback condition is recorded before execution.
• [ ] Manual confirmation is included on uncertainty, repeated failure, or expanded blast radius.
• [ ] Incident is not closed until two independent recovery confirmations, if risk is high.

Before auditing applied cycle anti-patterns

Full breakdown of symptoms and causes is in Part 12. Here are 12 questions as a quick checklist.

• [ ] constitution.md acts as a gateway before execution, not just as post-review.
• [ ] There are no rules in mutable_rules without ttl or with ttl over 90 days.

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

If the answer is negative for three or more items — do not add new automation layers; first close the gaps in the current loop.

Before final production exam

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

• [ ] Poisoned/fixed pair contains one defect and one verifiable fix.
• [ ] validation.md references at least one actually run runnable example or its project analog.
• [ ] judgment.md contains verdict, reason, evidence_ref, and next step.
• [ ] Budget and anti-Goodhart layers have at least one blocking invariant each.
• [ ] Readiness output separates blockers from improvements.
• [ ] Diagnostic checklist from Part 12 is passed, negative answers have an owner and next checkpoint.