Repository navigation
观察单:Resolve the diff base 是 Check Changeset 里唯一只认快路径标签读取的可失败步骤,标签晚到 + git 基准不可用时会红一个本该豁免的 PR #6434
Description
Activity
Findings triage — verdict: HOLD (
findingretained,domain:devxunchanged).Why still held: the trigger needs two independent conditions at once — the
skip-changesetlabel 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'sexit 1says "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 baseshrinks 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 baseon a PR carryingskip-changeset— that instance is what prices route 3 against route 1 and supplies the failure signature. Promote earlier ifpr-automation.ymlis 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.ymlis35353bd(#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
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
认领 — 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 toneeds-user-decision, notpm: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
- session:
由 #6378 / PR #6429 的实现过程中记录,未在该 PR 内修复(超出本单范围),按 Prime Directive #10 单独立观察单。
现象
pr-automation.yml的changeset-checkjob 里,能让 PR 变红的步骤共五个。PR #6429 之后,其中四个同时认两次活标签读取(快路径读取 + 结算读):Require a changeset (or the skip-changeset label)Reject an empty-frontmatter changeset added by this PRRequire an ADR-0087 disposition on a declared-breaking changesetGuard against accidental major bumps (launch window)第五个 ——
Resolve the diff base (merge base with the base branch)—— 只带steps.labels.outputs.skip != 'true'这一条快路径守卫,而它自己有两处exit 1:git merge-base算不出来(例如origin/BASE_REF取不到)。后果(复合条件,今天没人撞得到)
要踩到需要同时成立两件事:
skip-changeset标签晚于快路径读取才落地(即 Check Changeset 的首跑对 skip-changeset 路线结构性必红:job 在 PR 打开瞬间读标签,而标签只能在创建之后打上(今日实测复现 21 次) #6378 的那个窗口内 —— 这恰恰是常态),并且此时
Resolve the diff base会在结算读有机会纠正之前就把 job 判红,而这个 PR 本该是豁免的。条件 2 极少发生(需要 fetch 失败一类的基础设施抖动),所以今天没有已知实例,归观察类。这是有意留下的,不是遗漏
PR #6429 在正文的「不在本 PR 里」一节写明了该格,理由是:它的
exit 1表达的是「git 基准不可用」,不是 changeset 判决,本就不受标签豁免;#6378 的范围是消除结构性假红,顺手扩大一个豁免面不在其内。该 PR 新增的 CONSUMER 断言按「跑check-*.mjs或发出 no-changeset 错误」来圈定判定步骤,有意把这一步排除在外,以免断言把一个没论证过的豁免钉成契约。候选处置(未预设结论)
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 的成本结论直接冲突,需要重新测量再决定。Resolve the diff base的失败先落成一个 output,由后面已认两次读取的判定步骤统一裁决。倾向 1 或 3;⛔ 选 2 之前必须重测,否则会把 #6378 刚消掉的成本以另一种形式加回来。
未认领,交分诊定级。