OpenSpec 的局部安装、规格闭环和 Codex 调用都能工作，不等于应该把它安装进所有工作区。
OC-69 在完成来源调研后，又做了固定版本、可撤销的项目级试点，最终结论是：
可用性与可回滚性通过；保留软件项目按需试点，不接入 HomeLab 全局任务控制面。

这不是“安装失败所以不采用”，也不是“生成了 skill 就证明 Agent 更高效”。本文区分规格工具、执行工具和运行治理，保留实际通过的结果，也明确没有测出的收益。现有多会话机制见 《Codex 多会话自动推进》，循环框架比较见 《Ralph、ULW 与 Superpowers 是否值得接入现有 Agent 工作流》。

OpenSpec 补的是哪一层

本次于2026年10月26日固定使用 OpenSpec 1.15.0，不是持续追踪最新版本。项目采用 MIT 许可证。它面向需求、场景、设计、任务拆分和规格变更归档，适合在跨模块实现前明确约束。参考：固定版本仓库、许可证。

在该版本中，Codex 适配生成项目内 .agents/skills/openspec-*/SKILL.md，不是安装另一个模型执行后端。官方支持表明确将 Codex 列为 skills-only；本次实际生成 propose、explore、apply、update、sync、archive 六类入口。
CLI 管理工件，Agent 阅读这些指引后仍通过原有工具编写代码和运行测试。见 固定版本支持表。

因此它与当前任务系统分工不同：

层次 负责什么 不证明什么
OpenSpec 需求场景、设计、任务和规格差异 运行权限、资源可用、生产发布完成
task-tracker 任务归属、当前阶段、授权、验收、交接 代码自然正确或模型自动遵循
测试与实际运行证据 某条具体行为是否符合要求 所有未来场景都可用

OpenSpec 的 continue 是推进规格工件，不是唤醒 worker 或签发租约。
change archive 也不是运维任务的生产收口。只有把两者错误地当成同一权威，才会制造重复审批和假完成。

隔离试点实际做了什么

所有 CLI、配置、缓存、合成源码和生成 skills 都放在任务专属目录内；使用现有 bundled Node 24.19.0，没有全局 npm 安装，也没有修改用户 PATH、全局 AGENTS 或真实租约/inbox。两个案例不包含私人照片、凭据、生产 API、数据库或远端服务。

案例一：空标签的小修复

要求是标签 trim、转小写后不能成为空字符串。先运行回归，得到预期的 ValueError not raised 失败，再只修正对应函数。修复后通过测试，并完成规格、任务勾选和原生归档。

它证明了闭环可运行，却也说明小修复不一定值得增加完整规划层：普通任务卡、一条复现和回归测试已经能够表达问题，不应为了使用工具强制建立复杂设计。

案例二：跨模块筛选与 CSV 导出

使用纯合成内存记录，分别实现人物筛选与 CSV 序列化；测试覆盖匹配结果、保序、含逗号标题和无匹配。这里的规格有更明确的价值：两个模块共享同一组行为约束，任务拆分和最终主规格可以相互追溯。试点没有执行真实照片检索或文件导出。

最终两个 change 均通过严格校验，并真实执行 archive 合并到主规格。这不是只创建空目录或手动把任务状态改成完成。

已验证结果与不可外推的部分

项目 实际结果 结论边界
合成功能 5/5 测试通过 只覆盖本次两个案例
主规格 2/2 严格校验通过 不替代代码测试或生产验收
change 生命周期 两个 change 实际归档 不等于主任务或服务上线
退出演练 移出生成的规格/skills 后，原源码5项测试仍通过 没有删除业务源码或其它项目文件
恢复演练 原路径恢复后再次通过 已测试项目级可撤销性
原生 Codex 使用 按 skill 名称实际加载、读规格并运行测试，进程 exit0 未证明旧桌面 session 热加载或无显式名称的自然语言选择率

MAIN 的实际调用是一次 ephemeral、read-only 的 Codex CLI：只提供 $openspec-explore 名称而非 SKILL.md 路径，随后观察到实际文件加载、规格读取和测试执行。这个证据比“安装目录存在”更强，但仍不是多任务稳定性或自动选 skill 的统计结论。

保留了首次测试失败和修复记录，没有用最终成功覆盖前面的失败。一次相对 wrapper 路径错误在任务内修正；系统 Node 21 的 engine 警告则通过复用已安装 Node 24 解决，没有扩大到安装新运行时或修复 Codex 产品数据库。

真实成本，而不是宣传收益

局部安装共57个包，实际 node_modules 为16,872KiB，npm cache为25,044KiB，合计约41MiB磁盘占用。安装输出记录3秒，但这不是网络下载量或完整试点工程时间。依赖可按固定 lockfile 重建，本次保留演示与退出说明，没有为了归档再运行安装或删除。

运行环境关闭遥测及更新检查，并把 XDG/npm 配置和缓存定向任务目录。这是配置与源码核对结果，没有抓包证明绝对零网络行为；安装阶段使用公开包源。

本次没有对照测量 token、人工时长或真实任务完成率。
CLI 的聚合 usage 包含模型多轮往返、父目录指导和缓存，不能当作 OpenSpec 的独立增量。因此“更省 token”“更少人工”“更快收口”仍为 UNKNOWN，不以可用性通过替代收益证明。

为什么不直接全局采用

生成的 propose 指引要求规划后再等一次用户请求，apply 中也有普通错误即暂停的措辞。这与本次用户已经确认的完整闭环、包内有界修复授权不同。试点按用户指令优先级继续并记录适配成本，没有把生成 skill 原样视为全局工作流政策。

对以服务运维、权限、资源租约和恢复为主的 HomeLab，这套工具不能替代现有控制面；如果再强制每个小修复都创建完整规格，会增加维护和上下文负担。但对真实跨模块软件需求，规格与场景仍可能有价值，适合由项目 owner 按需启用。

最终采用边界是：项目内、版本固定、写入面清楚、退出可验证；任务卡仍决定谁执行、做什么、何时允许以及如何验收。不因试点成功推广到所有工作区，也不为追求正面收益无限扩大评测。这与 《Codex 本地知识检索试点》的证据纪律相同：机制通过和净收益是两个问题。

收口后的保留方式

OC-69 的研究、可回滚试点和 MAIN 验收均已完成，当前执行归档，不再保留一个等待继续研究的 worker。报告、合成源码/规格/测试、执行日志、wrapper 和依赖清单作为可复用资料保留；约41MiB依赖与缓存标为可再生，不因会话归档自动删除。

已有报告引用保持原路径，归档导航指向唯一原始证据，不复制第二份权威结果。后续真实项目推广或收益 A/B 是新的选择，不是当前任务无限延期的收尾条件。