企业官网建设流程全解析

OmX v0.4.2 发布质量门禁实战：main/dev 对齐验证、notify 通知与 tmux 团队回归的完整 QA 流程

【免费下载链接】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

导读：本文基于 OmX（oh-my-codex）v0.4.2 的 QA 执行报告（docs/qa-report-0.4.2.md）及其配套 QA 计划（docs/qa-plan-0.4.2.md），还原一次真实的发布前质量验证全过程：通过团队编排执行 QA、用git rev-list校验已部署main与dev的对齐关系、跑通 664 项自动化测试，并围绕“all-workers-idle 通知、auto-nudge 停滞检测、tmux 鼠标滚动、collab → multi_agent配置迁移、/exit干净退出”五个风险点逐一展开。读完本文，你将掌握 OmX 的发布质量门禁方法论，并能对照源码理解每个验证点背后的实现原理与可复现命令。

一、发布背景：v0.4.2 要交付什么

v0.4.2 是 2026-02-18 的发布版本，其范围是验证origin/main（已部署的 v0.4.1）与当前dev分支之间的增量。根据 CHANGELOG.md 中## [0.4.2] - 2026-02-18的记录，本次发布包含三类变更：

• Added（新增）：扩展了 auto-nudge 停滞检测短语（如 "next I can"、"say go"、"keep driving"），并引入聚焦“最后几行热区”的检测；新增 worker 空闲聚合通知（全部 worker 进入 idle/done 时提醒 leader，带冷却与事件日志）；团队会话默认开启 tmux 鼠标滚动（可用OMX_TEAM_MOUSE=0关闭）。
• Fixed（修复）：修复 worker 消息提交可靠性（提交按键轮次前后增加 settle/延迟时序）；修复 CLI 退出行为（bin/omx.js现在await main(...)后显式退出，/exit可干净终止）；用multi_agent全面替换废弃的collab特性引用。
• Tests（测试）：新增 all-workers-idle notify-hook 行为覆盖、auto-nudge 模式测试扩展、tmux 鼠标模式启用行为测试等。

QA 计划将风险聚焦在四个区域：notify hook 行为、tmux 团队 UX/可靠性、配置兼容性、生命周期/进程处理（见 docs/qa-plan-0.4.2.md）。这份 QA 报告正是围绕这些风险点执行并给出结论的。

二、团队执行：用$team编排 QA 任务

QA 执行的第一步是以 OmX 自身的多智能体团队能力来跑 QA：通过$team命令启动团队会话，QA 团队以全部任务终结（completed=3, failed=0）的方式完成，并干净关闭。

报告特别记录了一个运维细节：启动前检测并清理了初始的 stale worker 窗格（%1749、%1750两个 tmux pane）。从源码结构看，这与 src/team/tmux-session.ts 中团队会话生命周期管理（窗格所有权校验、@omx_team_pane_owner_id标识、启动前拓扑对账）是同一套机制，测试用例也在 src/hooks/tests/notify-hook-all-workers-idle.test.ts 中通过伪造 tmux 场景验证了“团队窗格缺失时不做注入”等边界行为。

这一步骤的意义在于：发布前 QA 本身即是对团队编排可用性的真实演练——如果$team会话无法干净启停，release gate 不可能通过。

三、Parity 验证：已部署 main 与 dev 的对齐审计

发布前必须确认dev分支没有丢失main上的任何功能提交。QA 使用了三条 git 命令：

# 合并感知的左右差异统计（左=main 独有，右=dev 独有） git rev-list --left-right --count origin/main...dev # 忽略合并提交后的左右差异统计 git rev-list --left-right --count --no-merges origin/main...dev # 列出 main 上有、dev 上没有的非合并提交 git log --oneline --no-merges dev..origin/main

执行结果：

• Merge-aware divergence（含合并提交）：6 18——main侧 6 个、dev侧 18 个。
• Non-merge divergence（忽略合并提交）：0 15——dev侧 15 个功能性提交，main侧 0 个。
• main上没有缺失于dev的非合并提交。

