Stability checkpoint

QA and dev are peers — dev keeps committing while QA tests. Findings filed against a moving codebase are stale before they are read, and they waste the Scrum Master's routing on defects that no longer exist.

QA holds one authority no other peer has: it declares when a checkpoint is needed. That is not authority over what dev builds; it is authority over when a snapshot exists.

Protocol

1. QA requests a checkpoint. Sent to the Scrum Master, naming what it needs stable — a feature, a subsystem, or the whole tree.
2. Dev finishes its current work order. Not its current thought — the whole work order, to a green state. Dev does not abandon partial work to satisfy a checkpoint; half-applied changes are worse to test than a moving target.
3. Dev tags it. An annotated tag, e.g. checkpoint/2026-08-14-conflicts, pushed with its branch. The tag is the contract: it is what QA tests and what findings will reference.
4. Dev continues on a branch. No waiting. This is the whole reason the protocol exists — a freeze that stops dev converts peers into a pipeline.
5. QA tests the TAG, not the branch tip, not the worktree. Every finding cites the tag plus file:line. A finding without a tag cannot be reproduced later and will be argued about instead of fixed.
6. Findings return to the Scrum Master via delivery. QA states which findings it considers stop-ship and why. The Scrum Master decides, not QA — and must be genuinely willing to halt a release on QA's word, or QA is decorative and everyone will learn that within two cycles.

Rework

When dev fixes a finding, it fixes against current HEAD, not the tag. QA re-verifies at the next checkpoint. Do not re-tag per fix — that recreates the freeze this protocol exists to avoid.

Cadence

One checkpoint per work order is usually right. More than that and QA is effectively serializing dev. Fewer, and findings arrive too late to be cheap.