OmX 0.12.3 发布就绪报告解读$team提示词路由修正与重复团队启动防护【免费下载链接】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本篇技术指南基于仓库中的 release-readiness-0.12.3.md 发布就绪评估文档结合对应的 release-notes-0.12.3.md 与源码实现完整剖析 OmXOh My codeX0.12.3 这一紧随 0.12.2 的紧凑补丁版本它解决了$team提示词在UserPromptSubmit中的路由正确性问题并为startTeam增加了重复同名校团队的启动防护。读完本文你将掌握该版本的两个核心修复的行为契约、底层实现调用链、测试验证方式以及理解 OmX 发布就绪评审release readiness的完整证据模型可直接复用到后续版本的发布检查中。版本背景为什么会有 0.12.30.12.3 是一个紧贴 0.12.2 的紧凑跟进补丁tight follow-up其发布动机非常明确PR #1364 本应随 0.12.2 一起发布但其冲突解决conflict resolution在 0.12.2 分支截断cut之后才完成因此无法挤进 0.12.2只能单独成版。该 PR 携带两项关键修复$team提示词路由正确性当$team在UserPromptSubmit中被检测到时不再静默地把提示词错误路由misroute到某个不合适的技能或路径而是正确落地团队状态并引导操作者使用omx teamCLI重复团队启动拆除startTeam在遇到同名且仍处于活跃状态的团队时必须在变更任何团队状态或创建工作树之前就拒绝启动。除此之外0.12.3 还同步对齐了 Node 端、Cargo 端、变更日志、发布正文和发布就绪文档等发布配套release collateral。根据 release-readiness-0.12.3.md 的结论该版本在v0.12.2..HEAD的补丁范围内验证通过裁决Verdict为GO就绪度评估日期为 2026-04-08。修复一$team提示词检测与路由修正检测接缝keyword-detector$team的检测与路由发生在 OmX 的关键词检测引擎 src/hooks/keyword-detector.ts 中。在当前 OmX 架构下原生UserPromptSubmit是规范的执行表面canonical execution surface该模块持有关键词注册表、运行时门控与钩子注入的技能/工作流状态。从源码结构看team属于需要显式意图的关键词集合const KEYWORDS_REQUIRING_INTENT new Set([ralph, team, stop, abort, parallel, autoresearch, ultragoal, autopilot]);这意味着普通文本中顺带提到 team 一词不会触发团队技能启动必须匹配到明确的编排式表达。KEYWORD_INTENT_PATTERNS中为team定义了如下触发模式见 src/hooks/keyword-detector.ts$team词首形式(?:^|[^\w])\$(?:team)\b显式提示词引用/prompts:team动词引导式表达use / run / start / enable / launch / invoke / activate / orchestrate / coordinate (a/an/the) team模式/编排式表达team mode / orchestration / workflow / agents对应测试位于 src/hooks/tests/keyword-detector.test.ts其中包括两条反向用例一条验证文件系统/团队状态路径文本不会误触发团队关键词例如.omx/state/team/execute-plan/mailbox/worker-3.json这类路径只作为提示文本出现时detectPrimaryKeyword必须返回null另一条验证偶然出现的散文式用法不会触发团队技能。这正体现了路由正确性的第一层含义既要命中真正意图又不得把路径文本或闲聊误判为技能启动。状态落地seeding 根级 team-state.json修复的第二层含义是状态落地位置与内容。当$team被确认命中后keyword-detector 会执行有状态技能种子化stateful skill seeding。在STATEFUL_SKILL_SEED_CONFIG中团队被配置为team: { mode: team, initialPhase: starting },即团队技能以starting为初始阶段phase。状态文件路径由resolveSeedStateFilePath决定会话作用域session scope写入.omx/state/sessions/sessionId/team-state.json根作用域root scope写入.omx/state/team-state.json。源码注释明确说明根级投影是共享文件两个会话同时激活团队会互相覆盖状态因此读取方优先使用会话作用域路径仅当所有者 session_id 匹配时才回退到根级——这也是 0.12.3 中$team命中UserPromptSubmit时 seed 根级team-state.json这一行为的实现基础。引导而非误路由nudge 到 omx team CLI修复的关键行为变化是不再静默地把$team提示词错误路由而是引导操作者走向正确的执行面。原生钩子 src/scripts/codex-native-hook.ts 中针对不同执行表面注入了不同的团队运行时指令已附着 tmux 运行时的会话Use the durable OMX team runtime via omx team ... for coordinated execution; do not replace it with in-process fanout.使用omx team ...持久化团队运行时进行协同执行不要用进程内扇出替代它运行时语法不明确时If you need runtime syntax, run omx team --help yourself.需要语法时自己运行omx team --help位于 tmux 之外的 native-hook / Codex App 会话明确提示omx team是 CLI/tmux 运行时表面在此处不可直接使用需先从附着 tmux 的 shell 启动 OMX CLI不得用进程内扇出替代。对应测试src/scripts/tests/codex-native-hook.test.ts断言了引导文案的存在消息必须匹配/Use the durable OMX team runtime via \omx team .../以及/run omx team --help yourself/。从实现意图可以推断这一修复堵住了一个真实隐患此前$team提示词可能被关键词引擎静默地映射到某个本地技能状态导致操作者以为团队已经启动实际上团队运行时tmux 会话、worker 面板、任务状态机根本没有被创建。现在检测与引导分离——检测照常 seed 状态但运行时创建交给显式的omx team ...CLI彻底消除提示词被吞掉的歧义。修复二startTeam 重复同名校团队启动防护非破坏性启动守卫第二个修复位于团队运行时 src/team/runtime.ts 的startTeam调用链中。startTeam在正式创建团队之前会调用assertTeamStartupIsNonDestructive非破坏性启动守卫其检查顺序为活跃团队冲突检查通过findActiveTeams查找同一 leader 会话下的活跃团队若已存在则抛出leader_session_conflict同名配置/清单/阶段读取并行读取该团队名的配置readTeamConfig、清单readTeamManifestV2与阶段状态readTeamPhaseState终态豁免若配置与清单都不存在则放行若当前阶段是终态阶段isTerminalPhase说明旧团队已结束允许重新启动同名团队冲突拒绝否则抛出team_name_conflict错误。从调用位置看src/team/runtime.tsassertTeamStartupIsNonDestructive会在任何团队状态变更或工作树worktree配置之前执行且当显示名与内部净化名sanitized name不一致时会分别对两个名称各做一次检查——这是为了防止同一个团队以两种名称绕过多重启动保护。team_name_conflict 的错误契约冲突错误的信息结构是 0.12.3 修复对外呈现的直接接口完整格式为team_name_conflict: active team state already exists for teamName (phase: phase, tmux: tmuxSession). Use omx team status teamName, omx team resume teamName, or omx team shutdown teamName instead of launching a duplicate team.这条错误消息本身就是一份补救操作指南向操作者提供了三条替代路径命令用途omx team status teamName查看该团队当前状态与阶段omx team resume teamName恢复既有团队而非重复启动omx team shutdown teamName关停旧团队后再重新启动阶段phase与 tmux 会话信息来自已持久化的团队阶段状态与配置默认 tmux 会话名为omx-team-teamName默认阶段渲染值为team-exec保证错误信息在状态缺失时仍然可读。测试验证拒绝且零副作用仓库中的测试对这一行为给出了严格约束最直接的是 src/team/tests/runtime.test.ts 中的用例startTeam rejects duplicate active same-name team state without mutating existing files预先以dup-team名称创建团队含任务 existing task以替换任务replacement task再次调用startTeam(dup-team, ...)断言抛出匹配/team_name_conflict: active team state already exists/的错误断言已有文件未被改动afterConfig?.task仍为existing taskcreated_at与启动前一致既有任务的 subject 与 description 均保持不变。另一条用例startTeam blocks duplicate no-session/no-tmux prompt-mode starts with stable cwd leader identity则覆盖了无会话、无 tmux 的提示词驱动启动场景第二次启动必须被拒绝leader_session_conflict: active team exists (...)且不得创建第二个提示词团队的.omx/state/team/状态目录——即被阻止的重复启动不能留下任何残留状态。发布验证证据根据 release-readiness-0.12.3.md 的验证矩阵0.12.3 在v0.12.2..HEAD补丁范围内执行了四道门禁全部通过检查项命令结果构建npm run buildPASS代码风格npm run lintPASS全量测试套件npm testPASS打包安装冒烟npm run smoke:packed-installPASS评审范围覆盖了本次变更的四个维度$team关键词检测与提示词路由接缝src/hooks/keyword-detector.ts、src/hooks/tests/keyword-detector.test.ts原生钩子引导逻辑src/scripts/codex-native-hook.ts、src/scripts/tests/codex-native-hook.test.tsstartTeam重复同名守卫src/team/runtime.ts、src/team/tests/runtime.test.ts发布元数据与文档package.json、package-lock.json、Cargo.toml、Cargo.lock、CHANGELOG.md、RELEASE_BODY.md、docs/release-notes-0.12.3.md。从团队模式配置侧看src/config/team-mode.ts 定义了teamMode开关合法值为enabled/disabled同时支持嵌套配置形态teamMode.enabled、orchestration.team.enabled、features.team状态来源可为 default / env / setup / file / invalid。团队状态根目录则可通过OMX_TEAM_STATE_ROOT环境变量显式指定见 src/team/state-root.ts 的resolveCanonicalTeamStateRoot默认解析为 leader 工作目录下的规范状态根。剩余风险与发布后监控发布就绪文档明确列出了两条剩余风险这是任何GO裁决都不可省略的诚实边界本地验证而非全量 CI 矩阵本次验证是本地一次性通过local verification pass未重跑完整 CI 矩阵因此矩阵维度下的环境差异操作系统、Node 版本、tmux 版本等仍是隐含风险提示词驱动团队启动路径需重点监控PR #1364 触碰的是活的live$team关键词处理与startTeam状态播种逻辑发布后应重点观察提示词驱动团队启动路径是否出现回归——尤其是误触发false positive与漏触发false negative两个方向以及重复启动守卫是否对合法的先 shutdown 再重启流程造成干扰。结论0.12.3 的发布就绪模型0.12.3 的最终裁决为ready for branch push and PR handoff——即该补丁已具备推送分支与提交 PR 的就绪度。从这篇评估文档中我们可以提炼出 OmX 发布就绪评审的通用方法论明确版本定位说明该版本相对前一版本的关系紧凑补丁 vs 功能版本、携带的 PR 及其截断后补发的原因精确圈定评审范围逐文件列出代码接缝与对应测试保证评审范围与变更范围一一对应提供可复现的证据矩阵构建、lint、全量测试、打包安装冒烟四道门禁均以可执行命令形式给出诚实披露剩余风险区分已验证与未验证并对变更热点给出发布后监控建议。对于希望深入 0.12.3 两个修复实现细节的读者建议按以下路径继续阅读仓库源码src/hooks/keyword-detector.ts关键词意图判定与状态播种、src/scripts/codex-native-hook.ts原生钩子的团队引导文案、src/team/runtime.tsstartTeam非破坏性守卫以及两份测试文件中的重复启动用例——它们共同构成了$team路由正确性与重复启动防护的完整证据链。【免费下载链接】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），仅供参考 OmX 0.12.3 发布就绪报告解读：`$team` 提示词路由修正与重复团队启动防护
OmX 0.12.3 发布就绪报告解读$team提示词路由修正与重复团队启动防护【免费下载链接】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本篇技术指南基于仓库中的 release-readiness-0.12.3.md 发布就绪评估文档结合对应的 release-notes-0.12.3.md 与源码实现完整剖析 OmXOh My codeX0.12.3 这一紧随 0.12.2 的紧凑补丁版本它解决了$team提示词在UserPromptSubmit中的路由正确性问题并为startTeam增加了重复同名校团队的启动防护。读完本文你将掌握该版本的两个核心修复的行为契约、底层实现调用链、测试验证方式以及理解 OmX 发布就绪评审release readiness的完整证据模型可直接复用到后续版本的发布检查中。版本背景为什么会有 0.12.30.12.3 是一个紧贴 0.12.2 的紧凑跟进补丁tight follow-up其发布动机非常明确PR #1364 本应随 0.12.2 一起发布但其冲突解决conflict resolution在 0.12.2 分支截断cut之后才完成因此无法挤进 0.12.2只能单独成版。该 PR 携带两项关键修复$team提示词路由正确性当$team在UserPromptSubmit中被检测到时不再静默地把提示词错误路由misroute到某个不合适的技能或路径而是正确落地团队状态并引导操作者使用omx teamCLI重复团队启动拆除startTeam在遇到同名且仍处于活跃状态的团队时必须在变更任何团队状态或创建工作树之前就拒绝启动。除此之外0.12.3 还同步对齐了 Node 端、Cargo 端、变更日志、发布正文和发布就绪文档等发布配套release collateral。根据 release-readiness-0.12.3.md 的结论该版本在v0.12.2..HEAD的补丁范围内验证通过裁决Verdict为GO就绪度评估日期为 2026-04-08。修复一$team提示词检测与路由修正检测接缝keyword-detector$team的检测与路由发生在 OmX 的关键词检测引擎 src/hooks/keyword-detector.ts 中。在当前 OmX 架构下原生UserPromptSubmit是规范的执行表面canonical execution surface该模块持有关键词注册表、运行时门控与钩子注入的技能/工作流状态。从源码结构看team属于需要显式意图的关键词集合const KEYWORDS_REQUIRING_INTENT new Set([ralph, team, stop, abort, parallel, autoresearch, ultragoal, autopilot]);这意味着普通文本中顺带提到 team 一词不会触发团队技能启动必须匹配到明确的编排式表达。KEYWORD_INTENT_PATTERNS中为team定义了如下触发模式见 src/hooks/keyword-detector.ts$team词首形式(?:^|[^\w])\$(?:team)\b显式提示词引用/prompts:team动词引导式表达use / run / start / enable / launch / invoke / activate / orchestrate / coordinate (a/an/the) team模式/编排式表达team mode / orchestration / workflow / agents对应测试位于 src/hooks/tests/keyword-detector.test.ts其中包括两条反向用例一条验证文件系统/团队状态路径文本不会误触发团队关键词例如.omx/state/team/execute-plan/mailbox/worker-3.json这类路径只作为提示文本出现时detectPrimaryKeyword必须返回null另一条验证偶然出现的散文式用法不会触发团队技能。这正体现了路由正确性的第一层含义既要命中真正意图又不得把路径文本或闲聊误判为技能启动。状态落地seeding 根级 team-state.json修复的第二层含义是状态落地位置与内容。当$team被确认命中后keyword-detector 会执行有状态技能种子化stateful skill seeding。在STATEFUL_SKILL_SEED_CONFIG中团队被配置为team: { mode: team, initialPhase: starting },即团队技能以starting为初始阶段phase。状态文件路径由resolveSeedStateFilePath决定会话作用域session scope写入.omx/state/sessions/sessionId/team-state.json根作用域root scope写入.omx/state/team-state.json。源码注释明确说明根级投影是共享文件两个会话同时激活团队会互相覆盖状态因此读取方优先使用会话作用域路径仅当所有者 session_id 匹配时才回退到根级——这也是 0.12.3 中$team命中UserPromptSubmit时 seed 根级team-state.json这一行为的实现基础。引导而非误路由nudge 到 omx team CLI修复的关键行为变化是不再静默地把$team提示词错误路由而是引导操作者走向正确的执行面。原生钩子 src/scripts/codex-native-hook.ts 中针对不同执行表面注入了不同的团队运行时指令已附着 tmux 运行时的会话Use the durable OMX team runtime via omx team ... for coordinated execution; do not replace it with in-process fanout.使用omx team ...持久化团队运行时进行协同执行不要用进程内扇出替代它运行时语法不明确时If you need runtime syntax, run omx team --help yourself.需要语法时自己运行omx team --help位于 tmux 之外的 native-hook / Codex App 会话明确提示omx team是 CLI/tmux 运行时表面在此处不可直接使用需先从附着 tmux 的 shell 启动 OMX CLI不得用进程内扇出替代。对应测试src/scripts/tests/codex-native-hook.test.ts断言了引导文案的存在消息必须匹配/Use the durable OMX team runtime via \omx team .../以及/run omx team --help yourself/。从实现意图可以推断这一修复堵住了一个真实隐患此前$team提示词可能被关键词引擎静默地映射到某个本地技能状态导致操作者以为团队已经启动实际上团队运行时tmux 会话、worker 面板、任务状态机根本没有被创建。现在检测与引导分离——检测照常 seed 状态但运行时创建交给显式的omx team ...CLI彻底消除提示词被吞掉的歧义。修复二startTeam 重复同名校团队启动防护非破坏性启动守卫第二个修复位于团队运行时 src/team/runtime.ts 的startTeam调用链中。startTeam在正式创建团队之前会调用assertTeamStartupIsNonDestructive非破坏性启动守卫其检查顺序为活跃团队冲突检查通过findActiveTeams查找同一 leader 会话下的活跃团队若已存在则抛出leader_session_conflict同名配置/清单/阶段读取并行读取该团队名的配置readTeamConfig、清单readTeamManifestV2与阶段状态readTeamPhaseState终态豁免若配置与清单都不存在则放行若当前阶段是终态阶段isTerminalPhase说明旧团队已结束允许重新启动同名团队冲突拒绝否则抛出team_name_conflict错误。从调用位置看src/team/runtime.tsassertTeamStartupIsNonDestructive会在任何团队状态变更或工作树worktree配置之前执行且当显示名与内部净化名sanitized name不一致时会分别对两个名称各做一次检查——这是为了防止同一个团队以两种名称绕过多重启动保护。team_name_conflict 的错误契约冲突错误的信息结构是 0.12.3 修复对外呈现的直接接口完整格式为team_name_conflict: active team state already exists for teamName (phase: phase, tmux: tmuxSession). Use omx team status teamName, omx team resume teamName, or omx team shutdown teamName instead of launching a duplicate team.这条错误消息本身就是一份补救操作指南向操作者提供了三条替代路径命令用途omx team status teamName查看该团队当前状态与阶段omx team resume teamName恢复既有团队而非重复启动omx team shutdown teamName关停旧团队后再重新启动阶段phase与 tmux 会话信息来自已持久化的团队阶段状态与配置默认 tmux 会话名为omx-team-teamName默认阶段渲染值为team-exec保证错误信息在状态缺失时仍然可读。测试验证拒绝且零副作用仓库中的测试对这一行为给出了严格约束最直接的是 src/team/tests/runtime.test.ts 中的用例startTeam rejects duplicate active same-name team state without mutating existing files预先以dup-team名称创建团队含任务 existing task以替换任务replacement task再次调用startTeam(dup-team, ...)断言抛出匹配/team_name_conflict: active team state already exists/的错误断言已有文件未被改动afterConfig?.task仍为existing taskcreated_at与启动前一致既有任务的 subject 与 description 均保持不变。另一条用例startTeam blocks duplicate no-session/no-tmux prompt-mode starts with stable cwd leader identity则覆盖了无会话、无 tmux 的提示词驱动启动场景第二次启动必须被拒绝leader_session_conflict: active team exists (...)且不得创建第二个提示词团队的.omx/state/team/状态目录——即被阻止的重复启动不能留下任何残留状态。发布验证证据根据 release-readiness-0.12.3.md 的验证矩阵0.12.3 在v0.12.2..HEAD补丁范围内执行了四道门禁全部通过检查项命令结果构建npm run buildPASS代码风格npm run lintPASS全量测试套件npm testPASS打包安装冒烟npm run smoke:packed-installPASS评审范围覆盖了本次变更的四个维度$team关键词检测与提示词路由接缝src/hooks/keyword-detector.ts、src/hooks/tests/keyword-detector.test.ts原生钩子引导逻辑src/scripts/codex-native-hook.ts、src/scripts/tests/codex-native-hook.test.tsstartTeam重复同名守卫src/team/runtime.ts、src/team/tests/runtime.test.ts发布元数据与文档package.json、package-lock.json、Cargo.toml、Cargo.lock、CHANGELOG.md、RELEASE_BODY.md、docs/release-notes-0.12.3.md。从团队模式配置侧看src/config/team-mode.ts 定义了teamMode开关合法值为enabled/disabled同时支持嵌套配置形态teamMode.enabled、orchestration.team.enabled、features.team状态来源可为 default / env / setup / file / invalid。团队状态根目录则可通过OMX_TEAM_STATE_ROOT环境变量显式指定见 src/team/state-root.ts 的resolveCanonicalTeamStateRoot默认解析为 leader 工作目录下的规范状态根。剩余风险与发布后监控发布就绪文档明确列出了两条剩余风险这是任何GO裁决都不可省略的诚实边界本地验证而非全量 CI 矩阵本次验证是本地一次性通过local verification pass未重跑完整 CI 矩阵因此矩阵维度下的环境差异操作系统、Node 版本、tmux 版本等仍是隐含风险提示词驱动团队启动路径需重点监控PR #1364 触碰的是活的live$team关键词处理与startTeam状态播种逻辑发布后应重点观察提示词驱动团队启动路径是否出现回归——尤其是误触发false positive与漏触发false negative两个方向以及重复启动守卫是否对合法的先 shutdown 再重启流程造成干扰。结论0.12.3 的发布就绪模型0.12.3 的最终裁决为ready for branch push and PR handoff——即该补丁已具备推送分支与提交 PR 的就绪度。从这篇评估文档中我们可以提炼出 OmX 发布就绪评审的通用方法论明确版本定位说明该版本相对前一版本的关系紧凑补丁 vs 功能版本、携带的 PR 及其截断后补发的原因精确圈定评审范围逐文件列出代码接缝与对应测试保证评审范围与变更范围一一对应提供可复现的证据矩阵构建、lint、全量测试、打包安装冒烟四道门禁均以可执行命令形式给出诚实披露剩余风险区分已验证与未验证并对变更热点给出发布后监控建议。对于希望深入 0.12.3 两个修复实现细节的读者建议按以下路径继续阅读仓库源码src/hooks/keyword-detector.ts关键词意图判定与状态播种、src/scripts/codex-native-hook.ts原生钩子的团队引导文案、src/team/runtime.tsstartTeam非破坏性守卫以及两份测试文件中的重复启动用例——它们共同构成了$team路由正确性与重复启动防护的完整证据链。【免费下载链接】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），仅供参考