[CI][Smart CI] Planner resolves CONTROL_BASE to main's tip, so every stacked PR fails the gate with planner-error

[Chris0Jeky]

What

The Smart CI planner resolves a pull request's control base to main's tip rather than to the PR's actual base branch, so any PR stacked on another PR's branch fails the gate with a planner-error that is not a defect in the PR under test.

Live instance: PR #2531 (base issue-1898/port-release-deadline, i.e. open PR #2522), run 33843172977, job 100929506193.

❌ planner-error — Error: pull-request planning requires merge SHA and tree SHA from the same fetched merge ref
❌ trust-mismatch — plan says T3, the event re-derives T1

Root cause

.github/workflows/smart-ci-shadow.yml:53 sets CONTROL_BASE: ${{ github.sha }}. The job env for that run shows:

CONTROL_BASE: ca6fe42fe2f2228241d9480d1d9d36087fe1b27e

which is main's tip at 06:07:19Z, not #2531's base issue-1898/port-release-deadline @ d8d53002. Verified:

git merge-base --is-ancestor ca6fe42f d8d53002   -> NO
git merge-base --is-ancestor ca6fe42f origin/main -> YES

The merge ref is built against the real base, so it can never reconcile with an expectedBase taken from the default branch. This is not staleness from a retarget: #2531 was created directly against the stacked base at 06:08:46Z with no base_ref_changed event.

trust-mismatch (plan says T3, the event re-derives T1) is a second, separate defect in the same run, not a consequence of the first.

Why #2506 does not close this

#2506 ("accept a merge ref regenerated against the live protected base tip") targets the same error string — git grep 'requires merge SHA and tree SHA' finds it only at scripts/ci/smart-ci/plan.mjs:59 — and adds a --base-ref "$BASE_REF" path driven by github.event.pull_request.base.ref. For #2531 that would resolve the right SHA and plausibly clear the planner-error. But:

1. The stacked case is entirely untested. gh pr diff 2506 | grep "baseRef: '" returns exactly three hits, all 'main' or ''.
2. The receipt would tell a false story. It would read "the base advanced from ca6fe42 to d8d5300" — the base did not advance; it is a different branch. A receipt is evidence, so a wrong narrative in it is its own problem.
3. It does nothing about trust-mismatch.

So #2506 should not be described as fixing #2531's red.

Suggested work

• Resolve the control base from github.event.pull_request.base.sha / base.ref rather than github.sha for pull_request/pull_request_target events.
• Add a planner test whose baseRef is a non-default branch.
• Distinguish "base branch is not the default branch" from "base advanced" in the receipt vocabulary.
• Triage trust-mismatch separately.

Impact and non-impact

Advisory only today: smart-ci-shadow.yml runs in observation mode and branch protection requires only the three security contexts (Dependency Security, SAST Scan, Secret Scan), so this reddens no merge. It matters for CI-03 #2327, which registers Smart CI / Required Gate as required after ≥20 PRs without a false red — a false red on every stacked PR both corrupts that observation window and would become a hard block once registered.

All of ci-required is green on #2531; only this advisory gate is red.

Refs #2324, #2327, #2506

[Chris0Jeky]

An unpublished branch already carries the primitive this needs

Found while auditing branch hygiene: origin/issue-2326/smart-ci-recall-report (tip 3b291914a, last commit 2026-08-30) has never had a PR opened and is not an ancestor of main, but it already contains the fix shape recommended above.

Its smart-ci-shadow.yml diff sets:

EXPECTED_BASE: ${{ github.event.pull_request.base.sha }}

which is precisely the substitution this issue asks for — resolving the control base from the pull request's own base rather than from github.sha. Its three commits are Add fail-closed Smart CI recall report, Bind Smart CI plans to fetched merge refs, and Validate Smart CI recall context, across .github/workflows/smart-ci-shadow.yml, docs/ci/SMART_CI.md, scripts/ci/smart-ci/plan.mjs, plan.test.mjs, recall-report.mjs, recall-report.test.mjs.

How it relates to #2506

The two overlap on three files — .github/workflows/smart-ci-shadow.yml, docs/ci/SMART_CI.md, scripts/ci/smart-ci/plan.test.mjs — but they take different routes to the same class of problem:

• ci(smart-ci): accept a merge ref regenerated against the live protected base tip #2506 (open) adds a --base-ref "$BASE_REF" path inside resolve-merge-ref.mjs, accepting a regenerated merge ref as merge-ref-moved. Its tests only ever pass baseRef: 'main', so the stacked case is untested, and for a stacked PR its receipt would claim "the base advanced", which is a false narrative.
• The parked branch changes what the expected base is at the workflow level, which addresses the stacked case at its root rather than tolerating the mismatch downstream.

These are not duplicates, and the parked approach is the better primitive for the defect in this issue. Whoever picks this up should read that branch before writing anything new — and reconcile with #2506 rather than landing a third overlapping change to the same three files.

Do not lose it

Recorded here because the branch has no PR and no issue reference pointing at it, so it is invisible to anyone reading #2326 or #2327. Whatever is decided, decide it explicitly — do not delete origin/issue-2326/smart-ci-recall-report before either landing its content or recording that it was superseded.

Refs #2326, #2327, #2506

[Chris0Jeky]

Live reproduction on main today (2026-09-06) — and it is not limited to stacked PRs

PR #2753 is not stacked. Its gate still failed the moment main's tip moved under it.

Sequence, same head SHA d01fc0ec1 throughout:

time (UTC)	event	Smart CI / Required Gate
19:03	run against base at the time	success
19:31	PR #2761 merged, main tip → 77c27b47e	—
19:34	ready_for_review re-trigger, CONTROL_BASE: 77c27b47e	failure

- ❌ `planner-error` — Error: pull-request planning requires merge SHA and tree SHA from the same fetched merge ref
- ℹ️ error-plan trust is pinned to T3; the event would classify T1
- ℹ️ escalated: planner-error

It does not self-heal. Three re-runs failed: gh run rerun --failed, a full gh run rerun (so Smart CI / Plan re-derived from scratch, and Plan itself succeeded each time), and a third attempt.

The workaround that does work: merging origin/main into the branch regenerates the merge ref. That is required anyway once the base moves, so it costs nothing extra here — but it does mean every open PR needs a touch after every merge to main if this gate ever becomes required.

Two things worth folding into this issue's scope:

• The title says "every stacked PR", but the trigger is narrower and broader at once: it is any PR whose merge ref predates the current base tip, stacked or not. Every merge into main puts every open PR in that state simultaneously.
• #2506 (accept a merge ref regenerated against the live protected base tip) is merged and did not prevent this, so either its acceptance path does not cover this shape or the merge-SHA/tree-SHA consistency guard rejects the case before that path is reached. I have not read the planner source to say which — reporting the reproduction, not the diagnosis.

Recorded against SC-4 on #2327: this is a false red by smart-ci-shadow.yml's own definition ("a red gate means a planner/plan defect ... never a product verdict"), and it falsifies the "zero false reds" observation figure I posted earlier today. SC-4's precondition is not met.

#2508 (record mergeBaseSha on the plan receipt) is directly relevant and this is a concrete argument for it.