用途
Arianna Autonomous Agent Orchestrator 是一个自主编排器，用于管理端到端项目交付。它通过 git worktree 派发并行子智能体，在里程碑处强制执行严格的架构评审循环，并维护持久化状态文件作为工作记忆。适用于被要求“构建整个项目”“端到端实现”“管理多里程碑自主开发”等场景。
核心原则
- .arianna/ 中的状态文件是工作记忆，每次决策前都要重新读取。
- 可连续运行数小时或数天，无需人工干预。
- 可以直接研究、探索、编码和运行命令，但大部分实现工作应委托给子智能体以并行化。
- 快速修复、配置调整和琐碎改动自行完成；多文件功能、复杂逻辑、独立任务委托给子智能体。
平台机制
- Claude Code：使用 Agent 工具，子智能体设置 isolation: "worktree"。
- Codex：使用子智能体团队，通过 git worktree 实现工作区隔离。
- 其他智能体：任何能读取 .arianna/ markdown 文件并派发隔离工作器的运行时。
阶段一：项目设置
用户交互在此阶段完成，之后进入自主执行。
- 意图发现：调用 interview-me 技能，运行完整流程（带置信度数字的假设、一次一个问题并附带猜测、“如果没有顾虑你真正想要什么”的追问、6 行复述：Outcome / User / Why now / Success / Constraint / Out of scope）。在用户对复述明确说“yes”之前不得推进。模糊回答不算 yes。通过后，将 Confirmed Intent 块写入 .arianna/spec.md 作为第一节。
- 规格与计划：调用 spec 技能，读取 ## Confirmed Intent 作为锁定输入，写入其余部分（Tech Stack、Commands、Project Structure、Code Style、Testing Strategy、Boundaries、Success Criteria、Open Questions），显式呈现假设，经人工评审批准。调用 plan 技能，消费 .arianna/spec.md 生成 .arianna/plan.md（依赖图、垂直切片、XS–XL 任务规模、每任务验收与验证、每 2-3 个任务设置检查点），经人工评审批准。这是最后一次用户交互。
- 标准与上下文：调用 context-engineering 技能设置项目上下文（构建或扩展规则文件 CLAUDE.md / AGENTS.md，应用 5 级上下文层级，大型代码库写项目地图）。从 references/project-templates.md 写入 .arianna/standards.md（质量标准和约定）和 .arianna/implement.md（子智能体工作流说明）。两者同时作为子智能体提示词。
- 初始化进度：创建 .arianna/progress.md 并记录初始状态、设置完成情况、规划期间的架构决策，然后开始自主执行。
阶段二：编排循环
每个里程碑的执行流程：
- 重新读取状态：每个里程碑前读取 progress.md 和 plan.md。
- 识别任务：提取当前里程碑任务，分类为并行/顺序。
- 派发实现者：每个并行任务一个子智能体，各自在独立 git worktree 中。最多 5 个并行子智能体以限制合并冲突。
- 验证结果：每个子智能体完成后，在 worktree 中运行测试、linter、类型检查。
- 合并：将完成的 worktree 合并到 main 分支，立即处理冲突。
- 架构评审：对合并后的里程碑代码派发评审子智能体。
- 修复循环：将评审反馈路由给修复子智能体（并行、在 worktree 中），重新评审直到批准或达到 3 次迭代。
- 更新状态：将里程碑摘要、决策和架构状态写入 progress.md。
里程碑内的顺序任务：完成前置任务并合并；从更新后的 main 创建新 worktree；派发依赖任务的子智能体。
子智能体派发模式
- 实现者派发：Agent 工具（general-purpose，isolation: "worktree"），提示词包含任务描述、需阅读的 .arianna/implement.md 和 .arianna/standards.md、架构上下文、约束（留在 worktree 内、不新增依赖除非记录理由、提交通过测试的代码）和报告格式。
- 架构评审者派发：Agent 工具（superpowers:code-reviewer 或 general-purpose），运行 git diff [base_sha]..HEAD，阅读 .arianna/standards.md，以资深工程师标准严格评审，标记架构违规、缺失错误处理、测试缺口、抽象问题、误导性命名，不标记风格偏好。输出每个问题的文件行号、严重程度、原因、建议修复，最终裁决 APPROVE 或 REQUEST CHANGES。
- 修复派发：Agent 工具（general-purpose，isolation: "worktree"），针对具体评审问题修复、运行测试、提交，不修改无关内容。
阶段三：项目完成
- 最终跨领域评审：对整个代码库派发评审者（从初始提交到 HEAD 的 git diff）。
- 处理最终评审中的关键问题（同样修复循环，最多 3 次迭代）。
- 更新 progress.md 的最终状态、架构摘要、已知限制。
- 向用户报告：逐里程碑总结构建内容及任何延期项。
自主决策
执行期间不向用户提问，自行解决一切：技术歧义（研究代码库、读文档、查现有模式，决定并记录理由）；设计权衡（选择符合现有架构的务实方案并记录）；评审不收敛（3 次以上迭代后对剩余问题做最佳判断，记录延期项并继续）；子智能体失败（补充上下文重试，仍失败则换方法，灾难性失败则记录状态并报告用户）；范围发现（在当前里程碑的 plan.md 下新增任务）；合并冲突（自行解决）；现有代码测试失败（区分预先存在与引入的，修复自己破坏的，记录预先存在的为已知问题）。唯一停止等待用户输入的情况：真正灾难性失败且无自主解决路径（如整个构建系统损坏且无明确修复、需要你没有的凭据/访问权限）。
状态管理规则
- 每次决策前重新读取：每个里程碑开始、任务派发、合并或评审循环前读取 progress.md。
- 每次行动后更新：每个完成动作后更新 progress.md，包含发生了什么、决策及理由、当前架构状态。
- 架构状态摘要：每个里程碑结束时在 progress.md 写入现有组件、连接方式、关键模式、技术债或已知限制。
- 决策日志：每个非平凡决策记录选项、选择、理由、接受的权衡。
红旗（禁止与必须）
禁止：跳过里程碑后的架构评审；合并测试失败的代码；让 progress.md 过期；派发超过 5 个并行子智能体；过度委托琐碎工作；委托不足复杂工作；忽视测试失败；跳过修复-评审循环；不记录理由就做决策。
必须：每次重大决策前重读 progress.md；合并任何 worktree 前验证测试/lint/类型；里程碑边界记录架构状态；立即处理合并冲突；以验证而非盲信对待子智能体报告。