responding-to-review-on-a-stacklisted

# 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](./pr-history-hygiene.md) owns linkage checks and landing, and [code-review](./code-review.md) 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