企业官网建设流程全解析

OmXdev分支 Open PR 就绪度评审：CI 门禁语义、合并顺序与源码级验证方法

【免费下载链接】oh-my-codexOmX - Oh My codeX: Your codex is not alone. Add hooks, agent teams, HUDs, and so much more.项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-codex

本文基于仓库 docs/reports/open-prs-dev-readiness-2026-04-09.md 展开，系统讲解 OmX（oh-my-codex）维护者在将多个待合并 PR 收拢进dev分支前所做的一次"就绪度评审"：如何解读 CI 红/绿的真实含义、如何逐 PR 收集证据、如何判定"已合并/可合并/需修复"，并给出可复用的gh/git命令与本地验证流程。读完本文，你将掌握一套基于工作流源码与运行时源码的 PR 合并决策方法论。

评审背景与结论概览

2026-04-09（UTC）对dev分支进行了一次 Open PR 就绪度盘点，评审基线为提交8656d21149a0772369f697df002f7bf85002db8d。涉及的 6 个 PR（#1403、#1402、#1400、#1382、#1380、#1357）横跨三个主题域：共享会话关闭加固（shared-session shutdown hardening）、tmux HUD 自愈与 prompt 提交调和（self-healing / prompt-submit reconcile）、以及 native-hook 相关的令牌与状态修复。评审最终给出的合并顺序建议为：

1. 关闭#1382（其头部提交已是dev祖先，属于"已合并"的陈旧 PR）；
2. 待devCI 重跑转绿后，先合并#1380；
3. 基于新devrebase 并重测#1400；
4. 待长任务跑完且全绿后合并#1402；
5. 人工复查#1357（PR body 与 diff 不一致，存在 prompt 契约风险）；
6. 修复#1403的未使用导入后重跑 CI 再议。

devCI 状态解读：红 ≠ 失败，取消 ≠ 通过

本次评审最关键的一课是：CI 的CI Status门禁变红，并不等于质量门禁失败。Push 运行24141814673之所以红，是因为长时间任务被取消（cancelled），而非快速校验任务失败。

各门禁的真实结果

• 通过：Rust Format、Rust Clippy、Lint、Typecheck（Node 20/22）、Test（Node 22 / smoke）、Coverage Report (Rust)、Coverage Gate (Team Critical)、Ralph Persistence Gate；
• 被取消：Test (Node 20 / full)、Coverage Report (TypeScript Full)；
• 失败门禁：CI Status（汇总门禁）。

根因：ci-status的 fail-closed 语义

根因在 .github/workflows/ci.yml 的ci-status汇总任务。该任务以if: always()运行（第 698-699 行），把changes、docs-check、rustfmt、clippy、rust-tests、native-rust-darwin、native-rust-windows、lint、typecheck、build-dist、ralplan-preflight-macos、test、test-windows-js、coverage-team-critical、ralph-persistence-gate、native-cache-integrity、build全部列为needs（第 703 行）。

其核心判定逻辑是check_job函数（第 745-762 行）：对于"激活的 lane"，result != success即报错；对于"未激活的 lane"，要求结果为success或skipped。也就是说：

• 取消（cancelled）既不等于success，也不等于skipped；
• 任何被取消的任务都会让汇总门禁进入failures > 0分支并exit 1（第 821-831 行）。

因此，只要长任务因超时或手动取消而中止，CI Status就会红——但快速校验任务（lint、typecheck、smoke、Rust 门禁等）可能全部通过。这与"代码质量出问题"是两回事，评审者必须区分"结构性红"与"真实失败红"。

lane 激活规则：为什么长任务被取消

ci-status的激活判定（第 791-802 行）依赖于上游changes任务的输出（full_suite、docs_changed、ts_changed、rust_changed、native_changed、shared_config_changed）。分类器（第 96-209 行）按路径前缀把改动归入 docs / ts / rust / native / shared-config 等 lane；full_suite=true时全部任务激活，否则只激活与改动域对应的任务。长任务（如 Node 20 full、TypeScript Full coverage）通常耗时长、易被并发策略取消——concurrency组（第 19-21 行）在非workflow_dispatch事件下cancel-in-progress: true，新 push 会取消同一 ref 上的旧运行，这正是"长任务被取消"的常见来源。

就绪度矩阵：6 个 PR 逐一拆解

#1403 — Shared-session shutdown 加固（硬阻断：不可合并）

