Load present shells from a skill-pack catalog and list leftover creation modules.

Design-flow now sees leftover catalog skills and aesthetics-card commitments; reply-format injects present-shells/, and world-simulator prompts add random-range plus a tighter module set. Co-authored-by: Cursor <cursoragent@cursor.com>
2026-09-07 01:21:10 +08:00
parent 770a8fdcdc
commit 3c751988de
59 changed files with 2793 additions and 1638 deletions
@@ -11,19 +11,19 @@ name: 美学纲领与交互范式
 id: aesthetics-interaction
 artifact: 设计.美学纲领与交互范式
 declaration: >
-  钉清站位、正文呈现、核心体验与禁忌、何时等用户；
-  询问相近故合为一步，勿拆成「交互」「美学」两步
+  钉清用户会在意的体验承诺：站位、反复感到什么、轮转何时停。询问相近故合为一步。
 when: |
-  可玩/可沉浸体验，但站位、呈现、核心感觉或轮转边界仍不清时；
-  世界模拟类配方通常作为工作流计划第一步（无上游依赖）。
-  已有等价定稿且用户未要求重谈 → 不要重复排入。
+  还不能回答这三件：代入还是旁观？最想反复感到什么？轮转到哪必须停等用户？
+  无上游，通常作第一步。
 when_not: |
-  只改实现细节且体验契约已验收；纯工具/排版；与「给玩家什么体验」无关。
+  这三件已有等价定稿、用户未要求重谈 → 不重复排入。
+  只改文风 → 「叙事指南与故事推进」；只改每轮看什么 → 「回复呈现」；只改排版/壳 → 「正文组成」。
+  只改舞台、规则、真值、槽位 → 对应下游技能。与「给玩家什么体验」无关 → 不排。
 boundary: |
-  本技能：体验是什么、怎么发生在用户身上、轮转怎么停；产出 context-fragment.v1。
+  本技能：体验是什么、怎么发生在用户身上、轮转怎么停。产出供后续编排阅读的开头节点。
  叙事指南与故事推进：把感觉落成遣词/笔墨/禁忌与推进——本步只钉感觉与轮转。
  舞台骨架 / 具体实例 / 生成规则：舞台与可执行规则——本步不定。
-  实现机制 / 变量* / 监控栏 / 正文组成 / 游玩拓扑 / 上下文投影排序 / 细化终稿：落到可运行结构——本步不定。
+  实现机制 / 变量* / 回复呈现 / 正文组成 / 游玩拓扑 / 上下文投影排序 / 细化终稿：落到可运行结构——本步不定。
 feeds: design_only
 ```

@@ -2,7 +2,7 @@
 # 各【导演】与编排都从这里选型。
 # id = modules/{id}/ 文件夹
 # name = 固定中文名（流程 JSON 的 name；同能力可多次时靠 step.id 区分）
-# declaration = catalog 短声明（可被 prompt.md ```meta 覆盖）
+# declaration = 给人看/兜底的短声明（规划选型以 prompt.md ```meta 为准并覆盖本表）
 # artifact = 执行期产物 tag（程序映射；不写进流程 JSON）
 # repeatable = true 时允许同能力多次**新建**编入增量 DAG（如生成规则、具体实例）。
 # 回头修改已完成节点不是 repeatable：用户在图上点该节点重进，不要排 mode=revise。
@@ -13,8 +13,9 @@
 #          〔先验产物〕=规划产物字段（可提前填，空则步内钉）
 # opening = 可选；覆盖 prompt.md 里 ```opening 默认问题（一般只写在 prompt.md）
 #
-# 编排选型：程序会读取各 modules/{id}/prompt.md 的 meta
-# （declaration / when / when_not / boundary）注入 design-flow；勿只靠本表短声明。
+# 编排选型：程序读取各 modules/{id}/prompt.md 的 meta
+# （declaration / when / when_not / boundary）注入 design-flow。
+# when/when_not 必须是规划对照用户话与已有产物就能判定的信号；调用条件写在技能 meta，不要写进配方 process。
 #
 # 标准范例：aesthetics-interaction（美学纲领与交互范式）
 # 后来写能力：同结构 prompt.md（含默认问题）+ 本表一行索引
@@ -30,16 +31,16 @@ modules:
  - id: aesthetics-interaction
    name: 美学纲领与交互范式
    declaration: >-
-      钉清站位、正文呈现、核心体验与禁忌、何时等用户；
-      询问相近故合为一步，勿拆成「交互」「美学」两步
+      钉清用户会在意的体验承诺：站位、反复感到什么、轮转何时停。
+      询问相近故合为一步。
    artifact: 设计.美学纲领与交互范式

  # —— 世界与内容 ——
  - id: world-blueprint
    name: 舞台骨架
    declaration: >-
-      体验需要可引用舞台时：钉尺度、基底与变造、关键舞台区，以及社会结构与世界状况；
-      只细化会上台部分，不做地图百科
+      本局舞台备案：划出玩家实际游玩会换区活动的主要区域并写细；
+      尺度与详细度随体验变。代入后几乎不移动、只在一处待着则不排
    artifact: 设计.舞台骨架

  - id: generation-rules
@@ -47,8 +48,8 @@ modules:
    kind: prior-artifact
    repeatable: true
    declaration: >-
-      仅当某类内容既重要又无法凭基底稳定生成时：写出规则
-      （怎么描写/生成 + 产物格式 + 可选多池，池绑 JSON 字段）；可按对象反复调用
+      要精准格式，或本局原创导致知识中无可参考对象、或难以在无指导情况下生成足够可信内容且故事里还要生成时：写出该对象族怎么生成；
+      不填最终实例；可按对象反复
    artifact: 设计.生成规则
    params:
      - key: target
@@ -66,7 +67,7 @@ modules:
    kind: prior-artifact
    repeatable: true
    declaration: >-
-      按预生成规则原样产出实际产物；不设计、不改合同；可按 rule_id/批次反复调用
+      已有预生成规则时：按该规则原样交出 records；不设计、不改合同；可按规则/批次反复
    artifact: 设计.具体实例
    params:
      - key: rule_id
@@ -82,49 +83,59 @@ modules:
  - id: narrative
    name: 叙事指南与故事推进
    declaration: >-
-      一次钉清写法与推进（遣词/笔墨/禁忌/示范 + 故事如何往前）；
-      整份双挂转述与主世界层，不为省 token 拆投影
+      美学已有方向时：把感觉落成可执行的遣词、笔墨落点、禁忌与推进方式；
+      不重做体验问卷
    artifact: 设计.叙事指南与故事推进

  # —— 机制与数据 ——
  - id: mechanism
    name: 实现机制
    declaration: >-
-      核心体验已明时：识别承重切面（如何支撑 / 缺失后果），产出可挂主世界层的上下文片段；
-      不重定体验、不写百科或执行单元
+      整体感觉已钉，故事里有必须当作既成事实的变造法则时：
+      点出它们如何约束故事，不解释为何存在
    artifact: 设计.实现机制

  - id: topology
    name: 拓扑图谱
-    declaration: 钉 worker/表/阶段的依赖、触发与数据流向；一张图说清谁读谁写
+    declaration: >-
+      必须生成、但不适合走「生成规则→具体实例」时：用拓扑结构写出来
+      （升级路径、地图、人物关系等）
    artifact: 设计.拓扑图谱

  - id: variable-design
    name: 变量设计与更新规则
    declaration: >-
-      钉真值字段、写入源（执行单元/用户/程序）、更新规则，以及按真值门控的
-      side_effects（Progressive 投影）；与运行规格 tables 对齐
+      体验必须跨轮记住少数状态时：钉真值、谁可写、如何变、维护语句，
+      以及按值换文案的映射索引
    artifact: 设计.变量设计与更新规则

  - id: variable-context
    name: 变量控制上下文
    declaration: >-
-      钉真值与投影如何挂进主世界层等上下文：可见性、措辞、未解锁不注入
+      已有真值或映射时：钉谁看见什么（主世界层/转述/旁观）、未解锁不注入；
+      无信息差则可不排
    artifact: 设计.变量控制上下文

  # —— 呈现 ——
  - id: status-bar
-    name: 设计监控栏
+    name: 回复呈现
    declaration: >-
-      钉用户可见监控栏字段：只留会变、影响决策或沉浸的信息
-      （主角/攻略目标/场景交互物等）；旧称设计状态栏
+      几乎每局都要：钉每轮终稿的必选/可选区域，以及各区域的简单内容规则
+      （字数、段落、选项怎么组成等）；不排版
    artifact: 设计.监控栏

+  - id: random-range
+    name: 随机范围整理
+    declaration: >-
+      上游已有检定/对抗/掷骰需求时：汇总全部要用的随机项与取值范围（含表达式），
+      供程序每轮插入备用随机数；排在正文组成之前
+    artifact: 设计.随机范围整理
+
  - id: reply-format
    name: 正文组成
    declaration: >-
-      基于固定呈现壳做适配微调（选 shell_id + 字段/显示名等）；
-      产出壳适配单，禁止从零发明布局；旧称设计回复格式
+      把「回复呈现」已钉的内容展示给用户：选壳、美化排版，可写 CSS/HTML/JS；
+      排在回复呈现之后、开场白之前；有随机表则一并接到隐藏备用区
    artifact: 设计.正文组成

  # —— 开局（创作偏晚） ——
@@ -141,8 +152,8 @@ modules:
    name: 游玩拓扑
    repeatable: false
    declaration: >-
-      勾选固定游玩槽位（主世界层/叙事转述/可选角色视角/可选机遇裁定，或写手大纲+章节）；
-      禁止自由发明执行单元
+      不能吃默认槽时才勾选：主世界层必开；有变量/表才开旁观；转述默认开；
+      强秘密才开视角；写手则大纲+章节；禁止发明执行单元与机遇槽
    artifact: 设计.worker规格

  - id: context-order
@@ -150,13 +161,12 @@ modules:
    repeatable: false
    auto: true
    declaration: >-
-      先抄固定执行单元名册，再为每个已启用者写出扁平投影序
-      （含对话.历史与 projection）；不发明槽、不重写长文、不演情节选择题
+      收成前给已启用槽排扁平投影序（含对话.历史）；
+      不发明槽、不重写长文、不演情节选择题
    artifact: 设计.上下文投影排序

  - id: refine
    name: 细化终稿
    declaration: >-
-      按已勾选固定槽与投影排序表收成运行规格（play_slots、常驻、表副作用）；
-      不发明新执行单元
+      按已勾选槽（或默认槽）与投影排序表收成运行规格；不发明新执行单元
    artifact: 设计.worker集
@@ -11,13 +11,13 @@ name: 具体实例
 id: concrete-instances
 artifact: 设计.具体实例
 declaration: >
-  按一条预生成规则原样产出实际产物（单层 JSON records）；可按 rule_id/批次反复调用；
-  本步不设计、不改合同
+  已有预生成规则时：按该规则原样交出 records；不设计、不改合同；可按规则/批次反复
 when: |
-  「设计.生成规则」中已有 `seed_only` 或 `seed_and_runtime` 的规则，需要生成实际内容。
+  「设计.生成规则」里已有 `seed_only` 或 `seed_and_runtime` 的规则，且现在需要实际名片/记录（开局 NPC、种子事件等）。
 when_not: |
-  `runtime_only` → 游玩期再生成。
-  无规则 / 规则不完整 / 想改格式或方法 → 回「生成规则」。
+  尚无规则或规则不完整 → 先「生成规则」。想改格式/方法/池 → 回「生成规则」，本步不改合同。
+  规则是 `runtime_only` → 不排，游玩期再生成。
+  只要规则不要预写实例 → 不排。
 boundary: |
  本技能只做一件事：按指定规则生成 records。规则说怎么写、什么格式、如何用池，就照做。
  生成规则：合同制定方——本步不重论证、不修改。
@@ -12,16 +12,15 @@ name: 上下文投影排序
 id: context-order
 artifact: 设计.上下文投影排序
 declaration: >
-  先列出本局固定执行单元（程序名册），再为每个已启用者写出扁平投影序
-  （含对话.历史与 projection）；不发明槽、不重写正文、不演情节选择题
+  收成前给已启用槽排扁平投影序（含对话.历史）；不发明槽、不重写长文、不演情节选择题
 when: |
-  游玩槽已确认（或可按默认），且主要上下文块已有可摘要产物，
-  需要决定各执行单元看见什么、以何顺序插入时。
+  游玩槽已确认（或可按默认），且主要上下文块已有可摘要产物，需要决定各执行单元看见什么、以何顺序插入。
+  本步为〔程序步〕：上下文已多、即将收成时排入。
 when_not: |
-  体验/站位仍混沌 → 先美学纲领与交互范式。
-  槽位未定且用户拒绝默认 → 先游玩拓扑。
+  体验/站位仍混沌 → 先「美学纲领与交互范式」。
+  槽位未定且用户拒绝默认 → 先「游玩拓扑」。
  上游上下文仍大量空洞、无法判断稳/变 → 先补缺口，勿空排。
-  只需勾选槽 → 游玩拓扑；只需合并终稿 → 细化终稿。
+  只需勾选槽 → 「游玩拓扑」；上下文很少、只需合并终稿 → 「细化终稿」可按默认序退化。
 boundary: |
  本技能：抄名册 → 凭各块 brief/挂载/稳变 给每槽 inserts[]。
  名册权威在程序（及已勾选的游玩拓扑）；本步不增白名单外 id。
@@ -36,7 +35,8 @@ feeds: design_only
 ```opening
 按已验收产物的概括，给每个固定执行单元分配上下文顺序（只排序，不改设定、不演游玩）。

-名册由程序钉死：主世界层 / 叙事转述 / 旁观维护（回合末）/ 可选角色视角 / 按需机遇（已并入主世界层工具）。
+名册由程序钉死：主世界层 / 叙事转述 / 旁观维护（回合末）/ 可选角色视角。
+无机遇裁定槽；「设计.随机范围整理」按 mount 挂进主世界层（等）inserts 即可。
 若前面产物够用，直接回复「按已有概括排序」。
 ```

@@ -47,21 +47,20 @@ feeds: design_only

 执行顺序（必须按此，禁止颠倒）：
 1. **抄名册**：以程序注入的【本局固定执行单元】为准列出 agents[]（id / label / enabled / when / duty）。
-   启用与否跟已勾选游玩拓扑走；未勾选则按默认：旁观+主世界层+转述开，角色视角关，机遇关。
+   启用与否跟已勾选游玩拓扑走；未勾选则按默认：主世界层+转述+旁观开，角色视角关（无机遇槽）。
 2. **再分配**：只对 enabled 的每轮槽写 inserts（order / ref / projection / 可选 note）。
   凭上游 **brief、挂载、稳变** 排序，禁止把百科全文再读一遍当创作。

 规则：
-1. 禁止发明白名单外 id（含画图等未入册槽）。
+1. 禁止发明白名单外 id（含画图、机遇裁定等未入册槽）。
 2. 禁止重写上游长文；只写顺序与投影。
 3. 每轮槽：order 0＝该槽固定人设；其后按「稳→对话.历史→易变」软排。
 4. 主世界层必须含 ref=`对话.历史`（默认 projection=summary）；转述与旁观维护默认不含历史。
-5. 主世界层应双挂「设计.叙事指南与故事推进」等 mount 到 gm 的块；转述只读裁决+文风/壳。
+5. 主世界层应双挂「设计.叙事指南与故事推进」等 mount 到 gm 的块；有「设计.随机范围整理」则挂 gm（summary 即可）；转述只读裁决+文风/壳。
 6. 旁观维护在回合末：须含「运行.本轮.裁决」与变量合同，不含历史。
