OmX 0.15.1 发布就绪评审补丁发布验证流程、启动策略与团队 DAG 依赖修复深度解析【免费下载链接】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-codex仓库中的官方发布就绪评审文档 docs/qa/release-readiness-0.15.1.md 为主体骨架系统拆解 0.15.1 补丁版本2026-04-29的发布准备流程包括直接/非 tmux 启动控制omx --direct与OMX_LAUNCH_POLICY、被动只读状态操作、repo-aware 团队 DAG 依赖重映射、setup/plugin 模式加固以及完整的本地验证证据链。读者读完本文后既能复现 OmX 的补丁发布就绪评审步骤也能理解这些变更在 src/cli/index.ts、src/state/operations.ts、src/team/repo-aware-decomposition.ts 中的底层实现原理。一、0.15.1 是什么补丁发布候选与版本基线0.15.1是 OmX 在0.15.x发布列车上的一个补丁patch版本由官方评审文档定义其候选信息目标版本0.15.1候选源分支dev/origin/dev本地版本号提升前的候选 SHA50b68ee5从候选源可达的基线标签v0.14.3评审日期2026-04-29其中最关键的一条版本约束在文档中专门标注v0.15.0虽然已存在但它不是当前dev发布列车上的祖先提交。因此由标签触发的发布工作流必须使用v0.14.3作为可达的比较基线compare base而不是v0.15.0。这一点在补丁发布实践中非常重要错误的比较基线会让变更差异集diff range失真导致发布说明和评审范围错位。二、发布范围本次补丁覆盖的六类变更根据评审文档的 Scope 节0.15.1作为补丁候选覆盖以下执行路径直接/非 tmux 启动控制direct/non-tmux launch controls被动状态读取passive state readsrepo-aware 团队 DAG 依赖重映射repo-aware Team DAG dependency remapping after task creationsetup/plugin 模式加固setup/plugin-mode hardening经审计的 exec 跟进audited exec follow-upsMCP/runtime 可靠性修复、文档与发布配套。对应的发布说明 docs/release-notes-0.15.1.md 与 CHANGELOG.md## [0.15.1] - 2026-04-29条目提供了逐项的 Highlights 描述下面结合源码逐一展开。2.1 启动策略显式化omx --direct与OMX_LAUNCH_POLICY0.15.1 最大的操作者可见变更是把 leader 启动策略从隐式自动改为显式可控制。核心能力是omx --direct直接启动交互式 leader绕过 OmX 的 tmux/HUD 管理OMX_LAUNCH_POLICYdirect|tmux|detached-tmux|auto通过环境变量显式指定启动策略。默认的交互式启动行为仍然是detached-tmux 托管因此该变更对默认用户无感知只对需要绕过 tmux/HUD 的场景例如无 tmux 环境、CI、嵌入式终端提供逃生通道。源码层面的实现位于 src/cli/index.tsCodexLaunchPolicy类型定义了三态策略inside-tmux | detached-tmux | directsrc/cli/index.ts#L825splitLeaderLaunchPolicyArgs解析命令行参数遇到--direct则显式指定direct遇到--tmux则显式指定detached-tmuxsrc/cli/index.ts#L830-L864resolveEnvLaunchPolicyOverride读取环境变量并做容错auto视为未指定返回默认行为tmux与detached-tmux归一化为detached-tmux非法值会打印一次警告并回退到默认策略src/cli/index.ts#L872-L891resolveCodexLaunchPolicy给出最终决策链显式direct优先 → 已在 tmux 中则inside-tmux→ 显式detached-tmux时若无 tmux 则回退direct→ Windows/非原生 Windows 回退direct→ 非 TTY 回退direct→ 否则 tmux 可用则detached-tmuxsrc/cli/index.ts#L902-L918。命令行帮助文本也明确说明了优先级规则CLI policy flags (--direct/--tmux) overrideOMX_LAUNCH_POLICY; the last flag before--winssrc/cli/index.ts#L373-L382且未设置或为空的环境变量会回到 auto/默认行为。配套的启动回退测试位于 src/cli/tests/launch-fallback.test.ts由 package.json 中的test:recent-bug-regressions:compiled脚本纳入回归车道。2.2 被动状态读取读操作不再产生写副作用评审文档明确指出state_read、state_list_active、state_get_status三类只读操作不再作为读取副作用去初始化.omx/state目录或 tmux-hook 配置。这在 src/state/operations.ts 中可验证state_read分支调用getReadScopedStatePaths只做路径解析随后用existsSync探测并读取 JSON 文件若不存在则直接返回{ exists: false, mode }全程不触发目录创建src/state/operations.ts#L761-L770state_list_active与state_get_status同样属于被动分支src/state/operations.ts#L1134-L1139。而写操作如state_write仍然会先resolveWritableStateScope初始化所需运行时状态。设计意图很清晰MCP 工具、HUD 轮询、状态查询等高频只读调用不应在读的时候悄悄改写磁盘布局——否则会产生难以排查的隐性副作用甚至污染并发写入场景。相关行为由 state 的测试套件如 src/state/tests/operations.test.ts、src/state/tests/single-writer-invariant.test.ts覆盖。2.3 Repo-aware 团队 DAG符号依赖重映射为具体任务 ID团队Team模式下repo-aware 分解DAG 分解在任务创建前只能使用符号节点 IDsymbolic id表达依赖关系。0.15.1 修复了任务创建后的依赖落地符号依赖会在任务创建后重映射为具体任务 ID并在 worker inbox/bootstrap 生成之前把运行时任务的依赖字段补齐。实现证据位于 src/team/repo-aware-decomposition.tsremapRepoAwareDecompositionMetadataToCreatedTasks函数接收规划任务列表含symbolic_id、symbolic_depends_on、lane、filePaths、domains、allocation_reason先建立nodeIdToTaskId映射task.symbolic_id→createdTasks[index].id再为每个已创建任务生成depends_on: symbolicDeps.map((dep) nodeIdToTaskId[dep]).filter(Boolean)从而把符号依赖转成真实任务 ID 并保留symbolic_depends_on原始信息src/team/repo-aware-decomposition.ts#L254-L278。该流程配合 src/team/runtime.ts 在生成 worker inbox/bootstrap 前完成字段 patchTeam 测试套件对此做了回归覆盖。2.4 Setup/plugin 模式加固与 exec 跟进发布范围还包含 setup/plugin 路径的恢复性修复setup 流程保留用户显式选择的 install-modelegacy/plugin在 plugin 模式下安全归档过期的 legacy 资产打通 plugin marketplace 发现package.json 的files字段包含.agents/plugins/marketplace.json文档明确记录直接启动逃生通道--direct/OMX_LAUNCH_POLICYdirect。同时非交互式omx exec作业现在可以通过审计的注入路径接收排队中的跟进指令audited exec follow-ups提升长任务的可控性。2.5 运行时与 Hook 可靠性修复0.15.1 还收拢了一批运行时/hook 修复评审文档与 CHANGELOG 归纳为Stop 生命周期读取偏好 canonical run-stateMCP 状态持久化在传输断开后仍可存活state persistence survives transport disconnectsprompt resume 避免未验证 PID 的硬失败源码日志文本不再误触发 hook 拦截块hook diagnostic false positives降低 macOS 启动轮询压力。这些修复共同构成了补丁级可靠性加固的底色均在本仓库 docs/release-notes-0.15.1.md 与 CHANGELOG.md 中有对应描述。三、变更执行路径审查清单评审文档逐一列出了本次版本中实际变更的执行路径Changed execution paths reviewed这是评审的可追溯性基础审查对象审查结论package.json、package-lock.json、Cargo.toml、Cargo.lock、plugins/oh-my-codex/.codex-plugin/plugin.json发布元数据已对齐到0.15.1CHANGELOG.md、RELEASE_BODY.md、docs/release-notes-0.15.1.md、docs/qa/release-readiness-0.15.1.md发布配套文档已对齐到0.15.1src/state/operations.ts 与 state MCP 测试只读操作保持无副作用写操作仍初始化所需运行时状态src/team/repo-aware-decomposition.ts、src/team/runtime.ts 与 Team 测试符号 DAG 依赖在任务创建后重映射为具体任务 IDsrc/cli/index.ts、README、发布说明与启动回退测试直接/分离 tmux 启动策略与逃生通道已文档化并有测试覆盖注意当前仓库根目录的 package.json 版本已演进为0.21.2本文所述为0.15.1评审时点的快照但这不影响对 0.15.1 评审流程与实现机制的理解启动策略解析、被动状态读取等核心代码模式仍然保留在对应的源码文件中。四、验证证据六道本地发布关卡评审文档以表格形式给出了本次本地发布准备阶段实际执行的验证证据逐项复现如下关卡Gate命令结果备注TypeScript 构建npm run buildPASS本地 0.15.1 版本提升后重建dist/原生 agent 生成校验npm run verify:native-agentsPASS校验通过 20 个可安装原生 agent 与 33 个 setup prompt 资产插件包/镜像校验npm run verify:plugin-bundlePASS校验通过 29 个 canonical skill 目录与插件元数据Lintnpm run lintPASS检查 581 个文件无自动修复应用No-unused 类型检查npm run check:no-unusedPASS以退出码0完成近期 bug 回归专项车道npm run test:recent-bug-regressions:compiledPASS本地 0.15.1 元数据提升后 462 个测试全部通过这些脚本的实际定义可在 package.json 的scripts段找到对应实现verify:native-agents调用node dist/scripts/verify-native-agents.jsverify:plugin-bundle等价于sync-plugin-mirror.js --checktest:recent-bug-regressions:compiled则通过run-test-files.js依次运行 keyword-detector、codex-native-hook、launch-fallback、session、team runtime、hardening-e2e、hook-simplification 等测试文件。这套构建 → 生成资产校验 → lint → 类型检查 → 回归测试的本地关卡组合就是 OmX 发布就绪评审的标准验证骨架。五、已知限制与被跳过的检查评审文档明确列出了本地预发布步骤有意不执行的项防止把本地就绪误读为全量就绪外部 GitHub CI、release tag 创建、npm 发布、GitHub Release 发布不属于本本地准备步骤在外部发布前若 GitHub CI 不可用官方建议补充执行完整npm test、打包安装冒烟packed install smoke、跨操作系统手工检查、Cargo workspace 测试。这也是理解 OmX 发布纪律的关键本地评审只回答代码与配套是否就绪tag/发布环节必须由维护者在 CI 全绿后显式触发。六、评审结论本地准备就绪发布仍须显式触发评审文档给出的最终 Verdict 是Local release prep is ready after the final verification pass.最终验证通过后本地发布准备已就绪。同时附带了明确的发布纪律在 CI 变绿且维护者显式运行 tag/publish 发布流程之前不要为v0.15.1打 tag 或执行发布。这一结论模式Verdict与配套的Scope → Changed paths → Verification evidence → Known limits → Verdict结构构成了 OmX 每个版本 docs/qa 目录下 release-readiness 系列文档的统一模板仓库中release-readiness-0.14.x至release-readiness-0.21.x均遵循该结构可作为理解 OmX 发布质量体系的入口文档。七、如何复现在本地仓库跑一遍 0.15.1 验证流程若要在当前仓库复现这套发布就绪验证以最新代码为准命令与 package.json 一致# 1. 构建 TypeScript 产物到 dist/ npm run build # 2. 原生 agent 生成校验 npm run verify:native-agents # 3. 插件包 / mirror 一致性校验 npm run verify:plugin-bundle # 4. 代码风格检查biome lint src npm run lint # 5. 无未使用变量的类型检查 npm run check:no-unused # 6. 近期 bug 回归专项车道编译后产物 npm run test:recent-bug-regressions:compiled结合文档中的已知限制若需要更完整的发布前置信度官方建议进一步执行完整npm test含构建、三类 verify、能力锁、prompt 指导校验与全量 node 测试、打包安装冒烟与 Cargo workspace 测试。评审证据的原始记录以 docs/qa/release-readiness-0.15.1.md 为唯一事实来源本文的源码级分析均可在上述src/路径与对应测试文件中复核。【免费下载链接】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），仅供参考