Planner

一个 Goal 是一件比一个 PR 大的事。自动推进能带着 Goal 的子 issue 一路做下去，但子 issue 得先有人拆出来。Planner 就是做这一步的：它把目标拆成一个个能单独交付的子 issue，把计划写进 Goal，然后停下。在你批准之前，什么都不会跑。

Planner 是谁

Planner 不是一篇角色笔记，而是一个位置：开在 Goal issue 旁边的对话，就是这个 Goal 的 Planner。只要 issue 的类型是 Goal，在它页面右边打开的对话都会带上 Planner 的规则，用的是你平时对话用的执行端和模型。

它的规则是固定的：

先读：Goal 本身、项目主笔记（先读 Context）、项目的 Decision-Log、项目里还开着的 issue 和各类型的状态、最近没人看过的变化、Goal 链接到的笔记。
只读地看代码：可以在工作目录里搜索、读文件、跑只读命令，但不改文件、不提交、不建分支。
目标说不清，先问你，问清楚再拆。
拆成子 issue：每个子 issue 是一次可交付的改动，一个分支、一个 PR。按文件归属来切，能并行的子 issue 不碰同一批文件；必须碰同一批文件，或者一个要用另一个的结果，就用 blocked_by 串起来。最多 max_children 个，默认 8 个，可以在 Issues/Issues.md 的 Settings 表里改。
每个子 issue 照它类型的模版写正文：必读笔记的链接、Goal、Why，以及可测的验收标准。子 issue 指向这个 Goal（goal:），负责人和 Goal 一样，停在它类型的第一个 Todo 状态。
填 Goal 的 ### Plan 表，在 ## Log 里记一笔。
然后停下，告诉你建了什么。它不改 Goal 和任何子 issue 的状态，也不派任何 run。

Goal 停在它类型的第一个状态（内置 Goal 是 Draft）时，issue 页上有一张 Planner 卡片。

点 开始拆分。右边打开一段新对话，第一句已经填好：「把目标拆成子 issue。」你可以改它，补上你的想法，再发出去。
Planner 读完、问完、拆完，Goal 的 Plan 表填好，子 issue 出现在看板的 Todo 里。卡片上会显示「有 N 篇子 issue 指向这个目标」。
不满意就在同一段对话里接着说：「第 3 个太大了，拆成两个」「先别做数据库那块」。Planner 会改它已经建的子 issue，不会重复建；该取消的，它点出名字，由你来取消。
满意了，点 批准 → Approved。Goal 挪到下一个 Todo 状态，自动推进接手：Goal 进 In Progress，没被挡着的子 issue 开工，同时最多 max_parallel 个。

在看板上把 Goal 从 Draft 拖到 Approved 也算批准，效果一样。

Planner 自己也能调用改状态的工具，但从对话里改的状态不会触发自动推进，Planner 的规则也写明了不许它这么做。你让它「批准吧」，它会告诉你去点按钮。

这是有意的分工：拆计划可以交给 AI 反复改，开始花执行端的时间、开始往仓库里提 PR，要由你来决定。批准之后，Goal 下面每个子 issue 走的仍然是它自己类型的流程，到了 Review PR、Verify Staging 这些 Your turn 的状态，照样停下来等你。

Goal 已经有子 issue 时，Planner 不会再拆一遍，除非你明确要求。这时候在 Goal 旁边的对话里问「进度怎么样」「哪个卡住了」，它会按 Goal 列出子 issue 来回答。