oh-my-codex 0.18.11 发布就绪检查全解析explore 硬弃用、Spark 路由诊断与版本化验证流程【免费下载链接】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本文基于 oh-my-codex 仓库的发布就绪检查文档 docs/qa/release-readiness-0.18.11.md系统拆解 0.18.11 版本从功能范围、PR 清单、版本同步审计到本地验证与 CI 发布门禁的完整发布流程。读完本文你将掌握该项目的发布就绪判定标准、omx doctor新增的 Spark/model lane 路由诊断原理、omx explore硬弃用后的迁移路径以及如何用check-version-sync.js、npm pack --dry-run等命令复现一次可靠的版本发布前验证。版本范围与发布时间线0.18.11 是紧跟在v0.18.10之后的一个清理型cleanup补丁版本其版本边界定义非常精确前一版本 Tagv0.18.10候选分支发布准备期使用专用 worktree 分支omx-release-0.18.11代码源来自origin/dev冻结候选 commit06baf8f4e41541778835686f7696b95cd2b39316对应提交信息为fix(doctor): add Spark/model lane routing diagnostic (#2757) (#2758)对比区间v0.18.10..06baf8f4共7 个 commit目标发布 Tagv0.18.11在分支 CI 与 main 晋升通过后创建血缘校验git merge-base --is-ancestor v0.18.10 06baf8f4返回 true确认前一 Tag 确实是当前候选的祖先保证版本区间内无分支漂移Dev HEAD CI 预检GitHub Actions run27171589905在06baf8f4上 completed/success这种先冻结 commit → 校验血缘 → 预跑 CI → 本地验证 → 再推 tag的顺序是该仓库发布流程的固定节奏任何发布候选都必须先证明自己是基于上一版本之上的线性演进才能进入后续验证环节。发布范围四项清理性变更0.18.11 打包了0.18.10之后的清理列车cleanup train共四个维度omx explore命令面硬弃用移除剩余的对omx explore的全局 AGENTS 指引提及omx doctorSpark/model lane 路由诊断新增诊断项排查 Spark 配额闲置问题tmux HUD 启动拆分保护在局促cramped的既有 tmux 窗口中跳过启动时的 HUD 拆分Catalog wiki skill manifest 条目为 wiki skill 补充 catalog 清单条目这四个变更覆盖了 CLI 面explore 弃用、诊断面doctor、HUD 运行时面tmux 拆分和目录元数据面catalog体现了该版本清理 加固的整体定位。合并 PR 清单PR类型内容#2746feat(explore)hard-deprecateomx explore命令面关联 #2744、#2745#2747chore(catalog)添加 wiki skill manifest 条目#2750fix(agents)从全局 AGENTS 指引中移除剩余的omx explore提及关联 #2749#2755fix(hud)在局促的既有 tmux 窗口中跳过启动时 HUD 拆分关联 #2754#2758fix(doctor)新增 Spark/model lane 路由诊断关联 #2757此外对比区间内还有两个无对应 PR 的直接提交direct-to-dev docs commit0d7a3899— docs(model)澄清 Codex 模型迁移切换指引#27486567fd3b— docs(model)回滚被错误归属的模型切换指引净效果为无文档变更两个文档提交一加一减相互抵消因此最终净变更仍是上述 5 个 PR 覆盖的功能面。Issue 层面发布准备期没有针对本区间的 open issue 被追踪closed issue 的覆盖情况由上述 PR 清单代表。omx explore硬弃用从命令面到源码实现本次发布最核心的变更是omx explore命令面的硬弃用。在 src/cli/explore.ts 中可以找到完整的弃用语义omx explore is hard-deprecated and the direct command surface has been removed. Use normal Codex repository inspection tools/subagents for read-only repository lookups. Use omx sparkshell -- command only for explicit shell-native read-only evidence or --tmux-pane summaries.关键点在于**硬弃用hard-deprecate**与软弃用的区别旧的兼容形式omx explore --prompt prompt、omx explore --prompt-file file全部有意失败fail intentionally唯一保留的入口是omx explore --help用于展示弃用说明与迁移指引源码层面exploreCommand仅在参数全部为帮助标志--help/-h/help时输出帮助文本其余任何调用都会直接throw new Error(...)抛出包含弃用信息的错误见 src/cli/explore.ts这种非帮助即报错的实现保证了旧脚本一旦触发omx explore会立刻得到明确反馈而不是静默降级。迁移路径按 src/cli/explore.ts 中的EXPLORE_HELP说明用户应迁移到两条路径普通只读仓库查询直接使用 Codex 标准的仓库检查工具/subagent无需任何 OMX 扩展命令shell 原生只读取证使用omx sparkshell -- command执行显式的 shell 原生只读命令或使用--tmux-pane摘要兼容路由的残留与诊断虽然命令面已移除但兼容路由开关USE_OMX_EXPLORE_CMD在 doctor 中仍被检查。src/cli/doctor.ts 中的checkExploreRoutingFromState会区分三种来源环境变量来源envUSE_OMX_EXPLORE_CMD被设置且为启用值时输出 warn建议移除USE_OMX_EXPLORE_CMD或置 0配置文件来源config在config.toml的[shell_environment_policy.set]下设置USE_OMX_EXPLORE_CMD 0为推荐做法若仍为启用值则输出 warn默认来源defaultconfig.toml不存在或未设置时直接判定为deprecated by default状态 pass与此同时checkExploreHarnesssrc/cli/doctor.ts在既无OMX_EXPLORE_BIN覆盖、又未启用兼容路由时会输出skipped: omx explore is hard-deprecated and explore routing is disabled by default; use omx sparkshell for shell-native read-only evidence这印证了弃用后的默认行为explore harness 检查被跳过而非执行只有显式覆盖OMX_EXPLORE_BIN或残留路由开关才触发进一步检查。omx doctorSpark/model lane 路由诊断#2758本次发布中技术含量最高的新增功能是 src/cli/doctor.ts 中的checkSparkRouting诊断。它的目标是解决一个真实痛点Spark lane 配额如gpt-5.6-luna对应的快速模型配额已正确接线解析却始终未被消耗。诊断输出面三条 lane 的模型解析诊断首先汇总当前生效的模型路由全景lanes: frontierfrontier模型, standardstandard模型, sparkspark模型 (source: 来源)frontier / standard / spark 三条 lane 的默认模型分别由getMainDefaultModel、getStandardDefaultModel、getSparkDefaultModel解析见 src/agents/native-config.ts 的导入以及 src/agents/native-config.ts 处 Spark 模型的解析调用spark模型来源通过resolveSparkModelSource单独判定模型类别体系定义在 src/agents/definitions.tsmodelClass取值为frontier | standard | fast其中fast类即 Spark lane 的挂靠目标四类可诊断问题诊断会逐一检查所有可安装的 Spark lane agentgetInstallableSparkLaneAgentNames即modelClass fast的原生 agent并报告以下问题agent toml 缺失agent.toml不存在于paths.agentsDir下 → 建议omx setup --force无 model 字段 / 模型与解析结果不一致agent.toml中的 model 与解析出的 Spark 默认模型不同 → 判定为 stale install建议omx setup --force与显式 agentModels 覆盖不一致agent 存在agentModels.agent显式覆盖时toml 内 model 必须与之吻合provider 路由异常两类子问题toml 内model_provider与 config 根 provider 不一致toml 内model_provider为非默认 provider非openai——此时会提示原生 Codex Spark 配额只有在 Spark 由默认 provider 服务时才会消耗通过时的输出所有问题清零后诊断返回 pass并附带接线汇总Spark-lane native agent(s) wired: agent1 - 模型 (provider: provider), ... If Spark quota is still unused, the leader may not be delegating read-only lookups to the Spark lane, or the Codex usage view may lag.值得注意最后这句即使一切接线正确Spark 配额仍可能闲置——此时问题不在配置而在运行时行为leader 未把只读查询委托给 Spark lane或 Codex 用量视图存在滞后。这体现了该诊断的设计边界它只负责验证配置接线这一层不越权声称能诊断所有配额问题。tmux HUD局促窗口中的启动拆分保护#2755第三个运行时层面的变更是 HUD 启动逻辑当用户已身处一个局促行数不足的既有 tmux 窗口时跳过启动时的 HUD 拆分避免挤压原有工作区。仓库中存在HUD_TMUX_MIN_LAUNCH_WINDOW_HEIGHT_LINES常量见 src/hud/constants.ts并在 src/hud/tests/reconcile.test.ts 中与HUD_TMUX_HEIGHT_LINES、HUD_TMUX_ULTRAGOAL_HEIGHT_LINES一同被测试引用其语义即启动 HUD 拆分所需的最小窗口高度。HUD 相关的窗口几何测试paneWidth/paneHeight/windowHeight 组合大量存在于 src/hud/tests/reconcile.test.ts用于验证各种窗口尺寸下的拆分决策。这一变更的实战意义是对在窄小终端窗口内已开启多个 pane 的用户HUD 启动不应再强行插入造成布局被破坏取而代之地HUD 会跳过该次拆分待窗口空间充足时再行初始化。从仓库结构看HUD 逻辑分散在 src/hud 下的constants.ts、reconcile.ts、tmux.ts等模块测试则通过reconcile.test.ts中构造的 pane 几何数据模拟真实 tmux 布局。Catalog wiki skill manifest 条目#2747第四个变更属于元数据层为 wiki skill 补充 catalog manifest 条目。在 src/catalog/manifest.json 中可以看到{ name: wiki, category: utility, status: active }wiki 被归类为utility工具类skill状态为activesrc/catalog/installable.ts 将wiki列为SETUP_ONLY_INSTALLABLE_SKILLS即仅在 setup 阶段安装的 skill对应测试 src/catalog/tests/schema.test.ts 明确断言includes wiki as an active utility skill并校验其category utility与status active生成的公开目录 src/catalog/generated/public-catalog.json 同步包含wiki条目该变更的意义在于catalog 是项目 skill 市场的单一事实来源SSOTwiki skill 此前可能因 manifest 缺失而无法被安装器正确识别或展示补齐条目后保证了 catalog 生成的公共目录、schema 校验与安装逻辑三者的自洽。版本与 lockfile 审计发布就绪检查中版本号在所有声明位置保持一致是硬性要求。0.18.11 的审计覆盖了根 package.json 与 package-lock.json升至0.18.11根 Cargo.toml workspace package 版本及根 Cargo.lock 中的全部 workspace 包omx-api、omx-explore-harness、omx-mux、omx-runtime、omx-runtime-core、omx-sparkshell均升至0.18.11plugins/oh-my-codex/.codex-plugin/plugin.json同步至0.18.11版本一致性由专用脚本 src/scripts/check-version-sync.ts 强制校验。该脚本会读取根package.json与Cargo.toml的[workspace.package].version依次检查各 crateomx-api、omx-explore、omx-runtime-core、omx-mux、omx-runtime、omx-sparkshell的Cargo.toml是否使用version.workspace true继承 workspace 版本传入--tag v0.18.11时额外校验 tag 必须等于v${package.json 版本}0.18.11 的校验结果为PASS (package0.18.11 workspace0.18.11 tagv0.18.11)这一环节保证了 npm 包版本、Rust workspace 版本与 Git tag 三者绝不会出现发布后才发现版本号漂移的尴尬。本地验证证据链八项检查全部 PASS发布准备在专用 worktreeomx-release-0.18.11中执行以下为本地验证的完整清单所有日志留存于.omx/release-0.18.11/logs/检查项命令结果依赖安装npm ciPASS构建npm run buildPASS版本同步node dist/scripts/check-version-sync.js --tag v0.18.11PASSCLI 帮助面node dist/cli/omx.js --helpPASS健康诊断node dist/cli/omx.js doctorPASS13 项通过、4 项环境相关警告、0 项失败打包预演npm pack --dry-runPASSoh-my-codex-0.18.11.tgz包大小 3.9 MB解包后 24.2 MB3049 个文件打包安装冒烟npm run smoke:packed-installPASS空白校验git diff --checkPASS发布说明生成node dist/scripts/generate-release-body.js ... --current-tag v0.18.11 --previous-tag v0.18.10通过生成内容保留完整 PR 清单、## Contributors段与**Full Changelog**: v0.18.10...v0.18.11行几点值得展开的细节node dist/cli/omx.js doctor的13 passed / 4 warnings / 0 failed直接反映本文前述的新增诊断Spark routing、Explore routing 等已纳入默认诊断套件并在此版本上全绿npm pack --dry-run的数字3.9 MB 压缩包、24.2 MB 解压、3049 文件可作为该版本包体积的基线后续版本可据此对比体积漂移generate-release-body.js在本地打一个注解v0.18.11tag 后即可生成最终 release body且必须保留完整对比区间 PR 清单与 Contributors 段——这保证了 GitHub release 正文与合并历史严格对应CI 与发布门禁尚未通过的最终关卡截至该文档定稿远程侧门禁仍处于 pending 状态共五道Release-prepdevCI 绿等待 push/merge 到 dev 后触发Main promotion CI 绿等待 main 快进fast-forward后触发Tag 触发的 release workflow等待v0.18.11tag 推送GitHub release 证明pendingnpm 发布证明pending这一本地全绿、远程待验的划分很关键本地验证只能证明这份代码在本地是可构建、可安装、可运行的而最终的发布结论必须依赖远程 CI 的独立证据——GitHub Actions 在 dev 分支、main 分支、tag 三个触发点上的绿标以及 GitHub release 与 npm registry 上的实际产物。就绪结论与可复用的发布流程0.18.11 的最终裁决是本地发布准备已就绪可推送版本同步、构建、CLI 冒烟--help、doctor、包 dry-run、打包安装冒烟、release body 生成全部通过。远程分支 CI、main 晋升、tag 工作流、GitHub release 证明与 npm 证明是剩余的最后发布门禁。从这个案例可以提炼出该项目可复用的发布准备范式冻结与血缘锁定候选 commit用git merge-base --is-ancestor证明与前一 tag 的线性关系范围盘点通过 PR 清单 无 PR 直提交清单完整界定净变更版本同步审计check-version-sync.js统一 npm、Rust workspace 与 tag 三处版本本地冒烟矩阵npm ci→npm run build→ CLI--help/doctor→npm pack --dry-run→smoke:packed-install→git diff --check→ release body 生成远程门禁分离将本地就绪与远程发布完成明确区隔任何一步 pending 都不允许宣布发布完成对想要复现或扩展该流程的读者可直接阅读 docs/qa/release-readiness-0.18.11.md 原文、src/scripts/check-version-sync.ts 的版本校验实现以及 src/cli/doctor.ts 中 Spark 路由诊断的完整判定逻辑——这三处构成了发布门禁 → 版本一致性 → 运行时健康诊断的完整证据链。【免费下载链接】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），仅供参考