oh-my-codex v0.9.1 热修复发布：packed-install 冒烟测试 hydration 资产本地化全解析

oh-my-codex v0.9.1 热修复发布packed-install 冒烟测试 hydration 资产本地化全解析【免费下载链接】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-codexoh-my-codex v0.9.1 是 Spark Initiative 特性线v0.9.0之上的一个目标明确的补丁热修复发布其核心使命是清除 v0.9.0 的红色发布状态并为打包安装packed-install冒烟测试提供可靠的可验证性。本文将以 docs/release-notes-0.9.1.md 为主线结合仓库中的 冒烟测试实现 与其 测试用例深入拆解这次热修复的来龙去脉、变更内容、发布定位与本地验证流程帮助读者理解 oh-my-codex 的发布治理模型与打包安装验证机制。为什么需要 v0.9.1红色发布状态的由来在 oh-my-codex 的发布历史上v0.9.0 是一个被标记为**历史性红色historically red**的发布。这意味着该标签对应的发布流程存在缺陷不能作为干净的发布基线被下游引用。根本原因在于打包安装冒烟测试所依赖的 hydration 资产修复smoke hydration fix在 v0.9.0 打标签之后才合入dev分支PR #806hotfix commitd86165dfix(release): localize smoke hydration assets。也就是说v0.9.0 的发布时刻打包安装冒烟测试仍在使用只在源码检出布局source checkout layout下才有效的路径无法真实模拟用户安装后的行为因此该发布被判定为红。v0.9.1 正是为清除这一状态而从main分支构建的补丁热修复发布v0.9.0保持历史红色记录不变v0.9.1携带合入的 hydration 修复成为 Spark Initiative 特性线以 0.9.0 为基础特性发布的干净替代发布clean superseding release除热修复路径和替代发布所需的版本/元数据更新外不引入任何新的功能范围。这种红发布保留历史记录、后置修复发布接替的模式保证了发布历史的事实准确性也让下游用户永远有一个可引用的干净标签。核心热修复packed-install 冒烟 hydration 资产本地化修复内容修复的核心表述是The packaged-install smoke flow now localizes hydration assets into the test workspace instead of relying on paths that are only valid in the source checkout layout.即打包安装冒烟流程现在将 hydration 资产本地化到测试工作区test workspace中而不再依赖仅在源码检出布局下才成立的路径。为什么要这样做在 v0.9.0 及之前冒烟测试的 hydration 资产引用的是源码目录中的固定路径。当用户通过npm install -g oh-my-codex安装打包产物后这些路径并不存在冒烟测试就无法真实反映打包安装后的运行时行为。将资产复制并解析到本地冒烟工作区使发布验证与打包安装的实际行为更一致。涉及的变更文件原文档记录的两个变更文件在仓库中已迁移至 TypeScript 源码目录原路径v0.9.1当前仓库路径scripts/smoke-packed-install.mjssrc/scripts/smoke-packed-install.tsscripts/__tests__/smoke-packed-install.test.mjssrc/scripts/tests/smoke-packed-install.test.ts源码级印证冒烟测试在验证什么从当前仓库的 smoke-packed-install.ts 可以看到这套冒烟测试已经演进为覆盖大量打包安装关键面的验证体系1. 核心启动命令冒烟PACKED_INSTALL_SMOKE_CORE_COMMANDS验证打包产物在隔离环境下能正常执行最基础的引导命令export const PACKED_INSTALL_SMOKE_CORE_COMMANDS [ [--help], [version], [api, --help], [sparkshell, --help], ] as const;2. 平台感知的运行时解析resolvePackedSmokeRuntimeBinary区分 Linuxomx-runtime与 Windowsomx-runtime.exe并校验候选路径必须是绝对路径、必须是可执行常规文件缺失时提示run npm run build:runtime。3. 探测环境隔离buildPackedProbeEnv剥离环境中的OMX_RUNTIME_BINARY等环境变量干扰支持默认回落到仓库target/debug/omx-runtime、缺失不注入变量、显式指定绝对路径三种供给模式。4. PATH 失败闭合替换replacePathKeyCaseInsensitive大小写不敏感地替换 PATH 键兼容 Windows 的Path剔除可能冒名顶替的 decoy 运行时实现 fail-closed 隔离。5. 工作目录保持校验assertPackedLaunchCwdPreserved允许文件系统别名symlink 指向同一真实目录拒绝不同目录。6. Codex 版本探测与 app-server JSON-RPC 客户端固定 Codex 版本PINNED_CODEX_VERSION 0.142.5按 PATH 顺序逐个探测候选上限 32 个唯一候选、5 秒全局截止接受精确版本输出codex-cli 0.142.5stderr 仅允许warning:/note:良性诊断拒绝任何变体。随后通过换行分隔的 JSON-RPC 协议与 Codex app-server 交互initialize→initialized→hooks/list→config/batchWrite。7. 托管 hook 信任状态回归验证恰好 7 个 OMX 生成的 hook 信任键MANAGED_CODEX_HOOK_EVENTSSessionStart、PreToolUse、PostToolUse、UserPromptSubmit、PreCompact、PostCompact、Stop拒绝陈旧/多余/畸形的hooks.state条目包括__proto__原型污染键并要求写入隔离的用户配置。8. 指令回归矩阵PACKED_INSTALL_NATIVE_HOOK_REGRESSION_PROMPTS数百条针对$ralplan、$autopilot、$team、$ultragoal等技能令牌的提示词回归用例覆盖全角标点、阿拉伯语逗号、易混淆 Unicode 字符、markdown 围栏边界、否定语义、别名链等极端情况验证 UserPromptSubmit 阶段的技能激活与停止块行为。对应的 测试用例 逐一断言这些行为例如验证探测环境剥离环境变量、PATH 去重后按序探测 32 个候选、损坏 shebang 与悬空候选不被当作缺失、超时候选不阻塞后续候选、不支持的 Codex 版本直接报Unsupported installed Codex version for the 0.142.5 boundary等。值得注意的是上述内容反映的是当前仓库中该冒烟脚本的演进状态v0.9.1 当时的变更范围严格限于文档所述的 hydration 资产本地化。这正说明该修复为后续发布验证能力的持续增强奠定了基线。发布定位历史记录与干净替代release notes 明确给出了三组发布定位事实基础特性发布仍为Spark Initiativev0.9.0历史性备注v0.9.0 保持红色因为发布冒烟热修复在该标签之后才落地干净替代发布v0.9.1。同时docs/release-body-0.9.1.md 与 docs/qa/release-readiness-0.9.1.md 也一致强调同一口径v0.9.0remains historically red;v0.9.1is the clean superseding release with the packed-install smoke hydration hotfix.这种一致性贯穿 release notes、release body 与 QA 就绪报告三份文档是发布治理中单一事实来源的体现。本地发布验证流程推荐发布消息release-body 与 QA 就绪报告给出了 v0.9.1 的本地发布关键验证清单涵盖版本同步、静态检查、全量测试、冒烟与打包产物node scripts/check-version-sync.mjs --tag v0.9.1 npm run lint npx tsc --noEmit npm run check:no-unused npm test node --test scripts/__tests__/smoke-packed-install.test.mjs npm run build:full npm run smoke:packed-install npm pack --dry-run对照 package.json 中当前仓库的脚本定义可以看到相关命令的演进形态build:full: npm run build npm run build:explore:release npm run build:sparkshell npm run build:api—— 全量构建已扩展为同时构建 TS、explore harness、sparkshell 与 api 多个产物smoke:packed-install: npm run build:runtime node dist/scripts/smoke-packed-install.js—— 打包安装冒烟现在先构建 Rust 运行时再执行编译后的冒烟脚本。实测通过证据docs/qa/release-readiness-0.9.1.md 记录了 v0.9.1 的本地验证结果GO本地发布关键门槛全部通过检查项命令结果版本同步node scripts/check-version-sync.mjs --tag v0.9.1PASSpackage0.9.1 workspace0.9.1 tagv0.9.1Lintnpm run lintPASS337 个文件72ms无修复TypeScript noEmitnpx tsc --noEmitPASSNo-unused 门槛npm run check:no-unusedPASS全量测试npm testPASS2397 pass / 0 fail冒烟测试覆盖node --test scripts/__tests__/smoke-packed-install.test.mjsPASS发布构建npm run build:fullPASS打包安装冒烟npm run smoke:packed-installPASSpacked install smoke: PASS打包 tarball 试运行npm pack --dry-runPASS生成oh-my-codex-0.9.1.tgz推荐发布消息release notes 建议使用保持历史记录准确的语言原样复用即可v0.9.0remains historically red;v0.9.1is the clean superseding release with the packed-install smoke hydration hotfix.关联上游背景Spark Initiative 的打包分发契约虽然 v0.9.1 本身不引入新功能但要理解这次热修复为何重要需要回顾其上游基础发布 docs/release-notes-0.9.0.md 中定义的 Spark Initiative 分发契约用户可通过npm install -g oh-my-codex正常安装 OMXnpm 包有意不直接捆绑全部原生二进制打标签的发布会为omx-explore-harness与omx-sparkshell发布跨平台原生归档打包安装通过native-release-manifest.json从 GitHub Release 资产中 hydration 匹配的原生二进制CI 直接验证 Rust 路径显式 Rust 工具链、cargo fmt --all --check、cargo clippy --workspace --all-targets -- -D warnings。由于打包安装依赖发布后 hydration 原生资产这一动态流程冒烟测试能否在本地工作区真实模拟该流程直接决定了发布的可信度。v0.9.1 的 hydration 资产本地化修复正是为了让冒烟测试不再依赖源码布局的幸运路径从而守住这条分发契约的最后一道闸门。小结v0.9.1 是一个规模极小但定位清晰的发布它用一次针对性的 hydration 资产本地化修复清除了 Spark Initiative 线上的红色发布状态确立了v0.9.0 历史红色、v0.9.1 干净替代的发布口径。从仓库现状回看这套 packed-install 冒烟验证已经从单一修复点演化为覆盖启动命令、平台运行时解析、环境隔离、Codex 版本钉扎与 hook 信任状态回归的完整发布防线——这正是 src/scripts/smoke-packed-install.ts 及其测试所持续守护的内容。对关注 oh-my-codex 发布治理与打包验证机制的读者而言v0.9.1 是一个理解如何干净地纠正一个红色发布的典型样本。【免费下载链接】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），仅供参考