完善配方驱动的创作编排

为可重复技能补充参数校验与展示，统一配方、编排器和执行单元术语。

Co-authored-by: Cursor <cursoragent@cursor.com>

docs/architecture.md

@@ -2,9 +2,9 @@
 
 ## 1. 文档定位
 
-本文档描述**系统级运行内核**：模块边界、创作定义与运行实例如何分离、总管 / Worker / Skill / 上下文如何协作、数据如何持久化，以及外部项目按层借鉴的原则。
+本文档描述**系统级运行内核**：模块边界、创作定义与运行实例如何分离、编排器 / 执行单元 / Skill / 上下文如何协作、数据如何持久化，以及外部项目按层借鉴的原则。
 
-本文档**不**设计具体剧本 Skill 的提示词、步骤或字段。剧本与创作方法见独立文档（如 `design-orchestrator-guide.md`）；Skill 包格式见 `skill-format.md` 系列。
+本文档**不**设计具体技能包的提示词、步骤或字段。工作流计划与创作方法见独立文档（如 `design-orchestrator-guide.md`）；Skill 包格式见 `skill-format.md` 系列。
 
 ---
 
@@ -14,7 +14,7 @@
 
 这些模式共享同一运行内核，区别来自：
 
-- 装载哪些 Skill / 能力包
+- 装载哪些 Skill / 技能包
 - 实例规格（Worker 声明）如何配置
 - 上下文如何按契约编译
 - 对状态读写实施什么权限
@@ -36,13 +36,13 @@
 
 语义上：`instance` 快照 ≈ 已发布的规格版本；`run` 快照 ≈ 运行过程存档。正式 `DefinitionVersion` 发布与迁移协议在现有快照之上增量补齐，不另起一套推倒重写。
 
-### 3.2 总管只负责任务调配
+### 3.2 编排器只负责任务调配
 
-总管 Agent（Main Agent）负责：判断目标是否完成、决定下一项任务、选择 Worker、必要时询问用户或结束。
+编排器（Main Agent）负责：判断目标是否完成、决定下一项任务、选择 Worker、必要时询问用户或结束。
 
-总管**不**负责：直接创作最终正文、临场拼接完整上下文、绕过权限读私有信息、直接改正式状态、同时兼创作与评测、把隐藏推理写入长期状态。
+编排器**不**负责：直接创作最终正文、临场拼接完整上下文、绕过权限读私有信息、直接改正式状态、同时兼创作与评测、把隐藏推理写入长期状态。
 
-任务所需信息由总管**声明意图**（如 invoke 哪个 worker）；真正发给 Worker 的上下文由 Runtime 的上下文编译器按 Skill / 声明契约生成。
+任务所需信息由编排器**声明意图**（如 invoke 哪个 worker）；真正发给 Worker 的上下文由 Runtime 的上下文编译器按 Skill / 声明契约生成。
 
 ### 3.3 Agent 决策与程序控制分离
 
@@ -59,7 +59,7 @@
 
 「下一步 invoke 哪个 skill」由 agent tool loop 决定。
 
-**5 相位阶段机**（`idle` / `running` / `waiting_user` / `done` / `error`）是并发与权限模型——谁可动、何时等用户、产物何时算事实——**不是**流水线剧本。详见 `runtime-state-machine.md`、`tool-contracts.md`。
+**5 相位阶段机**（`idle` / `running` / `waiting_user` / `done` / `error`）是并发与权限模型——谁可动、何时等用户、产物何时算事实——**不是**流水线计划。详见 `runtime-state-machine.md`、`tool-contracts.md`。
 
 确定性后台流程（导入导出、索引、迁移、批量评测）可用固定步骤；整场 AIRP / 小说创作流程不固化为完整 DAG。
 
@@ -97,7 +97,7 @@
 
 合成边界：
 
-> Book/规格描述可以运行什么，Session/快照保存实际发生了什么，相位机决定谁可动，总管决定下一步 invoke 谁，Context Compiler 决定 Worker 看见什么，Runtime 决定哪些修改正式生效。剧本 Skill 是可装载能力，不是系统固定流水线。
+> Book/规格描述可以运行什么，Session/快照保存实际发生了什么，相位机决定谁可动，编排器决定下一步 invoke 谁，Context Compiler 决定执行单元看见什么，Runtime 决定哪些修改正式生效。技能包是可装载能力，不是系统固定流水线。
 
 ---
 
@@ -125,7 +125,7 @@
 
 ### 5.4 Phase Runtime（Dynamic Scheduler 的具体形态）
 
-执行总管决定并维护相位边界：
+执行编排器决定并维护相位边界：
 
 1. 校验 Worker id ∈ 声明
 2. 编译上下文
@@ -147,7 +147,7 @@
 - **包 / Orchestrator manifest**：能力发现、验收与进 play 门槛
 - **Worker 契约**：声明驱动的输入输出、上下文段、工具边界
 
-注册、加载、版本与磁盘格式见 Skill 系列文档；**具体剧本步骤不在本文**。
+注册、加载、版本与磁盘格式见 Skill 系列文档；**具体工作流计划步骤不在本文**。
 
 ### 5.7 Context Compiler
 
@@ -192,7 +192,7 @@ Worker 不直接改「当前事实」。路径：输出 → 声明/schema 校验
 
 ## 7. 信息隔离
 
-隔离由 Runtime 强制：Worker 只看到契约允许的 tag / 段。多角色模拟时，角色 Worker 不得看到他角私有记忆、未公开事件、总管隐藏调度信息。
+隔离由 Runtime 强制：Worker 只看到契约允许的 tag / 段。多角色模拟时，角色 Worker 不得看到他角私有记忆、未公开事件、编排器隐藏调度信息。
 
 Context Trace 是排查泄漏的主工具（契约已定，实现渐进）。
 
@@ -206,7 +206,7 @@ Context Trace 是排查泄漏的主工具（契约已定，实现渐进）。
 | Agent Runtime | 自研（main-agent、phase-runtime、llm） | 领域对象不绑定外部 Agent 框架内部类型；Mastra 等仅可作按层参考或远期适配 |
 | 前端 | `web/` + Electron | 不强制 Next.js / assistant-ui；可借鉴交互模式 |
 | 存储 | 文件系统 Book JSON | SQLite/Drizzle 非近端前提 |
-| Skill | `skills/` + registry | 包内剧本与系统内核分离 |
+| Skill | `skills/` + registry | 包内工作流计划与系统内核分离 |
 
 外部仓库按模块借鉴，见 `references.md`；许可证见仓库根 `THIRD_PARTY_NOTICES.md`。
 
@@ -216,24 +216,26 @@ Context Trace 是排查泄漏的主工具（契约已定，实现渐进）。
 
 | 规划用语（抽象） | 本仓库用语（实现） |
 |------------------|-------------------|
-| CreationDefinition / DefinitionVersion | `设计.worker集` 截面；`instance` / `opening` 快照 |
-| RunInstance | Book + Session + 黑板 + `run` 快照 |
-| 导演 Skill / 能力包 | `orchestrator.md` 包（UI 可选；registry 一项） |
-| 剧本层（动态） | 对话谈成的 Worker 集 + play 期 tool loop 调度（非死板选单） |
-| Supervisor | Main Agent（tool loop） |
+| CreationDefinition / DefinitionVersion / 运行规格 | `设计.worker集` 截面；`instance` / `opening` 快照 |
+| RunInstance / 运行实例 | Book + Session + 黑板 + `run` 快照 |
+| Recipe / 配方 | `recipes/`（UI 选一层）；黑板 `创作.选用配方` |
+| Orchestrator / 编排器 | Main Agent（tool loop）+ `orchestrator.md` manifest |
+| Workflow Plan / 工作流计划 | `设计.创作流程`（增量 DAG；非死板选单） |
+| Skill / 技能 | `modules/` 工序池 |
+| Worker / 执行单元 | 一次 `run_worker` invoke |
 | Dynamic Scheduler | Phase Machine + Phase Runtime |
 | Worker Factory | `run_worker` → 声明校验 → executor |
 | Context Compiler | `assembleWorkerContext` / contextSegments |
 | Blackboard | tag 黑板（`BlackboardItem`） |
-| Commit Layer | 写入校验、表 rev 合并、acceptance |
+| Commit Layer / 人工审批 | 写入校验、表 rev 合并、acceptance |
 | Skill Registry | `skills/` loader + orchestrator manifest |
 
 用户可见中文口径（禁止裸露内部 id）见 `ui-glossary.md`。
 
 | 词 | 含义 |
 |----|------|
-| **Worker 声明** | accept 后的 `设计.worker集` |
-| **worker** | 一次 `run_worker` invoke |
+| **Worker 声明 / 运行规格** | accept 后的 `设计.worker集` |
+| **worker / 执行单元** | 一次 `run_worker` invoke |
 | **stage** | `design` → `play` → `done`（创作 → 游玩 → 已完成） |
 | **phase** | `idle` \| `running` \| `waiting_user` \| `done` \| `error` |
 
@@ -251,19 +253,20 @@ Context Trace 是排查泄漏的主工具（契约已定，实现渐进）。
 | **产品体验路线** | **`px-roadmap.md`**（PX0–PX5 交付与 DoD） |
 | **日常场景 → P0** | **`daily-use-p0.md`**（场景、功能表、P0 工作包） |
 | 外部参考 | `references.md` |
-| **剧本 / 创作方法（非系统架构）** | `design-orchestrator-guide.md`、`creation-playbook.md` |
+| **工作流计划 / 创作方法（非系统架构）** | `design-orchestrator-guide.md`、`creation-playbook.md`、`world-simulator-modules.md` |
 | **Skill 包格式（非系统架构）** | `skill-format.md`、`orchestrator-skill-format.md`、`worker-skill-format.md`、`skill-design-guide.md`、`preset-format.md` |
+| **技能撰写交接** | `briefs/capability-authoring-brief.md` |
 
 ---
 
 ## 11. 在现有内核上补齐（路线）
 
-已具备：相位机、Agent tool loop、Skill loader、design-intake、Worker 声明、上下文拼装、表 rev、Web UI、快照 API。
+已具备：相位机、Agent tool loop、Skill loader、design-flow/step（modules/recipes）、Worker 声明、上下文拼装、表 rev、Web UI、快照 API。
 
-1. **PX0**：导演选择 UI；AIRP + 长文/爽文主路径；**存档/续作硬稳定**；剧本层保持动态
+1. **PX0**：配方选择 UI；AIRP + 长文/爽文主路径；**存档/续作硬稳定**；工作流计划保持动态
 2. **PX1–PX2**：创作/游玩体验（可抄 UI）；副作用与多 run 线
 3. **PX3**：Context Trace、调度预算、规格钉版本、E2E
-4. **PX4–PX5**：长文加深；隔离模拟 + 调试（新方法边界可用新导演包）
+4. **PX4–PX5**：长文加深；隔离模拟 + 调试（新方法边界可用新配方）
 5. SQLite / 框架适配仅当痛点单开，不插入 PX0 关键路径
 
 权威表：[`px-roadmap.md`](./px-roadmap.md)。
@@ -286,16 +289,16 @@ Context Trace 是排查泄漏的主工具（契约已定，实现渐进）。
 
 ```text
 ✅ phase-machine、phase-runtime、skills loader
-✅ design-intake + Worker 声明校验
+✅ design-flow / design-step + modules/recipes + Worker 声明校验
 ✅ 声明驱动 worker 执行 + acceptance
 ✅ 表字段格 rev 合并
 ✅ Book session / run-snapshots / message branch
-✅ 导演选择 UI（新建作品）；instance/run 存档人话 kind
+✅ 配方选择 UI（新建作品）；instance/run 存档人话 kind
 ✅ 长文模板 outline / chapter-writer；引导覆盖爽文/分段
 ✅ 失败/revision/error 出口；黑板用户手改 API
-⬜ Context Trace
+🟡 Context Trace（有基础 trace UI；编译器装载检查未齐）
 ⬜ 规格版本发布与迁移协议
 ⬜ 调度嵌套 / 重复任务 / Token 预算补齐
-⬜ 边沿副作用完整调度器
+🟡 边沿副作用（有 table-side-effects；完整可观测 fixture 未齐）
 ⬜ 标准 fixture E2E（双线黄金路径自动化）
 ```

docs/book-storage.md

@@ -1,5 +1,9 @@
 # Book 存储模型
 
+> **状态：目标愿景（未完全实现）。**  
+> **现行实现**以 `src/types/book.ts`、`src/book/store.ts`、`src/types/book-session.ts` 与 [`run-snapshot.md`](./run-snapshot.md) 为准（扁平 `books/{id}.json` + `session.json` + run/instance 快照）。  
+> 下文 CardBook / PlayBook / designTrace 等为远期形态，**不要**按本文当当前磁盘契约写代码。
+
 ## 1. 定位
 
 Book = **长期项目容器**。Session = 一次打开的运行进程。黑板 = Session 内运行时 tag。

docs/briefs/capability-authoring-brief.md

@@ -1,11 +1,11 @@
-# 能力撰写交接简报（泛用）
+# 技能撰写交接简报（泛用）
 
-> **用途**：把本文**整份**交给另一 AI / 作者，用于撰写任意【能力】的 `modules/{id}/prompt.md`。  
+> **用途**：把本文**整份**交给另一 AI / 作者，用于撰写任意【技能】的 `modules/{id}/prompt.md`。  
 > **本文是自洽规范**：不依赖读者已熟悉本仓库。  
-> **不要**让撰写方改程序代码；**不要**只写某一能力的特例而不遵守通用格式。
+> **不要**让撰写方改程序代码；**不要**只写某一技能的特例而不遵守通用格式。
 
 范例（深度与结构对齐）：`skills/dialogue/world-simulator/modules/aesthetics-interaction/prompt.md`  
-能力池清单（选题用）：`docs/world-simulator-modules.md`  
+技能池清单（选题用）：`docs/world-simulator-modules.md`  
 术语权威：`docs/ui-glossary.md` §0
 
 ---
@@ -14,91 +14,93 @@
 
 ## 1.1 一句话
 
-**writing-agent** 是本地运行的多 Agent **文本创作 / 游玩**系统：用户选一个【导演】，在【创作】期谈成【剧本】，再在【游玩】期让【演员】按剧本上场，产出可读文本（角色扮演、长文/爽文、扩写、思想实验等共用同一内核）。
+**writing-agent** 是本地运行的多 Agent **文本创作 / 游玩**系统：用户选一个【配方】，在【创作】期谈成【工作流计划】与【运行规格】，再在【游玩】期让【执行单元】按规格上场，产出可读文本（角色扮演、长文/爽文、扩写、思想实验等共用同一内核）。
 
 ## 1.2 要解决什么问题
 
 | 要 | 不要 |
 |----|------|
 | 用程序控制「每一步注入什么上下文」 | 把整本长说明书一次塞进 LLM |
-| 用 Agent 按用户体验**编排**用哪些能力、什么顺序 | 死板选单 DAG，或全程让 LLM 自由发明工序 |
+| 用编排器按用户体验**编排**用哪些技能、什么顺序 | 死板选单 DAG，或全程让 LLM 自由发明工序 |
 | 产物可解析、可渲染、对人可读 | 产物里堆满英文变量名让用户难受 |
-| 规格（能复用的声明）与一局游玩过程分离 | 每种玩法重写一套运行时 |
+| 运行规格（能复用的声明）与一局游玩过程分离 | 每种玩法重写一套运行时 |
 
 ## 1.3 两段生命周期
 
 ```text
-【创作 design】选导演 → 编排剧本（步骤=能力）→ 逐步执行能力 → 谈成可运行规格
+【创作】选配方 → 编排工作流计划（步骤=技能）→ 逐步执行技能 → 谈成运行规格
         │
         ▼ 用户手动进入
-【游玩 play】用户输入 → 演员按规格上场 → 可见终稿；可存档 / 重 roll
+【游玩】用户输入 → 执行单元按规格上场 → 可见终稿；可存档 / 重 roll
 ```
 
