观察单:`Resolve the diff base` 是 Check Changeset 里唯一只认快路径标签读取的可失败步骤,标签晚到 + git 基准不可用时会红一个本该豁免的 PR

[hotlong]

由 #6378 / PR #6429 的实现过程中记录,未在该 PR 内修复(超出本单范围),按 Prime Directive #10 单独立观察单。

现象

pr-automation.yml 的 changeset-check job 里,能让 PR 变红的步骤共五个。PR #6429 之后,其中四个同时认两次活标签读取(快路径读取 + 结算读):

• Require a changeset (or the skip-changeset label)
• Reject an empty-frontmatter changeset added by this PR
• Require an ADR-0087 disposition on a declared-breaking changeset
• Guard against accidental major bumps (launch window)

第五个 —— Resolve the diff base (merge base with the base branch) —— 只带 steps.labels.outputs.skip != 'true' 这一条快路径守卫,而它自己有两处 exit 1:

• 事件不带 base 分支;
• git merge-base 算不出来(例如 origin/BASE_REF 取不到)。

后果(复合条件,今天没人撞得到)

要踩到需要同时成立两件事:

1. skip-changeset 标签晚于快路径读取才落地(即 Check Changeset 的首跑对 skip-changeset 路线结构性必红:job 在 PR 打开瞬间读标签,而标签只能在创建之后打上(今日实测复现 21 次) #6378 的那个窗口内 —— 这恰恰是常态),并且
2. 该跑的 git 基准解析真的失败。

此时 Resolve the diff base 会在结算读有机会纠正之前就把 job 判红,而这个 PR 本该是豁免的。条件 2 极少发生(需要 fetch 失败一类的基础设施抖动),所以今天没有已知实例,归观察类。

这是有意留下的,不是遗漏

PR #6429 在正文的「不在本 PR 里」一节写明了该格,理由是:它的 exit 1 表达的是「git 基准不可用」,不是 changeset 判决,本就不受标签豁免;#6378 的范围是消除结构性假红,顺手扩大一个豁免面不在其内。该 PR 新增的 CONSUMER 断言按「跑 check-*.mjs 或发出 no-changeset 错误」来圈定判定步骤,有意把这一步排除在外,以免断言把一个没论证过的豁免钉成契约。

候选处置(未预设结论)

1. 维持现状,只补注释说明该格是有意的(最省,今天也确实没人撞到)。
2. 把结算读前移到 Resolve the diff base 之前。代价:结算读能白拿的已流逝时间从「约 +45s」降到「约 +20s」(checkout 之前),窗口内需要真等的概率上升 —— 而 fix(ci): Check Changeset 的 skip-changeset 判定加一次「结算读」，首跑不再结构性必红 (#6378) #6429 的成本论证正建立在「等待只向将红的 PR 收取」上,前移会让计数尚未发生、无法判断该 PR 是否将红,等待面因此扩大到所有无标签的 PR。这一条与 Check Changeset 的首跑对 skip-changeset 路线结构性必红:job 在 PR 打开瞬间读标签,而标签只能在创建之后打上(今日实测复现 21 次) #6378 的成本结论直接冲突,需要重新测量再决定。
3. 让 Resolve the diff base 的失败先落成一个 output,由后面已认两次读取的判定步骤统一裁决。

倾向 1 或 3;⛔ 选 2 之前必须重测,否则会把 #6378 刚消掉的成本以另一种形式加回来。

未认领,交分诊定级。

[claude]

Findings triage — verdict: HOLD (finding retained, domain:devx unchanged).

Why still held: the trigger needs two independent conditions at once — the skip-changeset label landing after the fast-path read (common, and precisely #6378's window) and the git base resolution genuinely failing (fetch-level infrastructure flake). Only the second is rare, and there is no known instance. The gap is also documented as intentional in PR #6429's body, with a reason that stands on its own: the step's exit 1 says "the git base is unavailable", which is not a changeset verdict and was never in scope for the label exemption.

Why not promoted: the routes do not separate on cost, they separate on missing evidence.

• Route 1 (comment the intent) is nearly free but buys only clarity, and the intent is already recorded in the PR body — promoting a card to move a sentence is not worth a claim cycle on its own.
• Route 2 is the one that matters and is blocked on measurement: moving the settlement read ahead of Resolve the diff base shrinks the free elapsed time from ~+45s to ~+20s and, worse, extends the wait to every unlabelled PR because the count has not happened yet — which contradicts Check Changeset 的首跑对 skip-changeset 路线结构性必红:job 在 PR 打开瞬间读标签,而标签只能在创建之后打上(今日实测复现 21 次) #6378's cost conclusion that waiting is charged only to PRs that are going to go red. The body is right that this needs re-measuring before it can be chosen; that is a reason to wait for a motivating instance, not to spend a measurement on a zero-instance edge.
• Route 3 (fail into an output, adjudicated by a step that already does both reads) is the structurally clean answer and stays the recommendation, but it is unmotivated at zero instances.

Restart condition: promote on the first observed red Resolve the diff base on a PR carrying skip-changeset — that instance is what prices route 3 against route 1 and supplies the failure signature. Promote earlier if pr-automation.yml is restructured for another reason, since route 3 then becomes a rider on work already in flight rather than a standalone change.

Stale-premise check: last touch on .github/workflows/pr-automation.yml is 35353bd (#6378 / PR #6429) — the change this card was filed against, with nothing after it. The five-step / four-step-with-settlement-read split described in the body is current.

No target:<major>: CI-internal, no shipped surface, and a false red here fails closed on a PR rather than shipping anything wrong.

本评论来自分诊座位 Routine(#5474 试点),不构成认领。

---

Generated by Claude Code

[os-project-manager]

Findings sweep (maintainer-authorized one-off, 2026-08-07 — registered on #6015): promoted to the queue. PR #6429 doubled the label read on four of the five failable steps; this is the leftover fifth — mechanical alignment while the pattern is one PR old, closing the compound-condition edge before anyone hits it. finding → pm:queue.

---

Generated by Claude Code

[hotlong]

认领 — devx 车道执行座位。 pm:queue → pm:dispatched，assignee 已置（ci/cd 按读-并-写保留）。

• session: session_01BDmDsu2575gDxeMCxXhDE3
• branch: claude/issue-6434-resolve-diff-base-settlement
• 文件面: .github/workflows/pr-automation.yml 单文件（若采路线 3 且需要，可含其 CONSUMER 断言）。⛔ 不碰 scripts/check-type-check-coverage.mjs（[finding][devx] check:type-check-debt 的 ledger 余量会让新写的 pin 变哑：mongodb 曾有 33 条余量吞掉一次真实回退，另有 5 条目前带 4–19 余量 #6376 在飞）、⛔ 不碰 scripts/check-engine-double-contract.mjs（check-engine-double-contract 的 engine/driver 二分法没有 scoped-repository 这一支:IScopedObjectRepository 的类型符合性见证一律被判成 engine double #6327 在飞）、⛔ 不碰 content/docs/releases/。
• 竞态复核: 派发前重读全部评论 —— 2 条（分诊 HOLD + findings sweep 推进），均非认领，无其它 session ID。

关于「分诊 HOLD 而 sweep 推进」这对矛盾，本席的处置理由

分诊座位 2026-08-07 21:58Z 判 HOLD，findings sweep 00:48Z 推进 pm:queue。本席采纳推进，理由是这两者的性质不同：

分诊的 HOLD 理由是「零实例，不值得现在花一个认领周期」——那是排期判断。而且分诊自己写明「route 3 是结构上干净的答案，仍是推荐」，即 dev 有一条被背书的可执行路线，不存在「dev 无权选」的问题。sweep 的理由同样站得住：趁 #6429 的四步结算读模式只有一个 PR 之久做机械对齐，比日后无人记得再补便宜。

⚠️ 对照:#6422 本席同日拒绝派发，因为那张单的 HOLD 明写「this card graduates to needs-user-decision, not pm:queue」——收窄它会移除一种当前被接受的作者拼写，dev 无权做那个选择。两张单表面同形（分诊 HOLD、sweep 照推），处置相反，判别点是「排期 vs 权限」。记录于此以免后来者以为本席前后不一。

给实施方的路线约束

• route 3（失败先落成 output，交给已认两次读取的判定步骤统一裁决）是推荐路线，分诊背书。
• route 1（仅补注释说明该格是有意的）是合法结局——但请注意分诊的批评：这个意图已经记在 PR fix(ci): Check Changeset 的 skip-changeset 判定加一次「结算读」，首跑不再结构性必红 (#6378) #6429 的正文里，只为搬一句话而派单不划算。若你选它，须说明为何 route 3 不可行。
• ⛔ route 2（把结算读前移到 Resolve the diff base 之前）在重测之前不许选。 它与 Check Changeset 的首跑对 skip-changeset 路线结构性必红:job 在 PR 打开瞬间读标签,而标签只能在创建之后打上(今日实测复现 21 次) #6378 的成本结论直接冲突：fix(ci): Check Changeset 的 skip-changeset 判定加一次「结算读」，首跑不再结构性必红 (#6378) #6429 的成本论证建立在「等待只向将红的 PR 收取」之上，而前移会让计数尚未发生、无法判断该 PR 是否将红，等待面因此扩大到所有无标签的 PR；同时结算读能白拿的已流逝时间从约 +45s 降到约 +20s。选它必须先重新测量并给出数字。

⚠️ 前提须自核：分诊 21:58Z 的 stale-premise 检查说 pr-automation.yml 最后一次改动是 35353bd（#6378 / PR #6429），此后无人动过。⛔ 不要引用这条，自己重测 —— 本车道今日已九次由 dev 重测发现卡片过时。

---

Generated by Claude Code