结论：Parity 验证门禁 PASS。dev领先于main的 15 个非合并提交，正是 QA 计划中描述的 feature/fix/test 提交（auto-nudge 改进、all-workers-idle leader 通知、tmux 输入/滚动修复、覆盖率扩展），方向上完全一致。6 18与0 15的差异说明这 6 个合并提交全部来自dev侧合入，main无反向漂移。QA 计划中给出的是这套命令的完整预热版本（先git fetch origin --prune），生产实践中建议先 fetch 再对比。

四、自动化 QA：664 项测试全绿

自动化质量门禁执行的命令是：

npm test

结果：PASS—— 664 项测试全部通过，0 失败。

需要特别澄清的一点：QA 计划中书写的是npm run test:run，但报告明确指出当前 package.json 中不存在test:run脚本。实际执行的npm test是一条完整的组合流水线（见 package.json）：

npm run build \ && npm run verify:native-agents \ && npm run verify:plugin-bundle \ && npm run verify:capabilities-lock \ && npm run verify:prompt-guidance \ && npm run test:node \ && node dist/scripts/generate-catalog-docs.js --check \ && node dist/scripts/prompt-inventory.js --check

即：先编译 TypeScript，再依次校验 native agents、插件包、能力锁文件、prompt guidance 的一致性，最后通过node dist/scripts/run-test-files.js dist运行全部 Node 测试（test:node）。这说明“自动化测试通过”在 OmX 里不仅是单元测试绿，还包含产物与声明文件（catalog、prompt inventory、capabilities lock）的一致性校验。

QA 计划特别要求以下新增/更新套件通过（对应实现与测试均在仓库中可查）：

• src/hooks/tests/notify-hook-all-workers-idle.test.ts —— all-workers-idle 通知行为
• src/hooks/tests/notify-hook-auto-nudge.test.ts —— auto-nudge 模式检测
• src/team/tests/tmux-session.test.ts —— tmux 会话可靠性
• src/config/tests/generator-notify.test.ts —— 配置生成器 notify 契约

五、发布元数据检查：版本三处一致

发布元数据是防止“代码改了、版本没升”这类低级事故的兜底检查。报告核对了三处：

这与 QA 计划第 5 节 Release Gate 的验收条件一致：版本在package.json与package-lock.json中同步 bump，changelog 条目与本次交付行为匹配。

六、手动 QA 清单 A–E：五个风险点的验证口径与源码依据

报告对 A/B/C/E 四项给出“仅部分验证（自动化测试 + 代码路径检查）”的结论，D 项（配置迁移）由自动化测试完整覆盖。下面结合源码逐一展开这五个验证点，方便读者理解“为什么验、验什么、对应哪段实现”。

A. All workers idle 通知（全部 worker 空闲提醒）

验证口径（来自 docs/qa-plan-0.4.2.md）：

• 启动 ≥2 个 worker 的团队会话；
• 让所有 worker 进入idle或done；
• 验证 leader 收到一条空闲汇总提示；
• 在冷却窗口内重复触发，验证不会产生重复通知轰炸；
• 验证事件/日志条目已写入。

实现依据：核心逻辑位于 src/scripts/notify-hook/team-leader-nudge.ts。判定条件是workerStates.length > 0 && workerStates.every((state) => state === 'idle' || state === 'done')，即所有 worker 状态文件（status.json中的state）都为idle/done。随后通过 src/scripts/notify-hook/orchestration-intent.ts 的classifyLeaderActionState区分三种情形：

• done_waiting_on_leader（任务全部完成且 worker 窗格存活）→ 意图done-review-or-shutdown；
• stuck_waiting_on_leader（有 blocked 任务）→ 意图stalled-unblock；
• still_actionable（有 pending 后续任务）→ 意图followup-reuse。

leader 收到的提示文本形如[OMX] All N worker(s) idle. …（见 src/scripts/notify-hook/team-leader-nudge.ts）。