-- **创作**：谈清「这局要什么体验、用哪些能力钉成什么产物」。  
-- **游玩**：按已验收规格跑；用户新输入通常视为认可上一轮展示（否则重 roll）。
+- **创作**：谈清「这局要什么体验、用哪些技能钉成什么产物」。  
+- **游玩**：按已验收运行规格跑；用户新输入通常视为认可上一轮展示（否则重 roll）。
 
-## 1.4 运行时怎么分工（撰写能力时必须懂）
+## 1.4 运行时怎么分工（撰写技能时必须懂）
 
 | 角色 | 做什么 | 不做什么 |
 |------|--------|----------|
-| **导演（Agent）** | 决定下一步调哪个演员；编排剧本步骤 | 不直接写小说正文；不私自改相位 |
+| **编排器** | 决定下一步调哪个执行单元；编排工作流计划步骤 | 不直接写小说正文；不私自改相位 |
 | **程序（Runtime）** | 校验权限；按契约拼上下文；切步；发 opening；验收门控 | 不替用户发明体验 |
-| **能力（modules）** | 某一步「怎么和用户谈、产出什么形状」的方法正文 | 不是整场流水线 |
-| **演员（Worker）** | 一次 LLM 执行（创作期跑能力，或游玩期跑声明内 ref） | 不决定全局调度 |
+| **技能（modules）** | 某一步「怎么和用户谈、产出什么形状」的方法正文 | 不是整场流水线 |
+| **执行单元（Worker）** | 一次 LLM 执行（创作期跑技能，或游玩期跑声明内 ref） | 不决定全局调度 |
 
 关键路径：
 
 ```text
-用户选【导演】（如世界模拟器）
-  → design-flow：从【能力】排出**近期**步骤，写出 设计.创作流程
+用户选【配方】（如世界模拟器）
+  → design-flow：从【技能】排出**近期**步骤，写出 设计.创作流程（工作流计划）
        （可变增量 DAG：每步 id + 固定中文名 + depends_on；status=open|closed）
   → 用户验收近期流程
-  → 反复 design-step：程序注入「当前能力」的 prompt 切片 + 依赖产物
-  → 步骤做完仍 open → 再 design-flow（可追加同能力多次，如生成规则 / 具体实例）
-  → closed 后收成可进游玩的规格，如 设计.worker集
+  → 反复 design-step：程序注入「当前技能」的 prompt 切片 + 依赖产物
+  → 步骤做完仍 open → 再 design-flow（可追加同技能多次，如生成规则 / 具体实例）
+  → closed 后收成可进游玩的运行规格，如 设计.worker集
   → 用户手动进游玩
 ```
 
 ## 1.5 磁盘上两层内容（作者视角）
 
 ```text
-【导演】recipes/{导演id}/recipe.yaml     该方法的建议近期起点 / 调味说明
-【能力】modules/{能力id}/prompt.md       共用工序；多导演可选用同一能力
-       modules/catalog.yaml             能力目录：中文名 + 短声明 + 产物 tag（+ 可选 repeatable）
+【配方】recipes/{配方id}/recipe.yaml     方法论（适用/核心思路/设计流程/原则）+ 近期起点
+【技能】modules/{技能id}/prompt.md       共用工序；编排读 meta 选型，执行读方法全文
+       modules/catalog.yaml             技能目录：中文名 + 短声明 + 产物 tag（+ 可选 repeatable）
 ```
 
-- 新建作品**只选导演一层**，不再叠「能力包 + 配方」。  
-- 导演给出的步骤是**近期起点**；本局可增量追加、可反复调用标了 `repeatable` 的能力；验收的是本局【剧本】，不是磁盘死菜谱。
+- 新建作品**只选配方一层**，不再叠第二层选型。  
+- 配方给出的步骤是**近期起点**；本局可增量追加、可反复调用标了 `repeatable` 的技能；验收的是本局【工作流计划】与【运行规格】，不是磁盘死菜谱。
 
 ---
 
 # 第二部分：称呼定义（必须统一）
 
-对用户与能力正文，优先用**拍摄隐喻**。括号内为内部/旧称，撰写时勿当用户主词。
+对用户与技能正文，优先用下表中文。括号内为业界叫法 / 内部 id，撰写时勿当用户主词堆砌。
 
-## 2.1 四个核心词
+## 2.1 六个核心词
 
-| 称呼 | 含义 | 内部大致对应 | 禁止对用户说 |
-|------|------|--------------|--------------|
-| **导演** | ① 新建时选一次的方法起点（世界模拟器、扩写助手…）；② 会话里负责调度的 Agent | `recipes/`、Main Agent / orchestrator | 总管、配方（作选型主词）、能力包（作第二层选项） |
-| **剧本** | 本局谈成的流程与规格（活的） | `设计.创作流程` + 各能力产物 + 终稿 `设计.worker集` 等 | 「剧本 Skill 菜单」、死板流程卡 |
-| **演员** | 上场执行的一次单元 | Worker / `run_worker` | 对用户堆 `Worker · english-id` |
-| **能力** | 共用工序模块；导演从池里选型编排 | `modules/{id}/` | 组件池、模块（作者文档可用；用户文案用「能力」） |
+| 称呼 | 业界叫法 | 含义 | 内部大致对应 | 禁止对用户说 |
+|------|----------|------|--------------|--------------|
+| **配方** | Recipe | 新建时选一次的方法起点（世界模拟器、扩写助手…） | `recipes/` | 导演（旧）、能力包（作第二层选项） |
+| **编排器** | Orchestrator | 会话里负责调度的 Agent | Main Agent / orchestrator | 导演、总管（旧） |
+| **工作流计划** | Workflow Plan / Horizon DAG | 本局谈成的近期增量步骤图 | `设计.创作流程` | 剧本（旧，流程部分）、死板流程卡 |
+| **运行规格** | Runtime Spec | 可进游玩的执行声明 | `设计.worker集` 等 | 剧本（旧，规格部分） |
+| **执行单元** | Worker | 上场执行的一次单元 | Worker / `run_worker` | 演员（旧）；对用户堆 english-id |
+| **技能** | Skill | 共用工序模块；编排器从池里选型编排 | `modules/{id}/` | 能力（旧）、组件池 |
 
 关系口诀：
 
 ```text
-选导演 → 用能力编排 → 谈成剧本 → 演员按剧本上场
+选配方 → 用技能编排 → 谈成工作流计划 → 收成运行规格 → 执行单元按规格上场
 ```
 
 ## 2.2 阶段与界面
 
 | 称呼 | 含义 |
 |------|------|
-| **创作** | lifecycle `design`：谈剧本 |
-| **游玩** | lifecycle `play`：演员上场 |
+| **创作** | lifecycle `design`：谈工作流计划与运行规格 |
+| **游玩** | lifecycle `play`：执行单元上场 |
 | **产物** | 某步待验收输出（写入黑板 tag） |
-| **验收 / 接受** | 用户确认产物算数 |
+| **验收 / 接受** | 用户确认产物算数（人工审批） |
 | **黑板** | 按 tag 存正文的上下文板 |
 | **询问卡** | 结构化提问（选项可改写） |
 
@@ -106,11 +108,11 @@
 
 | 内部 id | 用户可见 | 含义 |
 |---------|----------|------|
-| `design-flow` | 创作 · 流程编排 | 编排/增量修订可变 DAG → `设计.创作流程` |
-| `design-step` | 创作 · 执行步骤 | 执行剧本中当前那一个能力 |
+| `design-flow` | 创作 · 流程编排 | 编排/增量修订工作流计划 → `设计.创作流程` |
+| `design-step` | 创作 · 执行步骤 | 执行工作流计划中当前那一个技能 |
 | `opening-generator` | 开局 · 开场白 | 可选；规格收成后的开场白 |
 
-## 2.4 剧本流程 JSON（编排产物：增量 DAG）
+## 2.4 工作流计划 JSON（编排产物：增量 DAG）
 
 ```json
 {
@@ -128,52 +130,53 @@
 |------|------|
 | `status` | `open` = 还可追加；`closed` = 不再扩步。缺省兼容旧稿视为已收口 |
 | `steps` 顺序 | 建议执行顺序 |
-| `id` | 本局步骤唯一键；同能力多次必须不同 |
-| `name` | 必须与能力目录中的**固定中文名**完全一致（可重复） |
+| `id` | 本局步骤唯一键；同技能多次必须不同 |
+| `name` | 必须与技能目录中的**固定中文名**完全一致（可重复） |
 | `depends_on` | 依赖的其它步骤 **id**（若某 name 在本流程唯一，也可写 name） |
 
 程序用中文 `name` 映射到 `artifact` tag；流程 JSON **不写**英文模块 id / tag。  
-**禁止**一次排死全程固定长链；「生成规则」「具体实例」等标了 `repeatable` 的能力应允许多次编入。
+**禁止**一次排死全程固定长链；「生成规则」「具体实例」等标了 `repeatable` 的技能应允许多次编入。
 
-## 2.5 已合并能力（勿拆回）
+## 2.5 已合并技能（勿拆回）
 
-| 错误拆法 | 正确能力 |
+| 错误拆法 | 正确技能 |
 |----------|----------|
 | 「交互范式」+「美学纲领」两步 | **美学纲领与交互范式**（`aesthetics-interaction`）一步 |
 
-询问相近则合并为一步；不要在新能力里建议再拆开。
+询问相近则合并为一步；不要在新技能里建议再拆开。
 
 ## 2.6 命名纪律
 
 | 种类 | 规则 | 例 |
 |------|------|-----|
-| 能力中文名 | 稳定、给人看、进流程 JSON | `实现机制` |
-| 能力 id | 英文 kebab，= 文件夹名 | `mechanism` |
+| 技能中文名 | 稳定、给人看、进流程 JSON | `实现机制` |
+| 技能 id | 英文 kebab，= 文件夹名 | `mechanism` |
 | 产物 tag | 通常 `设计.{中文名或约定名}` | `设计.实现机制` |
-| 游玩演员 ref | 英文 kebab | `narrator` |
-| 游玩演员展示名 | 中文 `name` | `叙事转述` |
+| 游玩执行单元 ref | 英文 kebab | `narrator` |
+| 游玩执行单元展示名 | 中文 `name` | `叙事转述` |
 | UI | 禁止裸露内部英文 id | 不要写 `design-step` 给用户 |
 
 ---
 
-# 第三部分：什么是「能力」（泛用定义）
+# 第三部分：什么是「技能」（泛用定义）
+
 
 ## 3.1 定义
 
-**能力** = 创作期可被编排进剧本的**一步工序**：
+**技能** = 创作期可被编排进工作流计划的**一步工序**：
 
 1. 有固定中文名与产物 tag；  
 2. 有一份程序可切割的方法文档（`prompt.md`）；  
-3. 执行时只注入**本能力**方法 + **依赖产物** + 用户表述；  
+3. 执行时只注入**本技能**方法 + **依赖产物** + 用户表述；  
 4. 与用户对话后产出**可验收**的结构化结果。
 
-能力**不是**：整场游戏引擎、游玩期每轮演员、也不是导演本身。
+技能**不是**：整场游戏引擎、游玩期每轮执行单元、也不是配方/编排器本身。
 
 ## 3.2 能力在系统中的生命周期
 
 ```text
 catalog 登记（短声明给编排看；可选 repeatable）
-    → 导演/编排增量选入 设计.创作流程（可同能力多次）
+    → 编排器增量选入 设计.创作流程（可同技能多次）
     → 用户验收流程（或后续扩步后再验）
     → 轮到该步：若有 opening → 程序先发出
     → 用户首答 → LLM 按能力方法谈/写
@@ -185,25 +188,25 @@ catalog 登记（短声明给编排看；可选 repeatable）
 
 | 交付物 | 路径 | 给谁看 |
 |--------|------|--------|
-| 目录行 | `modules/catalog.yaml` 一行 | 编排：只看短 `declaration` |
-| 方法全文 | `modules/{id}/prompt.md` | 执行该步的 LLM + 程序切割 |
+| 目录行 | `modules/catalog.yaml` 一行 | 索引、`repeatable`、编排 `params` |
+| 方法全文 | `modules/{id}/prompt.md` | 执行该步的 LLM + 程序切割；**编排读 `meta` 的 when/when_not/boundary** |
 
-编排时**禁止**把全文 prompt 塞进导演上下文；执行时才注入切割后的方法块。
+编排时注入能力 **meta 选型字段**（非全文 prompt）；执行时才注入切割后的方法块。
 
 ## 3.4 能力之间如何相处
 
-- **正推**：需要 [体验/产物] → 才纳入某能力；勿默认全选池内能力。  
+- **正推**：需要 [体验/产物] → 才纳入某技能；勿默认全选池内能力。  
 - **边界**：每个能力在 `meta.boundary` 写清「本步定什么 / 不定什么 / 交给谁」。  
-- **依赖**：由剧本 `depends_on` 声明；执行期程序注入对应产物。  
+- **依赖**：由工作流计划 `depends_on` 声明；执行期程序注入对应产物。  
 - **合并**：询问主题高度重叠 → 合成一个能力（如美学+交互）。  
 - **缩减**：每增必问能否删、能否常驻替代、能否合并。
 
 ## 3.5 方法层硬禁止（写任何能力都适用）
 
-- 题材 → 固定演员清单。  
+- 题材 → 固定执行单元清单。  
 - 否定式路由（「因为是 X 所以不需要 Y」）；应写「需要 A 体验 → 用 B 手段」。  
 - 把「世界模拟」当成一切开场的默认答案。  
-- 为排版/格式单独发明演员；能程序拼则程序拼。  
+- 为排版/格式单独发明执行单元；能程序拼则程序拼。  
 - 临时发明 tool。  
 - 一次 burst 写齐全部能力产物。  
 - 在能力产物里堆大量用户看不懂的英文变量名（机器 id 可有，但须有中文展示字段）。
@@ -251,7 +254,7 @@ when: |
 when_not: |
   {什么情况下不要进来}
 boundary: |
