atelier-plan 是架构师的规划纪律。其目标是产出一份足够详细的计划，使廉价执行者（Haiku）无需再做任何决策即可完成约 90% 的工作，并让检查者（Sonnet）能客观地验证每一部分。所有跨单元决策都在此一次性制定，执行者无需再做任何跨单元判断。所有产出持久化到 docs/atelier/<task-slug>/。
一、先判断这是否是 atelier 任务 atelier 的机制（contract + briefs + ledger）只用于保持多个单元的一致性。规划前先检查工作形态：
- 单一不可分割产物、不需要分层 → 不使用 atelier，直接完成。
- 单一产物，但需要成本/质量分层 → 运行退化计划：跳过 CONTRACT.md（没有跨单元接缝需要固定），写一个 briefs/UNIT-001.md 含验收标准，派发一个 Haiku 执行者、一个 Sonnet 检查者。这样仍能得到“Haiku 起草、Sonnet 验证”，但无需编排。
- 多个单元 → 继续以下步骤。
二、选择拆解模式 “一个单元 = 一个文件”只是拆分方式之一。根据最终产物的内聚度来选择模式：
- partition：每个单元拥有独立区域/文件；架构师拼接片段；并行派发。适用于输出可清晰分离的场景——代码文件、文档章节、地牢房间、独立变换。
- relay：每个代理继续同一产物，接收其当前状态 + 下一段的简要说明；顺序派发。适用于一件流动产物，各部分依赖前一部分的语气/流畅度——如逐拍写成的散文章节。
- layered：对整个产物进行角色专门化的多轮处理（如草稿 → 连续性编辑 → 润色）；顺序派发。适用于希望单一无缝语气但依次施加多种专门视角。 当各片段可分离时默认使用 partition。当并行碎片式撰写会产生接缝（语气漂移、连续性断裂、委员会撰写感）时，采用 relay 或 layered。也可混合：先将文档 partition 为章节，再在章节内 relay。 无论何种模式，一个好的单元：产出一个连贯贡献（一个区域、下一段或一轮处理）；只需阅读契约 + 自身简要说明（relay/layered 中还需当前产物状态）即可执行；小到足以由一次 Haiku 处理完成。 识别依赖。在 partition 中，独立单元并行运行。在 relay 和 layered 中，图为完全线性（每个单元依赖前一个并操作同一产物）。将所选模式记录在 CONTRACT.md 中。宁少勿多，优先选择边界清晰的较少单元——每次派发都有开销。
三、选择规划层级（direct 与 split） 独立于拆解模式，决定由谁编写每单元简要说明：
- direct — 架构师编写契约及每一份简要说明（本技能第 2–5 步）。一个翻译边界（架构师 → 执行者）。适用于单元少、简要说明微妙/高耦合、或正确性关键的工作。
- split — 架构师编写契约 + 每个单元的简洁规格，然后停止。编排器派发并行的 Sonnet atelier-brief 编写者（每单元一个）将规格扩展为完整简要说明。适用于单元多（约 ≥ 6）且简要说明机械/常规，或大规模运行。 也可混合：架构师自己写 1–2 个微妙单元的简要说明，常规的交给 split 层级。将所选层级记录在 CONTRACT.md 中。在 split 层级中，架构师执行步骤 2 + 3-split + 5 后停止（契约、简洁单元规格、账本——而非完整简要说明）。在 direct 层级中，架构师执行全部步骤 2–5。
四、编写 CONTRACT.md 使用 ../atelier/templates/CONTRACT.template.md。这是跨单元表面。具体性规则——对每一行的唯一测试：两个不同的执行者独立工作，是否必须就此达成一致，其输出才能拼合？是 → 这是一个接缝，将其固定在契约中。否（只影响一个单元的内部）→ 省略，写入该单元的简要说明。 契约中应包含：共享类型/错误形态 + 由哪个单元拥有；单元间传递的模式/数据形态；所有单元遵循的命名 + 格式约定；文件/输出归属图；固定为单一含义的术语；依赖图 + 顺序。简要说明中应包含：某函数如何构建并抛出错误；一个单元的内部数据结构；一个单元的局部变量名；一个单元的内部文件组织；一个单元输出内的散文措辞；一个单元的内部步骤顺序。 校准到执行者——Haiku 很强。这是支配原则，控制着 token 预算：契约的详尽程度应与执行者强度成反比。atelier 的执行者是 Haiku——远强于本地小模型，能填充显而易见字段、遵循惯例、自行处理普通歧义。因此只固定既是跨单元又确实有歧义的少数决策。架构师和检查者（Sonnet）的输出 token 是昂贵部分，简洁是目标而非详尽。存疑时，少写，让验收标准捕获罕见的遗漏。两个省钱的习惯：在真正的分叉点上做出决断；对共享形态只命名一次。跨模块测试是可选用工具而非强制要求，仅在真正脆弱的接缝上使用（整个项目一两个，而非每条边一个）。
五、（仅 split 层级）编写简洁 UNIT-SPECS，然后停止 若选择 split 层级，不要写完整简要说明。改为编写 UNIT-SPECS.md——每个单元一个简洁块（相当于 local_code_gen 的 sprint_descriptions.jsonl），供 Sonnet 简要说明编写者扩展。每块包含：id + 标题 + 目标（1–2 句）及拥有的文件/输出 + 依赖；它定义的符号（按名称，引用契约中的共享形态，不复述）；消费项——依赖的上游符号/章节；标准意图——高层面“完成”的含义及任何验证命令。简洁块保持简短，每块几行。使用 ../atelier/templates/UNIT-SPEC.template.md。然后转到步骤 5（账本）并停止——编排器派发 Sonnet 简要说明编写者。
六、（仅 direct 层级）为每个单元编写一份 BRIEF 使用 ../atelier/templates/BRIEF.template.md。每份简要说明自包含：执行者阅读契约 + 此简要说明，别无其他。以 Haiku 所需的层级描述——说明做什么，而非每次击键。仅在精确顺序真正承重处使用伪代码。点明该单元消费的确切输入（路径、上游符号/章节）。陈述执行者可能弄错的约束。
七、设置验收标准（信任契约） 每份简要说明都以具体、可检查的验收标准结尾。检查者按此列表评分，而非凭感觉。纪律（来自 simmer-setup）：检查 → 推断 → 提议 → 确认。架构师做思考，用户验证。绝不要求用户描述架构师能读到的东西。从任务和上下文为每个单元推断标准。使每条具体——“完成的样子”，而非“做得好”。分类每条标准：runnable（有则优先，尤其代码）——检查者执行的命令/测试：pytest 通过、curl 返回 200、构建成功；assertional（非代码）——具体清单项：“覆盖全部 5 个来源；无未引用断言；少于 800 词”。提议 + 确认——在一条消息中向用户呈现推断的标准，让其调整或覆盖。充分性检查跳过——若用户已陈述标准，跳过提议并直接使用。用户永远不被强迫撰写标准，但始终可否决。坏标准：“CSV 导出运行良好。”好标准：“（runnable）pytest tests/test_csv_export.py 通过” + “（assertional）输出有标题行和 CRLF 行尾” + “（assertional）未知 id → 404 ApiError，而非原始 dict”。
八、初始化 LEDGER 使用 ../atelier/templates/LEDGER.template.md。每单元一行，全部 pending，计数器为 0，依赖列按图填写。
本步骤输出（在 docs/atelier/<task-slug>/ 中）：CONTRACT.md（含依赖图及所选模式/层级）；LEDGER.md 已初始化；direct 层级：briefs/UNIT-NNN.md……每单元一份，各含验收标准（架构师撰写），除非已预先指定，否则与用户确认标准；split 层级：UNIT-SPECS.md（每单元一个简洁块，架构师撰写），简要说明尚不存在——编排器派发 Sonnet atelier-brief 编写者产生它们，标准在此之后确认。将控制权交回编排器进入派发阶段。