autopilot Checked

<principle id="no-ralph-wiggum">

<name>No Ralph Wiggum — 不允许半完成就声称 done</name>

agent 可能在只完成了一半的时候提前退出 loop（"看起来差不多了"）。

防护措施：

• 每个 phase 完成后输出 ✓ PHASE [id] COMPLETE: [客观证据]
• loop 结束前逐一核对所有 mandatory phase 的完成标记
• 缺标记 = 未完成 = 不允许退出

</principle>

<principle id="failure-classification">

<name>Failure Classification — 先分类再重试</name>

phase 失败时不能盲目 loop 回去重试同样的事情。

必须先分类失败原因，然后根据分类选择不同的修复路径：

<failure-type id="missing-context">

缺少上下文/信息。修复：扩大调查范围，读更多代码/日志/文档。

</failure-type>

<failure-type id="wrong-approach">

方案本身有问题。修复：回退到 plan 阶段，探索替代路径（多角度发散思考）。

</failure-type>

<failure-type id="environment-issue">

环境/配置/依赖问题（非代码 bug）。修复：用项目 debug skill 排查环境。

</failure-type>

<failure-type id="hallucinated-assumption">

基于错误假设实现。修复：回退到 investigate，验证假设再重新实现。

</failure-type>

<failure-type id="incomplete-output">

做了一部分但不完整。修复：继续当前 phase，不要从头开始。

</failure-type>

<failure-type id="external-blocker">

被外部因素阻塞（API 不可用、权限不足等）。修复：降级或中止并报告。

</failure-type>

记录每次失败的分类到 progress.md，防止重蹈覆辙。

</principle>

<principle id="adaptive-retry">

<name>Adaptive Retry — 重试必须改变策略</name>

"更多次重试 ≠ 更好的结果。如果系统重复相同的行为，它不是在改进，它只是在空转。"

每次 loop 回去重试时，必须满足以下条件之一：

• 使用了不同的修复方案
• 获取了新的上下文/信息
• 缩小了问题范围
• 换了工具或 skill
• 修正了之前的错误假设

如果想不出任何不同的做法 → 不要重试，直接中止并报告：

"连续 N 次以相同方式失败，无法找到新的修复路径。"

这比空转烧 token 有价值得多。

失败签名 = phase + 客观 gate + 观察到的失败 + 失败边界。

只有四项全同才累加重复计数；失败点向下游移动是 progressive discovery，

重置该签名计数但全局预算继续累计。详见 references/execution-budget.md。

</principle>

<principle id="evidence-ladder">

<name>Evidence Ladder — 说清楚你的"验证"到底证明了什么</name>

每条实质性结论都必须带证据等级：

L0 假设/读代码 → L1 单测 → L2 集成测试/fixture/构造流程

→ L3 目标环境上的原始事故身份或显式等价身份 → L4 部署后真实复发观测。

铁律：绝不能把 L0–L2 说成"历史根因已证实"。

加了兜底之后跑通了，只说明兜底生效，不说明原路径坏在哪。

fixture-only 的 L2 通过永远不能关闭一个用户报告的缺陷。

根因用词必须精确：confirmed root cause / supported mechanism /

defensive hardening / bounded unknown。详见 references/evidence-and-verification.md。

</principle>

<principle id="single-writer">

<name>Single Writer — "只有我在改这个仓库"是必须被证明的假设</name>

同一台机器上经常有多个 agent、多个 worktree 共享同一个 git 仓库。

任何时刻只允许一个 maker 写同一个工作树、一个 landing owner 做

commit/push/发布。写入前必须持有 git-common-dir 的原子租约；

证明不了本机独占就停止。

staging 只用精确文件清单，绝不 git add -A / git add .；

绝不 stash / checkout / reset / 覆盖别人的改动；绝不 force push。

push 后必须 fetch 并用 git merge-base --is-ancestor 回读远端 ancestry——

本地 commit 不算交付。详见 references/concurrency-and-landing.md。

</principle>

<principle id="bounded-increment">

<name>Bounded Increment — 每轮只推进一个有界增量</name>

一轮迭代 = 读 checkpoint → 校验归属与租约 → 提出一个假设或一个 phase delta

→ 执行一个带客观 gate 的 maker 或 checker 动作 → 记录结果和最强证据

→ 选择一个有界的下一步或停止。