-  本能力：…
+  本技能：…
   邻接能力：…（点名其它能力中文名，说明分工）
 ```
 
@@ -306,7 +309,7 @@ boundary: |
 | `id` | 英文 id（= 目录名） |
 | `artifact` | 本步写入的黑板 tag |
 | `declaration` | 给编排看的短声明（不是全文） |
-| `when` / `when_not` | 何时该/不该入选剧本 |
+| `when` / `when_not` | 何时该/不该入选工作流计划 |
 | `boundary` | 与邻接能力的分工 |
 
 ## 4.4 `catalog.yaml` 一行
@@ -321,11 +324,11 @@ boundary: |
 
 | 字段 | 谁用 |
 |------|------|
-| `declaration` | 插入导演/编排提示，选型 |
+| `declaration` | 插入编排提示，选型 |
 | `name` / `artifact` | 流程与执行映射 |
 | `opening` | 可选覆盖；一般只写在 prompt 的 `opening` 块 |
 
-改 `name` 会破坏已有剧本 JSON，尽量不改。
+改 `name` 会破坏已有工作流计划 JSON，尽量不改。
 
 ## 4.5 opening 节奏（通用）
 
@@ -348,7 +351,7 @@ task 必须写：禁止重复同一开场；在首答上补洞。
 - **键名对人友好**（中文或稳定中文标签）。  
 - 机器 id（如 `ref`）若需要，与中文名成对出现。  
 - 写清「本步完成的定义」；未决放 `开放问题`，不要假完备。  
-- 不要在本能力产物里偷偷交下游能力该交的终稿（除非本能力就是收成步）。
+- 不要在本技能产物里偷偷交下游能力该交的终稿（除非本技能就是收成步）。
 
 ## 4.8 追问（`probe`）通用要求
 
@@ -373,7 +376,7 @@ task 必须写：禁止重复同一开场；在首答上补洞。
 
 # 第六部分：给撰写 AI 的通用任务指令（粘贴用）
 
-请撰写（或重写）一个【能力】文档：  
+请撰写（或重写）一个【技能】文档：  
 `skills/dialogue/world-simulator/modules/{id}/prompt.md`  
 （具体中文名 / id / 边界由出题方在指令末行指定。）
 
@@ -381,7 +384,7 @@ task 必须写：禁止重复同一开场；在首答上补洞。
 
 1. 本文**第一部分～第四部分**的项目理解、称呼与格式契约。  
 2. 只使用规定的 fence 块；不要发明新 fence 名。  
-3. 对用户话术使用导演/剧本/演员/能力；不要写「总管调度 design-xxx」。  
+3. 对用户话术使用配方/编排器/工作流计划/执行单元/技能；不要写「编排器调度 design-xxx」。  
 4. 正推：体验 → 手段；禁止题材套件与否定式路由。  
 5. 交互与美学已合并为「美学纲领与交互范式」；禁止建议拆回两步。  
 6. 不要修改程序代码；默认只交付 `prompt.md`（除非出题方要求改 catalog）。  
@@ -400,27 +403,27 @@ artifact：
 
 ---
 
-# 第七部分：当前能力池速查（选题，非本文重点）
+# 第七部分：当前技能池速查（选题，非本文重点）
 
 世界模拟器常用（编排按需，勿默认全选）：
 
 | 能力 | id | 状态（以仓库为准） |
 |------|-----|-------------------|
 | 美学纲领与交互范式 | `aesthetics-interaction` | 范例 |
-| 实现机制 | `mechanism` | 待细写 |
+| 实现机制 | `mechanism` | 已写 |
 | 世界蓝图与人文地理 | `world-blueprint` | 已写 |
-| 生成规则 | `generation-rules` | 待细写 |
-| 具体实例 | `concrete-instances` | 待细写 |
+| 生成规则 | `generation-rules` | 已写（可反复） |
+| 具体实例 | `concrete-instances` | 已写（可反复） |
+| 叙事指南 | `narrative` | 已写 |
 | 拓扑图谱 | `topology` | 待细写 |
-| 叙事指南 | `narrative` | 待细写 |
 | 变量设计与更新规则 | `variable-design` | 待细写 |
 | 变量控制上下文 | `variable-context` | 待细写 |
 | 设计状态栏 | `status-bar` | 待细写 |
 | 设计回复格式 | `reply-format` | 待细写 |
-| Worker 规格 | `worker-spec` | 待细写 |
-| 细化终稿 | `refine` | 待细写 |
+| Worker 规格 | `worker-spec` | 已写（可反复） |
+| 细化终稿 | `refine` | 已写 |
 
-导演示例：世界模拟器、扩写助手（见 `recipes/`）。
+配方：世界模拟器、扩写助手（见 `recipes/`；写 `core`/`process`/`principles` + 起步 steps）。
 
 ---
 
@@ -432,4 +435,4 @@ artifact：
 | `world-simulator-modules.md` | 仓库内清单与格式摘要 |
 | `ui-glossary.md` | 用户可见文案权威 |
 | `architecture.md` | 运行内核；写能力时不必复述实现细节 |
-| 旧 `capability-mechanism-handoff.md` | 已过时为「单能力特例」；以本文为准 |
+| （已删）单能力特例简报 | 以本文为准；勿再恢复特例交接文 |

docs/briefs/capability-mechanism-handoff.md

@@ -1,20 +0,0 @@
-# （已迁移）实现机制单能力简报
-
-本文件原先只讲「实现机制」特例，**已废弃**。
-
-请改用泛用交接简报：
-
-→ **[`capability-authoring-brief.md`](./capability-authoring-brief.md)**
-
-其中包含：项目概述、导演/剧本/演员/能力称呼、泛用能力格式规范，以及可粘贴给其它 AI 的任务指令。
-
-若要写「实现机制」，在泛用简报第六部分末行填写：
-
-```text
-能力中文名：实现机制
-id：mechanism
-artifact：设计.实现机制
-上游依赖（常见）：美学纲领与交互范式
-明确不做（交给谁）：拓扑图谱 / Worker 规格 / 变量* / 状态栏 / 回复格式 / 细化终稿
-特殊产物要求（可选）：总览最小可运行结构；含「为何需要」「未纳入与原因」；正推禁止默认世界模拟套件
-```

docs/creation-playbook.md

@@ -1,31 +1,31 @@
 # 创作流程指南（Creation Playbook）
 
-> **文档层级：剧本 / 创作流程概念（非系统架构）。**  
+> **文档层级：工作流计划 / 创作流程概念（非系统架构）。**  
 > 系统模块与边界见 [`architecture.md`](./architecture.md)。
 
 ## 0. 内容在哪
 
 **设计方法（正推、三大步、表与副作用）** → **`design-orchestrator-guide.md`**（权威）。  
-**流程落地**在 skill 包（`orchestrator.md` + `design-intake`）。  
-写新包 → `skill-design-guide.md`（包格式薄层）→ `skills/.../orchestrator.md`。
+**流程落地**在 skill 包：`orchestrator.md` + `design-flow` / `design-step` + `modules/` / `recipes/`。  
+写新包 → `skill-design-guide.md`（包格式薄层）→ `skills/.../orchestrator.md`；清单见 `world-simulator-modules.md`。
 
 ---
 
 ## 1. 定位
 
 ```text
-Orchestrator 包     能力库 + manifest（静态）
+Orchestrator 包     技能库 + manifest（静态）
 黑板 tag            一次 Session 的实参（动态）
 Book                跨 Session：过程、资产、游玩
-设计.worker集       实例规格（JSON；accept 后 = Worker 声明）
+设计.worker集       运行规格（JSON；accept 后 = 执行单元声明）
 ```
 
 | 层 | 管什么 |
 |----|--------|
 | **运行相位** | `idle` / `running` / `waiting_user` — 系统在等什么 |
 | **业务 stage** | `design`（创作）→ `play`（游玩）→ `done` |
-| **Agent** | tool loop 内 invoke 哪个 worker |
-| **声明** | play 可调度哪些 ref；executor 读声明（非题材管道） |
+| **编排器** | tool loop 内 invoke 哪个执行单元 |
+| **运行规格** | play 可调度哪些 ref；executor 读声明（非题材管道） |
 | **Book** | 长期存储，见 `book-storage.md` |
 
 ---
@@ -33,18 +33,16 @@ Book                跨 Session：过程、资产、游玩
 ## 2. 默认包创作流
 
 ```text
-新建作品 → UI 引导 → 用户首句 → 创作单位逐步谈
-  → 宜：phase:core → 纲领类 fixed:* → worker:* → refine
-     （非死管道；可穿插，但禁止默认「先写完 worker 再填上下文」）
-  → 单位 = 已写出的 fixed:* / resident:* | worker:*（示例话题可问用户，非填空）
-  → 单位跑：只写 设计.worker集.草稿；讨论进 messages
-  → 用户接受 → 删本单位交互消息，只留产物；草稿保留
-  → ……谈完后终稿写 设计.worker集 → 验收后才可进 play
-  → （可选）开局 · 开场白 → 用户手动进游玩
-  → run：worker 按契约从黑板重装；acceptance=review 处停、压缩过程 tag
+新建作品 → UI 选配方 → 用户首句
+  → design-flow：排出近期 设计.创作流程（工作流计划 / 增量 DAG，status=open|closed）
+  → 反复 design-step：注入当前技能 modules/{id}/prompt.md + 依赖产物
+  → 不够则再 design-flow（可追加 / 反复调用 repeatable 技能）→ closed
+  → 收成 设计.worker集（运行规格）→ 验收后才可进 play
+  → （可选）opening-generator → 用户手动进游玩
+  → run：执行单元按契约从黑板重装；acceptance=review 处停、压缩过程 tag
 ```
 
-固定上下文 tag 的主收益是 **跨 worker 复用同一份正文**；写下游时仍依赖上游定稿（不能只报 tag 名省掉正文）。能省的是扯皮过程（验收折叠）。
+固定上下文 tag 的主收益是 **跨执行单元复用同一份正文**；写下游时仍依赖上游定稿（不能只报 tag 名省掉正文）。能省的是扯皮过程（验收折叠）。
 
 不再要求用户选择 skill 包；默认 orchestrator 见 `src/config/default-orchestrator.ts`。  
 方法细节见 **`design-orchestrator-guide.md` §7.2**。不要以「世界模拟器」为默认总形态。

docs/daily-use-p0.md

@@ -15,37 +15,39 @@
 |---|------|
 | 1 | 日常包含 **两类**：AIRP/交互扮演 **与** 长文/爽文创作（同一运行内核） |
 | 2 | **UI 不自研美学**：布局/控件直接抄参考产品即可；**存档与续作稳定是硬指标** |
-| 3 | **导演**：新建时用 UI **选一个**（世界模拟器 / 扩写助手…；初期可只有 1 项） |
-| 4 | **剧本动态**：不在 UI 里点选死板「剧本菜单」；选定导演后，由导演（Agent）听用户说话谈出本局剧本（创作流程 / Worker 集）与调度 |
+| 3 | **配方**：新建时用 UI **选一个**（世界模拟器 / 扩写助手…；初期可只有 1 项） |
+| 4 | **工作流计划动态**：不在 UI 里点选死板「流程菜单」；选定配方后，由编排器听用户说话谈出本局工作流计划（创作流程）与运行规格（Worker 集）并调度 |
 
-用户侧拍摄术语权威对照：**`ui-glossary.md` §0**（导演 / 剧本 / 演员 / 能力）。
+用户侧术语权威对照：**`ui-glossary.md` §0**（配方 / 编排器 / 技能 / 工作流计划 / 运行规格 / 执行单元）。
 
-### 0.2 导演 vs 剧本（动态）
+### 0.2 配方 vs 工作流计划 / 运行规格（动态）
 
 ```text
-导演        = 用户 UI 选一次的方法起点（可调味）
-            = 内部 recipes / 原「能力包·配方」合一
+配方        = 用户 UI 选一次的方法起点（可调味）
+            = 内部 recipes/
             = 例：世界模拟器、扩写助手
 
-剧本        ≠ 再选一张固定流程卡
-            = 选定导演之后：用户说话 → 导演调度创作
-              → 产出 设计.创作流程 + 设计.worker集（本局活剧本）
-              → 游玩再按声明让【演员】上场
+工作流计划  ≠ 再选一张固定流程卡
+            = 选定配方之后：用户说话 → 编排器调度创作
+              → 产出 设计.创作流程（近期增量 DAG）
 
-能力        = 共用工序（美学纲领与交互范式…）；导演从中编排
-演员        = 实际上场的 Worker
+运行规格    = 谈成的 设计.worker集 等可进游玩声明
+            → 游玩再按声明让【执行单元】上场
+
+技能        = 共用工序（美学纲领与交互范式…）；编排器从中编排
+执行单元    = 实际上场的 Worker
 ```
 
-| | 导演 | 剧本（动态） |
+| | 配方 | 工作流计划 / 运行规格（动态） |
 |--|------|----------------|
-| 谁选 | **用户 UI**（显式，一层） | **导演 Agent + 用户对话**（隐式） |
-| 变不变 | 选项相对稳定 | 每局流程、Worker 集、回合调度都可变 |
-| 忌讳 | 再叠一层「配方」选择 | 固化成死 DAG / 死选单 |
+| 谁选 | **用户 UI**（显式，一层） | **编排器 + 用户对话**（隐式） |
+| 变不变 | 选项相对稳定 | 每局流程、运行规格、回合调度都可变 |
+| 忌讳 | 再叠一层选型 | 固化成死 DAG / 死选单 |
 | 本仓库对应 | `recipes/` + 默认 skill 包 | `设计.创作流程` / `设计.worker集` |
 
-因此：**只给导演一个选择 UI**；**不要**再给「剧本 / 配方」做第二层死板选择器。
+因此：**只给配方一个选择 UI**；**不要**再给「工作流计划」做第二层死板选择器。
 
-**多导演**才有意义的情况：方法边界真不同（世界模拟 vs 扩写助手），而不是同一导演内的题材分化——后者留在剧本层动态谈成。
+**多配方**才有意义的情况：方法边界真不同（世界模拟 vs 扩写助手），而不是同一配方内的题材分化——后者留在工作流计划层动态谈成。
 
 ---
 
@@ -88,7 +90,7 @@ A4 / B4 **共用**同一套存档语义（`session.json` + `instance`/`run` 快
 |----|------|
 | N2 | 狼人杀级信息隔离 |
 | N3 | Context Trace 专业调试台 |
-| N4 | 多导演**运营商店**（P0 只要选择 UI，可仅 1 项） |
+| N4 | 多配方**运营商店**（P0 只要选择 UI，可仅 1 项） |
 | N5 | DefinitionVersion 完整发布迁移协议 |
 | N6 | SillyTavern 卡批量导入导出 |
 | N7 | 自研精美 UI / 按 `ui-design` 大改布局（**抄参考即可**） |
@@ -103,8 +105,8 @@ A4 / B4 **共用**同一套存档语义（`session.json` + `instance`/`run` 快
 
 | 功能 | 现状 | P0? |
 |------|------|-----|
-| 新建作品 → 选导演（能力包；初期可仅一项） | ✅/🟡 | **必做**（有选择 UI；一项时默认选中即可） |
-| 意图可走扮演 **或** 写手/爽文（剧本层动态，不另选死板剧本卡） | 🟡 | **必做** |
+| 新建作品 → 选配方（能力包；初期可仅一项） | ✅/🟡 | **必做**（有选择 UI；一项时默认选中即可） |
+| 意图可走扮演 **或** 写手/爽文（工作流计划层动态，不另选死板流程卡） | 🟡 | **必做** |
 | 验收出口无死胡同 | 🟡 | **必做** |
 | 进入游玩/写作阶段门槛清晰 | 🟡 | **必做** |
 | UI 自研打磨 | — | **不做**；缺块就抄参考产品交互 |
@@ -138,14 +140,14 @@ A4 / B4 **共用**同一套存档语义（`session.json` + `instance`/`run` 快
 
 ## 3. P0 详细路径
 
-**P0 一句话**：用户用 UI 选好**导演 Skill**（初期可只有一个）后，AIRP 与长文/爽文都在**剧本层动态**谈成并跑起来，且 **存档/续作稳定**；UI 抄参考即可。
+**P0 一句话**：用户用 UI 选好**配方**（初期可只有一个）后，AIRP 与长文/爽文都在**工作流计划层动态**谈成并跑起来，且 **存档/续作稳定**；UI 抄参考即可。
 
 ### 3.1 黄金路径（两条都要绿）
 
 **线 A（扮演）**
 
 ```text
-A-GP1  新建 → UI 选导演（可仅一项）→ 描述扮演/交互意图
+A-GP1  新建 → UI 选配方（可仅一项）→ 描述扮演/交互意图
 A-GP2  验收至可进游玩
 A-GP3  ≥3 回合输入→终稿
 A-GP4  存 run 档 → 刷新/重开续作成功