-5. 按需槽（机遇）enabled 时 inserts 可空。
-6. 越稳越靠前；本轮输入/真值/裁决通常在历史之后。
-7. 同一内容可挂多槽；chance 不必排进每轮 inserts。
-8. summary：如 `投影排序 · 旁观+主世界层+转述`。
+7. 越稳越靠前；本轮输入/真值/裁决通常在历史之后。
+8. 同一内容可挂多槽。
+9. summary：如 `投影排序 · 旁观+主世界层+转述`。

 若程序已发默认问题：禁止重复同一开场；用户说「按已有概括排序」或等价同意 → **立刻产出表**，禁止再问情节内选项。
 禁止 askUser 出游玩选择题（迎上去/推开她/反客为主 等）。材料已齐则顶层 askUser 为 null。
@@ -149,14 +148,6 @@ feeds: design_only
      "when": "every_turn",
      "duty": "强信息隔离时出反应建议",
      "inserts": []
-    },
-    {
-      "id": "chance",
-      "label": "机遇裁定",
-      "enabled": false,
-      "when": "on_demand",
-      "duty": "骰子/抽签；按需调用，不进每轮",
-      "inserts": []
    }
  ]
 }
@@ -165,7 +156,7 @@ feeds: design_only
 ## checklist

 ```checklist
- [ ] agents 只使用程序名册 id（auditor / gm / narrator / perspective / chance）
+- [ ] agents 只使用程序名册 id（auditor / gm / narrator / perspective）；无 chance
 - [ ] 未发明白名单外执行单元
 - [ ] 未重写上游长文，只有排序/投影
 - [ ] 未把游玩选项示例当成当前提问
@@ -173,5 +164,5 @@ feeds: design_only
 - [ ] 主世界层含「对话.历史」；转述与旁观维护默认无历史
 - [ ] 旁观维护含「运行.本轮.裁决」；转述含裁决且不含历史
 - [ ] 少变块整体靠前、本轮/真值靠后（软规则）
- [ ] 与游玩拓扑勾选一致
+- [ ] 与游玩拓扑勾选一致；有随机范围表则已挂 gm
 ```
@@ -11,25 +11,23 @@ name: 生成规则
 id: generation-rules
 artifact: 设计.生成规则
 declaration: >
-  仅当某类内容既重要又无法凭基底稳定生成时：为该对象族写出一条可执行规则
-  （怎么描写/生成 + 产物格式 + 可选多池，池绑 JSON 字段）；可按对象反复调用；本步不填最终实例
+  要精准格式，或本局原创听了会雾且故事里还要生成时：写出该对象族怎么生成（描写/格式/可选池）；不填最终实例；可按对象反复
 when: |
-  上游体验与世界基底已足以判断某类内容同时满足：
-  1. 对游玩重要；2. 仅凭现有上下文无法稳定产出合格、一致、可供下游使用的结果。
+  已有「美学纲领与交互范式」或等价整体感觉，且下面两条满足一条就排（可按对象族反复）：
+  a. 生成物必须有精准格式。例：武功典籍要有名字、效果、阶层。
+  b. 本局原创、听了会一头雾水的东西，故事里还要随机/反复生成。例：人人能绽放的「心之彩」；当成本局原创的斩魄刀。
 when_not: |
-  重要但常识/世界基底已够 → 不建规则。
-  难生成但不影响核心体验 → 不建规则。
-  只要预写最终记录、且不需专门规则 → 通常不必本步。
-  变量如何增减 → 「变量设计与更新规则」。
-  剧情如何推进 → 不借本步泛化。
+  整体感觉未钉 → 先「美学纲领与交互范式」。
+  常识能推、也不需要精准格式（现实名车、西幻常见种族）→ 不排。
+  只要几张具名名片、不必按规则生成 → 不排；已有规则再要名片 → 「具体实例」。
+  跨轮记住什么 → 「变量设计与更新规则」。故事怎么往前写 → 「叙事指南与故事推进」。
 boundary: |
-  本技能产出的是「规则」本身，一条规则包含：
-  （1）应该怎么描写、生成；（2）产物格式——单层 JSON（对接表格/旁观者/投影）；
-  （3）可选多「池」——各挂一个顶层字段，供抽取/组装/枚举。
+  本技能：一条规则＝怎么描写/生成 + 单层 JSON 产物格式 + 可选多池（各绑一个顶层字段）。
  具体实例：按规则填最终 records；本步不写最终实例（池条目≠实例）。
-  舞台骨架 / 实现机制：可引用，不重写百科、不重做移除检验。
+  舞台骨架 / 实现机制：可引用，不重写百科、不重钉既成法则。
  变量*：游玩期状态更新——本步只约束生成时的类型与合法初值范围。
-  旁观维护：可读「合同」——rule_id、产物格式、何时可 need_generate；不依赖整份描写长文。
+  随机范围整理：把本步（及其他上游）里需要的掷骰/检定范围收成插入表——本步可写合法区间，不代替那份汇总。
+  旁观维护：可读合同（rule_id、产物格式、何时可 need_generate）；不依赖整份描写长文。
 feeds: gm,auditor
 ```

@@ -41,10 +39,11 @@ feeds: gm,auditor
 - 若规划为空，先钉对象族，再谈规则。

 然后谈：
-1. 若不做专门规则、只靠世界设定临场写，最怕出现什么不可接受的结果？
-2. 更需要：开局先钉一批、游玩中再随机补，还是只在游玩期动态生成？
-3. 这类实例彼此有没有必须同场钉死的关系（如互为亲属、对立、同场搭档）？有 → 一次同批生成；彼此独立 → 一次一条。
-4. 哪些产物字段需要「池」？（池挂在 JSON 字段上，如气质标签池→`气质`；可多个；没有就说没有）
+1. 生成出来必须钉死哪些字段吗？（如武功典籍的名字、效果、阶层）没有就说没有。
+2. 这是不是本局原创、听了会一头雾水、还要在故事里随机生成的东西？
+3. 更需要：开局先钉一批、游玩中再随机补，还是只在游玩期动态生成？
+4. 这类实例彼此有没有必须同场钉死的关系（如互为亲属、对立、同场搭档）？有 → 一次同批生成；彼此独立 → 一次一条。
+5. 哪些产物字段需要「池」？（池挂在 JSON 字段上，如气质标签池→`气质`；可多个；没有就说没有）

 想到什么写什么；完整规则在正式产物里钉。
 ```
@@ -64,7 +63,7 @@ feeds: gm,auditor

 执行顺序：
 1. 认定对象族：规划有 `target` 则采用（用户要改则以最新为准）；规划为空则先钉对象。不要停下来让编排器补参。
-2. 双门槛：重要性 + 基础上下文不足。任一项不成立 → 结论「无需专门规则」，`rules: []`。
+2. 对照时机 a/b：必须有精准格式，或本局原创听了会雾且故事里还要生成。两条都不成立 → 结论「无需专门规则」，`rules: []`。
 3. 两项成立时，生命周期三选一（规划里 `lifecycle_intent` 合理则采用）：
   - `runtime_only`：仅游玩期动态生成；不要求「具体实例」。
   - `seed_only`：由「具体实例」预生成；规则用完可丢。
@@ -85,7 +84,7 @@ summary：建立 → `生成规则 · {对象} · {仅动态|仅预生成|预生
 ## principles

 ```principles
-1. 整条规则先问必要性：是否值得单独用「生成规则」承接？双门槛不成立则跳过，勿硬造表。
+1. 整条规则先问必要性：时机 a（精准格式）或时机 b（原创会雾且还要生成）是否成立？两条都不成立则跳过，勿硬造表。
 2. 一调用一对象族；格式或用途不同则分次编排。
 3. 规则 = 描写/生成方法 + 产物格式；池是可选附属（可多池），不是必填第三设计。
 4. 属性逐个过筛：每个字段必须对本对象族有意义；禁塞通用名片字段，也禁漏掉玩法接口字段。
@@ -104,7 +103,7 @@ summary：建立 → `生成规则 · {对象} · {仅动态|仅预生成|预生
 每轮 1～2 点。规划已钉且用户未改对象时，禁止重问 target / rule_id。规划为空或用户要换对象时，先问本轮生成什么。

 优先：整条规则是否必要；实例彼此有无必须同场对齐的关系（一次生成：同批 vs 单条）；某字段该不该进表（冗余 vs 漏接口）；单层格式类型/枚举/边界；哪些字段要池。
-若双门槛不成立 → 建议跳过，停追问字段与格式。
+若时机 a/b 都不成立 → 建议跳过，停追问字段与格式。
 不追问：最终实例正文、变量增减公式、其它对象族、完整世界百科。
 ```