主题：共享会话关闭加固 + 回归覆盖。快速检查大多绿，但运行24173665271中两个 Typecheck 任务均失败；Node 20 full 仍在跑。

硬阻断：在 PR 头e802eff1上本地执行npm run check:no-unused失败：

src/team/runtime.ts(20,3): error TS6133: 'isNativeWindows' is declared but its value is never read.

这是noUnusedLocals类的严格未使用检查。tsconfig.no-unused.json显式开启noUnusedLocals与noUnusedParameters（tsconfig.no-unused.json 第 4-7 行），package.json中的check:no-unused脚本即tsc -p tsconfig.no-unused.json（package.json 第 16 行）。

从源码看，isNativeWindows定义于 src/team/tmux-session.ts 第 2341 行，并在该文件多处（第 2058、2625、2729、2749、3044、3170 行）被使用；而共享会话关闭的核心入口shutdownTeam（src/team/runtime.ts 第 4851 行起）在关闭流程中通过resolveSharedSessionShutdownTopology（从./tmux-session.js导入，第 46 行）等函数处理 pane 拓扑。若 PR #1403 在runtime.ts顶部导入但未实际使用isNativeWindows，说明关闭路径的 Windows 分支判断被挪走或尚未接线，属于需要清理的悬空导入。

结论：不要合并。先删除未使用导入，重跑 PR CI，再重新评估。

#1402 — tmux HUD 自愈 / prompt 提交调和（好候选）

主题：tmux HUD 自愈 + prompt 提交调和。Lint、typecheck、smoke、rust coverage、team coverage gate 已通过；Node 20 full 与 TS full coverage 仍 pending。它触及src/cli、src/hud与 native-hook 运行事件。

HUD 相关实现集中在 src/hud（含authority.ts、reconcile.ts、render.ts、state.ts、tmux.ts等模块）；团队关闭/拓扑逻辑在 src/team/runtime.ts 中与shutdown_*错误码（如shutdown_shared_session_worker_owner_unavailable、shutdown_shared_session_HUD_pane_identity_changed）强相关——HUD pane 身份校验是共享会话关闭的前置条件。

结论：长任务跑完且dev全绿后，是比纯文档改动更优先的好候选。

#1400 — 未知$token重复续跑 + 陈旧 Ralph 状态修复

主题：未知$token的重复 continuation 修复 + 陈旧 Ralph 状态修复。Lint、typecheck、smoke、rust coverage、team coverage gate 已通过；长任务 pending。

依赖关系：与 #1380 都触及 src/scripts/codex-native-hook.ts 及其测试，存在重叠。该文件是 native-hook 的核心（约 1.2 万行），包含会话状态可用性判定（如isSessionStateUsable，见第 1371、1436 行附近）、陈旧指针恢复（"stale-dead" selected pointer 恢复逻辑，第 22212-22220 行附近）等与$token、stale 状态直接相关的实现。

结论：等 #1380 进入dev后再合并，随后 rebase/重测，否则会引发冲突或重复评审。

#1382 — 陈旧团队工作树启动清理（已合并，建议关闭）

主题：启动时清理陈旧团队工作树。PR 仍开着，但其头部提交e5f9ffe7...已是当前dev头的祖先——即改动早已落进dev。

判定方法：git merge-base dev pr-1382确认合并基，配合git rev-list --left-right --count dev...pr-<n>观察分支分叉计数，可确认"PR 头已被并入目标分支"。此时 CI Status 的红只是取消长任务产生的陈旧噪音。

结论：作为"陈旧/已合并"直接关闭，无需再做合并。

#1380 — 陈旧 deep-interview stop-hook 门控修复（钩子修复类首个合并）

主题：修复陈旧的 deep-interview stop-hook 门控。快速检查通过；CI Status 红仅因旧运行24142611197的长任务被取消。

结论：在devCI 转绿后，作为钩子修复类中第一个合入的 PR（先于 #1400）。

#1357 — AGENTS/template 令牌削减（保留人工复查）

主题：AGENTS/template 令牌（token）削减。快速检查通过；CI Status 红仅因旧运行24145469951的长任务取消。

风险：PR body/清单声称只改两个文件，但 diff 还改了CLAUDE.md，存在 body 与 diff 不一致；涉及 prompt 契约面，需要人工复核。

结论：在运行时修复（#1380/#1400/#1402）之后处理，优先级较低。

证据收集：可复用的评审命令集

评审依赖的原始证据全部来自仓库数据，原文记录的取证命令如下：