@@ -155,7 +157,7 @@ A-GP5  加载 earlier 档或新开一条线之一可用
 **线 B（长文/爽文）**
 
 ```text
-B-GP1  新建 → UI 选导演 → 描述爽文/长篇意图（写手或分段助手）
+B-GP1  新建 → UI 选配方 → 描述爽文/长篇意图（写手或分段助手）
 B-GP2  验收至可进写作（Worker 集含大纲/写章类能力，勿只能聊天扮演）
 B-GP3  连续生成 ≥2 段（章）正文
 B-GP4  存档含已生成正文 → 续作能接着写下一段
@@ -174,12 +176,12 @@ B-GP5  回到 earlier 档重 roll 某段 或 等价恢复可用
 | S4 | 回归：线 A、线 B 各完整存读一轮，不手改 `books/` | 双线绿 |
 | S5 | 已知「存档丢正文 / 续作进死相位」类 bug 清零 | 无阻断 |
 
-#### WP-D 导演选择（与存档并列早做）
+#### WP-D 配方选择（与存档并列早做）
 
 | # | 项 | 验收 |
 |---|-----|------|
-| D0 | 新建作品可选导演（registry）；仅 1 项时默认选中并可确认 | 进入该包创作 |
-| D1 | 人话展示导演名/简介，不暴露路径 | 可选懂 |
+| D0 | 新建作品可选配方（registry）；仅 1 项时默认选中并可确认 | 进入该包创作 |
+| D1 | 人话展示配方名/简介，不暴露路径 | 可选懂 |
 
 #### WP-A 进出与失败出口（文案够用即可）
 
@@ -202,7 +204,7 @@ B-GP5  回到 earlier 档重 roll 某段 或 等价恢复可用
 | # | 项 | 验收 |
 |---|-----|------|
 | L1 | 启动引导明确支持「写爽文/长篇/先大纲再写」 | B-GP1 |
-| L2 | design 能稳定收到写手向 Worker 集（补 template 或 design 提示，**同一导演内动态谈成**） | B-GP2 |
+| L2 | design 能稳定收到写手向 Worker 集（补 template 或 design 提示，**同一配方内动态谈成**） | B-GP2 |
 | L3 | play 连续 ≥2 段正文 | B-GP3 |
 | L4 | 正文在存档/续作中仍在 | B-GP4 |
 
@@ -222,7 +224,7 @@ B-GP5  回到 earlier 档重 roll 某段 或 等价恢复可用
 
 ### 3.3 P0 明确不做
 
-- 第二套死板「剧本选单」/ 固定题材 DAG  
+- 第二套死板「流程选单」/ 固定题材 DAG  
 - 自研精美 UI、工作台大改  
 - 隔离模拟、Trace 台、完整副作用调度、版本迁移协议  
 - 为文采大改全套提示词（仅修**阻断线 B 收不成写手规格**的引导/模板）  
@@ -231,19 +233,19 @@ B-GP5  回到 earlier 档重 roll 某段 或 等价恢复可用
 
 ```text
 1. WP-S 存档稳定（先修已知腐档）
-2. WP-D 导演选择 UI（可仅一项）
+2. WP-D 配方选择 UI（可仅一项）
 3. WP-A 失败出口 / 进出
 4. WP-R 线 A 回合
 5. WP-L 线 B 长文最小闭环（引导 + template + 存档验正文）
-6. WP-U 仅补抄来的缺口控件（含选导演/存档若未齐）
+6. WP-U 仅补抄来的缺口控件（含选配方/存档若未齐）
 7. WP-E 双线验收闸门 → P0 完成
 ```
 
 ### 3.5 P0 DoD
 
-- [ ] 线 A：A-GP1–5 通过（含选导演、续作/读档）  
-- [ ] 线 B：B-GP1–5 通过（含选导演、正文不丢）  
-- [ ] 导演选择 UI 可用（可仅一项）  
+- [ ] 线 A：A-GP1–5 通过（含选配方、续作/读档）  
+- [ ] 线 B：B-GP1–5 通过（含选配方、正文不丢）  
+- [ ] 配方选择 UI 可用（可仅一项）  
 - [ ] 无等待死胡同；失败可重试  
 - [ ] 不依赖手改磁盘文件  
 - [ ] UI 无大改承诺；存档稳定优先于观感  
@@ -254,13 +256,13 @@ B-GP5  回到 earlier 档重 roll 某段 或 等价恢复可用
 
 | 日常能力 | 阶段 |
 |----------|------|
-| 导演选择 UI（可仅一项）、剧本层动态谈规格、AIRP+长文主路径、**存档续作硬稳定** | **P0** |
+| 配方选择 UI（可仅一项）、工作流计划层动态谈规格、AIRP+长文主路径、**存档续作硬稳定** | **P0** |
 | 抄来的 UI 缺口补齐 | **P0（U）** / 不够再后补 |
 | 表编辑精修、改规格心流、副作用完整 | **PX1/PX2** |
 | Trace、预算、版本协议、E2E | **PX3** |
 | 长文「专业编辑器 / 评测 / 多卷」加深 | **原 PX4 收窄**（P0 已含最小长文） |
 | 隔离 + 专业调试 | **PX5** |
-| 多个导演包（方法真不同时再加） | **需要时再加**；非「剧本菜单」 |
+| 多个配方包（方法真不同时再加） | **需要时再加**；非「流程菜单」 |
 
 ---
 
@@ -270,5 +272,5 @@ B-GP5  回到 earlier 档重 roll 某段 或 等价恢复可用
 |---|--------|------|
 | 1 | 仅 AIRP | **已订正**：+ 长文/爽文 |
 | 2 | UI 要按设计稿打磨 | **已订正**：抄参考；存档稳定优先 |
-| 3 | 永远自动加载、无选包 UI | **已订正**：UI 选**导演**；剧本层保持动态 |
-| 4 | 单包 = 不能多种玩法 | **已澄清**：一个导演内剧本动态分化 |
+| 3 | 永远自动加载、无选包 UI | **已订正**：UI 选**配方**；工作流计划层保持动态 |
+| 4 | 单包 = 不能多种玩法 | **已澄清**：一个配方内工作流计划动态分化 |

docs/design-orchestrator-guide.md

@@ -1,6 +1,6 @@
-# 创作设计指导（总管 / 分步 design skills）
+# 创作设计指导（编排器 / 分步 design skills）
 
-> **文档层级：剧本 / 创作方法（非系统架构）。**  
+> **文档层级：工作流计划 / 创作方法（非系统架构）。**  
 > 运行内核边界见 [`architecture.md`](./architecture.md)；本文不定义相位机、持久化或 Context Compiler。
 
 权威说明：如何从用户意图收成 **实例规格（`设计.worker集` JSON）**，并指导 play 期声明调度。  
@@ -8,18 +8,20 @@
 
 相关：`context-assembly.md`（拼装）、`preset-format.md`（全局预设）、`tag-blackboard.md`（黑板）、`run-snapshot.md`（快照）。
 
-包内落地：
+包内落地（现行 `skills/dialogue/world-simulator/`）：
 
 | 文件 | 角色 |
 |------|------|
-| `orchestrator.md` | 总管调度 |
-| `design-common.md` | 创作共同开头（注入各 design-*） |
-| `workers/design-core/` | A 核心（开放，不拆 A1→A2→A3 管道） |
-| `workers/design-worker/` | 一次一个 worker |
-| `workers/design-fixed/` | 一次一块固定上下文 |
-| `workers/design-refine/` | C 细化 / 终稿 |
+| `orchestrator.md` | 编排器调度 |
+| `recipes/` | 配方选项（新建 UI 选一层） |
+| `modules/{id}/prompt.md` | 技能正文（design-step 注入） |
+| `workers/design-flow/` | 编排近期 `设计.创作流程` |
+| `workers/design-step/` | 执行当前能力步 |
+| `workers/opening-generator/` | 可选开场白 |
+| `worker-templates/` | play 执行单元默认契约 |
 
-**运行时以各 SKILL + design-common 为准**；本文是方法长文，改方法时与 skill 切片一起改。
+旧 `design-core` / `design-fixed` / `design-worker` / `design-refine` / `design-common.md` / `design-intake` **已移除**。  
+**运行时以包内 SKILL + modules 为准**；本文是方法长文，改方法时与 skill / 能力切片一起改。清单见 `world-simulator-modules.md`。
 
 ---
 
@@ -42,7 +44,7 @@
 - 把「世界模拟」当成开场默认答案
 - 固定 instantiate 管道（world-blueprint 等）
 
-**预设**：凡 LLM 请求（总管 / agent / worker）均插入用户预设。  
+**预设**：凡 LLM 请求（编排器 / agent / worker）均插入用户预设。  
 **进 play**：用户手动满意后进入（程序不强制开局锁定）。  
 **Play 回合**：用户新输入 = 认可上一轮最终展示；否则重 roll / 编辑后重 roll。表维护可延后。
 
@@ -89,7 +91,7 @@
 对当前理解与「现有 worker/上下文草案」打分或文字判定。
 
 **对内**：可只在思维链里过一遍。  
-**对外**（总管 `ask_user.assessment`，或关键分叉复述）：写成用户可读的完备度评价，再据此出题。
+**对外**（编排器 `ask_user.assessment`，或关键分叉复述）：写成用户可读的完备度评价，再据此出题。
 
 **首要（必须检）**
 
@@ -304,7 +306,7 @@ value, rev, updatedAt, source  # source: user | worker:<id> | system
 
 ### 6.1 用法（重要：不是填空）
 
-§6.2 里的名称 **只是示例话题**：告诉 design / 总管——**可以向用户询问类似内容**，再收成固定上下文。
+§6.2 里的名称 **只是示例话题**：告诉 design / 编排器——**可以向用户询问类似内容**，再收成固定上下文。
 
 ```text
 不是：按表逐项填空、默认必谈、谈完才算过关
@@ -478,7 +480,7 @@ Worker 规格应回答：职责是什么、读哪些已有 tag、写哪些 tag
 | 交互 / RP | 产出用户可见终稿的转述（如 narrator）→ `review`；世界裁决等中间层 → `continue` |
 
 创作期按 **§7.2 创作单位** 分块验收（worker 与固定上下文同级），与上表正交。  
-design-intake / 创作调度必须为 **每个** run worker 写出 `acceptance`；缺省时不得假设「全都不用验收」——面向用户的可读输出默认倾向 `review`，纯中间层倾向 `continue`，吃不准就 ask_user。
+design-flow / design-step / 创作调度必须为 **每个** run worker 写出 `acceptance`；缺省时不得假设「全都不用验收」——面向用户的可读输出默认倾向 `review`，纯中间层倾向 `continue`，吃不准就 ask_user。
 
 ---
 
@@ -502,7 +504,7 @@ design-intake / 创作调度必须为 **每个** run worker 写出 `acceptance`
 
 ---
 
-## 8. Play / Run 边界（给总管；运行时按声明执行）
+## 8. Play / Run 边界（给编排器；运行时按声明执行）
 
 - 只 `run_worker` 声明内的 ref
 - 遇 `acceptance: review` → 停、给人看、接受后压缩再继续

docs/implementation-guide.md

@@ -20,7 +20,7 @@
 |---|---|---|
 | **系统架构** | **`architecture.md`** | 模块边界、定义/实例、调度、上下文、持久化原则、风险 |
 | 运行内核 | `runtime-state-machine.md` | 5 相位、tool 边界、burst |
-| 运行内核 | `tool-contracts.md` | 总管 / worker tool |
+| 运行内核 | `tool-contracts.md` | 编排器 / worker tool |
 | 运行内核 | `context-assembly.md` | 上下文拼接：上半固定、下半动态 |
 | 运行内核 | `tag-blackboard.md` | 标签黑板 |
 | 持久化 | `book-storage.md` | Book、CardAsset、PlayBook、过程存储 |
@@ -33,11 +33,13 @@
 | **日常 → P0** | **`daily-use-p0.md`** | 日常场景、功能映射、P0 详细工作包 |
 | **剧本 / 方法（非系统架构）** | `design-orchestrator-guide.md` | 创作三大步、表/副作用、自检 |
 | **剧本 / 方法（非系统架构）** | `creation-playbook.md` | 创作流程概念（指向指导） |
+| **剧本 / 方法（非系统架构）** | `world-simulator-modules.md` | 编排器/能力清单与现行包布局 |
 | **Skill 格式（非系统架构）** | `orchestrator-skill-format.md` | manifest 写法（非编排表） |
 | **Skill 格式（非系统架构）** | `worker-skill-format.md` | SKILL.md、contextSegments |
-| **Skill 格式（非系统架构）** | `skill-format.md` | 包存储、registry |
+| **Skill 格式（非系统架构）** | `skill-format.md` | 包存储、registry（示例以 world-simulator 为准） |
 | **Skill 格式（非系统架构）** | `skill-design-guide.md` | 包格式薄层 |
 | **Skill 格式（非系统架构）** | `preset-format.md` | 预设导入 |
+| **能力撰写** | `briefs/capability-authoring-brief.md` | 外部 AI 写 modules 交接 |
 
 许可证占位：仓库根 `THIRD_PARTY_NOTICES.md`。
 
@@ -53,14 +55,16 @@
 
 | 路线阶段 | 目标 | 备注 |
 |----------|------|------|
-| **PX0（当前）** | 导演 UI + 双线主路径 + 存档硬稳定 | 详见 `daily-use-p0.md` / `px-roadmap.md` |
+| **PX0（当前）** | 编排器 UI + 双线主路径 + 存档硬稳定 | 详见 `daily-use-p0.md` / `px-roadmap.md` |
 | PX1–PX2 | 创作/游玩体验打磨；副作用 | UI 仍可抄 |
 | PX3 | Trace、预算、规格版本、E2E | — |
 | PX4 | 长文加深（P0 已含最小闭环） | — |
-| PX5 | 隔离 + 调试；必要时新导演包 | — |
+| PX5 | 隔离 + 调试；必要时新配方包 | — |
 | 延后 | SQLite / 事件溯源 / Mastra·Next | — |
 
-历史分期 A0–E 见下节（多数已 done，作文件职责索引，不再当作「当前从零启动」路线）。
+历史分期 A0–E 见下节（**多数已 done，仅作文件职责索引**；进度与验收以 [`px-roadmap.md`](./px-roadmap.md) 为准，勿再按 §9「未开始」判断现状）。
+
+> §3b / §9 中仍可能出现 `design-intake`、`skills/novel/`、缺失文件路径等**历史表述**；磁盘真相见 `skills/dialogue/world-simulator/README.md`。
 
 ---
 
