Stacked & Multi-base PRs

Stacked (dependent) PRs

A child PR builds on a parent PR's branch. Update the stack bottom-up:

1. Update the parent branch/PR first.
2. Rebase the child onto the updated parent — not onto the default branch, and never "merge main into the leaf" as the only step.
3. Push each level; keep each PR's base pointing at the one below it.

Multi-base (release + default)

Some orgs require the same change on the default branch AND a release/production branch:

1. Confirm the required target branches from the repo's rules.
2. Land the change once, then cherry-pick/port the identical code to the other base as a second PR.
3. Keep the two PRs' code identical; note the sibling in each description.
4. Treat the duplicate as a fresh review target. Request the original developer reviewer/team and use the repo's pending human/code-review labels. Do not copy QA approval or claim a developer checkmark from the sibling; the release PR needs its own explicit developer approval. Verify assignees, review requests, and labels after updating them.

Estimate an integration before changing branches

• Fetch the real upstream default branch and every dependency head; compare ancestry so already-included fixes are not imported twice.
• Use git merge-tree --write-tree --name-only <base> <head> to estimate conflicts without modifying a checkout or index. Report conflict counts as textual integration scope, not proof that auto-merged code is correct.
• Preserve current upstream security and profile-routing behavior when reconciling older UI work; do not resolve whole files with ours/theirs just to eliminate markers.
• Distinguish updating the local clone from publishing a fork-default update. A PR in a separate repository still compares against that repository's base; local upstream freshness does not update it.

MR additive-repair safeguards

• Invoke the pinned Node executable directly for worktree tests and set NODE_PATH to that worktree's mr_modules on the command. Shared dependency symlinks and concurrent shells can otherwise resolve another checkout; verify process.execPath and require.resolve('MRUtils') first.
• Check the merge commit's effective diff against its own base, not only HEAD. Lint-staged sees upstream files staged by a merge and can rewrite unrelated code; run targeted lint/tests and use a per-invocation hook override for the additive merge commit rather than changing repository hook configuration.
• Reconcile CMS migration composition with already-merged migrations in both execution orders. Preserve foreign-edit/staged-batch refusal and verify published records before retiring an old route; saved redirect flags alone do not establish that a redirect reached production.

Don't

• Collapse a stack by merging the default branch into the child.
• Let the two base PRs drift apart.
• Finish without listing every PR/MR in the stack as a link.