[ranxianglei]

现象(人话)

version-guard / kernel-guard / pi-subagents-guard / lane-guard 四个边界守卫只在 pull_request 事件跑。发版链路里 release-ci-gate.mjs 会用 workflow_dispatch 在发版 commit 上补跑 ci.yml —— 这一路径上四个守卫全部跳过:发版 sha 恰好是「version 字段、kernel 版本、锁文件」最该被检查的 commit,却永远看不到守卫。PR-merge 发版有守卫兜着,直推/回退路径没有。

根因

四个 job 的 if: github.event_name == 'pull_request'(#2637 fail-fast 分层的刻意设计:push 上跳过守卫让 4 条平台腿照跑)。当年没考虑 #3539 之后 dispatch 会成为发版 sha 的正式 CI 载体。

修复(纯 CI,无运行时代码)

1. 四个守卫条件改为 pull_request || workflow_dispatch(push 仍跳过,CI 排队与执行时间优化:不降低质量的前提下大幅节省(数据+方案清单) #2637 语义不变;守卫在 dispatch 上红 → failure() → 腿跳过 → run 红 → 发版门拒发,这正是想要的执法)。
2. version-guard / kernel-guard 分支解析加固:脚本原来用 BRANCH="${GITHUB_HEAD_REF}" —— 该变量 PR 专有,dispatch 上为空,会导致 *_release-v* / *_release-kernel-v* / bugfix-release/* 豁免全部失配,把合法发版 commit 误判红。改为 ${GITHUB_HEAD_REF:-${GITHUB_REF_NAME}}(dispatch 上 REF_NAME=被派发的分支名,豁免恢复工作)。这是本 PR 必须带上脚本改动的唯一原因。
3. kernel-guard 规则1(PR body 声明)在 dispatch 上跳过:dispatch 没有 PR body 可查;dispatch 本身就是 owner 手动触发(fallback/紧急通道),人工门已在链下完成。规则2/版本纪律(纯 diff 判定)照跑。

不变式核对

• master 空分母:dispatch 在 master 头上时 origin/master...HEAD 为空 diff,守卫空转通过(无害)。
• fallback 发版分支:diff 非空(version bump),靠 2) 的分支豁免放行 —— 与 PR 路径同一豁免表,无新口径。
• lane-guard / pi-subagents-guard:纯 diff 判定、无 PR 上下文、无分支豁免,加 dispatch 零语义变化。
• push / schedule 事件:行为逐字节不变。

来源

v0.1.204→master 回归审查 P3(PR #4412 评论「kernel-guard 等三个 guard 不在直推发版 commit 上跑(建议 || workflow_dispatch)」),P2-① 的伴随项(PR #4426 修了直推路径的 FULL 矩阵,本 PR 补守卫覆盖)。

[github-actions]

📦 Built Package Artifact

Branch: 2026-10-23_guards-on-dispatch (d2307a3)

Latest build — install this exact version

npm install -g [email protected]

This exact version is immutable and reproducible. The rolling pr tag tracks the newest test build across all PRs.

Recent builds (commit → version)

commit	version	build
d2307a3	[email protected]	build
f625637	[email protected]	build
571e84a	[email protected]	build
7705810	[email protected]	build
5b90213	[email protected]	build

Download artifact

1. Download the artifact from the Actions run
2. Extract the tarball and install:

tar xzf billion-context-pr4428.tgz
npm install -g package

---

Install instructions are refreshed on each push.

[ranxianglei]

(ai: zhipuai-lb/glm-5.3)

状态说明:本 PR 为 CI 覆盖加固,非回归修复。按 owner 决定「非回归问题本版不合并」,留待下个版本,保持 open、不阻塞发版。

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

(ai: vllm-qwen/qwen3.8-27b)

查重: 不重复 —— 全仓 open+closed 检索无其他条目覆盖「边界守卫不在 workflow_dispatch 上跑」这一机制。来源是 v0.1.204→master 回归审查的 P3 发现(PR #4412 评论);与 #4426 相关但机制不同(#4426 修直推路径的 FULL 测试矩阵覆盖,本 PR 修守卫 job 自身的触发条件)。

标签: bug、scope/ci、p3(CI 执法盲区,仅影响应急发版路径,低频,不影响终端用户)

状态确认(按 floor 2 的 owner 决定:非回归加固本版不合并,保持 open、不阻塞发版)。本轮未改任何代码,做了核对与定向验证:

分支与代码核对

• head 7705810ff(rebase 到 [PR] fix(#4440): remove exports of file-internal types from 3 files, restore unused-exports gate to green | fix(#4440): 删掉 3 个文件内部类型的 export,恢复 unused-exports 门为绿 #4441 合入后的 master),对 master 的 diff 只有 .github/workflows/ci.yml(+20/-9),纯 CI 变更、零运行时代码。
• 代码与描述逐条一致:四个守卫(version/kernel/pi-subagents/lane-guard)触发条件加 || workflow_dispatch;分支解析改为 ${GITHUB_HEAD_REF:-${GITHUB_REF_NAME}}(GITHUB_HEAD_REF 是 PR 专有变量,dispatch 上为空,不兜底则 *_release-v*/bugfix-release/* 豁免全部失配、合法发版 commit 被误判红);kernel-guard 的「PR body 必须声明 kernel-change」规则在 dispatch 上跳过(dispatch 无 body 可查,且 dispatch 本身是 owner 手动触发的应急通道,人工门已在链下完成),纯 diff 判定的版本纪律规则照跑。

定向验证(本地一次性 worktree + 模拟事件环境变量,闸门双向 8/8 通过)

• dispatch@release 分支 → 豁免命中放行;dispatch@master → 空分母空转通过;
• PR 形态回归:干净 PR 照旧通过;PR 形态改 kernel 未声明仍红(规则 1 对 PR 路径的执法没被削弱);PR 形态非 release 分支动 version 字段仍红;
• dispatch 形态改 kernel + bump 版本、无 body → 通过(规则 1 豁免生效、版本纪律仍有效)。

CI 状态:当前 head 47/47 completed(35 绿、12 skipped、0 红)。mergeable_state=behind:落后 master 14 个提交;base 之后 master 上 ci.yml 只有一处无关改动(#4437 shard 时权重平衡,plan-job 区域,与本 PR 的 guard 段无 hunk 重叠),rebase 冲突风险低。floor 1 的构建产物评论是自动通知(旧 head 5b90213 构建成功),无需动作。

结构化八问

1. 是什么问题:四个边界守卫只在 pull_request 事件上跑,发版链路用 workflow_dispatch 在发版 commit 上补跑 CI 的路径里守卫全部跳过——最该被检查的 commit(version bump/kernel 版本/锁文件)反而永远看不到守卫。
2. 什么原因导致的:CI 排队与执行时间优化:不降低质量的前提下大幅节省(数据+方案清单) #2637 做 fail-fast 分层时把守卫刻意设为 PR-only(push 上跳过让平台腿照跑);一键发版太慢:前置门单机串行跑全量测试 30-40 分钟,且同一套测试在发版链路里重复跑 2-3 遍 #3539 之后 dispatch 成为发版 sha 的正式 CI 载体,守卫条件没有同步跟上。
3. 影响范围与严重程度:只波及应急/回退发版路径(workflow_dispatch),常规 PR-merge 发版有守卫兜着;非法 commit 走 dispatch 路径时可绕过版本纪律与 kernel 声明检查。内部 CI 执法缺口,终端用户无感,p3。
4. 怎么修复的:四个守卫触发条件 OR 上 workflow_dispatch(dispatch 上守卫红 → failure() → 腿跳过 → run 红 → 发版门拒发,即想要的执法);配套把分支解析兜底到 GITHUB_REF_NAME 让发版分支豁免在 dispatch 上继续有效;kernel-guard 仅豁免 PR-body 声明这一条 PR 形态规则,其余规则不变。
5. 是否有回归问题:未发现。push/schedule 事件行为逐字节不变(条件只是 OR 新事件名);双向验证确认负向控制(F/H)仍红、正向控制(A-E)仍绿。
6. 是否破坏缓存:不涉及(纯 CI 触发条件,不触碰缓存/重试/增量游标逻辑)。
7. 是否改了设计方向:无——CI 排队与执行时间优化:不降低质量的前提下大幅节省(数据+方案清单) #2637 的分层语义(守卫生效并 gate 四条腿)保持不变,只补 dispatch 盲区。
8. 是否引入了新的配置:无。

收工判定:保持 open(按 owner 决定本版不合并、不阻塞发版)。分支代码与描述一致、双向定向验证通过、CI 全绿,当前无需任何动作;下个版本捡拾时先 rebase 最新 master 再合入即可。