@@ -85,7 +89,7 @@ npm run phase-demo      # 交互，手动 /decide /approve /worker-ask
 npm run phase-demo -- --auto   # worker 自动占位完成
 ```
 
-### Phase A1 — 总管 LLM 接入（阶段机之上）
+### Phase A1 — 编排器 LLM 接入（阶段机之上）
 
 目标：在 PhaseRuntime 之上接 Main Agent，不改动 phase-machine 规则。
 
@@ -96,7 +100,7 @@ npm run phase-demo -- --auto   # worker 自动占位完成
 
 ### Phase A2 — Skill 层（创作指南）
 
-目标：`skills/` 批量存储 SKILL.md；启动第一个询问是选 skill；总管读 activeSkill。
+目标：`skills/` 批量存储 SKILL.md；启动第一个询问是选 skill；编排器读 activeSkill。
 
 | # | 文件 | 状态 | 干嘛的 |
 |---|---|---|---|
@@ -107,7 +111,7 @@ npm run phase-demo -- --auto   # worker 自动占位完成
 | S04 | `src/skills/loader.ts` | todo | 解析 SKILL.md |
 | S05 | `src/skills/registry.ts` | todo | listSkills() |
 | S06 | `src/skills/resolver.ts` | todo | 推断当前 stage |
-| S07 | `src/main-agent/skill-context.ts` | todo | 注入总管 prompt |
+| S07 | `src/main-agent/skill-context.ts` | todo | 注入编排器 prompt |
 | S08 | `src/runtime/phase-machine.ts` | todo | 增加 skill_selection / skill_selected |
 | S09 | `src/cli/phase-demo.ts` | todo | 启动时 /select-skill |
 
@@ -115,7 +119,7 @@ npm run phase-demo -- --auto   # worker 自动占位完成
 
 ### Phase B — Tool Call 化
 
-目标：总管 / worker 从 JSON 决策改为 tool call；Runtime 做 tool 校验与事件转换。
+目标：编排器 / worker 从 JSON 决策改为 tool call；Runtime 做 tool 校验与事件转换。
 
 ### Phase C — 真实 Worker
 
@@ -167,7 +171,7 @@ npm run phase-demo -- --auto   # worker 自动占位完成
 |---|---|---|---|---|
 | A06 | `src/types/runtime.ts` | done | 相位、事件、会话、产物、ResumeContext | `runtime-state-machine.md` §2–5 |
 | A07 | `src/types/blackboard.ts` | done | BlackboardItem、TagIndex | `tag-blackboard.md` §2 |
-| A08 | `src/types/tools.ts` | todo | 总管 tool、worker tool 的参数与结果类型 | `tool-contracts.md` |
+| A08 | `src/types/tools.ts` | todo | 编排器 tool、worker tool 的参数与结果类型 | `tool-contracts.md` |
 
 **A06 职责：**
 - 定义 `RuntimePhase`（5 种）
@@ -178,7 +182,7 @@ npm run phase-demo -- --auto   # worker 自动占位完成
 
 **A07 职责（Phase E 迁移后）：**
 - 定义 `BlackboardItem`（id、tag、content、source、metadata）
-- 定义 `BlackboardTagIndex`（给总管：tag + source，无 content）
+- 定义 `BlackboardTagIndex`（给编排器：tag + source，无 content）
 - 定义 `BlackboardWrite`（worker 写回）
 
 **A08 职责（Phase B 再写）：**
@@ -218,7 +222,7 @@ npm run phase-demo -- --auto   # worker 自动占位完成
 | A11 | `src/blackboard/blackboard.ts` | done | listTagIndex、queryByPatterns、write | `tag-blackboard.md` §2 |
 
 **A11 职责：**
-- `listTagIndex()` — 给总管
+- `listTagIndex()` — 给编排器
 - `queryByPatterns()` — 给 worker 注入
 - `write()` — 按 tag 写回
 - `getContentByTag()` / `getLatestByTag()`
@@ -244,12 +248,12 @@ npm run phase-demo -- --auto   # worker 自动占位完成
 
 ---
 
-### 4.6 总管 LLM
+### 4.6 编排器 LLM
 
 | # | 文件 | 状态 | 干嘛的 | 对应文档 |
 |---|---|---|---|---|
-| A14 | `src/main-agent/main-agent.ts` | done | 总管：只选 worker，读 tag 索引 | `tag-blackboard.md` §6 |
-| A15 | `src/main-agent/prompts.ts` | todo | 总管 prompt 拆分 | `tag-blackboard.md` §6 |
+| A14 | `src/main-agent/main-agent.ts` | done | 编排器：只选 worker，读 tag 索引 | `tag-blackboard.md` §6 |
+| A15 | `src/main-agent/prompts.ts` | todo | 编排器 prompt 拆分 | `tag-blackboard.md` §6 |
 
 **A14 职责：**
 - `MainAgent.decide(context)` — 调 LLM，返回 `MainAgentDecision`
@@ -258,8 +262,8 @@ npm run phase-demo -- --auto   # worker 自动占位完成
 - `DEFAULT_WORKERS` — 第一版可用 worker 列表
 
 **约束：**
-- 总管不读黑板 value
-- 总管不直接改 phase
+- 编排器不读黑板 value
+- 编排器不直接改 phase
 - 不含 question-worker（提问是 worker 能力）
 
 **A15 职责（可选拆分）：** 把 prompt 从 main-agent.ts 抽出来，方便迭代。
@@ -275,12 +279,12 @@ npm run phase-demo -- --auto   # worker 自动占位完成
 **A16 职责：**
 - `RuntimeOrchestrator` — 对外 API：start、submitUserInput、approve、accept 等
 - `dispatch(event)` — 调 `applyEvent`，处理 `PhaseEffect`
-- `runMainAgent()` — phase=running 时调总管
+- `runMainAgent()` — phase=running 时调编排器
 - `runStubWorker()` — 第一版占位 worker（Phase C 替换）
 - `resumeStubWorker()` — worker 中途提问后恢复
 
 **约束：**
-- 唯一调用阶段机和总管的地方
+- 唯一调用阶段机和编排器的地方
 - user 事件（approve / accept）只从 CLI / API 进入，不从 LLM 进入
 
 ---
@@ -307,7 +311,7 @@ npm run phase-demo -- --auto   # worker 自动占位完成
 | B01 | `src/types/tools.ts` | tool 类型定义 |
 | B02 | `src/runtime/tool-registry.ts` | 注册 tool、校验参数、tool → event |
 | B03 | `src/main-agent/main-agent.ts` | 改为 tool calling 模式 |
-| B04 | `src/runtime/tool-handlers/main-agent.ts` | 总管 tool 处理器 |
+| B04 | `src/runtime/tool-handlers/main-agent.ts` | 编排器 tool 处理器 |
 | B05 | `src/runtime/tool-handlers/worker.ts` | worker tool 处理器（ask_user / submit） |
 
 **B02 职责：**
@@ -372,7 +376,7 @@ type WorkerRunOutcome =
 Phase A0（可运行阶段机）  ✅ 完成
   phase-machine + phase-runtime + phase-demo + 测试
 
-Phase A1（总管 LLM）     ✅ 有初版（orchestrator + run.ts）
+Phase A1（编排器 LLM）     ✅ 有初版（orchestrator + run.ts）
   下一步：orchestrator 应基于 PhaseRuntime 重构
 
 Phase B（tool call）      未开始

docs/orchestrator-skill-format.md

@@ -1,27 +1,30 @@
-# 总管 Skill 格式（Orchestrator / Manifest）
+# 编排器 Skill 格式（Orchestrator / Manifest）
 
 > **文档层级：Skill 包 manifest 格式（非系统架构）。**  
-> 总管与相位机边界见 [`architecture.md`](./architecture.md)、[`runtime-state-machine.md`](./runtime-state-machine.md)。
+> 编排器与相位机边界见 [`architecture.md`](./architecture.md)、[`runtime-state-machine.md`](./runtime-state-machine.md)。  
+> **现行包落地**见 [`skills/dialogue/world-simulator/README.md`](../skills/dialogue/world-simulator/README.md)、[`world-simulator-modules.md`](./world-simulator-modules.md)。
 
 ## 1. 定位
 
-**orchestrator.md** = 本包的 **manifest**：注册有哪些 capability、如何验收、何时可进 play。  
-**不**写逐步流水线剧本。  
+**orchestrator.md** = 本包的 **manifest**：注册有哪些 design worker、如何验收、何时可进 play。  
+**不**写逐步流水线工作流计划。  
 **创作方法**见 **`design-orchestrator-guide.md`**（三大步、表、自检）。
 
 ```text
-新建作品 → 默认包
-  → design：design-intake → 设计.worker集 JSON（实例声明）
+新建作品 → UI 选配方（recipes/）→ 默认包
+  → design-flow → 设计.创作流程（工作流计划 / 近期步骤 DAG）
+  → 反复 design-step（注入 modules/{id}/prompt.md）→ 收成 设计.worker集（运行规格）
   → 用户验收 → 用户手动进 play
-  → play：Agent 按 Worker 声明 invoke worker
+  → play：编排器按运行规格 invoke 执行单元
 ```
 
 | 谁决定 | 什么 |
 |--------|------|
-| **Agent** | 何时 invoke 哪个 worker id（tool loop） |
+| **编排器** | 何时 invoke 哪个 worker id（tool loop） |
 | **Manifest** | design worker 列表、验收策略、readiness |
-| **Worker 集** | 本实例启哪些 worker、表、常驻上下文、副作用 |
-| **templates** | design-intake 合并用的可选默认契约（非运行时权威） |
+| **运行规格** | 本实例启哪些执行单元、表、常驻上下文、副作用 |
+| **templates** | design 缺省时合并用的可选默认契约（非运行时权威） |
+| **recipes / modules** | 配方起点 / 技能工序正文 |
 
 见 `architecture.md`、`creation-playbook.md`、`design-orchestrator-guide.md`。
 
@@ -32,15 +35,20 @@
 ```text
 skills/dialogue/world-simulator/
 ├── orchestrator.md
-├── shared-context.md          # 可选
+├── recipes/                   # 配方选项
+├── modules/                   # 技能 prompt 切片
 ├── worker-templates/          # 可选 ref 模板（design 缺省）
 └── workers/
-    └── design-intake/SKILL.md
+    ├── design-flow/SKILL.md
+    ├── design-step/SKILL.md
+    └── opening-generator/SKILL.md
 ```
 
 - 文件固定名 **`orchestrator.md`**。
 - `registry.yaml` 的 `path` 指向它。
 
+旧名 `design-intake` / `design-core` 等 **已移除**；勿再写回磁盘。
+
 ---
 
 ## 3. Frontmatter
@@ -49,11 +57,13 @@ skills/dialogue/world-simulator/
 ---
 name: world-simulator
 description: >
-  默认能力库：Worker 集即实例声明…
+  默认技能库：用户选配方 → 编排工作流计划 → 逐步执行技能…
 category: dialogue
 bookKind: dialogue
 workers:
-  - design-intake
+  - design-flow
+  - design-step
+  - opening-generator
 demandTag: 用户.需求
 startupMode: agent-first
 uiPrompt: |
@@ -69,11 +79,11 @@ uiPrompt: |
 ## Skill 注册表
 ## Instance Ready / 进入游玩
 ## 验收策略
-## 总管优先行为
+## 编排器优先行为
 ## 禁用行为
 ```
 
-**不应包含：** 「第 N 步必须跑某 worker」管道剧本。  
+**不应包含：** 「第 N 步必须跑某 worker」管道计划。  
 方法细节指向 `design-orchestrator-guide.md`，勿在 manifest 重复长文。
 
 ---
@@ -84,8 +94,9 @@ uiPrompt: |
 
 | id | 说明 |
 |----|------|
-| design-intake | 产出 设计.worker集 JSON |
-| （可选）开局赋初值 | 创作末尾可选，非每轮 |
+| design-flow | 编排近期 `设计.创作流程`（增量 DAG） |
+| design-step | 执行当前能力步；注入 `modules/{id}/prompt.md` |
+| opening-generator | （可选）开场白，非每轮 |
 
 ### Play
 
@@ -105,7 +116,9 @@ uiPrompt: |
 
 | skill | requiresApproval | acceptanceMode |
 |-------|------------------|----------------|
-| design-intake | true | user_confirmed |
+| design-flow | true | user_confirmed（流程骨架） |
+| design-step | true | user_confirmed（能力产物） |
+| opening-generator | true | user_confirmed |
 
 play：**无**每轮强制验收；用户新输入 = 认可上轮终稿；重 roll 替代 reject。
 

docs/px-roadmap.md

@@ -11,20 +11,20 @@
 | 项 | 决定 |
 |----|------|
 | 日常玩法 | **AIRP/交互** + **长文/爽文**（同一内核） |
-| 导演 Skill | 新建时 **UI 选择**能力包；初期可只有 1 项（默认选中） |
-| 剧本层 | **动态**：听用户说话谈 Worker 集 + tool loop；不做死板剧本选单/DAG |
+| 编排器 Skill | 新建时 **UI 选择**技能包；初期可只有 1 项（默认选中） |
+| 工作流计划层 | **动态**：听用户说话谈 Worker 集 + tool loop；不做死板流程选单/DAG |
 | UI | **抄参考**即可，不自研美学 |
 | 硬指标 | **存档 / 续作稳定** |
-| 多导演 | 仅当方法边界真不同时再加包；爽文≠新导演 |
+| 多配方 | 仅当方法边界真不同时再加包；爽文≠新配方 |
 
 ### 0.2 成功标尺
 
 | 级别 | 含义 |
 |------|------|
 | **L1 可演示** | 带路能跑通一轮 |
-| **L2 可自助** | 选导演 → 创作 → 玩/写，少踩坑 |
+| **L2 可自助** | 选配方 → 创作 → 玩/写，少踩坑 |
 | **L3 可日常** | 双线存档续作可靠；少死循环 |
-| **L4 可扩展** | 新导演包或隔离模式不改内核边界 |
+| **L4 可扩展** | 新配方包或隔离模式不改内核边界 |
 
 ---
 
@@ -32,7 +32,7 @@
 
 | 阶段 | 名称 | 目标标尺 | 核心交付 | 状态 |
 |------|------|----------|----------|------|
-| **PX0** | 双线可日常最小集 | L2→摸 L3 | 导演选择 UI；线 A 扮演 + 线 B 长文/爽文主路径；**存档硬稳定**；失败出口；UI 只抄缺口 | **进行中（核心已落地）** |
+| **PX0** | 双线可日常最小集 | L2→摸 L3 | 配方选择 UI；线 A 扮演 + 线 B 长文/爽文主路径；**存档硬稳定**；失败出口；UI 只抄缺口 | **进行中（核心已落地）** |
 | **PX1** | 创作体验 | L3 design | 规格可读可改、进度可见、表/黑板可手改、instance 改规格 | **进行中（定稿存读+黑板改+进度面板已有）** |
 | **PX2** | 游玩/写作体验 | L3 play | 阅读主舞台（抄）、状态抽屉、重 roll 顺手、副作用调度、多 run 线打磨 | 未开始 |
 | **PX3** | 运行可信 | L3 加固 | Context Trace、调度预算、规格钉版本、mock E2E | 未开始 |
