这是什么

假设你已经用 OpenSpec 或 Spec Kit 写好了一个功能：

• 需求和设计有了；
• tasks.md 也列好了；
• 但任务多、上下文长、多个 Agent 容易互相覆盖；
• 某轮对话断了以后，很难判断哪些结果真的验证过。

Spec Autonomous 就是处理后半段的。它把一个目标或现有规范变成可持续推进的里程碑，给宿主生成一份份工作包，并把每次结果放进确定性的验收流程。

它负责什么

1. 找到项目里的 OpenSpec / Spec Kit 工件。
2. 把目标整理成 milestone、phase 和有依赖的任务图。
3. 根据依赖、读写范围和并发上限找出下一批工作。
4. 给每个任务准备独立 worktree 和不可变上下文。
5. 接受宿主返回的结构化结果，而不是相信一句“完成了”。
6. 核对实际 Git diff、执行验证、集成候选代码。
7. 安全回写原生任务状态，保存证据并继续下一批。
8. 在中断、失败、来源变化后恢复，最后预览并执行归档。

它不负责什么

• 不取代 OpenSpec / Spec Kit。 规范仍写在原来的 Markdown 中。
• 不内置模型。 没有模型路由、OAuth 或私有聊天历史。
• 不创建 Agent。 CLI 不启动 Codex / Claude 会话；这是宿主的职责。
• 不把 worktree 当安全沙箱。 worktree 隔离 Git 改动，但不是操作系统权限边界。
• 不把 exit 0 当完成。 进程成功、任务打勾、测试通过和代码已集成是四件不同的事。

三个参与者

参与者	大白话职责
OpenSpec / Spec Kit	写清楚要做什么，保存规范、设计、任务和原生流程
Codex / Claude Code 等宿主	创建新上下文，让 Agent 做需要理解和判断的工作
Spec Autonomous	管顺序、工作区、状态、证据、测试、集成、恢复和归档

最适合的场景

• 一个 change / feature 有多项任务，需要分批完成；
• 一个 milestone 横跨多个功能或阶段；
• 希望多个 fresh-context Agent 保持上下文干净；
• 需要并行，但不能让多个任务写同一批文件；
• 要求中断可恢复、结果可追溯、完成状态可信；
• 团队已经采用 SDD，不想迁移到另一套专有文档格式。

如果只是改一行文案或执行一次脚本，直接让 Agent 完成通常更简单。它解决的是长链路、可验证交付，不是给所有小事增加流程。