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导读本文基于 OmXoh-my-codexv0.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_MOUSE0关闭。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 团队以全部任务终结completed3, failed0的方式完成并干净关闭。报告特别记录了一个运维细节启动前检测并清理了初始的 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 再对比。四、自动化 QA664 项测试全绿自动化质量门禁执行的命令是npm test结果PASS—— 664 项测试全部通过0 失败。需要特别澄清的一点QA 计划中书写的是npm run test:run但报告明确指出当前 package.json 中不存在test:run脚本。实际执行的npm test是一条完整的组合流水线见 package.jsonnpm 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 契约五、发布元数据检查版本三处一致发布元数据是防止“代码改了、版本没升”这类低级事故的兜底检查。报告核对了三处检查项期望值结果package.jsonversion0.4.2✅package-lock.jsonversion0.4.2✅CHANGELOG.md包含## [0.4.2] - 2026-02-18✅这与 QA 计划第 5 节 Release Gate 的验收条件一致版本在package.json与package-lock.json中同步 bumpchangelog 条目与本次交付行为匹配。六、手动 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-shutdownstuck_waiting_on_leader有 blocked 任务→ 意图stalled-unblockstill_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_deferredleader_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 ill continue、keep driving、keep pushing、move forward、drive forward、ill continue fromPERMISSION_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_MOUSE0重启会话验证不强制启用鼠标模式。实现依据团队会话启动流程中在完成窗格布局后会执行// 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_MOUSE0 in the environment. if (process.env.OMX_TEAM_MOUSE ! 0) { enableMouseScrolling(sessionName, …); }见 src/team/tmux-session.ts。enableMouseScrollingsrc/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_MOUSE0是唯一关闭途径测试用例也在 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作为新特性键在生成器默认配置中为truefeatures.multi_agent: true。卸载路径同样维护这一契约removeOmxOwnedFeatureFlags默认连同collab一起清理仅在preserveMultiAgent时保留multi_agentsrc/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 报告的总体判定汇总如下门禁判定自动化质量门禁npm test664 通过 / 0 失败PASSParity 验证门禁mainvsdev对齐PASS手动交互门禁清单 A–EPARTIAL发布前需按要求完成显式交互验收这与 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考