@@ -40,7 +40,7 @@
 | **PX5** | 隔离 + 调试 | L4 | 私有上下文、泄漏测试；Trace/成本/分支调试台 | 未开始 |
 
 ```text
-现在 →  PX0（存档+双线+导演UI）
+现在 →  PX0（存档+双线+编排器UI）
       →  PX1（创作好改）
       →  PX2（玩/写好用）
       →  PX3（可信可测）
@@ -63,32 +63,32 @@
 | 序 | 工作包 | 内容 | 验收要点 |
 |----|--------|------|----------|
 | 1 | **WP-S** 存档稳定 | 续作相位正确；手动存/列表/加载；正文与关键 tag 不丢 | 线 A、B 各存读一轮，不手改磁盘 |
-| 2 | **WP-D** 导演选择 | 新建作品 UI 选导演；registry 列表；仅 1 项时默认选中 | 能选中并进入该包创作 |
+| 2 | **WP-D** 配方选择 | 新建作品 UI 选配方；registry 列表；仅 1 项时默认选中 | 能选中并进入该包创作 |
 | 3 | **WP-A** 进出与失败 | glossary 底线；`waiting_user` 有主按钮；LLM/worker 失败可重试 | 无死胡同、无裸 id 挡路 |
 | 4 | **WP-R** 线 A | 扮演 ≥3 回合不卡 | A-GP1–5 |
 | 5 | **WP-L** 线 B | 引导+template 能谈成写手规格；≥2 段正文；续作不丢文 | B-GP1–5 |
-| 6 | **WP-U** UI 抄补 | 仅补存档/确认/选导演等缺口控件 | 不按 ui-design 大重构 |
+| 6 | **WP-U** UI 抄补 | 仅补存档/确认/选配方等缺口控件 | 不按 ui-design 大重构 |
 | 7 | **WP-E** 闸门 | 双线冷启动+续作验收；勾选 DoD | 全绿才出 PX0 |
 
 ### 2.2 黄金路径（摘要）
 
-- **线 A**：选导演 → 扮演意图 → 验收 → ≥3 回合 → 存档 → 续作/读档  
-- **线 B**：选导演 → 爽文/长篇意图 → 验收写手规格 → ≥2 段正文 → 存档含正文 → 续作/读档  
+- **线 A**：选配方 → 扮演意图 → 验收 → ≥3 回合 → 存档 → 续作/读档  
+- **线 B**：选配方 → 爽文/长篇意图 → 验收写手规格 → ≥2 段正文 → 存档含正文 → 续作/读档  
 
 ### 2.3 非范围
 
-死板剧本选单；自研精美 UI；Trace；隔离；完整副作用；多导演商店（列表可扩展，P0 不追求多包运营）。
+死板流程选单；自研精美 UI；Trace；隔离；完整副作用；多配方商店（列表可扩展，P0 不追求多包运营）。
 
 ### 2.4 DoD
 
 - [ ] WP-S～E 完成  
 - [ ] 线 A、线 B 黄金路径各冷启动 + 续作通过  
-- [ ] 导演选择 UI 可用（可仅一项）  
+- [ ] 配方选择 UI 可用（可仅一项）  
 - [ ] 更新本文状态列 + `architecture.md` §13  
 
 ### 2.5 挂载
 
-`web/`（新建选导演、saves）、`session-manager`、`skill-catalog` / registry、`phase-runtime`、引导与 `worker-templates`
+`web/`（新建选配方、saves）、`session-manager`、`skill-catalog` / registry、`phase-runtime`、引导与 `worker-templates`
 
 ---
 
@@ -149,7 +149,7 @@ P0 已要求最小长文/爽文闭环。本阶段加深：
 | 隔离 | 私有上下文、公私事件、泄漏测试（依 Trace） |
 | 调试 | 调度时间线、Trace 检查器、Token/成本、分支树 |
 
-若隔离需要**不同方法边界**，以**新导演包**形式加入（UI 多一项），仍保持包内剧本动态。
+若隔离需要**不同方法边界**，以**新配方包**形式加入（UI 多一项），仍保持包内工作流计划动态。
 
 ---
 
@@ -157,7 +157,7 @@ P0 已要求最小长文/爽文闭环。本阶段加深：
 
 - Mastra / LangGraph 换相位机；Next 重写前端  
 - 完整事件溯源 + SQLite 近端必达  
-- 题材固定 instantiate 管道；死板剧本选单  
+- 题材固定 instantiate 管道；死板流程选单  
 - 把创作方法长文塞回系统架构文  
 
 ---
@@ -166,7 +166,7 @@ P0 已要求最小长文/爽文闭环。本阶段加深：
 
 | 里程碑 | 退出 | 产出 |
 |--------|------|------|
-| **M0** | PX0 DoD | 双线验收记录；导演 UI；存档稳定 |
+| **M0** | PX0 DoD | 双线验收记录；编排器 UI；存档稳定 |
 | **M1** | PX1+PX2 DoD | 内部「可日常」说明 |
 | **M2** | PX3 DoD | Trace/预算/E2E 绿灯 |
 | **M3** | PX4 或 PX5 | 长文加深或隔离/调试演示 |

docs/skill-design-guide.md

@@ -1,12 +1,17 @@
 # Skill 设计指南（包格式薄层）
 
 > **文档层级：Skill 包格式薄层（非系统架构）。**  
-> 运行内核见 [`architecture.md`](./architecture.md)；创作方法见下。
+> 运行内核见 [`architecture.md`](./architecture.md)；创作方法见下。  
+> **现行磁盘布局**见 [`skills/dialogue/world-simulator/README.md`](../skills/dialogue/world-simulator/README.md)。
 
 **创作方法（三大步、表、自检、正推）** 的权威文档是：
 
 → **[`design-orchestrator-guide.md`](./design-orchestrator-guide.md)**
 
+能力 / 编排器清单：
+
+→ **[`world-simulator-modules.md`](./world-simulator-modules.md)**
+
 本文只保留：**如何在仓库里建包、Worker 集弱结构示例、与旧概念对照**。不要在本文重复长方法文。
 
 格式字段见 `orchestrator-skill-format.md`、`worker-skill-format.md`；上下文见 `context-assembly.md`。
@@ -14,10 +19,11 @@
 **设计顺序（概念）：**
 
 ```text
-1. 用户意图 → design-intake（按 design-orchestrator-guide）→ 设计.worker集 JSON
-2. 需要时合并 worker-templates 默认契约（仅 design 缺省）
-3. 用户验收 → 用户手动进 play
-4. play：按声明调度；表维护/副作用边沿触发
+1. 用户选配方 → design-flow 排出近期 设计.创作流程
+2. 反复 design-step（modules 能力切片）→ 收成 设计.worker集 JSON
+3. 需要时合并 worker-templates 默认契约（仅 design 缺省）
+4. 用户验收 → 用户手动进 play
+5. play：按声明调度；表维护/副作用边沿触发
 ```
 
 ---
@@ -36,9 +42,11 @@
 
 Worker 集不是闭集枚举，也不是逐步管道。方法见 `design-orchestrator-guide.md`。
 
-### 0.2 design-intake
+### 0.2 design-flow / design-step
 
-与用户对话，增量更新草稿，accept 后即实例规格。进 play **由用户手动决定**。
+与用户对话，经编排器能力编排与逐步执行，增量更新草稿，accept 后即实例规格。进 play **由用户手动决定**。
+
+旧名 `design-intake` 仅作兼容别名出现在部分代码注释中，**磁盘上已不存在**。
 
 ### 0.3 弱结构示例（JSON）
 

docs/skill-format.md

@@ -1,7 +1,11 @@
 # Skill 格式与存储
 
 > **文档层级：Skill 包格式（非系统架构）。**  
-> 系统级模块与调度边界见 [`architecture.md`](./architecture.md)。
+> 系统级模块与调度边界见 [`architecture.md`](./architecture.md)。  
+>  
+> **现行唯一落地包**：`skills/dialogue/world-simulator/`（见该包 README、`world-simulator-modules.md`）。  
+> 下文部分示例仍保留历史 `novel/` / `weird-rules-short` 树形说明，**仓库内已不存在**；写新内容请以 world-simulator 为准。  
+> 创作流水线现行名：`design-flow` + `design-step`（旧称 `design-intake` 已废弃）。
 
 ## 1. 定位：两层 Skill
 
@@ -9,50 +13,50 @@
 
 | 类型 | 路径 | 消费者 | 写什么 |
 |------|------|--------|--------|
-| **总管 Skill** | `skills/{bookKind}/{name}/orchestrator.md` | Main Agent | **何时**调哪个 worker、验收方式、启动询问 |
+| **编排器 Skill** | `skills/{bookKind}/{name}/orchestrator.md` | Main Agent | **何时**调哪个 worker、验收方式、启动询问 |
 | **Worker Skill** | `workers/{workerId}/SKILL.md` | Worker Agent | **inputTags/outputTags**、怎么做 |
 
 ```text
-选 weird-rules-short（总管 Skill）
-  → 总管：brief 齐了 → run ruleset-worker，input=[project.brief]
+选 weird-rules-short（编排器 Skill）
+  → 编排器：brief 齐了 → run ruleset-worker，input=[project.brief]
   → Worker：读 workers/ruleset-worker/SKILL.md → 写 core / rules / commentary
-  → 总管：rules accepted → run review-worker
+  → 编排器：rules accepted → run review-worker
   → Worker：读 workers/review-worker/SKILL.md → 评估怎么做
 ```
 
-**何时评估** = 总管 Skill 的 Worker 编排表。  
+**何时评估** = 编排器 Skill 的 Worker 编排表。  
 **如何评估** = review-worker 的 Worker Skill。
 
 详细规范：
 
-- 总管 Skill → `docs/orchestrator-skill-format.md`
+- 编排器 Skill → `docs/orchestrator-skill-format.md`
 - Worker Skill → `docs/worker-skill-format.md`
 
-旧称「Skill = 创作说明书」仍成立，但说明书 **拆成编排（总管）与执行（worker）两份**。
+旧称「Skill = 创作说明书」仍成立，但说明书 **拆成编排（编排器）与执行（worker）两份**。
 
 ```text
 会话开始
-  → 询问 1：选哪个总管 Skill（skills/{bookKind}/{name}/orchestrator.md）
-  → 加载总管 Skill
-  → 询问 2：读总管 Skill「## 启动询问」
-  → 之后总管按「Worker 编排」调度；Worker 读本 skill 包内 workers/{id}/SKILL.md
+  → 询问 1：选哪个编排器 Skill（skills/{bookKind}/{name}/orchestrator.md）
+  → 加载编排器 Skill
+  → 询问 2：读编排器 Skill「## 启动询问」
+  → 之后编排器按「Worker 编排」调度；Worker 读本 skill 包内 workers/{id}/SKILL.md
 ```
 
 ---
 
 ## 2. 存储位置
 
-Skill 以 **Skill 包（skill pack）** 为单位：一个总管 + 其专属 workers，**同包绑定，不跨包复用 worker**。
+Skill 以 **Skill 包（skill pack）** 为单位：一个编排器 + 其专属 workers，**同包绑定，不跨包复用 worker**。
 
 ```text
 skills/
 ├── registry.yaml
 ├── novel/                                    # Book 形态
 │   ├── basic/
-│   │   └── orchestrator.md                   # 总管 Skill
+│   │   └── orchestrator.md                   # 编排器 Skill
 │   ├── weird-rules-short/
-│   │   ├── orchestrator.md                   # 总管：何时调谁、黑板 key
-│   │   └── workers/                          # 本总管专属，不与其他 skill 共享
+│   │   ├── orchestrator.md                   # 编排器：何时调谁、黑板 key
+│   │   └── workers/                          # 本编排器专属，不与其他 skill 共享
 │   │       ├── write-rules/
 │   │       │   └── SKILL.md                  # 规则怪谈：怎么写规则+解析
 │   │       └── review/
@@ -74,13 +78,13 @@ skills/
 ```text
 第一层文件夹 = bookKind（novel | dialogue），决定 Book 存储结构
 第二层文件夹 = 一个 skill 包，名与 frontmatter.name 一致
-  orchestrator.md   总管 Skill（编排、启动询问、验收）
+  orchestrator.md   编排器 Skill（编排、启动询问、验收）
   workers/{id}/     本包专属 worker；id 在包内唯一即可
 Worker 不复用：novel-standard 的 outline worker ≠ weird-rules-short 的任何 worker
 registry.yaml 的 path 指向 orchestrator.md，如 novel/weird-rules-short/orchestrator.md
 ```
 
-**为何不复用 worker：** 同一「产出形状」（如规则表）在不同总管下的写法、Rubric、自检完全不同；共享 worker 会把体裁细节塞进总管或搞混上下文。需要相似流程时 **复制 worker 包再改**，而不是引用全局 worker。
+**为何不复用 worker：** 同一「产出形状」（如规则表）在不同编排器下的写法、Rubric、自检完全不同；共享 worker 会把体裁细节塞进编排器或搞混上下文。需要相似流程时 **复制 worker 包再改**，而不是引用全局 worker。
 
 与 Cursor skill 的区别：
 
@@ -89,7 +93,7 @@ registry.yaml 的 path 指向 orchestrator.md，如 novel/weird-rules-short/orch
 | 位置 | `.cursor/skills/` | `skills/` |
 | 触发 | Agent 自动或显式引用 | **会话开始必须选一个** |
 | 内容 | 通用任务指南 | **创作流程 + 思维链 + 询问策略** |
-| 消费者 | Cursor Agent | 总管 LLM |
+| 消费者 | Cursor Agent | 编排器 LLM |
 
 ---
 
@@ -163,9 +167,9 @@ tags: [novel, outline, draft]
 
 ## 创作总纲
 
-（给总管：这类内容是什么、总体顺序、禁忌）
+（给编排器：这类内容是什么、总体顺序、禁忌）
 
-## 总管思维链
+## 编排器思维链
 
 （每轮决策前先检查什么、如何选 worker）
 
@@ -175,7 +179,7 @@ tags: [novel, outline, draft]
 
 ## 询问策略
 
-### 总管应先问
+### 编排器应先问
 ### 交给 Worker 问
 
 ## 推荐 Worker
@@ -188,7 +192,7 @@ tags: [novel, outline, draft]
 ```yaml
 ---
 name: novel-standard                    # 必需，唯一 id，[a-z0-9-]
-description: >                          # 必需，供启动时向用户展示、供总管匹配
+description: >                          # 必需，供启动时向用户展示、供编排器匹配
   第三人称描述 WHAT + WHEN。
 category: novel                         # 必需：Book 形态，见 §3.0
 bookKind: novel                         # 建议与 category 对齐；选定后 Book 结构固定
@@ -206,13 +210,13 @@ suggestedWorkers:                       # 可选，本 skill 常用 worker
 | 字段 | 必需 | 用途 |
 |---|---|---|
 | `name` | ✅ | skill id；通常与文件名一致（不含 .md） |
-| `description` | ✅ | 启动选择列表展示；总管判断用户描述是否匹配 |
+| `description` | ✅ | 启动选择列表展示；编排器判断用户描述是否匹配 |
 | `category` | ✅ | 与 `bookKind` 一致：`novel` \| `dialogue` |
 | `bookKind` | 建议 | 选定后 Book 结构固定；缺省时由所在文件夹推断 |
 | `tags` | | 体裁细分：`weird_rules`、`standard` 等 |
 | `path` | registry | 相对路径，如 `novel/weird-rules-short.md` |
 | `defaultFlowId` | | 选中后默认 execution flow |
-| `suggestedWorkers` | | 总管选 worker 时的白名单提示 |
+| `suggestedWorkers` | | 编排器选 worker 时的白名单提示 |
 
 ### 3.2 撰写标准：写作生命周期（推荐）
 
@@ -237,7 +241,7 @@ Skill 文件本质上是**给 LLM 与 Runtime 读的字符串规格**。下面
 | **写作中 · 分步引导** | `## 推荐阶段` + `## 示例` + `## 禁用行为` | 阶段链、每步约束、好/坏示例；对应 worker 与产出 key |
 | **写作后 · 自检润色** | `## 自检清单` + `## 验收策略` | 产出前检查点；LLM 自审 vs 人工 vs 程序验收 |
 | **质量评估** | `## 质量评估标准` | 可量化维度 + 各 stage 的 acceptanceMode |
-| **编排** | `## 总管思维链` + `## 询问策略` + `## 推荐 Worker` | 总管如何调度；谁向用户提问 |
+| **编排** | `## 编排器思维链` + `## 询问策略` + `## 推荐 Worker` | 编排器如何调度；谁向用户提问 |
 
 不必每个 skill 都写独立 `# 写作前` 大标题；**用统一章节名即可**，内容覆盖上表即可。
 
@@ -266,7 +270,7 @@ Skill 文件本质上是**给 LLM 与 Runtime 读的字符串规格**。下面
 
 #### `## 自检清单`（必需）
 
-写作后、提交验收前，worker 或总管应过的检查点（字符串列表即可）：
+写作后、提交验收前，worker 或编排器应过的检查点（字符串列表即可）：
 
 ```markdown
 ## 自检清单
@@ -298,7 +302,7 @@ suggestedWorkers: …
 
 ## 启动询问              # 写作前 · 需求分析
 ## 创作总纲
-## 总管思维链
+## 编排器思维链
 ## 推荐阶段              # 写作中 · 分步引导
 ## 询问策略
 ## 推荐 Worker
@@ -310,7 +314,7 @@ suggestedWorkers: …
 ## Book 结构             # 可选，novel / dialogue 形态说明
 ```
 
-代码当前**结构化解析**的仍主要是 `## 启动询问`；其余章节整段注入总管 prompt（待 `buildSkillContext`）。**全部是 Markdown 字符串，不矛盾。**
+代码当前**结构化解析**的仍主要是 `## 启动询问`；其余章节整段注入编排器 prompt（待 `buildSkillContext`）。**全部是 Markdown 字符串，不矛盾。**
 
 ### 3.3 正文必需章节（检查清单）
 
@@ -325,8 +329,8 @@ suggestedWorkers: …
 | **自检清单** | 写后 | 提交验收前的检查点 |
 | **验收策略** | 写后 | 各 stage 的 acceptanceMode |
 | **质量评估标准** | 质量 | 可量化维度 + **接受度（预留）** |
-| **总管思维链** | 编排 | 每轮决策检查 |
-| **询问策略** | 编排 | 总管问 vs worker 问 |
+| **编排器思维链** | 编排 | 每轮决策检查 |
+| **询问策略** | 编排 | 编排器问 vs worker 问 |
 | **推荐 Worker** | 编排 | 与 suggestedWorkers 一致 |
 
 可选：`## Book 结构`、`examples.md` 外链。
