merge_pr.py: --why gives a false negative for a GitHub-native stack member nf-mzx4 ← Beads

open priority 2 task unassigned

--why (explain() in tools/pr/merge_pr.py) was never made stack-aware — only merge() was, when nf-oqmx wired merge_pr.py onto GitHub-native stacks (#1206). Run against a stack member, explain() still applies the single-PR base != "main" refusal, so it reports "would merge on <authority>... but base=<parent-branch> — merge its parent first" for a PR that merge() will actually land cleanly seconds later via merge_stack().

Confirmed live in nf-oqmx's own rehearsal (bd comments nf-oqmx, 2026-08-21): ./tools/pr/merge_pr.py --why 1209 (a real 2-layer native-stack top PR, converged, approval:auto) said "merge its parent first"; `./tools/pr/merge_pr.py 1209` landed both layers cleanly moments later.

--why exists so a session learns what will stop a merge BEFORE it spends minutes on a presubmit build (its whole documented purpose) — a false negative there sends a session down the WRONG remedy (go merge the parent PR, which for a native stack means nothing: there is no separate merge to run, merge_pr.py on the top lands the whole landing set in one call).

Shape of the fix (not prescribed further — this is a discovery, not a design): explain() needs the same gh.pr_stack(number) dispatch merge() got, to either report the landing set's own gates or at minimum skip the single-PR base != "main" refusal for a stack member.

Dependencies

None.

Comments

No comments.

Add a comment