• 查看devCI 失败形态：gh run view 24141814673 --json ...；
• 逐 PR 查询检查状态：gh pr checks 1402、1400、1382、1380、1357、1403；
• 重叠检测（改动文件）：gh pr diff --name-only，用于识别 #1400 与 #1380 在src/scripts/codex-native-hook.ts上的重叠；
• 祖先/已合并检测：git rev-list --left-right --count dev...pr-<n>与git merge-base dev pr-1382；
• 本地 PR 验证（#1403）：在/tmp/worker3-pr1403中执行：
  • npm ci
  • npm run build
  • npm run check:no-unused→ 在src/team/runtime.ts命中未使用导入失败。

这套组合可复用于任何"多 PR 待合入dev"的窗口：先用gh pr checks看单 PR 状态，用gh pr diff --name-only查文件重叠以规划合并顺序，用git merge-base/git rev-list识别已经合入的陈旧 PR，最后用本地npm run check:no-unused等脚本复现硬阻断类问题。

从源码理解评审结论背后的机制

Typecheck 双关卡：tsc --noEmit与check:no-unused

.github/workflows/ci.yml 的typecheck任务（第 369-383 行）依次执行npm ci、npx tsc --noEmit、npm run check:no-unused。前者校验类型正确性，后者基于 tsconfig.no-unused.json 做未使用符号审计——这就是 #1403 被TS6133拦截的原因。评审矩阵中"两个 Typecheck 任务失败"即指这条双关卡链路。

Ralph Persistence Gate 与 Team Coverage Gate

ralph-persistence-gate（第 613-632 行）运行npm run test:ralph-persistence:compiled，覆盖dist/cli/__tests__/session-scoped-runtime.test.js、dist/mcp/__tests__/state-server-ralph-phase.test.js、dist/ralph/__tests__/persistence.test.js等（package.json 第 44 行）。coverage-team-critical（第 567-611 行）执行npm run coverage:team-critical:compiled，该脚本用c8限定dist/team与dist/state，阈值 lines=78 / functions=90 / branches=70 / statements=78（package.json 第 39 行），并在 job summary 中输出覆盖率表格。这两道门禁保障了团队运行时与 Ralph 状态持久化在合并前的质量下限——#1402、#1400 均通过，是"好候选"评级的重要依据。

合并顺序背后的依赖经济学

推荐顺序不是随意的：

• #1382 先关：零成本清理，避免陈旧的 CI 噪音继续干扰看板；
• #1380 先于 #1400：两者都改src/scripts/codex-native-hook.ts，先合并基线修复可让 #1400 在干净基线上 rebase，减少冲突与重复评审；
• #1402 单独评估：涉及src/cli、src/hud与 native-hook 运行事件，横跨面大，必须等长任务（Node 20 full、TS full coverage）转绿再合；
• #1357 保留人工：body 与 diff 不一致属于流程契约问题，需人工判断 prompt 削减是否破坏契约；
• #1403 修复后再议：TS6133是硬错误，任何合并都会在 CI 上立即暴露。

总结

这次 2026-04-09 的dev就绪度评审展示了 OmX 仓库一个可复制的工程实践：用结构化矩阵 + 工作流源码语义 + 本地复现来驱动合并决策。核心要点可归纳为三条：

1. 读懂 CI 红的种类：CI Status汇总门禁对cancelled是 fail-closed（见 .github/workflows/ci.yml 第 698-832 行），长任务取消导致的红不代表质量失败，必须逐任务核对gh run view结果；
2. 用 git 祖先关系清理陈旧 PR：git merge-base与git rev-list --left-right --count能在合并前就识别"已合入目标分支"的 PR，直接关闭省去噪音；
3. 本地复现硬阻断：npm ci && npm run build && npm run check:no-unused能把TS6133这类硬错误在合并前钉死（如 #1403 在src/team/runtime.ts的isNativeWindows未使用导入）。

对维护者而言，这份评审是dev分支质量闸门的实际运行样例；对贡献者而言，它也反过来说明了为什么提交前应跑通npm run lint、npm run check:no-unused与 Rust 侧cargo fmt --all --check/cargo clippy --workspace --all-targets -- -D warnings，因为这些都是 .github/workflows/ci.yml 中真实生效的合并前门禁。

【免费下载链接】oh-my-codexOmX - Oh My codeX: Your codex is not alone. Add hooks, agent teams, HUDs, and so much more.项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-codex