@@ -414,25 +418,25 @@ Runtime 写入 `用户.需求`（或 skill 指定的 startupTargetKey），确
 阶段 2（intake） 启动询问 → 用户描述需求 → confirm → agent burst
 ```
 
-**Agent 根据需求推理 worker 集**（`design-intake`），不再让用户在 registry 里四选一。
+**Agent 根据需求编排能力并收成 worker 集**（`design-flow` → `design-step`），不再让用户在 registry 里四选一。
 
 ---
 
-## 6. 总管如何使用已选 Skill
+## 6. 编排器如何使用已选 Skill
 
-`session.slots.activeSkill` 加载后，总管 prompt 注入：
+`session.slots.activeSkill` 加载后，编排器 prompt 注入：
 
 ```text
 当前 skill: novel-standard
 category: novel
 创作总纲: （SKILL.md 摘要或全文）
 当前推荐阶段: outline（由 resolver 根据黑板推断）
-询问策略: 总管应先问 brief；outline 细节交给 worker
+询问策略: 编排器应先问 brief；outline 细节交给 worker
 建议 worker: outline-worker, drafting-worker
 defaultFlowId: ghostwriting-flow
 ```
 
-总管决策仍通过 tool / JSON 决策，**不**直接改 phase。
+编排器决策仍通过 tool / JSON 决策，**不**直接改 phase。
 
 ---
 
@@ -441,10 +445,14 @@ defaultFlowId: ghostwriting-flow
 完整示例见仓库内真实文件（不要只在文档里维护一份）：
 
 ```text
-skills/novel/weird-rules-short.md
-skills/dialogue/theater-roleplay.md
+skills/dialogue/world-simulator/orchestrator.md
+skills/dialogue/world-simulator/workers/design-flow/SKILL.md
+skills/dialogue/world-simulator/modules/catalog.yaml
+skills/dialogue/world-simulator/recipes/catalog.yaml
 ```
 
+（历史示例 `skills/novel/weird-rules-short`、`theater-roleplay` 已不在仓库。）
+
 ---
 
 ## 8. 解析与加载（将来代码）
@@ -463,7 +471,7 @@ listSkills() → SkillIndexEntry[]
 loadSkill(skillId) → ParsedSkill（含 startupInquiry 解析自 ## 启动询问）
 selectSkill(session, skillId) → session.slots.activeSkill
 getStartupPrompt(activeSkill) → 流程 2 展示文案
-buildSkillContext(activeSkill, blackboardIndex) → 总管 prompt 片段
+buildSkillContext(activeSkill, blackboardIndex) → 编排器 prompt 片段
 ```
 
 ---
@@ -491,7 +499,7 @@ Creation Playbook（概念）
 ```text
 skills/ 目录 + 示例 orchestrator 包
 启动 → 自动绑定默认 orchestrator → intake（描述需求）
-总管 prompt 注入 skill 摘要
+编排器 prompt 注入 skill 摘要
 registry.yaml 可选（legacy 包 / 读档兼容）
 ```
 

docs/tag-blackboard.md

@@ -15,25 +15,26 @@ Runtime = 按声明拼接上下文；表字段 rev 合并
 ## 2. Skill 包、Worker 声明与 Book
 
 ```text
-Skill 包                         能力库 + design-intake + 可选 templates
+Skill 包                         recipes + modules + design-flow/step + 可选 templates
+设计.创作流程                     近期能力步骤 DAG（open|closed）
 设计.worker集（accepted，JSON）  本实例 Worker 声明（play 权威）
 Session + 黑板                   一次运行的实参
-Book                             过程、存档、资产（book-storage.md）
+Book                             过程、存档（现行见 run-snapshot.md；愿景见 book-storage.md）
 ```
 
 ### 业务 stage
 
 ```text
-design（创作：核心→细节交互→细化）→ 用户验收 → 用户手动进 play → done
+design（编排器→编排流程→执行能力→收成规格）→ 用户验收 → 用户手动进 play → done
 运行相位：idle | running | waiting_user | done | error
 ```
 
-创作方法权威：`design-orchestrator-guide.md`。
+创作方法权威：`design-orchestrator-guide.md`；包清单：`world-simulator-modules.md`。
 
 ### 创作
 
-`design-intake` → accept **`设计.worker集` JSON** → 用户手动进 play（可选开局 · 开场白，非强制锁定）。
-无独立 instantiate 管道。见 `design-orchestrator-guide.md`。
+`design-flow` → `设计.创作流程` → 反复 `design-step` → accept **`设计.worker集` JSON** → 用户手动进 play（可选开场白，非强制锁定）。
+无独立 instantiate 管道。见 `world-simulator` 包 README。
 
 ### Play
 
@@ -45,6 +46,7 @@ Agent 只能 `run_worker` **声明中的 ref**；执行契约来自 Worker 集
 
 ```text
 用户.需求 / 用户.最新输入 / 用户.修订说明
+设计.创作流程
 设计.worker集 / 设计.worker集.草稿
 创作.当前单位 / 创作.已验收单位 / 创作.已验收内容 / 创作.对话
 运行.初始变量 / 运行.事件流 / 运行.本轮.*
@@ -54,7 +56,7 @@ Agent 只能 `run_worker` **声明中的 ref**；执行契约来自 Worker 集
 
 固定上下文（叙事指南、美学纲领等）在实例规格里落地，play 时经 `resident_context.mount` / `contextSegments` **挂到多个 worker**——这是 tag 化的主收益，不是省掉创作期依赖正文。
 
-命名与创作单位 id 见 `design-orchestrator-guide.md` §6、`ui-glossary.md`；词表可另补 `docs/tag-vocabulary.md`。
+命名见 `design-orchestrator-guide.md`、`ui-glossary.md`、`world-simulator-modules.md`。
 
 ---
 

docs/ui-design.md

@@ -1,10 +1,14 @@
 # Web UI 心流设计
 
+> **状态：PX1+ 目标态 / 体验北星。**  
+> **PX0 不做按本文大重构**；仅抄补存档/确认/选配方等缺口（见 [`px-roadmap.md`](./px-roadmap.md) WP-U）。  
+> 用户可见文案权威仍是 [`ui-glossary.md`](./ui-glossary.md)。
+
 ## 1. 定位
 
 Writing Agent 的 Web 界面是 **全屏创作工作台**，不是即时通讯客户端。
 
-**用户可见文案**（阶段名、Worker 名、气泡标题）须服从 **`ui-glossary.md`**：内部仍用 `design` / `design-core` 等 id，界面映射为「创作」「创作 · 核心」等中文。实现见 `src/server/display-labels.ts` 与 `web/display-labels.js`。
+**用户可见文案**（阶段名、Worker 名、气泡标题）须服从 **`ui-glossary.md`**：内部仍用 `design` / `design-flow` 等 id，界面映射为「创作」「创作 · 流程编排」等中文。实现见 `src/server/display-labels.ts` 与 `web/display-labels.js`。
 
 | 层 | 角色 |
 |----|------|
@@ -308,7 +312,7 @@ Continue 提交后：卡收起 → 系统 `running` → 回复摘要进对话流
 
 Worker / Agent 发问侧（对齐 Cursor AskQuestion：询问不阻断主产出）：
 
-- 总管 `ask_user`：**assessment 是主内容**；`questions` 挂在其下，用户可 Skip 并请总管基于现有信息继续。
+- 总管 `ask_user`：**assessment 是主内容**；`questions` 挂在其下，用户可 Skip 并请编排器基于现有信息继续。
 - Worker：优先 `outputs` + `askUser` 同时给出；有产物时追问挂在验收态下，用户可直接「接受目前产物」而不作答。仅完全无法产出时才阻塞提问。
 - 能推断选项时 **必须** 给 `options`；每项写成用户可直接采用或微调的**建议示范**（可含短场景钩子），禁止空泛「是 / 否」。
 - `editable` 默认 `true`；挂载题 `required` 默认 `false`。

docs/ui-glossary.md

@@ -4,39 +4,49 @@
 
 **实现**：`src/server/display-labels.ts`（权威映射）；`web/display-labels.js` 须与本文及该文件保持一致。新增高频 id 时：**先改本文 → 再改代码**。
 
-**产品隐喻**：用户侧统一用**拍摄**用语——**导演 / 剧本 / 演员 / 能力**。旧称「总管 / 能力包 / 配方 / Worker」仅作内部或过渡别称。
+**产品口径**：用户侧与作者文档统一用**业界编排用语的中文译名**——**配方 / 编排器 / 技能 / 工作流计划 / 运行规格 / 执行单元**。旧拍摄词「导演 / 剧本 / 演员 / 能力」与「总管 / 能力包」仅作历史别称，勿再写进新文案。
+
+文档写法：**中文为主**；英文业界叫法仅在术语表首次定义时括注，正文尽量不再夹英文。
 
 ---
 
-## 0. 拍摄术语（首选）
+## 0. 核心术语（首选）
 
-| 拍摄术语 | 用户可见含义 | 内部对应 | 勿再对用户说 |
-|----------|--------------|----------|--------------|
-| **导演** | ① 新建时**手动选一次**的方法起点（如世界模拟器、扩写助手），可按现场「调味」；② 会话里负责调度的 Agent | `recipes/` 选型 → 黑板 `创作.选用配方`；Main Agent / orchestrator | 配方、能力包（作第二层选项）、总管 |
-| **剧本** | 本局谈成的流程与规格（活的，不是死选单） | `设计.创作流程`、`设计.worker集` | 「剧本 Skill 菜单」、死板流程卡 |
-| **演员** | 上场执行的单元（一次 `run_worker`） | Worker / design-* / play workers | 对用户堆「Worker · id」；标题用中文名 |
-| **能力** | 共用工序模块（美学纲领与交互范式…）；导演从中选型编排 | `modules/` 组件池 | 组件池、模块（可作作者文档用词） |
+| 中文（首选） | 业界叫法 | 用户可见含义 | 内部对应 | 旧称（勿再用） |
+|--------------|----------|--------------|----------|----------------|
+| **配方** | Recipe | 新建时**手动选一次**的方法起点（如世界模拟器、扩写助手）；给出建议的近期步骤，可按现场调味 | `recipes/` → 黑板 `创作.选用配方` | 导演（选型）、能力包、第二层「配方」选型 |
+| **编排器** | Orchestrator / Supervisor | 会话里负责调度的 Agent：决定下一步调谁、是否追问或结束 | Main Agent / `orchestrator.md` | 导演（调度）、总管 |
+| **技能** | Skill / Capability module | 共用工序模块（美学纲领与交互范式…）；编排器从池里选型编排 | `modules/` | 能力、组件池（作者文档可写模块） |
+| **工作流计划** | Workflow Plan / Horizon DAG | 本局谈成的**近期**增量有向无环图（步骤 = 技能实例）；可追加、拆分、复用、修订 | `设计.创作流程` | 剧本（流程部分）、死板流程卡 |
+| **运行规格** | Runtime Spec / Definition | 可复用的执行声明：执行单元、表、常驻上下文、权限与验收点 | `设计.worker集` 等 | 剧本（规格部分）、Worker 集（对用户） |
+| **执行单元** | Worker | 上场执行的一次单元（一次 `run_worker`） | Worker / design-* / play workers | 演员 |
+
+关系口诀：
 
 ```text
-用户选【导演】（世界模拟器 / 扩写助手 …）
+用户选【配方】（世界模拟器 / 扩写助手 …）
         │
         ▼
-【导演】调度 → 从【能力】里编排 → 谈成【剧本】
+【编排器】调度 → 从【技能】里编排 → 谈成【工作流计划】→ 收成【运行规格】
         │
         ▼
