responding-to-review-on-a-stack

name	responding-to-review-on-a-stack
status	beta
description	Respond to code review across a dependent PR stack — fix on the PR that introduced the issue, propagate the fix up-stack, keep each review fix a distinct commit, lease-protect any rewrite, and re-audit threads, approvals, and checks after every rewrite. Use when review comments span several stacked PRs.

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

1. Triage every comment on the merits before acting: verify the claim against the code — a reviewer flagging the right symptom can still misdiagnose the cause.
2. Map each accepted finding to its originating PR and fix it there.
3. Propagate the fixed layer through every affected child in order — merge-forward (merge the fixed parent into the child, validate, continue upward) or a native cascading rebase (validate the rewritten layers, then publish).
4. Trust but verify delegated fixes — a sub-agent's report describes intent, not necessarily what landed. Re-run the gates on the actual tree; prove a regression guard fails on the unfixed code.
5. Reply in the review thread, not as a top-level comment, stating the fix and the current commit or head that carries it.
6. After any rewritten push, re-read unresolved threads, approvals, mergeability, and checks. A force-pushed OID or outdated inline anchor is not current evidence that the finding remains resolved.

Workflow

1. Ground — one worktree per PR; confirm the stack object, not just the branch chain.
2. Triage — verify each comment on the merits; accept or rebut.
3. Fix at origin — land each accepted fix on the introducing PR, as a distinct commit.
4. Propagate — move the fixed layer up-stack via merge-forward or a validated cascading rebase.
5. Verify — re-run gates on every affected PR; re-audit threads, approvals, and checks after any rewrite.
6. Reply — state the fix and its commit in the review thread.

Completion criteria

• Every fixed PR's current diff contains the intended correction at the layer that introduced the issue.
• The stack is recognized by the platform and each child's diff against its parent shows only that child's changes.
• Unresolved threads, approvals, mergeability, and checks were re-audited after every rewritten push.
• The relevant gates pass on every affected PR, not just the top.