冷却机制：报告与测试都强调“cooldown 内不重复通知”。实现上存在两层冷却：一是resolveLeaderAllIdleNudgeCooldownMs()控制的 all-idle 专属冷却，状态记录在.omx/state/team-leader-nudge.json的last_idle_nudged_by_team中（src/scripts/notify-hook/team-leader-nudge.ts）；二是通用空闲通知冷却，可通过环境变量OMX_IDLE_COOLDOWN_SECONDS覆盖，默认 60 秒，状态文件为.omx/state/idle-notif-cooldown.json，取 0 可完全关闭节流（见 src/notifications/idle-cooldown.ts）。

测试侧用OMX_TEAM_ALL_IDLE_COOLDOWN_MS环境变量控制冷却长度（测试中分别用 500ms 与 600000ms），并覆盖了“leader pane 缺失时延迟投递（leader_notification_deferred+leader_pane_missing_no_injection）”“冷却窗口内只写一次延迟可见性”“不向 shell leader pane 注入”等边界（src/hooks/tests/notify-hook-all-workers-idle.test.ts）。事件统一写入团队events/events.ndjson，日志写入.omx/logs/tmux-hook-<date>.jsonl，便于事后审计。

B. Auto-nudge 停滞模式检测

验证口径：

• 喂入包含新短语（如 "say go"、"next I can"、"keep driving"）的输出；
• 验证停滞检测在“最后几行热区”内触发；
• 验证无关文本不会误触发。

实现依据：检测规则集中在 src/scripts/notify-hook/auto-nudge.ts，分为三组：

• DEFAULT_STALL_PATTERNS（默认停滞短语）：continue with、continue on、pick up with、keep going、and i'll continue、keep driving、keep pushing、move forward、drive forward、i'll continue from；
• PERMISSION_SEEKING_STALL_PATTERNS（征求许可类，如if you want、would you like、next i can、say go、say yes、let me know if、proceed from here等）；
• PLANNING_ONLY_STALL_PATTERNS（规划类，如plan、review、next step、ready to proceed等）。

热区（hot zone）机制：matchesNormalizedPatterns只取规范化文本的最后 800 字符（slice(-800)），并在其中进一步抽取最后 3 行作为热区做优先匹配（src/scripts/notify-hook/auto-nudge.ts）。这正对应 QA 计划中“last-lines hot zone”的描述——只有当停滞信号出现在输出的尾部热区时才触发，避免陈旧对话内容误触发。此外还有一层防误触发：CAPTURE_TEST_LINE_RE会先过滤掉测试运行器的状态行（如✓ should continue with the next step），防止测试名里的“continue with”被误判为停滞（src/scripts/notify-hook/auto-nudge.ts）。检测到的停滞还会被归约为stall:proceed_intent之类的语义签名用于去重。

C. Tmux 输入可靠性 + 鼠标滚动

验证口径：

• 团队模式下，鼠标滚轮可滚动 pane 历史；
• 方向键仍可用于 CLI 输入历史；
• 反复发送 worker 提示，验证提交一致性；
• 设置OMX_TEAM_MOUSE=0重启会话，验证不强制启用鼠标模式。

实现依据：团队会话启动流程中，在完成窗格布局后会执行：

// Enable mouse scrolling so agent output panes can be scrolled with the // mouse wheel without conflicting with keyboard up/down arrow-key input // history navigation in the Codex CLI input field. (issue #103) // Opt-out: set OMX_TEAM_MOUSE=0 in the environment. if (process.env.OMX_TEAM_MOUSE !== '0') { enableMouseScrolling(sessionName, …); }

见 src/team/tmux-session.ts。enableMouseScrolling（src/team/tmux-session.ts）执行三个会话级操作：set-option -t <session> mouse on、set-option -t <session> set-clipboard on（启用 OSC 52，免 xclip/pbcopy 即可复制选中文本）、以及 copy-mode 下划线伪影缓解。关键设计是严格限定 session 作用域，不触碰服务端全局 tmux 绑定与用户（如 oh-my-tmux）的全局配置。OMX_TEAM_MOUSE=0是唯一关闭途径，测试用例也在 src/team/tests/tmux-session.test.ts 中验证了启用与拒绝路径。报告结论将本项标记为 PARTIAL，理由是本项需要交互式会话真实验证，自动化只能覆盖代码路径。

