一次“GO”是怎么挣来的oh-my-codex 0.9.0 发布就绪验证与原生资产分发实践【免费下载链接】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 仓库中 0.9.0 发布就绪评审文档 为主线完整还原一个携带 Rust 原生二进制的 CLI 项目在打 tag 前的验证闭环评审范围界定、20 项冒烟与测试证据、版本同步机制、打包分发契约与风险注记。读完后你可以掌握一套可复用的“发布就绪release readiness”核查方法并理解该项目“npm 包不带原生二进制、由 GitHub Release 资产按需水合hydration”的原生资产分发设计。背景0.9.0 要带什么上发布列车就绪文档的头部信息给出了基本盘日期 2026-03-12、目标版本0.9.0、本地结论GO且版本 bump 完成后已在dev分支重跑通过发布门禁。文档的“评审范围Scope reviewed”列出了四个板块v0.8.15之后未发布的dev工作Spark Initiative相关能力面omx explore默认只读探索入口omx sparkshellRust 驱动的 shell 检查 sidecar符合条件的只读 shell 任务从 explore 路由到 sparkshell原生发布流水线工作跨平台原生资产发布、发布清单release manifest生成、packed-install 冒烟门禁、build:full工作流验证0.9.0的发布说明与 QA 草稿产出对应 docs/release-notes-0.9.0.md。这个范围不是空话它直接对应仓库里的构建脚本。package.json 中的build:full定义为build:full: npm run build npm run build:explore:release npm run build:sparkshell npm run build:api即 TypeScript 主构建、explore harness 发布构建、sparkshell 构建、api 构建四段串联——这正是文档中“build:fullworkflow validation”一项检查的落地对象。crates/omx-explore、crates/omx-sparkshell 等 Cargo 工作区成员则是cargo build -p omx-explore-harness、cargo build -p omx-runtime的构建目标。验证证据清单20 项检查全量继承就绪文档的核心是一张 20 行的验证证据表每一行都给出检查名、可复制命令和结果。下表完整保留原文档内容检查命令结果完整源码构建npm run build:fullPASSCLI help 冒烟node bin/omx.js --helpPASS版本冒烟node bin/omx.js versionPASSoh-my-codex v0.9.0版本同步node scripts/check-version-sync.mjs --tag v0.9.0PASSAsk help 冒烟node bin/omx.js ask --helpPASSHUD help 冒烟node bin/omx.js hud --helpPASSDoctor 冒烟node bin/omx.js doctorPASS10 passed, 0 warnings, 0 failedStatus 冒烟node bin/omx.js statusPASSSetup dry-run 冒烟node bin/omx.js setup --dry-runPASSExplore help 冒烟node bin/omx.js explore --helpPASSExplore prompt-file 冒烟node bin/omx.js explore --prompt-file /tmp/omx-explore-smoke.txtPASSExplore→sparkshell 路由冒烟OMX_SPARKSHELL_LINES1 node bin/omx.js explore --prompt git log --oneline -10PASSsummary 输出Sparkshell help 冒烟node bin/omx.js sparkshell --helpPASSSparkshell 直跑冒烟node bin/omx.js sparkshell git --versionPASSgit version 2.34.1Sparkshell summary 冒烟OMX_SPARKSHELL_LINES1 node bin/omx.js sparkshell git log --oneline -10PASSsummary 输出Sparkshell tmux-pane 冒烟node bin/omx.js sparkshell --tmux-pane %2141 --tail-lines 120PASS全量测试npm testPASS2375pass /0fail打包 tarball 干跑npm pack --dry-runPASSoh-my-codex-0.9.0.tgzExplore 验证泳道npm run test:explorePASS39pass /0failSparkshell 验证泳道npm run test:sparkshellPASSRust 套件32 11 50fail说明表中命令为 0.9.0 评审时点的原始记录入口为bin/omx.js、同步脚本为.mjs形式当前仓库中对应物已演进为dist/cli/omx.js入口与 src/scripts/check-version-sync.ts编译后运行检查语义保持一致。版本同步检查到底查了什么check-version-sync --tag v0.9.0这一项不是形式检查。从当前源码 src/scripts/check-version-sync.ts 可以看到它的完整判定逻辑读取根目录package.json的version用 TOML 解析根 Cargo.toml 的[workspace.package].version要求两者相等逐个检查omx-api、omx-explore、omx-runtime-core、omx-mux、omx-runtime、omx-sparkshell六个 crate 的Cargo.toml必须声明version.workspace true防止某个 crate 的版本号被单独漂移若传了--tag v0.9.0则断言 tag 必须精确等于v${package.json version}。任何一条不满足都会打印[version-sync] ...并以非零码退出。这条门禁的意义在于TS 侧包版本与 Rust 工作区版本、git tag 三者强绑定杜绝“npm 装到 0.9.0、原生资产却按 0.8.x 清单解析”的错位。打包冒烟为什么npm pack --dry-run是发布级检查package.json 的files字段显式列出打包内容dist/、crates/、skills/、prompts/、templates/、src/scripts/、plugins/等并带有!crates/**/.omx/**排除规则同时prepack链最后一步是clean:native-package-assetspostpack再次执行清理。也就是说npm 包刻意不包含已暂存的原生二进制——这解释了文档风险注记中“npm pack --dry-run保持绿色很重要因为打包安装会故意排除 staged 原生二进制真正的二进制必须由发布工作流以 GitHub Release 资产形式补齐”这句话。配套的 packed-install 冒烟脚本是 src/scripts/smoke-packed-install.ts其核心命令集定义为export const PACKED_INSTALL_SMOKE_CORE_COMMANDS [ [--help], [version], [api, --help], [sparkshell, --help], ] as const;即把真实 tarball 安装到隔离目录后逐条执行核心命令验证产物可用。文档中npm pack --dry-run产出oh-my-codex-0.9.0.tgz这一行与该脚本共同构成“打包形态”的双重验证干跑验证清单完整性冒烟脚本验证安装后行为。分泳道测试explore 与 sparkshell 为什么单独立道npm run test:explore与npm run test:sparkshell在文档中各自独立报数39 passRust 套件32 11 5。对照 package.json 脚本定义可以印证“泳道”的构成test:explorecargo test -p omx-explore-harness加三个 Node 测试文件explore CLI、explore 路由、explore→sparkshell 引导契约test:sparkshell委托给 src/scripts/test-sparkshell.ts驱动 crates/omx-sparkshell 下的 Rust 测试套件。这种“Rust 套件 契约级 Node 测试”组合的方式使得文档中 Explore 泳道 39 个用例、Sparkshell 泳道三组 Rust 套件通过这类精确数字成为可信的发布证据而不是笼统的一句“测试通过”。发布形态证据用数字描述这次发布文档的“Current release-shape evidence”一节用五个事实固化了发布形态当前包版本0.9.0仓库内最新已有 git tagv0.8.15当前分支dev未发布头与 tag 的差距55 个非合并提交未发布 diff149 个文件变更12,325 / -254。同窗口的 docs/release-notes-0.9.0.md 给出了相互印证的口径提交窗口 2026-03-10 至 2026-03-12 的 55 个非合并提交、同样的 149 文件 / 12,325 / -254 快照并列出代表性提交如e8e7594只读 shell 任务经 sparkshell 路由、23d1cf5统一跨平台原生发布、559089f增加 packed install 冒烟门禁。QA 草稿与发布说明使用同一组统计数字本身就是“发布物料一致性”的证据。原生分发契约0.9.0 的第一风险面文档风险注记第一条直言“首要回归面是新的原生分发契约hydration、fallback 顺序、跨平台资产解析。”结合源码可以把这句话展开成具体机制。二进制解析的 fallback 顺序src/cli/sparkshell.ts 定义了 sparkshell 原生二进制的候选路径族打包路径bin/native/platform-arch[-libc]/omx-sparkshellLinux 下按 musl/glibc 偏好展开多个候选仓库本地构建路径target/release/omx-sparkshell以及嵌套的native/omx-sparkshell/target/release/...环境覆盖OMX_SPARKSHELL_BIN直接指定二进制绝对路径或相对cwd解析。resolveSparkShellBinaryPath的判定顺序是先看OMX_SPARKSHELL_BIN覆盖再依次尝试水合缓存候选、打包产物、仓库本地构建。这与 docs/release-notes-0.9.0.md 中“运行时 fallback 顺序在 env 覆盖、水合缓存、打包产物、仓库本地构建之间保持显式”的表述一一对应。水合hydration从哪里来发布说明明确npm 包不直接捆绑全部原生二进制带 tag 的发布会发布omx-explore-harness与omx-sparkshell的跨平台原生归档打包安装通过native-release-manifest.json从 GitHub Release 资产中水合匹配的二进制。package.json 中的verify:native-agents对应 src/scripts/verify-native-agents.ts与build:explore:release/build:sparkshell脚本则分别承担清单校验与归档构建两端。文档“剩余发布动作”一节列出的 GitHub Actions 校验项——原生资产发布、原生资产清单校验、packed install 冒烟校验、npm publish——正是这条链路的四个闸门。tmux-pane 摘要操作者关键特性而非内部细节风险注记第三条把omx sparkshell --tmux-pane定性为“团队调试的操作者关键特性”。从 src/cli/sparkshell.ts 的用法文案可以确认其参数契约Usage: omx sparkshell command [args...] or: omx sparkshell [--json] [--budget chars] command [args...] or: omx sparkshell --shell shell command or: omx sparkshell --tmux-pane pane-id [--tail-lines 100-1000]要点包括shell 元字符仅在显式--shell时才被解释默认走直接 argv 执行tmux pane 模式是显式 opt-in先抓取更大的 pane 尾部再做原始/摘要处理--tail-lines取值范围 100–1000文档冒烟用例中的--tail-lines 120正落在该区间内。此外还有相关环境变量OMX_SPARKSHELL_MODEL/OMX_SPARKSHELL_FALLBACK_MODEL选择摘要与重试模型OMX_SPARKSHELL_MODEL_INSTRUCTIONS_FILE覆盖打包摘要指令OMX_SPARKSHELL_SUMMARY_TIMEOUT_MS控制本地 API 摘要超时。这些细节说明该命令被当作面向操作者的正式接口来维护与文档风险注记的定位一致。explore 的刻意约束风险注记第二条要求“在 sparkshell 路由启用期间持续检查 shell-only / read-only 边界保持完整”。从当前仓库的 src/cli/explore.ts 结构可以看到这条约束的最终走向在后续版本中omx explore的直接命令面已被硬弃用hard-deprecated帮助文案明确引导用户“对只读仓库查找使用常规 Codex 检查工具仅在显式 shell 只读取证或--tmux-pane摘要时使用omx sparkshell -- command”。可以推断0.9.0 评审时“保持边界完整”的要求正是该表面最终收敛为 sparkshell 单一路径的伏笔同时该文件中的 Windows 说明也印证了原生 harness 依赖 POSIX sh/bash 包装这一跨平台限制与文档中“Linux 冒烟无法直接验证 Windows 运行时行为”的注记同源。剩余发布动作与风险注记文档在给出 GO 结论前仍单列了“剩余发布动作Remaining release actions”即本地验证之外、必须在 tag 之后完成的闭环打 tagv0.9.0并确认 GitHub Actions 发布任务全部完成原生资产发布原生资产清单校验packed install 冒烟校验npm publish使用 docs/release-notes-0.9.0.md 发布 GitHub Release。对应的五条风险注记原文如下它们构成该版本发布后的观察清单首要回归面是新的原生分发契约hydration、fallback 顺序、跨平台资产解析omx explore是刻意受限的发布验证应持续确认 shell-only / read-only 边界在 sparkshell 路由启用下依然完整omx sparkshell --tmux-pane是团队调试的操作者关键项pane 摘要行为应按“面向发布的特性”对待而非隐藏内部细节npm pack --dry-run保持绿色很重要因为打包安装刻意排除 staged 原生二进制发布工作流必须通过 GitHub Release 资产补齐这些二进制跨平台 Windows 专项修复已落在发布窗口内但 Linux 冒烟无法直接验证 Windows 运行时行为仍需 CI / 发布矩阵确认。其中第 4 条与前文打包分析呼应第 5 条则明确了“本地证据边界”本地冒烟只覆盖当前平台Windows 结论被显式外推给 CI 矩阵避免了把单平台绿灯误读为全平台绿灯。最终结论与可复用的核查清单文档的“Final local verdict”只有一句话基于上述本地 post-bump 验证0.9.0 已具备 tag 与发布条件。把它拆开看这份就绪文档示范了一个可复用的发布核查骨架范围先行明确评审的是哪个 tag 到 dev 的窗口v0.8.15..dev并点名新特性面与流水线工作避免“全量泛查”证据可复制每项验证都给出精确命令与精确结果数字2375 pass / 0 fail、39 pass、32 11 5让第三方可原样复跑形态固化用包版本、最新 tag、分支、非合并提交数、diff 统计五个数字钉死发布形态并与发布说明共享同一数据源风险显式化把“本地验证覆盖不到的部分”Windows 运行时、发布后 CI 闸门写成风险注记而非默认安全动作与结论分离GO 结论只覆盖本地验证tag 之后的原生资产发布、清单校验、冒烟校验、npm publish 单列为剩余动作不被结论提前吞并。对维护者而言这套流程的适用前提是项目同时存在 TypeScript 与 Cargo 双栈需要版本三同步、且 npm 包依赖外部 Release 资产提供原生二进制需要 packed-install 冒烟与水合链路验证oh-my-codex 0.9.0 的这次评审恰好完整覆盖了这两个前提下的全部检查点。【免费下载链接】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），仅供参考 一次“GO”是怎么挣来的：oh-my-codex 0.9.0 发布就绪验证与原生资产分发实践
一次“GO”是怎么挣来的oh-my-codex 0.9.0 发布就绪验证与原生资产分发实践【免费下载链接】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 仓库中 0.9.0 发布就绪评审文档 为主线完整还原一个携带 Rust 原生二进制的 CLI 项目在打 tag 前的验证闭环评审范围界定、20 项冒烟与测试证据、版本同步机制、打包分发契约与风险注记。读完后你可以掌握一套可复用的“发布就绪release readiness”核查方法并理解该项目“npm 包不带原生二进制、由 GitHub Release 资产按需水合hydration”的原生资产分发设计。背景0.9.0 要带什么上发布列车就绪文档的头部信息给出了基本盘日期 2026-03-12、目标版本0.9.0、本地结论GO且版本 bump 完成后已在dev分支重跑通过发布门禁。文档的“评审范围Scope reviewed”列出了四个板块v0.8.15之后未发布的dev工作Spark Initiative相关能力面omx explore默认只读探索入口omx sparkshellRust 驱动的 shell 检查 sidecar符合条件的只读 shell 任务从 explore 路由到 sparkshell原生发布流水线工作跨平台原生资产发布、发布清单release manifest生成、packed-install 冒烟门禁、build:full工作流验证0.9.0的发布说明与 QA 草稿产出对应 docs/release-notes-0.9.0.md。这个范围不是空话它直接对应仓库里的构建脚本。package.json 中的build:full定义为build:full: npm run build npm run build:explore:release npm run build:sparkshell npm run build:api即 TypeScript 主构建、explore harness 发布构建、sparkshell 构建、api 构建四段串联——这正是文档中“build:fullworkflow validation”一项检查的落地对象。crates/omx-explore、crates/omx-sparkshell 等 Cargo 工作区成员则是cargo build -p omx-explore-harness、cargo build -p omx-runtime的构建目标。验证证据清单20 项检查全量继承就绪文档的核心是一张 20 行的验证证据表每一行都给出检查名、可复制命令和结果。下表完整保留原文档内容检查命令结果完整源码构建npm run build:fullPASSCLI help 冒烟node bin/omx.js --helpPASS版本冒烟node bin/omx.js versionPASSoh-my-codex v0.9.0版本同步node scripts/check-version-sync.mjs --tag v0.9.0PASSAsk help 冒烟node bin/omx.js ask --helpPASSHUD help 冒烟node bin/omx.js hud --helpPASSDoctor 冒烟node bin/omx.js doctorPASS10 passed, 0 warnings, 0 failedStatus 冒烟node bin/omx.js statusPASSSetup dry-run 冒烟node bin/omx.js setup --dry-runPASSExplore help 冒烟node bin/omx.js explore --helpPASSExplore prompt-file 冒烟node bin/omx.js explore --prompt-file /tmp/omx-explore-smoke.txtPASSExplore→sparkshell 路由冒烟OMX_SPARKSHELL_LINES1 node bin/omx.js explore --prompt git log --oneline -10PASSsummary 输出Sparkshell help 冒烟node bin/omx.js sparkshell --helpPASSSparkshell 直跑冒烟node bin/omx.js sparkshell git --versionPASSgit version 2.34.1Sparkshell summary 冒烟OMX_SPARKSHELL_LINES1 node bin/omx.js sparkshell git log --oneline -10PASSsummary 输出Sparkshell tmux-pane 冒烟node bin/omx.js sparkshell --tmux-pane %2141 --tail-lines 120PASS全量测试npm testPASS2375pass /0fail打包 tarball 干跑npm pack --dry-runPASSoh-my-codex-0.9.0.tgzExplore 验证泳道npm run test:explorePASS39pass /0failSparkshell 验证泳道npm run test:sparkshellPASSRust 套件32 11 50fail说明表中命令为 0.9.0 评审时点的原始记录入口为bin/omx.js、同步脚本为.mjs形式当前仓库中对应物已演进为dist/cli/omx.js入口与 src/scripts/check-version-sync.ts编译后运行检查语义保持一致。版本同步检查到底查了什么check-version-sync --tag v0.9.0这一项不是形式检查。从当前源码 src/scripts/check-version-sync.ts 可以看到它的完整判定逻辑读取根目录package.json的version用 TOML 解析根 Cargo.toml 的[workspace.package].version要求两者相等逐个检查omx-api、omx-explore、omx-runtime-core、omx-mux、omx-runtime、omx-sparkshell六个 crate 的Cargo.toml必须声明version.workspace true防止某个 crate 的版本号被单独漂移若传了--tag v0.9.0则断言 tag 必须精确等于v${package.json version}。任何一条不满足都会打印[version-sync] ...并以非零码退出。这条门禁的意义在于TS 侧包版本与 Rust 工作区版本、git tag 三者强绑定杜绝“npm 装到 0.9.0、原生资产却按 0.8.x 清单解析”的错位。打包冒烟为什么npm pack --dry-run是发布级检查package.json 的files字段显式列出打包内容dist/、crates/、skills/、prompts/、templates/、src/scripts/、plugins/等并带有!crates/**/.omx/**排除规则同时prepack链最后一步是clean:native-package-assetspostpack再次执行清理。也就是说npm 包刻意不包含已暂存的原生二进制——这解释了文档风险注记中“npm pack --dry-run保持绿色很重要因为打包安装会故意排除 staged 原生二进制真正的二进制必须由发布工作流以 GitHub Release 资产形式补齐”这句话。配套的 packed-install 冒烟脚本是 src/scripts/smoke-packed-install.ts其核心命令集定义为export const PACKED_INSTALL_SMOKE_CORE_COMMANDS [ [--help], [version], [api, --help], [sparkshell, --help], ] as const;即把真实 tarball 安装到隔离目录后逐条执行核心命令验证产物可用。文档中npm pack --dry-run产出oh-my-codex-0.9.0.tgz这一行与该脚本共同构成“打包形态”的双重验证干跑验证清单完整性冒烟脚本验证安装后行为。分泳道测试explore 与 sparkshell 为什么单独立道npm run test:explore与npm run test:sparkshell在文档中各自独立报数39 passRust 套件32 11 5。对照 package.json 脚本定义可以印证“泳道”的构成test:explorecargo test -p omx-explore-harness加三个 Node 测试文件explore CLI、explore 路由、explore→sparkshell 引导契约test:sparkshell委托给 src/scripts/test-sparkshell.ts驱动 crates/omx-sparkshell 下的 Rust 测试套件。这种“Rust 套件 契约级 Node 测试”组合的方式使得文档中 Explore 泳道 39 个用例、Sparkshell 泳道三组 Rust 套件通过这类精确数字成为可信的发布证据而不是笼统的一句“测试通过”。发布形态证据用数字描述这次发布文档的“Current release-shape evidence”一节用五个事实固化了发布形态当前包版本0.9.0仓库内最新已有 git tagv0.8.15当前分支dev未发布头与 tag 的差距55 个非合并提交未发布 diff149 个文件变更12,325 / -254。同窗口的 docs/release-notes-0.9.0.md 给出了相互印证的口径提交窗口 2026-03-10 至 2026-03-12 的 55 个非合并提交、同样的 149 文件 / 12,325 / -254 快照并列出代表性提交如e8e7594只读 shell 任务经 sparkshell 路由、23d1cf5统一跨平台原生发布、559089f增加 packed install 冒烟门禁。QA 草稿与发布说明使用同一组统计数字本身就是“发布物料一致性”的证据。原生分发契约0.9.0 的第一风险面文档风险注记第一条直言“首要回归面是新的原生分发契约hydration、fallback 顺序、跨平台资产解析。”结合源码可以把这句话展开成具体机制。二进制解析的 fallback 顺序src/cli/sparkshell.ts 定义了 sparkshell 原生二进制的候选路径族打包路径bin/native/platform-arch[-libc]/omx-sparkshellLinux 下按 musl/glibc 偏好展开多个候选仓库本地构建路径target/release/omx-sparkshell以及嵌套的native/omx-sparkshell/target/release/...环境覆盖OMX_SPARKSHELL_BIN直接指定二进制绝对路径或相对cwd解析。resolveSparkShellBinaryPath的判定顺序是先看OMX_SPARKSHELL_BIN覆盖再依次尝试水合缓存候选、打包产物、仓库本地构建。这与 docs/release-notes-0.9.0.md 中“运行时 fallback 顺序在 env 覆盖、水合缓存、打包产物、仓库本地构建之间保持显式”的表述一一对应。水合hydration从哪里来发布说明明确npm 包不直接捆绑全部原生二进制带 tag 的发布会发布omx-explore-harness与omx-sparkshell的跨平台原生归档打包安装通过native-release-manifest.json从 GitHub Release 资产中水合匹配的二进制。package.json 中的verify:native-agents对应 src/scripts/verify-native-agents.ts与build:explore:release/build:sparkshell脚本则分别承担清单校验与归档构建两端。文档“剩余发布动作”一节列出的 GitHub Actions 校验项——原生资产发布、原生资产清单校验、packed install 冒烟校验、npm publish——正是这条链路的四个闸门。tmux-pane 摘要操作者关键特性而非内部细节风险注记第三条把omx sparkshell --tmux-pane定性为“团队调试的操作者关键特性”。从 src/cli/sparkshell.ts 的用法文案可以确认其参数契约Usage: omx sparkshell command [args...] or: omx sparkshell [--json] [--budget chars] command [args...] or: omx sparkshell --shell shell command or: omx sparkshell --tmux-pane pane-id [--tail-lines 100-1000]要点包括shell 元字符仅在显式--shell时才被解释默认走直接 argv 执行tmux pane 模式是显式 opt-in先抓取更大的 pane 尾部再做原始/摘要处理--tail-lines取值范围 100–1000文档冒烟用例中的--tail-lines 120正落在该区间内。此外还有相关环境变量OMX_SPARKSHELL_MODEL/OMX_SPARKSHELL_FALLBACK_MODEL选择摘要与重试模型OMX_SPARKSHELL_MODEL_INSTRUCTIONS_FILE覆盖打包摘要指令OMX_SPARKSHELL_SUMMARY_TIMEOUT_MS控制本地 API 摘要超时。这些细节说明该命令被当作面向操作者的正式接口来维护与文档风险注记的定位一致。explore 的刻意约束风险注记第二条要求“在 sparkshell 路由启用期间持续检查 shell-only / read-only 边界保持完整”。从当前仓库的 src/cli/explore.ts 结构可以看到这条约束的最终走向在后续版本中omx explore的直接命令面已被硬弃用hard-deprecated帮助文案明确引导用户“对只读仓库查找使用常规 Codex 检查工具仅在显式 shell 只读取证或--tmux-pane摘要时使用omx sparkshell -- command”。可以推断0.9.0 评审时“保持边界完整”的要求正是该表面最终收敛为 sparkshell 单一路径的伏笔同时该文件中的 Windows 说明也印证了原生 harness 依赖 POSIX sh/bash 包装这一跨平台限制与文档中“Linux 冒烟无法直接验证 Windows 运行时行为”的注记同源。剩余发布动作与风险注记文档在给出 GO 结论前仍单列了“剩余发布动作Remaining release actions”即本地验证之外、必须在 tag 之后完成的闭环打 tagv0.9.0并确认 GitHub Actions 发布任务全部完成原生资产发布原生资产清单校验packed install 冒烟校验npm publish使用 docs/release-notes-0.9.0.md 发布 GitHub Release。对应的五条风险注记原文如下它们构成该版本发布后的观察清单首要回归面是新的原生分发契约hydration、fallback 顺序、跨平台资产解析omx explore是刻意受限的发布验证应持续确认 shell-only / read-only 边界在 sparkshell 路由启用下依然完整omx sparkshell --tmux-pane是团队调试的操作者关键项pane 摘要行为应按“面向发布的特性”对待而非隐藏内部细节npm pack --dry-run保持绿色很重要因为打包安装刻意排除 staged 原生二进制发布工作流必须通过 GitHub Release 资产补齐这些二进制跨平台 Windows 专项修复已落在发布窗口内但 Linux 冒烟无法直接验证 Windows 运行时行为仍需 CI / 发布矩阵确认。其中第 4 条与前文打包分析呼应第 5 条则明确了“本地证据边界”本地冒烟只覆盖当前平台Windows 结论被显式外推给 CI 矩阵避免了把单平台绿灯误读为全平台绿灯。最终结论与可复用的核查清单文档的“Final local verdict”只有一句话基于上述本地 post-bump 验证0.9.0 已具备 tag 与发布条件。把它拆开看这份就绪文档示范了一个可复用的发布核查骨架范围先行明确评审的是哪个 tag 到 dev 的窗口v0.8.15..dev并点名新特性面与流水线工作避免“全量泛查”证据可复制每项验证都给出精确命令与精确结果数字2375 pass / 0 fail、39 pass、32 11 5让第三方可原样复跑形态固化用包版本、最新 tag、分支、非合并提交数、diff 统计五个数字钉死发布形态并与发布说明共享同一数据源风险显式化把“本地验证覆盖不到的部分”Windows 运行时、发布后 CI 闸门写成风险注记而非默认安全动作与结论分离GO 结论只覆盖本地验证tag 之后的原生资产发布、清单校验、冒烟校验、npm publish 单列为剩余动作不被结论提前吞并。对维护者而言这套流程的适用前提是项目同时存在 TypeScript 与 Cargo 双栈需要版本三同步、且 npm 包依赖外部 Release 资产提供原生二进制需要 packed-install 冒烟与水合链路验证oh-my-codex 0.9.0 的这次评审恰好完整覆盖了这两个前提下的全部检查点。【免费下载链接】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），仅供参考