@@ -125,8 +124,8 @@ summary：建立 → `生成规则 · {对象} · {仅动态|仅预生成|预生
    },
    "必要性判断": {
      "生成对象": "本轮对象族",
-      "对游玩的重要性": "没有专门规则会损失什么",
-      "基础生成的不足": "现有上下文为何不够；若足够则写清",
+      "对游玩的重要性": "时机 a：必须钉死哪些字段；无则写「不需精准格式」",
+      "基础生成的不足": "时机 b：为何听了会雾、现有常识推不出；能推则写清",
      "结论": "建立专门规则|无需专门规则"
    },
    "rules": [
@@ -212,7 +211,7 @@ summary：建立 → `生成规则 · {对象} · {仅动态|仅预生成|预生
      {
        "名": "必要性",
        "分数": 8,
-        "说明": "整条规则：是否有必要单独用「生成规则」承接该类内容；跳过时理由是否充分"
+        "说明": "时机 a 或 b 是否成立；跳过时理由是否充分"
      },
      {
        "名": "属性妥当",
@@ -266,12 +265,14 @@ summary：建立 → `生成规则 · {对象} · {仅动态|仅预生成|预生

 ```examples
 好：
+- 武功典籍：单层含 名字/效果/阶层（时机 a）。
+- 「心之彩」：本局原创、听了会雾，故事里还要随机生成（时机 b）。
 - D&D 怪物：单层含 名称/等级/攻击骰/……；池可绑 `气质`；自评属性妥当高（未漏战斗接口）。
 - 女主规则：不设「性别」字段；关系切面进表；池可空。
 - 互为仇敌的两名开局 NPC：一次生成=同批，关系写清对立如何对齐；数量=2。
 - 可互换的酒馆路人：一次生成=单条，关系写「彼此独立」；要 5 个就点 5 次。
 - 事件钩子：池绑顶层 `钩子`；方法写抽 1～2 条写入该字段。
- 普通古董 → 无需专门规则（必要性维度说明跳过理由）。
+- 现实名车、西幻常见种族 → 无需专门规则（常识能推且不需精准格式）。

 坏：
 - 产物写成 `{ "外貌": { "发色": "…" } }` → 非单层，前端表格/投影难对接。
@@ -1,4 +1,4 @@
-# 实现机制
+# 实现机制

 > 技能文档。程序只切割下方 **fence 块**；`##` 标题仅供人读。  
 > 产物外壳对齐：`docs/context-fragment-design.md`；范例：`aesthetics-interaction`。
@@ -10,39 +10,34 @@ name: 实现机制
 id: mechanism
 artifact: 设计.实现机制
 declaration: >
-  当核心体验已经明确，需要识别由哪些角色、世界、关系、规则或情境切面支撑，
-  并把体验落成可供后续设定工作的核心支点时使用
+  整体感觉已钉，故事里有必须当作既成事实的变造法则（科幻意义上的第一初设定）时：点出它们如何约束故事，不解释为何存在
 when: |
-  已有「美学纲领与交互范式」或等价的体验声明，但还不能回答：
-  “这个体验具体靠什么存在？”
-  “拿掉哪些东西后，核心感觉就会明显变质？”
-  “哪些设定切面必须被后续世界、角色与规则设计继承？”
+  已有「美学纲领与交互范式」或等价整体感觉，且用户表述或美学卡里有必须当作既成事实的变造法则。
+  例：现代都市但已繁荣一统、存在修炼体系；三体黑暗森林；机器人三定律。
+  特征：故事不必纠结它为什么存在，拿掉则故事骨架会换。
 when_not: |
-  核心体验尚未明确 → 先「美学纲领与交互范式」。
-  只需补舞台骨架/实例 → 「舞台骨架」或「具体实例」。
-  需持续生成规则 → 「生成规则」；需真值门控 → 「变量设计与更新规则」。
-  只需叙述呈现与推进口径 → 「叙事指南与故事推进」。
+  整体感觉未钉 → 先「美学纲领与交互范式」。
+  没有特殊变造，或「特殊」只是身份/开场处境、能被「舞台骨架」「具体实例」「开场白与开场变量」覆盖（如现实世界模拟普通大学生）→ 不排。
 boundary: |
-  本技能：识别支撑核心体验的关键切面（如何支撑 / 缺失后果）；产出 context-fragment.v1。
-  美学纲领与交互范式：体验目标与轮转——本步不重定。
-  舞台骨架 / 具体实例 / 生成规则 / 变量* / 叙事指南与故事推进：展开环境、实例、生成、真值、写法——本步只钉承重切面。
+  本技能：点名故事当作既成事实的变造法则，写清如何约束后续；不补起源、不写舞台百科、不写人物名片。
+  美学纲领与交互范式：体验与轮转——本步不重定。
+  舞台骨架：环境与社会格局。具体实例 / 开场白与开场变量：名片与第一屏（身份特殊走它们）。
+  生成规则 / 变量* / 叙事指南与故事推进：持续生成、跨轮真值、遣词推进——本步只钉前提法则。
 feeds: gm
 ```

 ## opening

 ```opening
-核心体验已有方向时，用几句话想想：它具体靠什么撑住？（想到什么写什么，不必整齐；点名即可，不必论证来源或补起源史。）
+整体感觉已有方向时，把故事里「必须当作已经成立」的变造法则点出来（想到什么写什么；点名即可，不必解释它为什么存在）。

-1. 这体验主要靠哪些东西成立？
-   角色的某一面、一段关系、世界条件、规则或情境……用你自己的词点名。
-   例：丈夫会把异常证据合理化；力量越用越侵蚀自我；村里每年必须献祭才能过冬。
+1. 这局有哪些特殊变造，后续情节都得认它？
+   例：现代都市，但世界已繁荣一统；存在修炼体系；黑暗森林法则；机器人三定律。

-2. 拿掉或改弱哪一样，核心感觉会明显变味甚至垮掉？
-   一句话即可——只点「缺了就不对」的，装饰和以后再展开的先别列。
+2. 拿掉或改弱哪一条，故事骨架会换成另一个？
+   一句话——只点「缺了就不是这个故事」的。

-3. 若已有具体画面或作品参照，它主要指哪一切面在撑体验？
-   例：信息差、无法撤销的前提、身份代价、循环反馈……不必复述整部设定。
+3. 若只是某人身份特殊、开场处境特殊，先别写在这里（那是舞台 / 人物 / 开场白）。
 ```

 ## task
@@ -50,21 +45,21 @@ feeds: gm
 ```task
 你正在执行「实现机制」。产物必须是 **context-fragment.v1** JSON，写入「设计.实现机制」。

-这里的「机制」不是必须解释到底的科学原理，也不等于程序规则。它更接近可直接成立的初始设定：后续内容依赖它，本步不必补起源史或完整理论。
+本步钉的是故事的第一初设定：已被承认、不必解释来源、却会决定后续能不能这么写的变造法则。不是科学原理，不是舞台百科，也不是人物名片。

-核心操作：从已确认的核心体验出发，追问「什么在支撑它」，识别缺失后会让体验不成立、变弱或变质的角色、关系、世界、规则与情境切面。
+从已确认的整体感觉出发，点出这些法则，写清它们如何约束故事、拿掉会怎样。用户没有这类特殊变造：覆盖检验写明「无特殊法则」，追问确认是否跳过；身份/开场类特殊交给「舞台骨架」「具体实例」「开场白与开场变量」。

 执行顺序：
-1. 读依赖产物与用户表述，忠实提取核心体验；不重做美学/交互。
+1. 读依赖产物与用户表述，忠实提取整体感觉与已点名的变造；不重做美学/交互。
 2. 思考阶段判断基准世界可能性范围（只校验，不写入产物）。
-3. 检查体验如何产生、增强、维持，及多支点如何共同成立。
-4. 对每个候选做移除检验。
-5. 只保留有明确支撑关系的主要支点；常识、装饰、完整人物卡、后续技能展开对象不纳入。
-6. 写入正文：依据体验、支撑点（含切面形态）、支撑点关系、覆盖判断。
+3. 列出必须当作既成事实的变造法则，检查拿掉后故事骨架是否会换。
+4. 对每条候选做移除检验。
+5. 只保留缺了会换骨架的法则；常识、装饰、人物名片、开场处境、后续技能展开对象不纳入。
+6. 写入正文：依据体验、支撑点（每条法则）、支撑点关系、覆盖判断。
 7. 填自评与追问（薄弱点才问；题目可空数组）。
 8. 输出符合 output 契约的 JSON。

-工作姿态——「识别已经在那里之物」：不另造体验；不设设定菜单；不题材套件；可整理未命名关系；可暂定请用户修正；二选一支点先问清再写。
+工作姿态——「点出已经成立之物」：不另造体验；不补起源史；不设设定菜单；不题材套件；可整理用户未命名的法则并请修正；二选一先问清再写。

 依赖含混时不越权重做上一步。无法在本步解决的写入开放问题或追问。

@@ -75,25 +70,22 @@ summary：`实现机制 · …`（点题主要支撑）。
 ## principles

 ```principles
-1. 体验向支撑正推
-   始终保持：核心体验 → 成立所需条件 → 承担该条件的具体元素 → 该元素真正相关的切面 → 切面如何支撑体验。
-   不能从题材标签、常见套路或预制角色清单反推「应该具有什么」。题材只能提供可能性，不能代替支撑关系。
+1. 从整体感觉正推到既成法则
+   始终保持：整体感觉 → 故事必须承认的变造法则 → 该法则如何约束后续。
+   题材标签不能代替「这条法则缺了故事会换」。

-2. 支撑点不是完整设定
-   同一元素可有很多面向，本步只描述承担支撑功能的那一面。
-   例：「丈夫」可有职业、外貌、童年；若核心体验只依赖认知过滤，本步只写认知过滤如何运作及支撑了什么，不补完整人物小传。
+2. 法则不是完整设定
+   同一设定可有很多面向，本步只写「当作已经成立、后续必须认」的那一面。钉的就是这类既成事实整句，不顺着去补体系百科：
+   这个世界没有花里胡哨的魔法，只有繁衍到极致的斗气。
+   这个西幻世界里，男尊女卑是常态。
+   这里以三国杀高手为尊。

 3. 以缺失后果检验必要性
-   每个支撑点至少能回答其一，最好两个都能答：
-   - 它如何让某项核心体验产生、增强或持续？
-   - 缺少它以后，哪项核心体验会消失、减弱或改变性质？
-   只能回答「更丰富」「一般都会有」「以后可能用得上」的，不是本步核心支点。
+   每条法则至少能回答：拿掉以后，故事骨架会换成哪一个？只能回答「更丰富」「以后可能用得上」的，不纳入。

-4. 机制可以是不同性质的切面
-   不必都是世界法则，也不必形成统一机械系统。可以是：
-   角色的认知/欲望/能力/限制/心理张力；关系结构；社会制度/习俗/权力/信息条件；
-   环境物理/空间/资源；被直接承认的超常前提；约束/循环/反馈；反衬/代价/对照。
-   按体验所需识别性质，不把所有支点强行改写成规则。
+4. 本步写的是第一初设定，不是人物或舞台
+   可以是：被直接承认的超常前提、已完成的世界变造（繁荣一统）、约束性公理（黑暗森林、三定律）、体系性硬规则（修炼境界）。
+   人物个性、身份特殊、开场处境、地理社会展开，交给舞台 / 实例 / 开场白。

 5. 基准世界只作内部校验
   思考阶段判断「什么可能存在」，不要写入产物。最小充分继承：
@@ -102,12 +94,12 @@ summary：`实现机制 · …`（点题主要支撑）。
   - 具体作品世界：优先最近一层作品设定；原作未定义处再参考其底层世界。
   - 类型世界：只继承与当前体验有关的类型约定，不带入类型全部常见元素。
   - 从头创造：显式设定优先；未定义处用最少量常识基础。
-   - 混合或二创：只处理与当前支撑点有关的继承与变造，不整理完整谱系。
-   变造可表现为情境极端化、既有效果强化或新增法则。候选超出已知可能性时不要暗中加入；先确认变造是否本在用户设想中。
+   - 混合或二创：只处理与当前法则有关的继承与变造，不整理完整谱系。
+   候选超出已知可能性时先确认变造是否本在用户设想中，不暗中加入。

-6. 初始设定可以不解释来源
-   解释「它怎样支撑体验」，不要求「宇宙为什么会有它」。
-   超常前提、社会常态或人物特性可作为初始事实成立；不要为显得严谨而补起源、发明者、历史沿革或伪科学理论，除非这些本身就是核心体验的支撑。
+6. 法则可以不解释来源
+   写清「它怎样约束故事」，不要求「宇宙为什么会有它」。
+   不为显得严谨而补起源、发明者、历史沿革或伪科学理论，除非「追查来源」本身就是这条法则要支撑的体验。

 7. 按真实复杂度描述
   一句话能说清就用一句话；否则才按过程、张力、层次、构成、循环或关系网展开。
@@ -263,7 +255,7 @@ summary：`实现机制 · …`（点题主要支撑）。
 - [ ] 依据的核心体验忠实来自上游，非本步新设计？
 - [ ] 每个支撑点有归属元素、切面、如何支撑、缺失后果？
 - [ ] 自评含覆盖度 / 充分度 / 克制度？
- [ ] 未写成设定菜单、人物卡、起源史、叙事指南与故事推进、order 表？
+- [ ] 未把身份/开场处境写成法则？未写成设定菜单、人物卡、起源史、order 表？
 - [ ] 宁少勿多；支撑点关系仅保留有体验作用的项（可空）？
 - [ ] 追问只打会改变支点的缺口，带建议选项？
 ```
@@ -272,23 +264,23 @@ summary：`实现机制 · …`（点题主要支撑）。

 ```examples
 好：
- brief「秘密靠丈夫认知过滤与证据逼近维持」；正文有依据体验 + 支撑点（认知切面过移除检验）+ 覆盖检验；自评三维（覆盖/充分/克制）；追问用短场景打待探。
- 循环支点「力量与自我侵蚀同步」：展开诱因/收益/代价/反馈；与「身边人延迟识别」写进支撑点关系。
+- brief「现代都市认修炼境界与繁荣一统」；正文有依据体验 + 支撑点（修炼可越级、世界已一统）过移除检验；自评三维；无宗门百科。
+- 公理支点「黑暗森林」：一句话钉「猜到即打击」；不写宇宙社会学论文。
 - 整份落在 context-fragment.v1；支撑点切片示例：

 {
-  "名称": "丈夫的认知过滤",
-  "归属元素": "丈夫",
-  "支撑切面": "面对威胁完美家庭信念的证据时，优先采用无害解释",
-  "切面形态": { "结构": "一句话", "概述": "维护既有信念的认知过滤，而非单纯迟钝。", "展开": [] },
-  "对应体验": ["秘密长期存在", "濒临暴露的紧张"],
-  "如何支撑": "可疑证据可出现而不立刻终结秘密。",
-  "缺失后果": "若能直接识别证据则秘密速终；若永无证据则紧张消失。",
+  "名称": "黑暗森林",
+  "归属元素": "宇宙公理",
+  "支撑切面": "暴露坐标即招来打击，文明默认隐藏",
+  "切面形态": { "结构": "一句话", "概述": "被承认的既成法则，不解释为何如此。", "展开": [] },
+  "对应体验": ["猜疑链下的生存紧张"],
+  "如何支撑": "后续情节不能靠「对外广播求援」轻松收场。",
+  "缺失后果": "若可公开求援而不被打击，故事从藏匿改成外交。",
  "完备度": "90%"
 }

 坏：
 - 设定菜单：「可选诅咒/寄生物/邪神…」
- 人物卡膨胀；叙事文风；无必要起源史
+- 把普通大学生的身份特殊写成法则；起源史、人物卡、舞台百科
 - 只有散文支点、无 schema / 自评 / 追问
 ```
@@ -12,14 +12,15 @@ name: 叙事指南与故事推进
 id: narrative
 artifact: 设计.叙事指南与故事推进
 declaration: >
-  一次钉清写法与推进：遣词、笔墨、禁忌、示范，以及故事如何往前（可含变量钩子）；
-  不重做美学感觉问卷；整份双挂转述与主世界层
+  美学已有方向时：把感觉落成可执行的遣词、笔墨落点、禁忌与推进方式；不重做体验问卷
 when: |
-  已有美学纲领，需要把感觉落成可执行的写法与推进时。
+  已有美学纲领（或等价），但转述/主世界层仍会不知道这四件：遣词什么味道、笔墨落谁身上、绝对不能写什么、故事靠场面自己推还是等用户。
+  用户主动谈文风、措辞禁忌、写法档（官能/爽文/恐怖/情色等）也排。
 when_not: |
  美学未钉 → 先「美学纲领与交互范式」。
-  版式/监控栏 → 「正文组成」/「设计监控栏」。
-  事件池 schema / side_effects → 「生成规则」/「变量设计」。
+  用户只要感觉/站位、不要文风细则 → 不排，沿用美学。
+  版式/壳 → 「正文组成」；每轮看什么（字数/变量/日期）→ 「回复呈现」。
+  事件池 schema、真值增减 → 「生成规则」/「变量设计与更新规则」。
 boundary: |
  本技能：一份 context-fragment，写清怎么写 + 怎么推；不必拆技能、也不必为省 token 做精细双投影。
  美学：感觉与轮转。生成规则/变量*：合同与表。
@@ -33,6 +34,9 @@ feeds: narrator,gm

 1. 像什么文风？遣词什么味道？笔墨花在谁身上？有什么绝对不能写？
 2. 故事往前靠什么：场面自己推、等用户决策，还是无专门推进？正文若有几种写法档要切换（官能 / 爽文 / 恐怖 / 情色这类），点名即可；没有就说没有。
+3. 用户每轮输入怎么用？未提及时按体验二选一写入（可简短确认，不必当缺口追问）：
+   - **大纲扩写**（写手/成稿向）：输入＝待扩写为事实的大纲；细化完全后写正文；不超出大纲未涉及的剧情，完整演绎大纲。
+   - **扮演停笔**（代入扮演、等用户决策）：用户本轮行为与对话作正文开头并扩写填满；不可写用户角色未给出的其它行为/对话；不可替用户角色做决定；正文停在其他角色等用户角色回应之刻。
 ```

 ## task
@@ -46,8 +50,13 @@ mount：`narrator` 与 `world-simulator` 都挂同一份全文——不要为省
 执行顺序：
 1. 继承美学体验与禁忌，改写成做法向句子。
 2. 写纲领、遣词（含示范）、笔墨焦点、禁忌/不偏好。
+   遣词用户未提段落形态时，默认写入：完整长自然段叙述，不要单句成段（篇幅数字交给「回复呈现」）。
 3. 情境备用 = 写法档（体裁/调性容器），不是具体桥段。有切换则每条写：名字=档名（如「官能小说」「网文爽文」「展示恐怖」「展示情色」），用法=该档怎么遣词、笔墨落哪、何时切进来。无切换则 `[]`。用户若报出「当众折辱」「独处一室」这类场合，升一档写进对应写法档，场合本身不单列。
 4. 写推进与决策（可写「无专门推进」）；变量只写钩子。
+   「用户输入用法」未提及时：按美学/交互范式选一种写入产物——
+   - 写手/大纲成稿 → **大纲扩写**（输入＝大纲→细化成正文；不越界、完整演绎）；
+   - 代入扮演、轮转等用户决策 → **扮演停笔**（输入的行为与对话作正文开头并扩写填满；不写用户角色未给出的行为/对话；不替用户角色做决定；停在其他角色等回应之刻）。
+   两种都像则写进追问让用户点一次；不要混成半套规则。
 5. 自评 + 追问。

 summary：`叙事指南与故事推进 · …`
@@ -58,9 +67,14 @@ summary：`叙事指南与故事推进 · …`
 ```principles
 1. 感觉 vs 做法：美学写要什么爽；本步写怎么遣词、笔墨落哪、故事怎么推。
 2. 遣词与禁忌要可执行；绝对禁忌 ≠ 不偏好。
+   用户未提及时：完整长自然段，不要单句成段。
 3. 推进可轻可无；表规格交给变量/生成规则。
+   用户输入用法两套可选默认（未提及时择一，勿混用）：
+   - 大纲扩写：输入＝大纲→扩写为事实→细化后正文；不发明大纲未涉及的剧情，完整演绎大纲。
+   - 扮演停笔：用户本轮行为与对话→正文开头并扩写填满；禁止描述用户角色未输入的其它行为/对话；禁止替用户角色做决定；正文停在其他角色需要用户角色回应之刻。
 4. 情境备用是写法档：名字用「官能小说」「网文爽文」「展示恐怖」「展示情色」同级；用法写该档遣词与何时切入。无切换则空数组。
 5. 整份双挂即可；禁止拆成两个技能。
+6. 字数区间归「回复呈现」；本步管怎么写与怎么推，不重钉字数。
 ```

 ## probe
@@ -70,10 +84,14 @@ summary：`叙事指南与故事推进 · …`

 已在美学写清的感觉改写成做法向句子，不重问「想感受到什么」。

-缺其中一件：在产物「追问」写 1～2 点（建议选项 + 短句示例）。四件够验收：`追问.题目` 为 `[]`。推进方式不明则正文写「无专门推进」，不问好感公式、进度表或事件池。
+用户未提段落形态时：写入长自然段默认并简短确认即可。
+用户未提输入用法时：按体验选「大纲扩写」或「扮演停笔」写入产物并简短确认；两者都像才追问二选一，不必当成大缺口。
+
+缺遣词/笔墨/禁忌/推进其中一件：在产物「追问」写 1～2 点（建议选项 + 短句示例）。四件够验收：`追问.题目` 为 `[]`。推进方式不明则正文写「无专门推进」，不问好感公式、进度表或事件池。

 用户谈到变量增减、生成规则、舞台百科：只抽取能改遣词 / 禁忌 / 推进方式的一句，其余写入「开放问题」。
 用户提到要换写法：收成写法档写入「情境备用」（官能 / 爽文 / 恐怖 / 情色这类），不追问具体场合怎么摆；没提则 `[]`。
+字数问「回复呈现」；本步不追问字数。
 ```

 ## output
@@ -120,12 +138,14 @@ summary：`叙事指南与故事推进 · …`
    "推进与决策": {
      "有无专门推进": "有|无",
      "驱动力来源": "…",
+      "用户输入用法": "择一写入。大纲扩写：输入＝待扩写为事实的大纲；细化后写正文；不超出大纲未涉及处，完整演绎。扮演停笔：用户本轮行为与对话作正文开头并扩写填满；不可写用户角色未给出的其它行为/对话；不可替用户角色做决定；停在其他角色等用户角色回应之刻。用户另定则改写",
      "叙事速度与详略": "…",
      "成败与难度": "…",
      "变量门控钩子": []
    },
    "内容与表达": {
      "视角执行": "…",
+      "段落形态": "默认：完整长自然段叙述，不要单句成段；用户另定则改写",
      "场景详略映射": ["…"]
    }
  },
@@ -157,6 +177,6 @@ summary：`叙事指南与故事推进 · …`
 ## examples

 ```examples
-好：一次钉清遣词 + 笔墨落点 + 禁忌；推进写「等用户决策」或「无专门推进」；情境备用是「展示情色」「网文爽文」两档及切换时笔墨。
-坏：拆成「文风技能」和「推进技能」两步；追问好感公式 / 事件池；或把「当众折辱」「独处一室」当成情境备用。
+好：一次钉清遣词 + 笔墨落点 + 禁忌；推进写「等用户决策」或「无专门推进」；输入用法按体验钉「大纲扩写」或「扮演停笔」之一；情境备用是「展示情色」「网文爽文」两档及切换时笔墨。
+坏：拆成「文风技能」和「推进技能」两步；把两套输入用法混成半套；追问好感公式 / 事件池；或把「当众折辱」「独处一室」当成情境备用。
 ```
@@ -12,19 +12,18 @@ name: 开场白与开场变量
 id: opening-setup
 artifact: 设计.开场白与开场变量
 declaration: >
-  创作终节点：写出 1～多条遵循正文组成/叙事/监控栏契约的开场白，并钉与之同真相的开场变量初值；
-  选定后程序落库、结束创作并保存定稿
+  创作终节点：写出 1～多条开场白并钉同真相初值；选定后落库、结束创作并保存定稿
 when: |
-  体验、舞台、叙事、变量（若有）、正文组成、细化终稿等已大致可引用，
-  需要可开玩的第一段剧情与初始真值快照时；排在收成链之后，作为最后一步。
+  收成链已齐（至少体验契约可引用，且「细化终稿」已产出或可立即收成运行规格），需要可开玩的第一段剧情与同真相初值。
+  排在收成之后作最后一步。用户要进游玩但还没有第一屏 → 排。
 when_not: |
-  体验/呈现仍混沌 → 先美学与正文组成等。
-  只要改文风不要开场 → 叙事指南。
-  只要改真值规则不要开场文 → 变量设计。
-  尚未细化终稿、Worker 集未齐 → 先收成。
+  体验/呈现仍混沌 → 先「美学纲领与交互范式」与「回复呈现」「正文组成」等。
+  只要改文风不要开场 → 「叙事指南与故事推进」。
+  只要改真值规则不要开场文 → 「变量设计与更新规则」。
+  运行规格未齐 → 先「细化终稿」。尚未选定开场前若要补前序节点（如 NPC）→ 插在本步之前，勿以「收口已排入」拒绝追加。
 boundary: |
-  本技能是创作终节点：1～多条开场正文（按正文组成块序）+ 开场变量初值 + 可选监控栏初值示意。
-  必须遵守已验收的叙事指南、正文组成、监控栏、变量设计；不重做这些契约。
+  本技能是创作终节点：1～多条开场正文（按回复呈现清单 + 正文组成展示）+ 开场变量初值。
+  必须遵守已验收的叙事指南、回复呈现、正文组成、变量设计；不重做这些契约。
  具体实例：开场可引用已有实例名片，不在本步新造百科。
  选定后由程序写入 输出.开场白 / 运行.初始变量 / 变量.当前，关闭 DAG 并保存定稿；不要在本步之后再排其它能力。
 feeds: narrator
@@ -0,0 +1,138 @@
+# 随机范围整理
+
+> 技能文档。程序只切割下方 **fence 块**；`##` 标题仅供人读。  
+> 产物外壳：`docs/context-fragment-design.md`。  
+> 本步把上游已定的检定/对抗/掷骰需求，收成一份**程序可插入的随机值范围表**；不发明新裁定法则。  
+> 游玩期：程序按本表每轮往消息里塞备用随机数（前端折叠隐藏、用户看不见，发给 AI 时仍在上下文）；主世界层直接用表中本次数，不再单独「机遇裁定」槽。
+
+## meta
+
+```meta
+name: 随机范围整理
+id: random-range
+artifact: 设计.随机范围整理
+declaration: >
+  上游已有检定/对抗/掷骰需求时：汇总全部要用的随机项与取值范围（含表达式），供程序每轮插入备用随机数；排在正文组成之前
+when: |
+  机制/生成规则/变量/叙事等上游已出现需要随机数的内容（对抗、检定、抽签、伤害区间等），且尚未收成一份范围表。
+  排在「正文组成」之前（通常紧挨其前；回复呈现可并行或略前）。
+when_not: |
+  全程不靠随机数推进 → 不排。
+  还在定「怎么裁定 / 公式本身」→ 先「实现机制」「生成规则」或「变量设计与更新规则」；本步只汇总已定需求。
+  只谈前端怎么藏、选壳美化 → 「正文组成」。
+  只谈每轮可见区域与字数 → 「回复呈现」。
+boundary: |
+  本技能：一份清单——每项随机用途、范围或表达式（如力量*5～*10、敏捷检定 1～100）、本轮建议备用条数。
+  不写新裁定法则、不写骰子剧情；法则来自上游，此处只整理成程序可读范围。
+  游玩拓扑：不再开「机遇裁定」槽；真随机靠本表 + 程序插入上下文。
+  正文组成：负责把隐藏备用区接到壳/消息里——本步只交「要插什么数」。
+feeds: gm,narrator
+```
+
+## opening
+
+```opening
+把本局所有要用的随机数收成一张表（想到什么写什么）：
+
+1. 上游里哪些地方要掷 / 检定 / 抽区间？（对抗、伤害、事件抽签……）
+2. 每一项的取值范围或表达式？（例：敏捷检定 1～100；攻击伤害＝力量×5～×10）
+3. 每轮消息大概要预先塞几条备用？（够用即可，不要灌爆）
+```
+
+## task
+
+```task
+你正在执行「随机范围整理」。产物必须是 **context-fragment.v1** JSON，写入「设计.随机范围整理」。
+
+本步只做一件事：把上游已定、游玩时会用到的随机需求，整理成程序可插入的范围表。
+禁止重议「要不要检定」「公式对不对」——缺则追问上游或写进开放问题；本步不发明新法则。
+
+执行顺序：
+1. 扫机制 / 生成规则 / 变量 / 叙事 / 美学：列出所有「需要随机数才能裁定」的点。
+2. 每项写清：用途短名、范围或表达式（相对变量/表字段时写清引用）、单位（整数 d100 / 闭区间等）。
+3. 钉本轮建议备用条数（按项或全局）；够本轮最坏情况即可。
+4. 无随机需求则本步不应被排；若误进：正文写空清单并说明「无需随机」。
+5. 自评 + 追问；输出 JSON。
+
+summary：`随机范围整理 · {项数或主要用途}`。
+```
+
+## principles
+
+```principles
+1. 只汇总，不定新法。范围与表达式必须能追溯到上游已验收产物。
+2. 表达式写给人与程序都能读：`力量*5～*10`、`1～100`、`池权重抽 1`——忌散文。
+3. 一项一类用途；不要把「战斗」糊成一条却含三种掷法。
+4. 备用条数服务「本轮上下文预插入」；宁少可补，勿一次塞上百。
+5. 不输出机遇裁定槽、不写 chance tool 调用说明。
+```
+
+## probe
+
+```probe
+每轮 1～2 点：某项范围是否仍是散文；表达式引用的变量/表是否未在上游出现；有无漏掉已声明的检定。
+不追问：壳怎么藏、CSS、文风、要不要主世界层。
+全程明显无随机：确认不排即可，不必硬凑表。
+```
+
+## output
+
+```output
+{
+  "schema": "context-fragment.v1",
+  "技能": "随机范围整理",
+  "brief": "一句话：收了哪些随机项",
+  "mount": ["world-simulator", "narrator"],
+  "稳变": "stable",
+  "正文": {
+    "依据": ["上游机制/生成规则/变量/叙事中与随机相关的要点"],
+    "插入意图": "程序按本表每轮往消息隐藏区插入备用随机数；裁决时只用上下文已有数，不另开机遇槽",
+    "项": [
+      {
+        "id": "agility-check",
+        "用途": "敏捷检定",
+        "范围": "1～100",
+        "表达式": null,
+        "来源": "实现机制·… / 变量·…",
+        "每轮备用条数": 3
+      },
+      {
+        "id": "attack-damage",
+        "用途": "攻击伤害",
+        "范围": null,
+        "表达式": "力量*5～*10",
+        "来源": "变量设计·力量 / 机制·对抗",
+        "每轮备用条数": 2
+      }
+    ],
+    "全局备用上限": "可选；防止灌爆上下文的软上限"
+  },
+  "自评": {
+    "维度": [
+      { "名": "覆盖", "分数": 8, "说明": "上游随机点是否收齐" },
+      { "名": "可执行", "分数": 8, "说明": "范围/表达式是否可直接插数" }
+    ],
+    "薄弱点": ""
+  },
+  "追问": { "导语": "", "题目": [] },
+  "开放问题": []
+}
+```
+
+硬规则：合法 JSON；`项` 可 `[]`（仅当误排且确认无随机）；有项则每项须有用途 +（范围或表达式至少一者）；禁止 order；summary 见 task。
+
+## checklist
+
+```checklist
+- [ ] 每项都能对上上游，没有本步新发明的裁定？
+- [ ] 范围/表达式短且可插数？
+- [ ] 未要求机遇裁定槽或 chance tool？
+- [ ] 排在正文组成之前的意图是否写进 brief/插入意图？
+```
+
+## examples
+
+```examples
+好：两项——敏捷 1～100（备用 3）；攻击伤害 力量*5～*10（备用 2）；插入意图写清隐藏备用区。
+坏：在本步新写一套战斗规则；或只写「战斗要掷骰」无范围；或指引去开 play_slots.chance。
+```
@@ -11,16 +11,15 @@ name: 细化终稿
 id: refine
 artifact: 设计.worker集
 declaration: >
-  按已勾选固定槽与「上下文投影排序」表收成可进游玩的规格：
-  play_slots、投影插入序、常驻上下文、表与副作用；不发明新执行单元
+  按已勾选槽（或默认槽）与投影排序表收成运行规格；不发明新执行单元
 when: |
-  前面技能已大致谈清（至少有体验契约；槽已勾选或可按默认；
-  若已有多块上下文则宜先有投影排序表），需要输出「设计.worker集」JSON 时；
-  编排应将流程 status 导向 closed。
+  至少体验契约可引用；槽已勾选或可按默认；若上下文块已多则宜先有投影排序表。
+  需要输出「设计.worker集」才能进游玩时排；编排应将流程导向 closed。
 when_not: |
-  体验站位未定 → 先上游。
-  拓扑未勾选且用户拒绝默认槽 → 先「游玩拓扑」。
+  体验站位未定 → 先「美学纲领与交互范式」。
+  不能吃默认槽且尚未勾选 → 先「游玩拓扑」。
  上下文块已多且稳/变未排序 → 先「上下文投影排序」。
+  只要改某一块设定长文 → 回头修改对应上游节点，不要用本步重写。
 boundary: |
  本能力：合并上游 → 完整运行规格 JSON（interaction、play_slots、context_order/inserts、
  workers 由槽展开、resident_context、tables）。
@@ -1,7 +1,7 @@
 # 正文组成

 > 技能文档。程序只切割下方 **fence 块**；`##` 标题仅供人读。  
-> **创作定位：基于固定呈现壳做适配微调**（`docs/play-presentation-shells.md`）。  
+> **创作定位：把「回复呈现」已钉的内容展示给用户**（选壳、美化排版，可写 CSS/HTML/JS）。壳介绍与规格写在各壳自己的文档，程序动态装载。  
 > 产物外壳：`docs/context-fragment-design.md`。  
 > 旧称：设计回复格式。

@@ -12,41 +12,33 @@ name: 正文组成
 id: reply-format
 artifact: 设计.正文组成
 declaration: >
-  基于七种固定呈现壳做适配微调（选 shell_id + 填字段/显示名/开关等）；
-  产出壳适配单；禁止从零发明布局或完整 UI
+  把「回复呈现」已钉的内容展示给用户：选壳、美化排版，可写 CSS/HTML/JS；有「随机范围整理」则把隐藏备用随机区接到消息；排在二者之后、开场白之前
 when: |
-  需要为本局选定呈现壳，或微调监控字段/块显示名/建议行动开关时；
-  或需要约定隐藏变量段时。
+  已有「回复呈现」（或等价：每轮终稿看什么已钉）后排。几乎每局都要。
+  若本局有随机需求：须已有「随机范围整理」（或确认无随机）后再排本步。
+  必须在「开场白与开场变量」之前。
 when_not: |
-  明确只要纯散文 → 可不排（运行时默认 prose）。
-  只谈文风 → 「叙事指南与故事推进」。
-  壳已定、只筛监控字段明细 → 「设计监控栏」。
-  不要在本步设计新布局或写 CSS。
+  还不知道每轮给用户看什么 → 先「回复呈现」。
+  已定要检定/掷骰但范围表未收 → 先「随机范围整理」。
+  不要排在开场白之后。几乎不跳过。
+  只谈文风遣词 → 「叙事指南与故事推进」。只改呈现区域与内容规则（字数/选项槽/监控键）→ 「回复呈现」。
 boundary: |
-  本技能：壳适配单（shell_id + 微调轴 + 块挂到壳已有区域）。
-  布局骨架只读：docs/play-presentation-shells.md。
-  设计监控栏：字段表细则。叙事指南：文风。变量设计：真值规则。
+  本技能：前端展示——从【可选呈现壳】选壳、把回复呈现的各区域落到版式、美化排版（可含 CSS/HTML/JS）；若有随机范围表，预留/接到隐藏备用随机区（用户看不见、发给 AI 仍在上下文）。
+  回复呈现：必选/可选区域 + 各区简单内容规则——本步不重议清单与规则，只负责怎么显示。
+  随机范围整理：要插哪些数、范围是什么——本步不改范围表，只负责怎么藏进消息。
+  叙事指南：文风。变量设计：真值规则。开场白：第一屏——本步先定展示。
 feeds: narrator
 ```

 ## opening

 ```opening
-本局在固定呈现壳上做适配（不是设计新界面）。
+本局把「回复呈现」里已钉的内容展示给用户（选壳、美化排版）。壳清单由程序动态装载，不要背死几种。

-0. 按「要同时看见什么」七选一：
-   · prose — 只要正文
-   · chat_monitor — 正文 + 扫状态
-   · spotlight — 大正文 + 弱状态
-   · turn_panel — 场面 + 交互物 + 行动
-   · split_board — 正文 ‖ 线索
-   · choice_dock — 局面 + 选项
-   · chapter_reader — 章正文 + 进度
-
-1. 要微调什么？（监控字段、块称呼、要不要建议行动、tone_chrome…）
-2. 有没有隐藏段给模型/程序维护变量？
-3. 定稿时会用前面情节架空一幕灌进壳里，专供你看版式/美化（内容随便，不当正史）。
-4. 不要谈「再发明一种全新布局」。
+1. 对照【可选呈现壳】：哪一个最适合放下已钉的那些东西？
+2. 各项落到壳的哪一区？显示名叫什么？
+3. 要不要额外的 CSS/HTML/JS 来美化（没有就说没有）？
+4. 定稿时会用前面情节架空一幕灌进壳里，专供你看版式/美化（内容随便，不当正史）。
 ```

 ## task
@@ -54,18 +46,17 @@ feeds: narrator
 ```task
 你正在执行「正文组成」。产物必须是 **context-fragment.v1** JSON，写入「设计.正文组成」。

-本步 = **壳适配单**：七种壳里选一个，只改允许的微调轴。
-权威：`docs/play-presentation-shells.md`。
-禁止从零设计分区、禁止自造 shell_id、禁止完整 CSS。
+本步 = **前端展示**：按「回复呈现」的清单，从【可选呈现壳】里选一个，把内容落到区域并美化排版。可写本局需要的 CSS/HTML/JS。
+禁止重议「看什么、正文多少字」；禁止自造目录没有的 shell_id。

 执行顺序：
-1. 读美学/叙事：继承人称与终稿归属；不重开文风问卷。
-2. **选 shell_id**；说明为何是这个壳而不是其它壳（主面积给谁）。
-3. 可见块：只挂到该壳已有区域；写显示名与职责（适配文案，不是新分区）。
-4. 监控栏：字段意图（细则可交「设计监控栏」）；无 monitor 的壳写「不启用」。
-5. 隐藏段（若有）：定界与用途。
-6. 填「呈现壳.微调」；前端拆分区域必须与壳一致。
-7. **示例**：用前面已定情节架空一幕，按本步壳与可见块灌进 `present.v1` 形状，专供验收版式/美化；示例文可短，游玩正文字数不在本步打磨。
+1. 读「回复呈现」与美学/叙事：清单是权威；不重开「看什么」问卷。
+2. **选 shell_id**（必须是【可选呈现壳】里的 id）；说明为何这个壳放得下清单里的项。
+3. 可见块：把清单各项挂到该壳已有区域；写显示名与职责。
+4. 需要时写「渲染」：本局 CSS/HTML/JS 片段（美化排版，不是新后端协议）。
+5. 隐藏段（若清单要求）：定界与用途。
+6. 填「呈现壳.微调」；分区必须与壳一致。
+7. **示例**：用前面已定情节架空一幕灌进 `present.v1`，专供验收版式/美化；字数以回复呈现为准，本步不重钉篇幅。
 8. 自评 + 追问；禁止写 context `order`。

 summary：`正文组成 · 适配 {shell_id} · …`。
@@ -74,21 +65,20 @@ summary：`正文组成 · 适配 {shell_id} · …`。
 ## principles

 ```principles
-1. 创作 = 选壳 + 适配微调
-   不是 UI 创意；布局骨架只读。本步验收重点是「看起来对不对」，不是故事写得好不好。
-   「按意见修改」：以最新产物为底；用户要求按先后都有效，冲突时以较新的为准。用户说整体可以、或只提美化/行距/显示名 → 不换 shell_id。换壳必须用户点名。
+1. 创作 = 把「回复呈现」的清单展示出来
+   选壳、分区、显示名、CSS/HTML/JS 都为那份清单服务。本步验收重点是「看起来对不对」。
+   「按意见修改」：以最新产物为底；用户要求按先后都有效，冲突时以较新的为准。用户说整体可以、或只提美化 → 不换 shell_id。换壳必须用户点名。

-2. 只改微调轴
-   字段、显示名、开关、tone_chrome、空态；不改分区、不增区域、不自造壳。
+2. 清单权威在「回复呈现」
+   正文篇幅、要不要日期、展示哪些变量，以那份产物为准。本步只决定怎么显示。

-3. 监控栏 ≠ 名片卡
-   只盯会变、影响决策或沉浸的信息。
+3. 壳是底，渲染可加
+   从【可选呈现壳】选底。需要时写本局 CSS/HTML/JS 做美化；不要发明新的后端协议或目录没有的壳。

 4. 隐藏段服务维护，不污染阅读

 5. 与转述、变量分工
-   文风归叙事指南；真值归变量设计；本步只交壳适配契约。
-   游玩单轮用户主读正文默认 500～2000 字，写进「拼装与终稿.单轮正文篇幅」，供转述遵守。
+   文风归叙事指南；真值归变量设计；看什么归回复呈现；本步只交展示契约。

 6. 示例 = 壳与美化预览，非正史
   用已定材料随便架空一幕，把各区域/监控/行动坞撑满，让用户看见版式。
@@ -100,8 +90,8 @@ summary：`正文组成 · 适配 {shell_id} · …`。
 ```probe
 每轮 1～2 点。

-优先：选哪个壳；微调哪些字段/显示名；隐藏段要不要；示例灌数是否让版式看得清。
-不追问：新布局、完整 CSS、事件池 schema、文风遣词、示例文笔好坏。
+优先：壳能否放下回复呈现的各项；分区与显示名；要不要 CSS/HTML/JS。
+不追问：重议字数/变量清单、事件池 schema、文风遣词、示例文笔好坏。
 ```

 ## output
@@ -115,10 +105,10 @@ summary：`正文组成 · 适配 {shell_id} · …`。
  "稳变": "stable",
  "正文": {
    "依据的体验与呈现": [
-      "从美学/叙事继承的呈现要点"
+      "从回复呈现继承的清单 + 美学/叙事呈现要点"
    ],
    "呈现壳": {
-      "shell_id": "prose|chat_monitor|spotlight|turn_panel|split_board|choice_dock|chapter_reader",
+      "shell_id": "必须与【可选呈现壳】某一 id 一致",
      "为何选它": "一句话",
      "微调": {
        "tone_chrome": "messenger|terminal|book|default",
@@ -136,20 +126,18 @@ summary：`正文组成 · 适配 {shell_id} · …`。
        "职责": "这块给用户什么信息",
        "顺序": 1,
        "可空": true,
-        "填充方": "叙事转述|程序拼装|监控栏|其它",
+        "填充方": "叙事转述|程序拼装|回复呈现变量|其它",
        "内容形态": "散文|短列表|键值行|其它",
        "示例": "可选：该块一句占位（总预览见正文.示例）"
      }
    ],
-    "监控栏锚点": {
-      "本局是否启用": "是|否",
-      "在可见块中的块id": "若启用则指向可见块之一",
-      "职责摘要": "盯哪些类信息",
-      "字段草稿": [
+    "呈现清单落实": {
+      "依据的回复呈现": "brief 或要点",
+      "各项落到": [
        {
-          "名": "会变且值得盯的字段",
-          "为何监控": "决策/沉浸理由",
-          "来源意图": "真值|投影|临场生成"
+          "清单项": "正文|日期|某变量|建议行动|…",
+          "区域": "monitor|header|body|footer|aside|hidden",
+          "显示名": "可空"
        }
      ]
    },
@@ -171,16 +159,21 @@ summary：`正文组成 · 适配 {shell_id} · …`。
          "区域id": "monitor|header|body|footer|aside",
          "对应块id": ["…"],
          "意图": "固定顶栏|主滚动|折叠文末|…",
-          "渲染提示": "纯文本|Markdown；勿写完整工程"
+          "渲染提示": "纯文本|Markdown|自定义"
        }
      ],
+      "渲染": {
+        "html": "可选：本局结构片段；无则空字符串",
+        "css": "可选：本局样式；无则空字符串",
+        "js": "可选：本局交互；无则空字符串"
+      },
      "说明": "无分区则写「单流渲染」（通常 prose）"
    },
    "拼装与终稿": {
      "终稿tag": "通常 输出.用户展示",
      "拼装方": "叙事转述一次写出各块|程序按块拼接|混合",
      "推荐灌数": "分块壳优先 present.v1；prose 可为纯 Markdown",
-      "单轮正文篇幅": "默认 500～2000 字（汉字，写入 body）；短于 500 仅当用户明确要求极短",
+      "单轮正文篇幅": "以回复呈现的字数为准，本步不重钉",
      "与裁决包关系": "转述读 settlement 再填各块；隐藏段可含 variable_changes 镜像"
    },
    "示例": {
@@ -211,14 +204,14 @@ summary：`正文组成 · 适配 {shell_id} · …`。
        "说明": "用户该看见的块是否齐、顺序是否服务体验"
      },
      {
-        "名": "监控克制",
+        "名": "清单落实",
        "分数": 8,
-        "说明": "监控栏是否只盯会变信息（若无监控栏可 N/A）"
+        "说明": "回复呈现的各项是否都落到壳区域"
      },
      {
        "名": "可实现",
        "分数": 8,
-        "说明": "shell_id 是否在七种壳内；分区与隐藏段是否可交给转述/程序"
+        "说明": "shell_id 是否在【可选呈现壳】内；分区与隐藏段是否可交给转述/程序"
      },
      {
        "名": "版式可感",
@@ -244,22 +237,22 @@ summary：`正文组成 · 适配 {shell_id} · …`。

 硬规则：
 1. 合法 JSON；含公共三段外壳。
-2. 正文须含 `呈现壳.shell_id`（七种之一）与 `微调`；可见块只挂壳已有区域。
-3. `可见块` 至少 1 条（通常含 body）；禁止自造区域 id / 第五种壳。
+2. 正文须含 `呈现壳.shell_id`（须在【可选呈现壳】内）与 `微调`；可见块只挂壳已有区域。
+3. `可见块` 至少 1 条（通常含 body）；禁止自造区域 id / 目录没有的壳。
 4. 正文须含 `示例`：`性质` 标明非正史；`灌数` 为 `present.v1`，`shell` 与本步 shell_id 一致；只填该壳已有区域。
 5. 示例内容可糙：只为验收壳与美化；禁止当开场白/正史；禁止为示例新造设定。
-6. 禁止程序 API schema、context `order`、完整 CSS。
-7. 自评：可见完备 / 监控克制 / 可实现 / 版式可感。
+6. 禁止程序 API schema、context `order`。需要美化时写本局 CSS/HTML/JS，不要另起后端协议。
+7. 自评：可见完备 / 清单落实 / 可实现 / 版式可感。
 8. summary：`正文组成 · 适配 {shell_id} · {brief 缩略}`。
 9. 兼容旧称产物 tag「设计.回复格式」。

 ## checklist

 ```checklist
- [ ] 是「选壳+微调」，不是从零设计布局？
- [ ] shell_id 在七种壳内？可见块未超出该壳分区？
- [ ] 微调轴已填或明确默认？监控栏未塞死名片字段？
- [ ] 隐藏段（若有）定界清楚？未写 CSS 工程？
+- [ ] 是把「回复呈现」的清单展示出来，而不是重议看什么？
+- [ ] shell_id 在【可选呈现壳】内？可见块未超出该壳分区？
+- [ ] 清单各项已落到区域？字数未在本步另定一套？
+- [ ] 隐藏段（若有）定界清楚？CSS/HTML/JS 只服务本局展示？
 - [ ] 有示例灌数（present.v1），壳一致、各区撑开，且标明非正史？
 - [ ] 未把示例写成开场白或打磨成长文？
 ```
@@ -268,14 +261,13 @@ summary：`正文组成 · 适配 {shell_id} · …`。

 ```examples
 好：
- 适配 chat_monitor：微调监控字段=好感/今日话题；body 显示名=「短信」；示例灌数把气泡区+监控撑开，文笔随便。
- 适配 chapter_reader：只开 header+body；aside 关；示例给短章头+一段 body。
- 适配 turn_panel：开 suggested_actions；监控只盯体力/好感；示例 meta 带 2～3 个占位行动。
+- 回复呈现要正文+好感：选 chat_monitor，好感进 monitor，正文进 body；可加短 CSS 美化芯片。
+- 回复呈现只要正文：选 prose；渲染可空。
+- 回复呈现要选项：选 choice_dock，示例 meta 带占位行动。

 坏：
- 「我们自定义一种左右分栏新界面」。
+- 本步重钉「正文 300 字」而回复呈现已经写了 800～1500。
 - 不写 shell_id，只写「要好看的 UI」。
- 监控栏列出姓名、性别等死设定。
 - 示例写成第一章正史，或为写好看新造未定设定。
 - 示例 shell 与呈现壳不一致，或灌了壳没有的区域。
 ```
@@ -1,89 +1,92 @@
-# 设计监控栏
+# 回复呈现

 > 技能文档。程序只切割下方 **fence 块**；`##` 标题仅供人读。  
-> 产物外壳：`docs/context-fragment-design.md`；字段筛选气质对齐「生成规则」属性妥当。  
-> 旧称：设计状态栏。更名因：这里盯的是**会变、要监控的信息**，不是名片式「状态展览」。
+> 产物外壳：`docs/context-fragment-design.md`。  
+> 旧称：设计监控栏 / 设计状态栏。  
+> 本步钉：**每轮终稿有哪些区域（必选/可选）**，以及各区域的**简单内容规则**；不排版、不选壳。

 ## meta

 ```meta
-name: 设计监控栏
+name: 回复呈现
 id: status-bar
 artifact: 设计.监控栏
 declaration: >
-  钉用户可见监控栏字段：只留会变、影响决策或沉浸的信息
-  （主角状态/攻略目标/场景可交互对象等）；不进姓名性别等死字段
+  几乎每局都要：钉每轮终稿的必选/可选区域，以及各区域的简单内容规则（字数、段落、选项怎么组成等）；不排版
 when: |
-  「正文组成」已启用监控栏，或体验需要持续可见的监控信息时；
-  需要逐字段筛「该不该监控」时。
+  舞台/世界/变量等上游大致齐后排。几乎每局都要。
+  排在「正文组成」之前：先钉有什么区域、各区怎么写，再交给正文组成去展示。
 when_not: |
-  明确不要 HUD/监控条 → 不排。
-  版式块序未定、连有没有监控栏都不清 → 先「正文组成」。
-  真值如何增减 → 「变量设计与更新规则」（本步只选展示哪些）。
-boundary: |
-  本技能：监控栏字段清单、来源意图、刷新与可见条件；产出 context-fragment.v1。
-  正文组成：监控栏在整轮版式中的位置——本步不重排其它块。
-  变量设计：真值与 side_effects——本步可引用字段名，不写更新公式。
-  生成规则：内容表 schema——监控栏不是生成实例表，但同样忌冗余字段。
+  上游还没齐 → 先那些。
+  只谈怎么排版、选壳、CSS/HTML/JS → 「正文组成」。
+  只谈文风遣词 → 「叙事指南与故事推进」。
+  检定/掷骰范围汇总 → 「随机范围整理」。
+  变量如何增减 → 「变量设计与更新规则」（本步只定展示哪些、展示规则）。
+boundary: >
+  本技能：区域清单（必选/可选）+ 各区域简单内容规则（字数、自然段、选项槽位与提示口径等）。
+  正文组成：如何把这些区域展示给用户（壳、美化、CSS/HTML/JS）——本步不定版式。
+  随机范围整理：隐藏备用随机数表——本步不收范围。
+  变量设计：真值与更新——本步可点名要展示的键与监控规则，不写增减公式。
 feeds: narrator
 ```

 ## opening

 ```opening
-这一局监控栏要让用户盯住什么？（想到什么写什么）
+每轮最终回复要分哪些区域？（想到什么写什么）

-1. 监控对象是谁/哪一层？
-   例：主角生存资源；攻略目标态度；当前场景可交互对象；任务进度……
-
-2. 哪些数字或短状态会变、且变了会影响你下一步？
-   不要列几乎不变的名片（姓名、性别等——绝大多数局都不需要）。
-
-3. 刷新节奏？每轮都刷，还是事件后才变？
+1. 必选：正文——字数、段落形态？未提及时默认：约 1000～2000 字；完整长自然段，不要单句成段。
+2. 要不要状态/变量监控（如开头日期、好感）？盯哪些键？
+3. 要不要选项栏？若要：几个槽、各自什么气质（如 A 冒险 / B 稳重），生成选项时遵守什么提示？
+4. 要不要可选块：小故事旁支、线索条等？没有就说没有。
 ```

 ## task

 ```task
-你正在执行「设计监控栏」。产物必须是 **context-fragment.v1** JSON，写入「设计.监控栏」。
+你正在执行「回复呈现」。产物必须是 **context-fragment.v1** JSON，写入「设计.监控栏」。

-监控栏 = 用户可见的**监控**区：只放有用、会变的信息。
-可含：主角资源/状态、攻略目标状态、当前场景可交互对象等——按体验需要选，不默认堆满。
+本步做两件事：
+1. **区域**：每轮终稿有哪些块——哪些必选、哪些可选。
+2. **简单规则**：每个启用区域怎么生成/填写（字数、自然段、选项槽与提示口径、监控键等）。
+
+不选壳、不写 CSS/HTML/JS、不排版。展示交给「正文组成」。
+
+默认必选：`正文`。用户未点名正文规格时，采用默认规则：
+- 字数约 **1000～2000**；
+- **完整长自然段叙述，不要单句成段**。
+用户另有要求则以用户为准。
+
+常见可选：`状态监控`（日期、变量芯片等）、`选项栏`、`小故事`（旁支短文）等——按体验增减，不要堆满。

 执行顺序：
-1. 读正文组成（若有）与变量设计：继承栏位位置与已有真值名。
-2. 逐字段过筛（同生成规则「属性妥当」）：对本局是否值得监控？不变的名片字段删除。
-3. 写清每字段：名、为何监控、来源意图、可见条件、展示形态（短文本/数值/列表）。
-4. 写刷新时机与空态（无目标/无交互物时显示什么）。
-5. 自评 + 追问；输出 JSON。
+1. 读美学/叙事/变量/舞台：继承体验与已有真值名。
+2. 钉必选区域：至少含正文；写清内容规则。未提及时用默认（1000～2000 字；长自然段、勿单句成段）。
+3. 逐个判定可选区域：要则写规则；不要则不进清单（可在「刻意不启用」说明）。
+4. 若开选项栏：钉槽位数、各槽气质/组成规则、生成时的短提示口径（供转述遵守）。
+5. 若开状态监控：点名键、形态、刷新意图；不写变量增减公式。
+6. 自评 + 追问；输出 JSON。

-summary：`设计监控栏 · …`（点题监控对象）。
+summary：`回复呈现 · …`（点题必选+主要可选）。
 ```

 ## principles

 ```principles
-1. 监控 ≠ 角色卡
-   姓名、性别、种族等几乎不变内容默认排除（除非玩法就是改性别/改名且必须盯）。
-
-2. 只留有用消息
-   能回答：变了以后用户会不会改决策或沉浸感？不能则删。
-
-3. 对象可以多层
-   不限于「主角状态」：攻略目标、场景可交互列表、世界危机进度等都可进栏——但每层字段仍要克制。
-
-4. 来源可追溯
-   字段应能指向真值、投影或临场短生成；禁止无来源的装饰假数。
-
-5. 展示短
-   监控栏不是正文；长描写放叙事，栏内短标签/数字/一行列表。
+1. 区域 = 用户每轮会看见的内容槽；规则 = 槽里怎么写。两者都在本步钉死。
+2. 正文默认必选。其它区域默认可选：有体验需要才开。
+3. 规则要可执行、宜短：字数、自然段、选项槽气质、监控键名——够转述与正文组成接上即可。
+   正文规格用户未提及时：字数 1000～2000；完整长自然段，不要单句成段。
+4. 选项栏的「选项由什么组成 / 各槽提示词」在本步规定，不推到叙事指南或正文组成。
+5. 不问「长什么样」。壳、分区、CSS/HTML/JS 交给「正文组成」。
+6. 展示用的变量是子集；增减仍归变量设计。
 ```

 ## probe

 ```probe
-每轮 1～2 点：缺哪类监控对象；某字段是否死字段该删；刷新过频还是过稀。
-不追问：整页 CSS、文风、完整变量更新公式。
+每轮 1～2 点：必选是否只剩正文；某可选区开了却没规则；选项槽气质是否空；正文段落/字数是否离谱。
+不追问：选哪个壳、CSS、文风遣词、变量更新公式。
 ```

 ## output
@@ -91,62 +94,92 @@ summary：`设计监控栏 · …`（点题监控对象）。
 ```output
 {
  "schema": "context-fragment.v1",
-  "技能": "设计监控栏",
-  "brief": "一句话：监控谁/什么",
+  "技能": "回复呈现",
+  "brief": "一句话：必选哪些区 + 开了哪些可选区",
  "mount": ["narrator"],
  "稳变": "stable",
  "正文": {
-    "依据": ["正文组成锚点 / 变量设计字段 / 体验需要"],
-    "监控对象": [
+    "依据": ["美学/叙事/变量/舞台里与「每轮看见什么」相关的要点"],
+    "必选区域": [
      {
-        "对象id": "pc|target|scene|world|…",
-        "名称": "主角|攻略目标|当前场景|…",
-        "为何出现在栏内": "…"
+        "id": "body",
+        "名称": "正文",
+        "规则": {
+          "字数": "默认 1000～2000；用户另定则从其",
+          "自然段": "完整长自然段叙述，不要单句成段",
+          "其它": "可选：人称、是否含对白密度等一句"
+        }
      }
    ],
-    "字段": [
+    "可选区域": [
      {
-        "名": "短名，用户可见",
-        "对象id": "归属上述对象",
-        "为何监控": "变了如何影响决策或沉浸",
-        "来源意图": "真值键名|投影tag|临场",
-        "类型示意": "number|string|short_list|enum",
-        "可见条件": "始终|某阶段|有目标时…",
-        "展示形态": "例：❤ 37；或一行「可交互：门、柜」",
-        "禁止原因若曾候选": "例：性别——不变，已剔除；无则空"
+        "id": "status",
+        "名称": "状态监控",
+        "启用": true,
+        "规则": {
+          "字段": [
+            {
+              "名": "日期|好感|…",
+              "来源": "真值键|投影|临场",
+              "形态": "短文本|数字|枚举"
+            }
+          ],
+          "刷新": "每轮|事件后"
+        }
+      },
+      {
+        "id": "choices",
+        "名称": "选项栏",
+        "启用": true,
+        "规则": {
+          "槽数": 2,
+          "槽": [
+            {
+              "槽id": "A",
+              "气质": "冒险",
+              "组成": "推进风险/探索的行动一句",
+              "生成提示": "写给转述：本槽选项须偏冒险、短、可点"
+            },
+            {
+              "槽id": "B",
+              "气质": "稳重",
+              "组成": "保守/观察/缓和的行动一句",
+              "生成提示": "写给转述：本槽选项须偏稳重、短、可点"
+            }
+          ]
+        }
+      },
+      {
+        "id": "side_story",
+        "名称": "小故事",
+        "启用": false,
+        "规则": {
+          "字数": "无则空",
+          "与正文关系": "旁支；不抢主线"
+        }
      }
    ],
-    "刻意不监控": [
-      "姓名、性别…及原因"
-    ],
-    "刷新": {
-      "时机": "每轮|事件后|变量边沿|手动",
-      "空态": "无数据时显示什么"
-    },
-    "与版式关系": "在正文组成中的块位置；若尚无正文组成则写建议位置"
+    "刻意不启用": [
+      "本局不开的区域及原因"
+    ]
  },
  "自评": {
    "维度": [
      {
-        "名": "属性妥当",
+        "名": "区域清楚",
        "分数": 8,
-        "说明": "逐字段：无死名片；该盯的生存/关系/场景信息未漏"
+        "说明": "必选/可选是否分明；下游能否直接按区展示与灌数"
      },
      {
-        "名": "克制度",
+        "名": "规则可执行",
        "分数": 8,
-        "说明": "字段是否够少、展示是否够短"
-      },
-      {
-        "名": "可接线",
-        "分数": 8,
-        "说明": "来源意图是否接得上变量/投影/正文组成"
+        "说明": "字数/段落/选项槽/监控键是否够转述遵守"
      }
    ],
    "薄弱点": "一句话"
  },
  "追问": {
-    "导语": "为钉准监控栏，还需确认：",
+    "导语": "为钉准每轮区域与规则，还需确认：",
    "题目": [
      {
        "问": "…",
@@ -161,29 +194,31 @@ summary：`设计监控栏 · …`（点题监控对象）。

 硬规则：
 1. 合法 JSON；公共三段外壳。
-2. 正文键固定：依据、监控对象、字段、刻意不监控、刷新、与版式关系。
-3. 自评：属性妥当 / 克制度 / 可接线。
-4. 字段不得无故包含姓名/性别等死设定（列入「刻意不监控」并说明）。
-5. summary：`设计监控栏 · {brief 缩略}`。
-6. 兼容旧 artifact「设计.状态栏」。
+2. 正文须含：必选区域（至少正文）、可选区域、刻意不启用。
+3. 每个启用区域须有可执行的 `规则`；选项栏须含槽气质与生成提示。
+4. 禁止选壳、写 CSS/HTML/JS、发明前端分区。
+5. summary：`回复呈现 · {brief 缩略}`。
+6. 产物 tag 仍为「设计.监控栏」。

 ## checklist

 ```checklist
- [ ] 字段均为会变且有用？死名片进了「刻意不监控」？
- [ ] 可含攻略目标/场景交互物等非主角对象？
- [ ] 来源意图清楚？未写成长文正文？
+- [ ] 正文在必选区，且有字数/自然段等规则？
+- [ ] 可选区逐项启用或刻意不启用？
+- [ ] 选项栏若开：槽气质与生成提示已写？
+- [ ] 状态监控若开：字段与来源已写？
+- [ ] 未写排版或 CSS/HTML/JS？
 ```

 ## examples

 ```examples
 好：
- 末日：体力、口粮、威胁等级；刻意不监控姓名性别。
- 恋爱：攻略目标好感/心情；场景可交互：公园长椅、便利店。
- 字段 3～7 个，短展示。
+- 必选正文默认 1000～2000 字、长自然段勿单句成段；可选状态监控=日期+好感；选项栏 A 冒险 / B 稳重，各有生成提示。
+- 必选正文；不开选项、不开小故事；状态只盯体力。用户要求极短时字数可低于默认。

 坏：
- 监控栏 = 完整人物卡（名/性/龄/身高/籍贯…）。
- 把叙事指南整段塞进栏内。
+- 只写「要选项」却不定 A/B 气质与生成提示。
+- 正文无字数/段落规则。
+- 在本步选壳或写 CSS。
 ```
@@ -1,6 +1,8 @@
 # 拓扑图谱

-> **状态：待完善** — 块格式见 `docs/world-simulator-modules.md`；范例见 `aesthetics-interaction`。
+> 技能文档。程序只切割下方 **fence 块**；`##` 标题仅供人读。  
+> 产物外壳：`docs/context-fragment-design.md`。  
+> 必须生成、但不适合走「生成规则→具体实例」时：用拓扑结构写出来。

 ## meta

@@ -8,52 +10,156 @@
 name: 拓扑图谱
 id: topology
 artifact: 设计.拓扑图谱
-declaration: 钉 worker/表/阶段的依赖、触发与数据流向；一张图说清谁读谁写
-when: 实现机制大致清楚，需要钉依赖边、触发边与数据流向时
-when_not: 尚未决定有哪些执行单元就先画复杂图
+declaration: >
+  有些东西必须生成，但不需要或不适合走「生成规则→具体实例」时：用拓扑结构写出来（升级路径、地图、人物关系等）
+when: |
+  已有「美学纲领与交互范式」或等价整体感觉，且同时满足：
+  这些东西必须生成；不需要或不适合走「生成规则→具体实例」；能用拓扑结构描述。
+  很泛：升级路径、地图、人物关系等等都可以。
+when_not: |
+  整体感觉未钉 → 先「美学纲领与交互范式」。
+  需要精准格式，或本局原创听了会雾且还要按规则生成 → 「生成规则」；已有规则再要名片 → 「具体实例」。
+  只是活动区域写细、没有拓扑可描述 → 「舞台骨架」。
+  跨轮真值 → 「变量设计与更新规则」。执行单元勾选 → 「游玩拓扑」。
+  没有必须生成的拓扑结构 → 不排。
 boundary: |
-  本能力：依赖/触发/读写流向。
-  游玩拓扑：固定槽勾选；本步若仍需要，只画已启用槽之间的数据流。
-  实现机制：总览「要哪些件」，本步钉件与件的边。
+  本技能：用拓扑结构写出必须存在、又不走生成规则合同的内容（节点、连接、方向/层级）。
+  生成规则 / 具体实例：复杂合同与 records——本步不写生成格式、不填名片表。
+  舞台骨架：活动区域写细——本步不重写舞台百科。
+  游玩拓扑：固定槽勾选——本步不描述执行单元谁读谁写。
+  变量*：跨轮状态——本步不设计变量表。
+feeds: gm
 ```

 ## opening

 ```opening
+先说要写哪块拓扑（想到什么写什么）：
+
+1. 有什么必须生成、又不适合走「生成规则→具体实例」？
+2. 它的拓扑是什么：升级路径、地图、人物关系，还是别的连接？
+   例：家门→小区门→花园↑；谁连谁；功法从哪一阶接到哪一阶。
 ```

 ## task

 ```task
-钉清拓扑：单元、依赖、触发、读写流向。写入 设计.拓扑图谱。
-（待作者细写）
+你正在执行「拓扑图谱」。产物必须是 **context-fragment.v1** JSON，写入「设计.拓扑图谱」。
+
+本步写出必须生成、但不需要或不适合走「生成规则→具体实例」的内容。用拓扑结构描述即可：升级路径、地图、人物关系等都很泛，能连起来就写。
+
+执行顺序：
+1. 认定本步写哪几块拓扑（名称 + 为何必须生成、为何不走生成规则）。
+2. 每块列出节点与连接（从哪到哪、什么关系、有无方向或层级）。
+3. 路径写清顺序或岔路；关系写清称谓或从属；升级写清阶与阶怎么接。点保持短名，不写成百科或名片表。
+4. 填齐正文 + 自评 + 追问，输出 JSON。
+
+若程序已发默认问题：禁止重复开场；在首答上补洞。
+summary：`拓扑图谱 · {名称或类型}`。
 ```

 ## principles

 ```principles
-一张图说清；环依赖与隐式读写必须显式写出或拆掉。
+1. 先问：必须生成吗？走「生成规则→具体实例」是不是过重或不合适？能用拓扑结构描述吗？三问成立才写。
+2. 拓扑很泛：升级路径、地图、人物关系都是同一类产物，不要只当成探索地图。
+3. 节点短、连接准。点不是名片，连接不是散文，也不是生成合同。
+4. 该用规则反复生成的对象族不要塞进本步。
 ```

 ## probe

 ```probe
-（待作者细写）
+每轮 1～2 点。已答清的禁止重问。
+
+优先：为何不走生成规则；这块拓扑是路径、地图还是关系；缺了哪条连接会断。
+不追问：执行单元读写、生成格式与池、变量公式、舞台百科、具体名片字段。
 ```

 ## output

 ```output
 {
-  "节点": [{ "id": "…", "类型": "worker|表|阶段|…" }],
-  "边": [{ "from": "…", "to": "…", "关系": "依赖|触发|读写|…" }],
-  "说明": "…"
+  "schema": "context-fragment.v1",
+  "技能": "拓扑图谱",
+  "brief": "一句话：写了哪几块拓扑",
+  "mount": ["world-simulator"],
+  "稳变": "stable",
+  "正文": {
+    "拓扑": [
+      {
+        "名称": "升级路径 / 地图 / 人物关系 / …",
+        "类型": "路径|地图|关系|其它",
+        "用途": "为何必须生成、游玩里怎么用",
+        "节点": [
+          {
+            "id": "英文或短码",
+            "名称": "家门 / 某阶 / 某人短名",
+            "是什么": "一句；不是名片"
+          }
+        ],
+        "连接": [
+          {
+            "from": "节点 id",
+            "to": "节点 id",
+            "关系": "通往 / 下一阶 / 父女 / …",
+            "方向": "单向|双向",
+            "备注": "如 ↑ 上楼；无则空字符串"
+          }
+        ]
+      }
+    ]
+  },
+  "自评": {
+    "维度": [
+      {
+        "名": "时机合适",
+        "分数": 8,
+        "说明": "是否必须生成、且不该走生成规则→具体实例"
+      },
+      {
+        "名": "结构清楚",
+        "分数": 8,
+        "说明": "拓扑是否写清、有无断连"
+      }
+    ],
+    "薄弱点": "一句话"
+  },
+  "追问": {
+    "导语": "为钉准这块拓扑，还需确认：",
+    "题目": [
+      {
+        "问": "…",
+        "建议选项": ["选项A", "选项B", "其它（请写明）"],
+        "示例": "可选"
+      }
+    ]
+  },
+  "开放问题": []
 }
 ```

+硬规则：
+1. 合法 JSON；必含 `schema` / `技能` / `brief` / `正文` / `自评` / `追问`（题目可 `[]`）。
+2. 正文含 `拓扑` 数组；每块含名称、类型、节点、连接。
+3. `mount` 默认主世界层；**禁止**写 `order`。不写执行单元槽位、不交 records、不写生成 schema。
+4. summary：`拓扑图谱 · {brief 缩略}`。
+
 ## checklist

 ```checklist
- [ ] 每个关键读写是否有边？
- [ ] 是否与实现机制列表一致？
+- [ ] 含 schema / brief / 正文 / 自评 / 追问？
+- [ ] 每块拓扑有节点和连接？路径/地图/关系能认？
+- [ ] 确是必须生成且不适合走生成规则→具体实例？
+```
+
+## examples
+
+```examples
+好：家门→小区门→花园↑——地图拓扑，连接带方向。
+好：家族谁连谁——关系拓扑，连接是称谓。
+好：功法一阶接到二阶、旁支接到某秘术——升级路径。
+坏：其实该按规则反复生成的对象族（如心之彩）硬写成拓扑。
+坏：把舞台活动区再抄一遍，没有连接。
+坏：描述主世界层谁读谁写 → 游玩拓扑，不是本步。
 ```
@@ -10,19 +10,19 @@ name: 变量控制上下文
 id: variable-context
 artifact: 设计.变量控制上下文
 declaration: >
-  钉真值/投影/Data 摘要如何挂进主世界层、叙事转述与旁观：
-  可见性、措辞、未解锁不注入；汇总映射当前档供旁观 agent
+  已有真值或映射时：钉谁看见什么（主世界层/转述/旁观）、未解锁不注入；无信息差则可不排
 when: |
-  变量设计已有真值或 Data 映射索引，需要规定谁看见什么、旁观看哪份摘要时。
+  变量设计已有真值或 Data 映射，且存在信息差：玩家不该看见但主世界层/旁观要知道，或到某档才允许提起，或旁观需要「当前档摘要」。
 when_not: |
-  尚无变量且无投影。
-  仅内部记账永不进提示词 → 可跳过，在变量设计备注即可。
-  只改字段与更新规则 → 变量设计与更新规则。
+  尚无变量且无投影 → 不排。
+  仅内部记账、永不进任何提示词 → 跳过，在变量设计备注即可。
+  只改字段与更新规则 → 「变量设计与更新规则」。
+  真值对所有槽同样可见、无剧透边界 → 可不排。
 boundary: |
  本技能：挂载表、剧透边界、旁观汇总视野、与维护语句/投影 tag 对齐。
  变量设计：字段、映射索引、维护语句形状、side_effects。
  具体实例：表行正文——本步不重生成，只声明「旁观读当前档/哪几个摘要键」。
-  设计监控栏 / 正文组成：用户可见层；本步管提示词视野。
+  回复呈现 / 正文组成：用户可见层（看什么 / 怎么展示）；本步管提示词视野。
 feeds: gm,auditor
 ```

@@ -11,20 +11,20 @@ name: 变量设计与更新规则
 id: variable-design
 artifact: 设计.变量设计与更新规则
 declaration: >
-  钉真值、谁可写、如何变；起草 side_effects；约定维护语句形状；
-  汇总 Data 映射索引（分档/实例来自生成规则与具体实例）供投影与旁观
+  体验必须跨轮记住少数状态时：钉真值、谁可写、如何变、维护语句，以及按值换文案的映射索引
 when: |
-  体验需要可追踪状态，且下游要可靠查询、门控、防重复或按值换文案时。
+  体验需要跨轮记住少数状态，否则会糊：必须可查询、门控、防重复，或到某值换一套态度/文案/章纲。
+  用户点名要好感/资源/阶段数字、分档换性格、进度门控时排。
 when_not: |
-  无状态纯对话，或状态只临场描写、从不程序化。
-  只要大段设定不要门控 → 舞台骨架 / 生成规则。
-  只规定挂进谁的提示词 → 「变量控制上下文」。
-  只规定用户看见哪些监控字段 → 「设计监控栏」。
+  无状态纯对话，或状态只临场描写、从不程序化 → 不排。
+  只要大段设定不要门控 → 「舞台骨架」/「生成规则」。
+  只规定谁的提示词看见什么 → 「变量控制上下文」。
+  只规定每轮给用户看哪些（正文/字数/变量/日期）→ 「回复呈现」。
 boundary: |
  本技能：真值清单、更新规则、维护语句约定、Data 映射索引、side_effects 草案。
  分档长文/性格切片正文：由生成规则定格式、具体实例填表；本步做索引与门控，不重写整表。
  正文组成：隐藏段定界符——本步钉「维护语句写什么」；定界样式与之对齐。
-  机遇裁定 chance：真随机 toolcall，不是变量表维护手段。
+  随机范围整理：检定/掷骰取值范围汇总（程序插备用数）——不是变量表维护手段；本步不收随机表。
  变量控制上下文：挂载对象与旁观汇总视野。
  细化终稿：收成 tables.side_effects。
 feeds: gm
@@ -52,7 +52,7 @@ feeds: gm
 - **Progressive**：side_effects 按真值边沿投影当前切片；旁观/主世界层读投影或汇总，不整表常驻

 **维护语句**：规定模型每轮如何声明变更（供程序拆进 `变量.当前` / 裁决包 `variable_changes`）。
-这不是 chance toolcall；toolcall 只做骰子/抽签。隐藏段定界与「正文组成」对齐。
+这不是掷骰；随机数走「随机范围整理」+ 程序插入的备用数。隐藏段定界与「正文组成」对齐。

 执行顺序：
 1. 读美学/机制/生成规则/具体实例/正文组成；不重开体验。
@@ -2,7 +2,8 @@

 > 能力文档。程序只切割下方 **fence 块**；`##` 标题仅供人读。  
 > **禁止自由发明执行单元。** 只从固定槽勾选；程序按 `play_slots` 展开 workers。  
-> 方法：`docs/progressive-data-design.md`；模板：`worker-templates/`。
+> 方法：`docs/progressive-data-design.md`；模板：`worker-templates/`。  
+> 真随机：不靠「机遇裁定」槽；上游定法则 →「随机范围整理」收表 → 程序往消息隐藏区插备用数。

 ## meta

@@ -11,21 +12,22 @@ name: 游玩拓扑
 id: worker-spec
 artifact: 设计.worker规格
 declaration: >
-  勾选固定游玩槽位（旁观维护 / 主世界层 / 叙事转述 / 可选角色视角 / 可选机遇裁定；写手路径为大纲+章节），
-  禁止自由发明新的执行单元 ref
+  不能吃默认槽时才勾选：主世界层必开；有变量/表维护才开旁观；转述默认开；强秘密才开视角；写手则大纲+章节；禁止发明执行单元与机遇槽
 when: |
-  体验契约已大致清楚，需要决定游玩期启用哪些固定槽时；
-  或要修订已勾选槽位（开/关 auditor、perspective、chance 等）时。
+  体验契约已大致清楚，且不能吃默认槽：要关旁观、关转述、开角色视角（强秘密不能进主世界层），或走写手大纲+章节。
+  或要修订已勾选槽（开/关 auditor、perspective、narrator 等）。
 when_not: |
-  体验/站位仍混沌 → 先美学纲领与交互范式。
-  只需收成完整运行规格 → 交给细化终稿（本步只交槽位勾选）。
-  不要用本步「发明」世界观/性格/变量专用执行单元。
+  体验/站位仍混沌 → 先「美学纲领与交互范式」。
+  世界模拟可吃默认（主世界层+转述+旁观；视角关）→ 可不排，「细化终稿」按默认收成。
+  只需输出完整运行规格 → 「细化终稿」（本步只交槽位勾选）。
+  检定/掷骰范围汇总 → 「随机范围整理」；不要为本步加「机遇裁定」槽。
+  不要用本步发明世界观/性格/变量专用执行单元。
 boundary: |
  本能力：输出 play_slots（及写手路径的 writing_slots），可选覆盖挂载说明；不写完整 设计.worker集。
+  主世界层（gm）几乎总要。旁观维护：有变量/表/规则要程序化盯时才开。转述默认开。
+  不再设机遇裁定（chance）槽：真随机走「随机范围整理」+ 程序插入上下文备用数。
  细化终稿：按本步勾选展开 workers、合并常驻与 tables。
  变量设计 / 变量控制上下文：真值与投影，不是推理槽。
-  旁观维护（auditor）：副 LLM，表/规则检查，默认空操作；无长对话史。
-  机遇裁定（chance）：`play_slots.chance` 开时主世界层 harness 获批量程序工具；非每轮独立上场。
  叙事指南与故事推进：挂到转述槽（推进可兼挂主世界层）；世界/机制：挂到主世界层——本步只点名槽。
 ```

@@ -35,15 +37,16 @@ boundary: |
 游玩时用哪些固定槽？（只勾选，不要发明新角色名当「新系统」）

 世界模拟类常见：
-1. 旁观维护（表/规则检查，默认每轮上场但多数轮空操作）——要 / 不要（默认要）
-2. 主世界层（裁决，几乎总要）——要 / 不要
-3. 叙事转述（写你看见的正文，几乎总要）——要 / 不要
+1. 主世界层（裁决）——要（几乎总要）
+2. 叙事转述（写你看见的正文）——要 / 不要（默认要）
+3. 旁观维护（有变量/表/规则要盯时才开；默认：有变量类上游则要）——要 / 不要
 4. 角色视角（仅当有强秘密、不能进主世界层时）——要 / 不要（默认不要）
-5. 机遇裁定（骰子/抽签/比点等真随机，按需调用、不进每轮）——要 / 不要（默认不要；有战斗检定、抽签事件时建议开）
+
+不要勾「机遇裁定」：检定/掷骰用「随机范围整理」收表，程序插备用随机数。

 写手/扩写类常见：大纲/细纲 + 章节正文（固定两槽，同上只勾选）。

-变量、性格分档、世界观：不是槽，后面用变量/世界等技能收进上下文。
+变量、性格分档、世界观：不是槽，用变量/世界等技能收进上下文。
 ```

 ## task
@@ -51,22 +54,23 @@ boundary: |
 ```task
 你正在执行「游玩拓扑」。产物写入「设计.worker规格」。

-核心操作：让用户勾选固定槽，写成 `play_slots`（世界模拟）或 `writing_slots`（扩写）。**禁止**新建未在固定列表中的 ref。
+核心操作：让用户勾选固定槽，写成 `play_slots`（世界模拟）或 `writing_slots`（扩写）。**禁止**新建未在固定列表中的 ref；**禁止**再开机遇裁定槽。

 固定 ref 白名单：
 - 世界模拟每轮：`world-simulator`（gm）、`narrator`、`auditor`（回合末）、`role-decide`（perspective，默认关）
- 世界模拟机遇：`play_slots.chance` 控制主世界层 harness 的批量 `chance` 工具（默认 false）；非每轮独立 LLM 槽
 - 扩写：`outline`、`chapter-writer`
- 禁止：`variable-update`、自造 kebab、为世界观/性格再拆槽
+- 禁止：`chance` / 机遇裁定、`variable-update`、自造 kebab、为世界观/性格再拆槽

 执行顺序：
 1. 读配方与体验契约，判断路径：世界模拟 vs 写手分段。
-2. 默认世界模拟：`auditor: true, gm: true, narrator: true, perspective: false, chance: false`；
+2. 默认世界模拟：`gm: true, narrator: true, auditor: true, perspective: false`；
   调度序 gm → perspective? → narrator → auditor；
-   仅信息隔离才开 perspective；需要骰子/抽签/比点等真随机时设 `chance: true`（主世界层 harness 批量工具，不进每轮序）。
+   主世界层必开（用户明确只要旁观/写手路径除外）；
+   有变量设计/表维护需求 → auditor true；纯无状态对话可 auditor false；
+   仅信息隔离才开 perspective。
 3. 写手路径：`outline` + `chapter-writer` 默认都开；用户明确只要正文则可关 outline。
 4. 可写简短 `mount_notes`（哪类上游产物挂哪槽），不粘贴长文。
-5. 输出 JSON。summary：`游玩拓扑 · 旁观+gm+转述` 或 `游玩拓扑 · gm+转述+机遇` 等。
+5. 输出 JSON。summary：`游玩拓扑 · gm+转述+旁观` 等（勿写机遇）。

 若程序已发默认问题：禁止重复同一开场；在首答上补洞。
 ```
@@ -74,12 +78,13 @@ boundary: |
 ## principles

 ```principles
-1. 只勾选，不发明：ref 必须在白名单内。
-2. 默认：世界模拟 = 旁观维护 + 主世界层 + 转述；perspective 默认关。
-3. 变量 / Data / Progressive 不是执行单元；旁观维护只出 maintain.v1，不写真相。
-4. 删掉检验仍适用：关某个槽要说得清损失什么。
-5. 本步不输出完整 Worker 集、不写 tables 全文（交给细化终稿 / 变量设计）。
-6. 可修订已有勾选，不要为「更聪明」加槽。
+1. 只勾选，不发明：ref 必须在白名单内；无机遇裁定槽。
+2. 默认：世界模拟 = 主世界层 + 转述 + 旁观；perspective 默认关。主世界层必要。
+3. 有变量/表/规则要盯 → 开旁观；无则可不开。
+4. 变量 / Data / Progressive 不是执行单元；旁观维护只出 maintain.v1，不写真相。
+5. 删掉检验仍适用：关某个槽要说得清损失什么。
+6. 本步不输出完整 Worker 集、不写 tables 全文、不写随机范围表（交给细化终稿 / 变量设计 / 随机范围整理）。
+7. 可修订已有勾选，不要为「更聪明」加槽。
 ```

 ## probe
@@ -89,9 +94,10 @@ boundary: |

 - 正文是否必须由独立转述写？（不要则 gm 兼呈现，narrator=false——需用户明确）
 - 是否有「主世界层不该知道的角色秘密」？（有才 perspective=true）
+- 有变量/表要盯却关了旁观？或无状态却硬开旁观？
 - 扩写：要不要先验大纲再写章？

-不要问「还想加什么 Worker」。
+不要问「还想加什么 Worker」；不要问要不要机遇裁定。
 ```

 ## output
@@ -104,8 +110,7 @@ boundary: |
    "auditor": true,
    "gm": true,
    "narrator": true,
-    "perspective": false,
-    "chance": false
+    "perspective": false
  },
  "writing_slots": {
    "outline": true,
@@ -115,7 +120,7 @@ boundary: |
    "生成规则/变量合同/旁观摘要 → auditor（无长对话史）",
    "叙事指南与故事推进 → narrator（推进兼 gm）",
    "世界/机制/变量规则 → gm",
-    "真随机检定 → play_slots.chance=true（gm harness 批量工具，非每轮 chance worker）",
+    "随机范围整理 → gm（上下文备用随机数；无机遇槽）",
    "真值与 side_effects → 细化终稿 tables"
  ],
  "开放问题": []
@@ -125,28 +130,30 @@ boundary: |
 填写规则：
 - `path=world_sim` 时必须有 `play_slots`；`writing_slots` 可省略。
 - `path=writing` 时必须有 `writing_slots`；`play_slots` 可省略。
- `auditor` / `chance` 缺省：auditor 视为 true，chance 视为 false；`chance: true` 时为主世界层开启 harness 机遇工具（仍可声明按需 `chance` ref 供显式 run_worker，但游玩默认不走每轮 chance 演员）。
+- `play_slots.gm` 世界模拟路径下应为 true。
+- `auditor` 缺省：有变量/表维护意图视为 true，否则可 false。
+- 不要输出 `chance` 字段；旧产物若有 `chance: true`，本步改为 false/删除，并指向「随机范围整理」。
 - 不要输出自造 `actors[]` / 自由 `workers[]`。
 - 旧产物若含 `actors[]`：本步应改写为槽位勾选，不再追加自定义 ref。

 ## checklist

 ```checklist
- [ ] 是否只有白名单槽，无自造 ref？
- [ ] auditor / perspective / chance / 只要正文等非常规选择是否有理由？
- [ ] 是否误把变量管理做成槽？是否误把 chance 当成每轮 LLM？
- [ ] 是否误交完整 设计.worker集？
+- [ ] 是否只有白名单槽，无自造 ref、无机遇裁定？
+- [ ] 主世界层是否开启（世界模拟路径）？旁观是否与变量需求一致？
+- [ ] auditor / perspective / 只要正文等非常规选择是否有理由？
+- [ ] 是否误把变量管理做成槽？是否误交完整 设计.worker集？
 ```

 ## examples

 ```examples
 好：
- play_slots: auditor+gm+narrator，perspective/chance false；mount_notes 一行。
+- play_slots: gm+narrator+auditor，perspective false；有变量故开旁观。
 - 有凶手真名不能进 GM：perspective true，并说明只出反应建议。
- 需要检定/抽签：`chance: true`（gm harness 批量工具）。
+- 需要检定：不写 chance；提醒排「随机范围整理」。

 坏：
 - actors 里发明 affinity-manager、lore-keeper、dice-master（LLM）。
- 为性格分档再拆一个执行单元。
+- 为性格分档再拆一个执行单元；或再开机遇裁定槽。
 ```
@@ -10,24 +10,19 @@ name: 舞台骨架
 id: world-blueprint
 artifact: 设计.舞台骨架
 declaration: >
-  体验需要可引用的舞台背景时：钉尺度、基底与变造、关键舞台区，以及社会结构与世界状况；
-  只细化会上台的部分，不做地图或设定百科
+  本局舞台备案：划出玩家实际游玩会换区活动的主要区域并写细；尺度与详细度随体验变。代入后几乎不移动、只在一处待着则不排
 when: |
-  体验契约（及可选的实现机制）已大致清楚，但仍不能回答：
-  “这局发生在多大的舞台上？以什么基底成立、变在哪里？”
-  “台上是谁在互动？世界以何种状况运转故事？”
-  “下游要引用哪些舞台区、社会格局或世界状况？”
+  已有「美学纲领与交互范式」或等价整体感觉，且玩家实际游玩会在划分的活动区域上发生（会换区、会移动）。
+  变造世界与现实世界都要排：只是详细度有所不同。
+  玩家实际游玩过程中的主要活动区域必须写细，但如果本身世界变造不多、或特殊设定较少（如西幻就足以概括的世界），就不需要多写。
 when_not: |
-  核心体验未钉清 → 先「美学纲领与交互范式」。
-  只需识别体验支撑切面、不必展开环境与社会 → 「实现机制」。
-  需要可点名的人/地/物名片 → 「具体实例」。
-  需要内容如何持续生成 → 「生成规则」。
-  用户只要轻设定、明确拒绝世界骨架 → 不要排入。
+  整体感觉未钉 → 先「美学纲领与交互范式」。
+  代入后几乎不移动：玩家只会在一处待着体验，不会走到别的活动区域（如网聊、门卫室）→ 不排。
+  可点名名片 → 「具体实例」另排。持续生成合同 → 「生成规则」。
 boundary: |
-  本技能：可引用舞台骨架——尺度、基底+变造、关键舞台区、社会结构、世界状况；产出 context-fragment.v1。
-  不是地理志：凡影响核心运转且会上台的（生灵种类、势力、灾变、通道、习俗等）都落在社会结构或世界状况里。
+  本技能：舞台备案——范围、基底+变造、主要活动区域（写细）、社会结构、世界状况。
  美学纲领与交互范式：体验与轮转——本步不重定。
-  实现机制：承重切面——本步展开世界侧骨架，不重做移除检验。
+  实现机制：既成变造法则——本步把法则落到活动区域上长什么样，不重钉法则来源。
  具体实例 / 生成规则 / 叙事指南与故事推进：名片、生成节奏、遣词与推进——本步不定。
 feeds: gm
 ```
@@ -35,17 +30,17 @@ feeds: gm
 ## opening

 ```opening
-先用几句话框住「这局会出现的背景舞台」（想到什么写什么）：
+先框住「玩家实际会待着玩的地方」（想到什么写什么）：

 1. 舞台有多大？熟悉基底是什么？变在哪里？
   例：一座城 / 一所学校几个系 / 「魔族与人族对峙的前线」（可抽象，不必真地图）。

 2. 社会结构与世界状况里，什么在撑故事？
   例：人类与丧尸如何相处；每年寒灾；南极通往怪物世界的出口；村中活人祭祀……
-   只点会影响核心运转、会反复碰到的，不写物种大全或民俗全书。
+   只点会影响核心运转、会反复碰到的。

-3. 真正会反复出现的舞台区是哪里？
-   一句话即可——只点「会上台」的部分，其余可留黑。
+3. 玩家实际游玩的主要活动区域是哪几块？
+   这些区域要写细——不是点名就走。舞台外可以留黑。
 ```

 ## task
@@ -53,27 +48,25 @@ feeds: gm
 ```task
 你正在执行「舞台骨架」。产物必须是 **context-fragment.v1** JSON，写入「设计.舞台骨架」。

-钉的是**会出现在台上、影响故事核心运转的背景**——不只是地理：
-空间格局、谁在台上互动（社会结构）、世界如何运转（世界状况：灾变、通道、习俗、禁忌、命脉等）都属本步。
-不是纸面地图，也不是设定集百科。尺度由本局体验决定。
+本步是舞台**备案**：变造世界与现实世界都有划分的舞台。钉的是玩家实际游玩过程中的**主要活动区域**——这些区域要写细。范围、基底与变造、社会结构、世界状况沿用现有字段。

-同一「现代都市」基底下：
- 「体验作为韩国顶级财阀」→ 舞台往往是地球级势力、国家与资本网络；
- 「体验普通大学生活」→ 舞台可能只是一座城，甚至一所学校的几个系。
+尺度由本局体验决定。同一「现代都市」基底下：
+- 「体验作为韩国顶级财阀」→ 舞台往往是地球级势力、国家与资本网络，活动区写到财团/宴会/听证层；
+- 「体验普通大学生活」→ 舞台可能只是一座城或一所学校，活动区写到系馆与社团层。详细度不同，不是跳过本步。

-核心操作：在已确认体验（及可选机制支点）之上，用「熟悉基底 + 变造」钉出可引用骨架；写清社会结构与世界状况；只细化关键舞台区。
+核心操作：在已确认体验（及可选的既成法则）之上做备案；玩家主要活动区域写细；舞台外留黑。

 执行顺序：
-1. 读依赖与用户表述，忠实继承体验与世界侧机制支点；不重做美学/机制。
+1. 读依赖与用户表述，忠实继承体验与既成法则；不重做美学/机制。
 2. 判定舞台尺度：以体验会碰到的边界为准。
 3. 选定熟悉基底，写清变点。
 4. 钉「社会结构」：台上有哪些种类/势力/阶层在互动（种类级与格局级，非名片）。
 5. 钉「世界状况」：灾变、通道、祭祀、资源命脉、禁忌等——须能回答如何影响核心运转；软性日常条件也归此。
-6. 只展开关键舞台区；舞台外「刻意留黑」。
+6. 玩家主要活动区域写细；舞台外「刻意留黑」。
 7. 类型滤镜仅作体裁/氛围参照；禁止题材套件勾选。
 8. 填齐正文 + 自评 + 追问，输出 JSON。

-工作姿态——「搭舞台，不写百科」：不问世界完整长什么样，问玩家会反复看见/碰到什么背景与运转部件。
+工作姿态——「备案活动区，不写百科」：问玩家会反复待在哪、碰到什么运转部件；舞台外不补全图。

 若程序已发默认问题：禁止重复开场；在首答与依赖上补洞。
 summary：`舞台骨架 · …`（点题尺度 / 社会结构或世界状况）。
@@ -92,20 +85,20 @@ summary：`舞台骨架 · …`（点题尺度 / 社会结构或世界状况）
   可以是抽象格局（对峙、割据、阶层天井）。不要求接壤比例尺、全史年表。
   下游需要点名条目时交给「具体实例」；本步给格局级与状况级引用钩子。

-3. 变造基底，再按舞台细化
-   优先路径：大家都有印象的基底世界 → 点明变在哪里 → 只细化关键舞台区与会撑故事的社会/状况条目。
-   细化粒度跟舞台走：财阀博弈可写到国家/财团层；校园日常写到系馆与社团层即可。
+3. 变造基底，再按活动区写细
+   优先路径：大家都有印象的基底世界 → 点明变在哪里 → 玩家主要活动区域写细，并写清会撑故事的社会/状况条目。
+   详细度跟体验走：财阀博弈可写到国家/财团层；校园日常写到系馆与社团层。这是备案详细度，不是跳过本步。

 4. 类型滤镜是叠加在基底上的体裁/氛围参照，不是必选题单
   可用于澄清「故事以何种体裁被讲述」，从而影响冲突模式与背景气质。
   禁止：列出大菜单请用户勾选；禁止因选了滤镜就自动塞满该类型常见地理与势力。

 5. 与实现机制的分工
-   机制已钉「世界侧支撑切面」时：本步展开其环境/社会/状况骨架，不重做「如何支撑／缺了会怎样」。
-   机制未排入时：仍可从体验直接推断最小舞台；不要假装已经做过支撑检验。
+   机制已钉既成变造法则时：本步把法则落到主要活动区域上长什么样，不重钉「为何存在」。
+   机制未排入时：仍从体验直接做舞台备案。

-6. 宁少勿多，舞台外留黑
-   关键舞台区 + 撑故事的社会与状况写清即可停止。舞台外、体验碰不到的部分默认不写。
+6. 活动区写细，舞台外留黑
+   玩家主要活动区域写细即可停止。舞台外、体验碰不到的部分默认不写。
   「未展开范围」写明刻意省略，避免下游把留黑当成缺口去补百科。

 7. 正推，禁止否定式路由
@@ -122,7 +115,7 @@ summary：`舞台骨架 · …`（点题尺度 / 社会结构或世界状况）
 ```probe
 只追问会改变尺度、变造、社会结构、世界状况或台上格局的缺口。每轮 1～2 点。已答清的禁止重问。

-【默认问题已覆盖】尺度、基底+变点、社会结构/世界状况、会反复出现的舞台区。首答后按缺口补。
+【默认问题已覆盖】尺度、基底+变点、社会结构/世界状况、玩家主要活动区域。首答后按缺口补。

 优先方式：

@@ -136,13 +129,13 @@ summary：`舞台骨架 · …`（点题尺度 / 社会结构或世界状况）
   例：「台上互动方是否就是『人类 + 无攻击欲的丧尸』？还有没有别的智能方会影响你的掌控？」
   例：「『每年寒灾』是全局运转的硬时钟，还是只在边陲传说？祭祀是真要死人，还是可被你改写的习俗？」

-4. 关键舞台区边界
-   例：「真正会反复出现的，是总部—宴会—监管听证，还是还要经常切到海外子公司现场？」
+4. 主要活动区域
+   例：「真正会反复待着玩的，是总部—宴会—监管听证，还是还要经常切到海外子公司现场？这些区要写细。」

 5. 滤镜澄清 / 机制落地（可选）
   体裁气质会改变冲突模式时才问滤镜；机制已点世界侧切面时，问它在台上长什么样，不重做支撑检验。

-才追问：两种尺度会显著改变后续；变点/社会/状况不清会改核心运转；关键舞台区范围决定要否某类势力；类型标签分不清氛围与硬设定。
+才追问：两种尺度会显著改变后续；变点/社会/状况不清会改核心运转；主要活动区域范围决定要否某类势力；类型标签分不清氛围与硬设定。

 不追问：具体名片（→ 具体实例）；完整物种志/民俗志/世界史/全地图；生成/变量/文风；用户已拒绝展开的背景；基底可默认继承的常识。
 ```
@@ -258,7 +251,7 @@ summary：`舞台骨架 · …`（点题尺度 / 社会结构或世界状况）
 - [ ] 自评为覆盖度 / 充分度 / 克制度？
 - [ ] 尺度由体验决定？基底+变造可引用？
 - [ ] 社会结构与世界状况已写（或空数组且说明无需）？硬状况能说清如何影响运转？
- [ ] 只细化关键舞台区，且有未展开范围？
+- [ ] 玩家主要活动区域已写细，且有未展开范围？
 - [ ] 未写成地图百科、物种志、民俗全书、类型勾选菜单、具体名片？
 - [ ] 追问只打尺度/社会/状况/变造缺口，带建议选项？
 ```
@@ -267,7 +260,7 @@ summary：`舞台骨架 · …`（点题尺度 / 社会结构或世界状况）

 ```examples
 好：
- 体验「普通大学生活」→ 舞台＝校园几系；社会结构＝师生/社团层；世界状况可轻；未展开＝国家政治。
+- 体验「普通大学生活」→ 仍要备案；舞台＝校园几系（活动区写细）；世界状况可轻；未展开＝国家政治。
 - 体验「垄断粮食的末日支配」→ 社会结构＝人类 + 无攻击欲丧尸 + 楼内依赖关系；世界状况＝外出采集命脉；舞台区＝楼内安全区 / 楼外采集区。
 - 世界状况示例：每年寒灾；南极通往怪物世界的出口；村中活人祭祀。
 - 抽象：「魔族与人族对峙割据」——社会结构两种阵营；不画大陆全图。