D. 配置生成器迁移（collab → multi_agent）

验证口径：

• 在全新与既有配置上跑 setup/generator 路径；
• 验证[features]包含multi_agent = true与child_agents_md = true；
• 验证废弃的collab键不会被重新引入。

实现依据：此项由自动化测试完整覆盖并通过（generator-notify+ 配置生成器套件）。核心实现是 src/config/generator.ts 的upsertFeatureFlags：当[features]区块不存在时，会注入：

[features] child_agents_md = true # …hooks feature flag… goals = true

当区块存在时，会主动删除废弃的collab与未发布的goal标志（/^\s*(?:collab|goal)\s*=/匹配行被移除），并把child_agents_md强制为true。multi_agent作为新特性键在生成器默认配置中为true（"features.multi_agent": true）。卸载路径同样维护这一契约：removeOmxOwnedFeatureFlags默认连同collab一起清理，仅在preserveMultiAgent时保留multi_agent（src/config/generator.ts）。测试 src/config/tests/generator-notify.test.ts 还验证了生成配置中notify = ["node", "…notify-hook.js"]以 TOML 数组形式写在顶层、hooks = true等契约。

E./exit进程终止

验证口径：启动omx，调用/exit，验证进程干净退出、不挂起。

实现依据：CHANGELOG 与 QA 计划均确认修复点为bin/omx.js现在await main(...)后再显式退出。从代码结构看，CLI 入口链位于 src/cli/index.ts（入口dist/cli/omx.js由 package.json 的bin字段声明）。此前版本可能因主函数未 await 导致/exit后进程残留，本次通过显式等待与退出收敛了生命周期。此点同样需要交互式真实验证，因此被标为 PARTIAL。

七、总体结论：三道门禁的判定口径

QA 报告的总体判定汇总如下：

这与 QA 计划第 5 节的 Release Gate 定义完全一致：自动化测试通过、手动清单 A–E 通过、changelog 与交付行为匹配、版本三处一致 bump，四项全部满足才放行发布。本次执行在自动化与对齐维度全部通过，但 A/B/C/E 的交互式验证被明确记录为“需要发布前补做的显式交互验收”——这种“自动化全绿、交互部分留痕”的诚实报告方式，本身就是可复用的质量门禁实践：把可自动化的交给测试套件，把必须人验的以清单形式固化。

八、如何在本仓库复现这套验证

若要在当前仓库复现上述验证流程（注意当前仓库版本已演进至package.json中的 0.21.2，命令以现行为准）：

# 1. 对齐审计（替换为你的远程名与分支） git fetch origin --prune git rev-list --left-right --count origin/main...dev # 2. 完整自动化质量门禁（build + 各类 verify + 全量 Node 测试） npm test # 3. 定向验证 v0.4.2 相关风险套件 npm run test:node # 等价于 node dist/scripts/run-test-files.js dist

更精确的定向运行可参考 package.json 中的test:recent-bug-regressions、test:explicit-terminal-contract等既有组合脚本，它们展示了如何用node dist/scripts/run-test-files.js精确圈定指定测试文件集合。手动清单 A–E 则需在真实 tmux 会话中按 docs/qa-plan-0.4.2.md 的步骤逐条执行，并通过.omx/logs下的tmux-hook-<date>.jsonl与团队events/events.ndjson核验事件落盘。

结语

v0.4.2 的 QA 执行报告展示了一条可复用的发布质量闭环：团队编排执行 → 分支对齐审计 → 自动化全量回归 → 发布元数据一致性 → 风险点手动清单。其中“all-workers-idle 冷却通知”“最后 3 行热区停滞检测”“会话级 tmux 鼠标模式”“collab → multi_agent迁移清理”“/exit显式退出”五个风险点在 CHANGELOG.md、QA 计划、生成器与 notify-hook 源码、以及对应测试套件之间形成了完整可追溯的证据链。无论你是要复现一次发布验收，还是想理解 OmX 多智能体协作的可靠性设计，这份报告连同源码都是最直接的起点。

【免费下载链接】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