Appendix A: Checklists

These checklists compress the operating method. They are short on purpose. Add a project-specific line only when a real failure in your project earns it.

Before implementation

• Reproduce the current behavior against the real binary or artifact.
• Record the revision, environment, input, command, and observed result.
• State the one semantic decision that could invalidate the work.
• Name the canonical state.
• State how the system treats malformed, unsupported, or partial input.
• Identify compatibility, migration, and rollback boundaries.
• Name the invariant that will prove success.
• Separate unrelated judgment calls into other branches.

Design review

• Can a declared path be unreachable?
• Can a resumed path differ from an uninterrupted one?
• Can data disappear while the UI still looks plausible?
• Can malformed input be silently coerced?
• Can two modes agree semantically but differ in bytes?
• Does the proof share logic with the implementation?
• Does the change rely on a fact outside this repository?
• Can the change be reversed without unrelated damage?
• Is the design more complex than the contract requires?

Regression proof

• The new test fails on the old implementation.
• The failure occurs at the expected assertion.
• A deliberate tamper or mutation is detected.
• Every semantically relevant field is compared.
• Lazy work is forced before measurement.
• The test uses an independent oracle where practical.
• The targeted test and surrounding suite both pass on the fix.

Review triage

• Each finding cites code or a contract.
• Each finding supplies a concrete exposing input or state.
• Accepted findings receive a repair and proof.
• Rejected findings receive a technical reason.
• Deferred findings identify the missing evidence or scope.
• High-value false positives are recorded when likely to recur.

Integration

• The branch is refreshed against current main.
• Targeted and full checks pass on the refreshed branch.
• One coherent change is merged.
• The full suite passes on the new integrated tree.
• Regenerated artifacts contain real changes, not encoding noise.
• A whole-codebase migration merges alone, not inside an unrelated parallel batch.

Release

• Documentation and examples match the accepted behavior.
• Every surface that restates the behavior is current: site, editor integration, embedded agent instructions, migration notes.
• The whole required CI graph concluded green, not only the release workflow.
• Expected release assets exist and open.
• The install path delivers the intended version.
• The live surface serves the intended version.
• Issue and pull-request state match what shipped.
• Artifacts described as generated are regenerated or validated by the current build.

After the work

• Record the reusable bug class, not only the local fix.
• Add or revise a standing rule only when the failure justifies it.
• Record guardrail friction that needs a mechanism fix.
• State any remaining uncertainty.
• Remove temporary process notes that no longer define behavior.