不允许把"调查全部 + 实现 + 部署 + review"塞进一个增量。

只读的事实收集可以并行（输出互不依赖时），写入永远单 maker。

</principle>

</core-principles>

---

平台适配

autopilot 默认通过状态文件推进；需要跨轮恢复时使用当前平台能力，持久 Goal 另受明确请求约束：

<platform-detection>

<platform id="claude-code">

<loop-command>/loop</loop-command>

<goal-command>/loop + 自定步调目标驱动</goal-command>

<description>

Claude Code 中使用 /loop 驱动目标迭代。

/loop 支持按间隔运行，也支持自定步调（不指定间隔时 model 自行决定何时继续）。

</description>

</platform>

<platform id="codex">

<loop-command>state-only + 当前任务定时恢复</loop-command>

<goal-command>仅 explicit-goal 模式：/goal [完成条件描述]</goal-command>

<description>

Codex 仅在用户或系统明确要求持久 Goal 时使用 /goal；否则使用运行状态和当前任务定时恢复。

/goal 持续运行直到声明的条件成立，由独立的 checker model 验证完成。

</description>

</platform>

<fallback>

平台未知时先检查实际工具，不猜测命令。继续 state-only 的可执行工作；需要恢复时再选择可用调度能力。两种模式都必须执行完整客观验收。

</fallback>

</platform-detection>

---

工作流程总览

<workflow>

<step id="scope">快速调查，理解任务实际涉及什么（2-5 分钟）</step>

<step id="plan">分类任务 → 拆解为 XML 阶段 → 选 skill → 定 loop 目标 → 初始化 state file</step>

<step id="execute">运行状态（explicit-goal 仅在明确请求时）+ agent-mode（内层按阶段派 subagent）→ 全程无人值守</step>

<step id="report">输出收尾总结 + 所有 phase 完成标记</step>

</workflow>

用户调用 autopilot 本身就是确认——不需要中途展示计划等"go"。

如果用户明确说"先让我看看计划"，才暂停展示。默认直接执行。

### Reference 导航（按 phase 加载，不要在开始时全部加载）

| 时机 | 加载 |

| --- | --- |

| 任务形态模板与调查清单 | references/phase-library.md 中对应那一节 |

| goal / loop / checkpoint / 预算 / 失败记账 | references/execution-budget.md |

| 工单归属、认领、批次、终态、续跑租约 | references/ownership-and-tracker.md |

| maker 编辑 / commit / rebase / push / 发布 | references/concurrency-and-landing.md |

| 测试设计 / E2E / 根因表述 / 关闭判定 | references/evidence-and-verification.md |

| 交付、复盘、规则晋升、最终审计 | references/learning-and-audit.md |

### 必须停止的红旗

• 候选工单是 draft、in-progress、有预约/有效外来租约/接管，或已有开工证据；
• 认领回读未成功却已经开始改代码；
• 一批只共享标签/模块/症状，没有共享精确根因和同一条验证链；
• 出现第二个 maker 或第二个 landing owner，或本机租约回读不一致；
• 想用 mock/fixture 关闭用户报告的缺陷，或用兜底成功宣称历史根因已证实；
• 任务目标没有 proof/constraints，未记录用户明确的上限，或 checkpoint 没有有界的下一步动作；
• 同一失败签名重复三次而策略没有真正改变，或 A→B→A 无新证据来回摆；
• staging 含任务外路径、远端回读不含交付 SHA，或出现任何 force-push 倾向；
• 学习规则没有证据/eval/独立 checker 就要改权威规则文件。

命中红旗时：先记录 checkpoint，停止有问题的操作或原样重试，检查可安全继续的替代路径。仍有有界下一步时继续；只有用户上限已到或证据证明没有安全路径时才结束任务并报告未完成部分。不得靠重复等待或无变化的重试绕过保护。

---

Step 1: 快速定范围

在规划之前，先花 2-5 分钟弄清任务实际涉及什么。

没有调查的计划是空中楼阁——先看再拆。

### 1a. 自动分类任务类型

根据用户输入 + 调查发现判断类型：

<task-types>

<type id="bug-fix"

signals="fix, broken, 不工作, issue, error, 报错, 修, crash, 挂了">

修复已知缺陷。从现象追到根因，根治而非打补丁。

</type>

<type id="feature"

signals="add, implement, 新增, 做一个, 加上, 支持, spec, 功能">