-【演员】按剧本上场执行 → 游玩 / 成稿
+【执行单元】按规格上场 → 游玩 / 成稿（运行实例）
 ```
 
-**一层选型**：新建作品只选**导演**，不要再叠「能力包 + 配方」两层。
+**一层选型**：新建作品只选**配方**，不要再叠「能力包 + 配方」两层。
 
-**调味**：导演给出的建议步骤是**近期起点**；编排时可增量追加、可反复调用标了可反复的能力（像现场改戏），验收的是本局【剧本】，不是磁盘上的静态菜谱。
+**调味**：配方给出的建议步骤是**近期起点**（horizon）；编排时可增量追加、可反复调用标了可反复的技能。验收的是本局【工作流计划】与【运行规格】，不是磁盘上的静态菜谱。
+
+**剧本拆分**：旧称「剧本」同时罩住流程与规格，易混。现固定拆成：
+- **工作流计划** = 怎么排技能步骤（DAG）
+- **运行规格** = 游玩期按什么声明执行
 
 ---
 
 ## 1. 原则
 
 1. **内外分离**：id 给机器；中文给用户。
-2. **拍摄词优先**：对用户优先用 §0；技术文档可写「导演（Main Agent / recipe）」对照。
+2. **本节词优先**：对用户与作者文档优先用 §0；技术实现注释可写「编排器（Main Agent）」「配方（recipe）」对照。
 3. **阶段用产品词**：lifecycle 的 `design` / `play` 用户侧统一为 **创作** / **游玩**（勿译成「设计模式 / 播放」）。
 4. **与 SKILL `name` 对齐**：磁盘 worker 若已有中文 `name`，展示优先用 name；本表是缺省与高频兜底。
 5. **气泡标题形态**：`{中文名}` 或 `{中文名} · {动作}`，例如「创作 · 流程编排 · 产出」，不要「Worker · design-flow 产出」。
@@ -45,30 +55,39 @@
 
 ## 2. 生命周期 / 阶段
 
-| 内部 id / 词 | 用户可见 | 业界对照与选用说明 |
-|--------------|----------|-------------------|
-| `design` | **创作** | 谈【剧本】的工作台。不用「设计」作顶栏主词。 |
-| `play` | **游玩** | 【演员】按剧本上场。不用「播放」。 |
+| 内部 id / 词 | 用户可见 | 说明 |
+|--------------|----------|------|
+| `design` | **创作** | 谈工作流计划与运行规格的工作台。不用「设计」作顶栏主词。 |
+| `play` | **游玩** | 执行单元按运行规格上场。不用「播放」。 |
 | `done` | **已完成** | — |
 | `idle` | **待命** | — |
 | `running` | **执行中** | — |
 | `waiting_user` | **等待你** | — |
 
+相关业界概念（对用户可简化）：
+
+| 中文 | 业界叫法 | 含义 |
+|------|----------|------|
+| **人工审批 / 验收** | Human-in-the-loop（HITL）Approval | 用户对步骤或产物有最终决定权；评价标准只辅助建议 |
+| **运行实例** | Runtime Instance / Run | 钉住某次规格截面的一局游玩过程 |
+| **作品** | Project / Book | 长期项目容器（过程、资产、存档）；不等于「可玩成品」口语 |
+
 ---
 
 ## 3. 角色与系统概念（对照表）
 
 | 内部词 | 用户可见（首选） | 过渡别称 | 说明 |
 |--------|------------------|----------|------|
-| Agent / Main Agent / orchestrator | **导演** | 总管（旧） | 调度【演员】、推进【剧本】；气泡可用「导演 · 思考」。 |
-| Worker | **演员** | Worker / 执行单元 | UI 标题用中文名；检查器可写演员（Worker）。 |
-| Tool | **工具** | Tool | 导演 tool call；气泡可用「工具 · 读黑板」。 |
-| Skill pack / recipe（用户选型） | **导演**（选项名） | 能力包 / 配方（旧） | 新建下拉只出现导演选项（世界模拟器、扩写助手…）。 |
-| Module / modules pool | **能力** | 组件池（作者文档） | 美学纲领与交互范式等；见 `world-simulator-modules.md`。 |
-| Creation flow + Worker 集 | **剧本** | — | 动态谈成；非死选单。 |
+| Agent / Main Agent / orchestrator | **编排器** | 导演、总管（旧） | 调度执行单元、推进工作流计划；气泡可用「编排器 · 思考」。 |
+| Worker | **执行单元** | 演员（旧） | UI 标题用中文名；检查器可写执行单元。 |
+| Tool | **工具** | Tool | 编排器 tool call；气泡可用「工具 · 读黑板」。 |
+| recipe（用户选型） | **配方**（选项名） | 导演、能力包（旧） | 新建下拉只出现配方选项（世界模拟器、扩写助手…）。 |
+| Module / modules pool | **技能** | 能力、组件池（旧） | 见 `world-simulator-modules.md`。 |
+| `设计.创作流程` | **工作流计划** | 剧本（旧，流程部分） | 增量 DAG；非死选单。 |
+| `设计.worker集` | **运行规格** | 剧本（旧，规格部分） | 可进游玩的声明截面。 |
 | Blackboard | **黑板** | 上下文板 | — |
 | Artifact | **产物** | — | 待验收输出。 |
-| Accept / Review | **验收** / **接受** | — | 按钮用「接受」；阶段说明用「验收」。 |
+| Accept / Review | **验收** / **接受** | 人工审批 | 按钮用「接受」；阶段说明用「验收」。 |
 | Intake | **需求描述** | 启动填空 | — |
 | Burst | **本轮调度** | — | 少对用户说 burst。 |
 | Questions card | **询问卡** | Questions | 详见 `ui-design.md` §8。 |
@@ -79,8 +98,8 @@
 
 | 内部 id | 用户可见 | 备注 |
 |---------|----------|------|
-| `design-flow` | **创作 · 流程编排** | 以已选【导演】为起点，编排/增量修订可变 DAG → 写入剧本（创作流程） |
-| `design-step` | **创作 · 执行步骤** | 按剧本执行当前【能力】 |
+| `design-flow` | **创作 · 流程编排** | 以已选【配方】为起点，编排/增量修订工作流计划（可变 DAG） |
+| `design-step` | **创作 · 执行步骤** | 按工作流计划执行当前【技能】 |
 | `opening-generator` | **开局 · 开场白** | 创作末尾可选 |
 | `design-core` 等 | （已废弃） | 旧分步 skill；勿再调度 |
 
@@ -95,7 +114,7 @@
 
 ---
 
-## 5. 游玩期常用演员（缺省）
+## 5. 游玩期常用执行单元（缺省）
 
 声明里可覆盖；无中文名时用下表：
 
@@ -106,9 +125,9 @@
 | `world-simulator` | **世界推演** |
 | `round-present` | **回合呈现** |
 
-导演选项展示名示例：`world-simulator`（recipe）→ **世界模拟器**；`expand-assistant` → **扩写助手**。
+配方选项展示名示例：`world-simulator`（recipe）→ **世界模拟器**；`expand-assistant` → **扩写助手**。
 
-**创造演员时**：规格里另写 `name`（中文展示名）。`ref` 仍用英文 kebab；UI 优先 `name`。
+**创造执行单元时**：规格里另写 `name`（中文展示名）。`ref` 仍用英文 kebab；UI 优先 `name`。
 
 ---
 
@@ -118,11 +137,11 @@
 |--------------|--------------|------|
 | `phase:core` | **单位 · 核心** | — |
 | `phase:refine` | **单位 · 细化** | — |
-| `worker:{ref}` | **演员 · {中文名或 ref}** | `worker:narrator` → 演员 · 叙事转述 |
-| `fixed:{topic}` | **能力 · {话题中文}** | `fixed:aesthetics-interaction` → 能力 · 美学纲领与交互范式 |
+| `worker:{ref}` | **执行单元 · {中文名或 ref}** | `worker:narrator` → 执行单元 · 叙事转述 |
+| `fixed:{topic}` | **技能 · {话题中文}** | `fixed:aesthetics-interaction` → 技能 · 美学纲领与交互范式 |
 | `resident:{id}` | **常驻 · {id 或名}** | — |
 
-能力话题建议译名：
+技能话题建议译名：
 
 | topic | 用户可见 |
 |-------|----------|
@@ -141,7 +160,7 @@
 |----------------------|----------------|----------|
 | `intake` | 描述需求 | 描述创作需求 |
 | `input` | 补充说明 | 补充说明 / 回答追问 |
-| `worker_questions` | 回答提问 | 回答 · {中文演员名} |
+| `worker_questions` | 回答提问 | 回答 · {中文执行单元名} |
 | `approve_step` | 确认执行 | 建议调用 {中文名} |
 | `review_artifact` | 验收产物 | 验收产物 |
 
@@ -151,9 +170,10 @@
 
 - `Worker · design-core`、`run_worker(design-core)`
 - 顶栏 / pill 写 `design` / `play` 英文
-- 「总管会调度 design-core」（应写「导演会先谈剧本」或「将开始：创作 · 流程编排」）
-- 新建作品同时出现「导演 + 配方」两层选择
+- 「总管会调度 design-core」「导演会先谈剧本」（应写「编排器会先谈工作流计划」或「将开始：创作 · 流程编排」）
+- 新建作品同时出现「导演 + 配方」或「能力包 + 配方」两层选择
 - 询问卡标题直接写 `design-core`
+- 新文案继续使用拍摄词「导演 / 剧本 / 演员 / 能力」作首选
 
 技术日志、导出里的「调试附录」、开发者文档不受本条限制，但默认导出给用户的 Markdown 应走同一套映射。
 
@@ -165,7 +185,8 @@
 |------|------|
 | `ui-design.md` | 布局与心流；文案须服从本文 |
 | `architecture.md` | 内部术语；用户侧以本文为准 |
-| `daily-use-p0.md` | 导演 / 剧本产品定义 |
-| `world-simulator-modules.md` | 【能力】与导演（recipes）作者清单 |
+| `daily-use-p0.md` | 配方 / 工作流计划产品定义 |
+| `world-simulator-modules.md` | 【技能】与配方（recipes）作者清单 |
 | `creation-playbook.md` | 创作/游玩流程概念 |
 | `design-orchestrator-guide.md` | 创作方法（可继续写英文 id，面向作者） |
+| `briefs/capability-authoring-brief.md` | 技能撰写交接（术语须与本文一致） |

docs/worker-skill-format.md

@@ -1,7 +1,8 @@
 # Worker Skill 格式
 
 > **文档层级：Worker / 声明契约格式（非系统架构）。**  
-> 上下文编译原则见 [`architecture.md`](./architecture.md)、[`context-assembly.md`](./context-assembly.md)。
+> 上下文编译原则见 [`architecture.md`](./architecture.md)、[`context-assembly.md`](./context-assembly.md)。  
+> **现行包落地**见 [`skills/dialogue/world-simulator/README.md`](../skills/dialogue/world-simulator/README.md)。
 
 ## 1. 定位（现行：声明驱动）
 
@@ -9,11 +10,12 @@
 
 ```text
 play 时执行契约 = accept 后的 设计.worker集 某条 workers[]（实例 Worker 声明）
-可选模板       = worker-templates/{ref}.yaml（design-intake 合并默认值）
-磁盘 SKILL.md  = 仅创建阶段必要 worker（现：design-intake）
+可选模板       = worker-templates/{ref}.yaml（design 缺省合并默认值）
+磁盘 SKILL.md  = 仅创作阶段必要 worker（现：design-flow / design-step / opening-generator）
+技能正文       = modules/{id}/prompt.md（由 design-step 注入，不是独立 worker）
 ```
 
-总管 `run_worker(id)` → Runtime 校验 id ∈ Worker 声明 → 从 **Worker 集条目**（+ 可选模板合并）拼 prompt → 写声明的 `outputs`。
+编排器 `run_worker(id)` → Runtime 校验 id ∈ Worker 声明 → 从 **Worker 集条目**（+ 可选模板合并）拼 prompt → 写声明的 `outputs`。
 
 **不要**为每个 play ref 预置 `workers/narrator/SKILL.md`；实例差异写在 Worker 集里。
 
@@ -28,28 +30,33 @@ play 时执行契约 = accept 后的 设计.worker集 某条 workers[]（实例
 ```text
 skills/dialogue/world-simulator/
 ├── orchestrator.md
+├── modules/{id}/prompt.md     # 能力切片（非 SKILL.md）
 ├── worker-templates/          # 可选模板，非执行文件
 └── workers/
-    └── design-intake/SKILL.md
+    ├── design-flow/SKILL.md
+    ├── design-step/SKILL.md
+    └── opening-generator/SKILL.md
 ```
 
 - 目录名 = worker id。
 - 文件名固定 **`SKILL.md`**。
 
+旧 `design-intake` / `design-core` / `design-fixed` / `design-worker` / `design-refine` **已移除**。
+
 ---
 
 ## 3. Design Worker Frontmatter（示例）
 
 ```yaml
 ---
-id: design-intake
+id: design-step
 skill: world-simulator
-name: 实例设计 · Worker 集
+name: 创作 · 执行能力步
 stage: design
 inputTags:
   - "用户.需求"
+  - "设计.创作流程"
 outputTags:
-  - "设计.worker集"
   - "设计.worker集.草稿"
 inputMerge: latest
 ---
@@ -70,7 +77,7 @@ inputMerge: latest
 
 ## 4. 实例声明字段（写入 `设计.worker集`）
 
-design-intake 产出的每条 worker：
+`refine` 能力 / design 收口产出的每条 worker：
 
 ```yaml
 workers:
@@ -95,12 +102,13 @@ workers:
 
 - Agent **不**指定 inputTags；读 Worker 声明 / 模板。
 - `ref: null` + `gap`：声明了职责但无模板 / SKILL，需补声明或 temp worker。
-- 验收：`design-intake` 默认 `user_confirmed`；play 中间 worker 可 `no_confirmation`。
+- 验收：design-flow / design-step 默认需用户确认；play 中间 worker 可 `no_confirmation`。
 
 ## 相关
 
 | 文档 | 关系 |
 |------|------|
 | `creation-playbook.md` | 创作流 |
+| `world-simulator-modules.md` | 能力 / 编排器清单 |
 | `worker-declaration.ts` | Runtime 声明校验 |
 | `worker-templates/README.md` | 可选模板 |

docs/world-simulator-modules.md

@@ -1,15 +1,15 @@
-# 世界模拟器 · 导演与能力撰写清单
+# 世界模拟器 · 编排器与能力撰写清单
 
 > 给作者用。用户侧术语：**`docs/ui-glossary.md` §0**。  
-> 运行：选导演 → 编排**增量**剧本 DAG → `design-step` 执行能力；可再扩步反复调用。  
+> 运行：选配方 → 编排**增量**工作流计划 DAG → `design-step` 执行技能；可再扩步反复调用。  
 > **标准范例**：`modules/aesthetics-interaction/prompt.md`。  
 > **给外部 AI 的完整泛用规范**：**`docs/briefs/capability-authoring-brief.md`**（项目概述 + 称呼 + 格式契约）。
 
 ## 两层
 
 ```text
-【导演】recipes/     【能力】modules/
-        └─ 编排增量 DAG → design-step 注入能力块 →（open 则再编排）→ 演员上场
+【配方】recipes/     【技能】modules/
+        └─ 编排增量 DAG → design-step 注入技能块 →（open 则再编排）→ 执行单元上场
 ```
 
 ---
@@ -76,20 +76,37 @@ declaration: …
 切割实现：`parseModulePromptSections` / `extractModuleOpening` / `formatModulePromptForLlm`（`src/skills/creation-flow.ts`）。  
 注入 LLM 时按块顺序拼接，**不含** `opening`（开场已由程序发出）。
 
-### catalog 一行（插入导演提示词）
+### catalog 一行（索引 + 编排结构）
 
 | 字段 | 作用 |
 |------|------|
-| `id` / `name` / `declaration` / `artifact` | 选型与产物映射 |
+| `id` / `name` / `declaration` / `artifact` | 索引与产物映射；`declaration` 可被 prompt `meta` 覆盖 |
 | `repeatable` | 可选；`true` = 允许同能力多次编入增量 DAG |
+| `params` | 可选；编排期 `steps[].params` 声明（`key`/`label`/`required`/`hint`）；必填项须在进执行前钉齐 |
 | `opening` | 可选覆盖；一般只写在 prompt 的 `opening` 块 |
 
+编排器注入【能力 · 可选工序】时，会读取各能力 `prompt.md` 的 `meta`（`declaration` / `when` / `when_not` / `boundary`），**不是**只看 catalog 短声明。执行全文仍只在 design-step 注入。
+
+### 配方 `recipe.yaml`
+
+| 字段 | 作用 |
+|------|------|
+| `when` | 适用什么体验 |
+| `core` | 整套设计方法的核心思路与目标 |
+| `process` | 设计流程（如何增量选型、何时收成） |
+| `principles` | 配方特有取舍 |
+| `brief` / `steps` | 近期起点；不是固定全程 DAG |
+
+配方**不要**重复罗列各能力调用条件；那是能力 meta 的职责。旧字段 `hint` 仍可读作兜底。
+
 ### 默认问题节奏（通用）
 
 ```text
 程序发 opening → 用户首答 → LLM（opening + 首答 + 切割后的方法块 + 依赖）
 ```
 
+有编排参数的能力：先由 design-flow askUser 钉 params → 用户认可 DAG → design-step 注入【本步参数】执行；勿把「生成什么」推迟到执行期。
+
 ---
 
 ## 目录与清单
@@ -107,11 +124,11 @@ recipes/world-simulator|expand-assistant/recipe.yaml
 | 美学纲领与交互范式 | `aesthetics-interaction` | **范例已写** |
 | 实现机制 | `mechanism` | **已写** |
 | 世界蓝图与人文地理 | `world-blueprint` | **已写** |
-| 生成规则 | `generation-rules` | 骨架，**可反复** |
-| 具体实例 | `concrete-instances` | 骨架，**可反复** |
+| 生成规则 | `generation-rules` | **已重写**，可反复；双门槛 + schema + 生命周期；编排必填 `params.target` |
+| 具体实例 | `concrete-instances` | **已重写**，可反复；执行预生成规则；编排必填 `params.rule_id` |
+| 叙事指南 | `narrative` | **已写** |
 | 拓扑图谱 | `topology` | 骨架，待细写 |
 | 设计状态栏 | `status-bar` | 骨架，待细写 |
-| 叙事指南 | `narrative` | 骨架，待细写 |
 | 变量设计与更新规则 | `variable-design` | 骨架，待细写 |
 | 变量控制上下文 | `variable-context` | 骨架，待细写 |
 | 设计回复格式 | `reply-format` | 骨架，待细写 |
@@ -120,20 +137,21 @@ recipes/world-simulator|expand-assistant/recipe.yaml
 
 | 能力 | id | 状态 |
 |------|-----|------|
-| Worker 规格 | `worker-spec` | 骨架，**可反复** |
-| 细化终稿 | `refine` | 骨架，待细写 |
+| Worker 规格 | `worker-spec` | **已写**，可反复 |
+| 细化终稿 | `refine` | **已写**（产物=`设计.worker集`） |
 
-| 导演 | 状态 |
+| 编排器 | 状态 |
 |------|------|
-| 世界模拟器 | 建议第一步：美学纲领与交互范式 |
-| 扩写助手 | 待完善 |
+| 世界模拟器 | 方法论已写（core/process/principles）；起点：美学纲领与交互范式 |
+| 扩写助手 | 方法论已写；起点：美学纲领与交互范式；勿默认套世界模拟全套 |
 
 ---
 
 ## 验收
 
-1. 只选导演 → 出**近期**创作流程（`status=open`）  
+1. 只选配方 → 出**近期**创作流程（`status=open`）  
 2. design-step 能切割出 `opening`/`task`/…  
 3. 有 `opening` 时先程序开场再 LLM  
-4. 可追加同能力多次（不同 step.id）；收成前 `status=closed`  
-5. UI 用拍摄术语  
+4. 可追加同能力多次（不同 step.id + params）；收成前 `status=closed`  
+5. UI 用编排术语；有编排参数的步骤须展示 params  
+6. 缺必填 params 的步骤不得视为可执行（校验失败 / 编排先 askUser）