Responding to Review on a Stack

A discipline for acting on review comments that span several PRs in a dependent stack (A ← B ← C …). It owns review-fix placement and propagation; pr-history-hygiene owns linkage checks and landing, and code-review owns finding the issues.

The defining constraint: a fix lands on the PR that introduced the issue, then flows up-stack — never downstream, where the introducing PR ships the unfixed code and the fix is hidden from its reviewer.

Ground rules

• One worktree per PR branch. Each PR's fixes happen in that PR's own worktree; parallel fixes never share a checkout.
• The stack object is authoritative. Base branches establish the expected dependency order; the platform's stack metadata proves it is recognized. Do not treat a matching branch chain as an official stack without checking that metadata.
• A fix lands on the introducing PR, then flows up-stack. When a comment on PR B points at code B introduced, fix it on B and propagate into C — even if C also carries the file.
• Each review fix remains a distinct commit. A later rebase may change its OID, but do not amend a reviewed fix out of the branch history. Amend only your own not-yet-pushed, not-yet-reviewed work.
• Choose merge-forward or rebase deliberately. Both are allowed after review. A rewritten push must be lease-protected and must abort rather than overwrite a concurrently advanced remote head; raw force is forbidden.

Resolve comments through the stack