收紧世界模拟器能力与壳提示，对齐新的落盘合同和呈现分工。

让选题填写与游玩投影读到一致的规格口径。 Co-authored-by: Cursor <cursoragent@cursor.com>
2026-10-07 23:49:34 +08:00
parent ff5c77bfb1
commit cf6cb68429
22 changed files with 623 additions and 462 deletions
@@ -7,42 +7,74 @@ name: 美学纲领与交互范式
 id: aesthetics-interaction
 artifact: 设计.美学纲领与交互范式
 declaration: >
-  提取用户最想反复获得的核心体验，以及让它成立的背景与规则内核；同时钉清参与和停笔边界。
+  提取用户最想反复获得的核心体验与让它成立的承重内核，写成给后续能力读的美学纲领；
  同时钉清交互范式：人称视角、模型可代写什么、用户保留什么、后果由谁裁定、何时停笔。
 when: |
-  用户要的是叙事、角色扮演或持续互动，但还不能明确说出：最想反复获得什么体验，以及什么承重前提让它成立。
+  用户要的是叙事、角色扮演或持续互动，但还不能明确说出：最想反复获得什么体验、自己站在什么位置、轮转到哪必须停等用户。
  用户主动改变核心体验、代入站位或关键权限时也应重写。
 when_not: |
  本局不依赖体验契约的纯转换、资料整理或机械格式任务，可不使用。
  只改遣词和具体写法 → 叙事指南；只改推进与输入用法 → 故事推进；只改舞台详情或硬法则 → 对应能力。
 boundary: |
-  本能力只交核心体验、体验成立的背景与规则内核、参与边界。
+  本能力只交三块：美学纲领（体验是什么、怎样发生、呈现尺度）、背景与规则的承重内核、交互范式（视角、描写权限、后果控制、停笔）。
-  背景与规则只提取承重内核，不扩写百科；舞台细节归舞台骨架，可执行硬法则归实现机制。
+  背景与规则只提取承重内核，不扩写百科；舞台细节归舞台骨架，可执行硬法则归实现机制；具体遣词句式归叙事指南。
 feeds: design_only
 ```
 ## opening
 ```opening
-先说你最想在这局里反复获得什么体验，以及你希望自己站在什么位置。可以直接给一个场景、关系或感觉，不必先整理设定。
+先用几句话抓住你要的世界和体验核心（想到什么写什么，不必整齐）：
 1. 原型世界是什么？变在哪里？
   例：丧尸世界，但只有我不会被感染；现代都市，但灵异是真的；也可以只说「现代都市」，变点稍后补。
 2. 你代入吗？希望自己站在什么位置？
   · 完全代入（我就是那个人，TA 的遭遇≈我的遭遇）
   · 部分代入 / 跟着体验（有距离）
   · 操控或旁观（角色是棋子/观察对象）
   · 其它（请写明）
 3. 你最想在这局里反复获得什么体验？
   一句话即可——权力、求生紧张、关系拉扯、解谜、荣耀、禁忌刺激……用你自己的词。
 ```
 ## task
 ```task
-从用户材料中提取一份体验契约，写入 `设计.美学纲领与交互范式`。产物只回答三件事：用户最想反复获得什么核心体验；什么最小背景或规则内核让它成立；模型与用户各自能决定什么、何时必须停笔。
+从用户材料中提取一份体验契约，写入 `设计.美学纲领与交互范式`。它是后续所有能力取舍的依据，也会挂给主世界层与转述层直接阅读。产物回答三件事：
-保留用户自己的重点和尺度。材料不足时少写，把真正影响核心体验或背景内核的缺口交给 `self_score.gap`；产物正文不放评分、诊断、追问或开放问题。
+1. 美学纲领：用户最想反复获得什么体验，它通过什么关系、处境、感官或选择反复发生，呈现时的氛围与尺度。
 2. 背景与规则：删掉就会让这份体验不成立的最小承重前提，以及它如何约束人物、选择与后果。
 3. 交互范式：用户与所扮演角色的关系、人称与视角、模型对 user 每类行为能代写到哪一步、世界后果由谁裁定、何时必须停笔等用户。
 保留用户自己的重点、用词和尺度。材料不足时少写或写「未定」，把真正影响体验或权限的缺口交给 `self_score.gap`；产物正文不放评分、诊断、追问或开放问题。
 ```
 ## principles
 ```principles
-1. 核心体验不是题材、剧情简介或情绪标签；要写用户如何参与、体验怎样反复发生。
+1. 核心是用户想要的体验；其余字段都是为了让它稳定地反复发生。完善设定时回头核对原本的核心体验，不让它被设定冲淡。
-2. 背景与规则寻找最小承重内核：可以是关键关系、社会前提、世界规则或作用机制。删掉它会使核心体验不成立。
+2. 核心体验不是题材、剧情简介或情绪标签：写用户如何参与、体验怎样反复发生。同一设定不同用户要的可以完全不同（角斗士：荣耀 / 自由 / 血与酒），找到这个人要的那一个，而不是补全世界观。
-3. 角色人文关系、描写焦点和文风信号可作为核心体验的组成材料，但不为评分硬拆成独立维度。
+3. 变造世界先抓「原型 + 变在哪里」；核心体验往往来自变点。背景与规则只写承重内核：关键关系、社会前提、世界规则或作用机制。
-4. 本步不扩写世界百科，不制定完整硬机制，不细化遣词句式，不决定故事推进方法。
+4. 用户常说不清想要什么：展示优于提问，大胆优于保守；用两种站位或两种感觉的短场景让用户选或改；负面信号同样有效。用户可以说不，随时准备整份改写。
-5. 参与边界写可执行权限：模型可补哪些反应与行动，哪些决定必须留给用户，何时停笔。
+5. 用户要的内容去道德化、常态化处理：按用户给的尺度写进「边界与尺度」，写清服务体验的用法与真正的禁忌，不替用户加或减尺度。
-6. 用户改口导致体验内核改变时整份重写，不在旧契约后追加互相冲突的补丁。
+6. 交互范式写可执行权限，不写口号。描写权限按行为类别逐项写：哪些模型可直接代写、哪些只写到起势就停、哪些必须留给用户；「用户输入后」写模型对一句输入是只确认、补细节还是连带推出后果。
 7. 交互范式要保护美学纲领：权限、视角和停笔点的设置要让核心体验更容易发生，两者矛盾时以美学纲领为准改范式。
 8. 本步不扩写世界百科，不制定完整硬机制，不细化遣词句式，不决定故事推进方法，不输出执行单元列表或插入 order。
 9. 用户改口导致体验内核改变时整份重写，不在旧契约后追加互相冲突的补丁。
 ```
 ## probe
 ```probe
 本步最先要钉清三件：站位（代入还是旁观、镜头看哪、爽从哪来）、核心感觉（反复感受到什么）、轮转停点（何时等用户）。三件写进 `体验锚定`；开场白写入前程序会检查它们。
 用户首句、默认问题首答或黑板「用户.需求」里已有的直接采纳，已答清的不重问。
 缺其中一件：回复里只问这一件，给 2～3 个带短场景的建议选项，不问开放式「你还想要什么」。三件已清：再挑一个最影响体验的薄弱点（视角、某类描写权限、尺度）给选项；都够用就不再追问。
 用户讲到人物、舞台、规则细节：只抽取能改变体验、站位或权限的那一句写进正文，其余留给对应能力，本步不追问细节。
 ```
 ## output
@@ -53,29 +85,58 @@ feeds: design_only
  "技能": "美学纲领与交互范式",
  "brief": "一句话点出用户最想反复获得的核心体验",
  "体验锚定": {
-    "站位": "用户与当前角色/作品的关系",
+    "站位": "用户与所扮演角色/作品的关系：代入、部分代入、旁观或操控",
    "核心感觉": "最想反复获得的体验",
    "轮转停点": "何时必须停笔等待用户"
  },
  "mount": ["world-simulator", "narrator"],
  "稳变": "stable",
  "正文": {
-    "核心体验": {
+    "美学纲领": {
-      "体验主张": "用户最想反复获得什么",
+      "体验内核": "给后续能力和游玩层读的纲领正文，可多段：用户要反复感到什么、它靠什么关系或处境成立、从哪一刻开始、怎样被反复兑现",
-      "发生方式": "它通过哪些关系、处境、感官或选择反复发生",
+      "发生方式": "体验通过哪些关系、处境、感官或选择反复发生",
      "角色人文": "关键人物关系中的权力、尊严、亲疏或人性张力；无则省略",
-      "描写信号": "应把注意力放在哪里、呈现什么质感；具体写法交给叙事指南"
+      "呈现要点": {
        "氛围基调": "整体质感与情绪温度",
        "描写焦点": "注意力放在哪里：哪些瞬间、反应、细节值得放慢写；具体遣词交给叙事指南",
        "边界与尺度": "色情/暴力/血腥等按用户给的尺度：服务体验的用法与真正的禁忌",
        "其它要点": ["反差、日常化、节奏偏好等短条；无则省略"]
      }
    },
    "背景与规则": {
      "原型与变点": "熟悉的原型世界，以及变在哪里；无变造则省略",
      "核心内核": "让体验成立的最小承重前提",
-      "作用方式": "它如何约束人物、选择与后果",
+      "作用方式": "它如何约束人物、选择与后果，怎样持续制造该体验",
      "非必要设定": "明确本步不展开的装饰信息；无则省略"
    },
-    "参与边界": {
+    "交互范式": {
-      "用户站位": "代入、部分代入、旁观、操控或本局自定义描述",
+      "前置配置": {
-      "模型可代演": "可补写的行动、反应和既有习惯",
+        "用户与user关系": "完全代入 / 部分代入 / 旁观 / 操控，及其含义",
-      "用户保留权": "不得替用户决定的事项",
+        "人称": "如：第二人称称「你」",
-      "世界反馈": "模型可直接裁定和推进的外部后果",
+        "元叙事": "如：不跳出故事直接问卷，决策用情节呈现"
      },
      "叙事视角": {
        "主要视角": "镜头跟谁、看什么",
        "视角切换": "禁止，或允许的例外",
        "可写内心": "可以写谁的内心；如仅 user 或仅 NPC 外显",
        "不呈现的信息": "user 不该知道、正文不能透露的内容"
      },
      "描写权限": {
        "思考与抉择": "关键决定是否只能由用户做，模型写到哪里停",
        "言语": "模型能否替 user 说话、说到什么程度",
        "主动行动": "模型能否替 user 发起行动",
        "情绪与身体反应": "模型可补写的生理与情绪反应",
        "习惯与既有技能": "模型可按既有设定自动执行的部分",
        "外在状态": "外貌、伤势、衣着等可否直接描写",
        "用户输入后": "对用户一句输入：只确认 / 补细节 / 连带推出后果"
      },
      "后果与叙事控制": {
        "行为后果判定": "谁裁定 user 行为的成败与代价",
        "世界对user的影响": "NPC 与世界如何主动作用于 user",
        "时间与场景": "模型可否推进时间、切换场景，跨度多大",
        "引入新内容": "模型可否主动引入新人物、事件、威胁",
        "设计困境": "是否主动给 user 制造两难；怎样的两难服务体验"
      },
      "停笔时机": "必须等用户输入的明确时机"
    }
  }
@@ -83,19 +144,24 @@ feeds: design_only
 ```
 硬规则：
-1. 输出合法 JSON；保留 `体验锚定` 仅为兼容，不做计数门槛。
+1. 输出合法 JSON。`体验锚定` 三项必填短句：开场白写入前程序按它判定体验是否已锚定，缺项会拒绝写入开场白。
-2. `正文` 只含 `核心体验`、`背景与规则`、`参与边界`；未知字段省略，不用“完备度”或诊断对象占位。
+2. `正文` 只含 `美学纲领`、`背景与规则`、`交互范式` 三块，每块是对象，不写成一段散文。未知字段写「未定」或省略，不编造百科。
-3. 不在产物正文写 `自评`、`追问`、`开放问题`、评分依据或用户回复。
+3. 不在产物里写 `自评`、`追问`、`开放问题`、完备度、评分依据或用户回复；缺口交给 `self_score.gap`。
-4. `mount` 固定包含 `world-simulator` 与 `narrator`；后续投影器分别裁剪字段。
+4. `mount` 固定包含 `world-simulator` 与 `narrator`；不写数字 `order`，不输出执行单元列表。
 ## score
 ```score
-核心体验：
+美学纲领：
- 5：准确提取用户最想反复获得的体验，写清用户站位、体验如何发生及何时停笔；后续能力可据此取舍。
+- 5：准确提取用户最想反复获得的体验，写清它怎样反复发生、从哪一刻成立，呈现焦点与尺度贴合用户原话；后续能力可据此取舍。
- 3：大方向正确，但仍偏题材或情绪概括，或体验如何反复发生尚不明确。
+- 3：大方向正确，但仍偏题材或情绪概括，或体验如何反复发生、尺度如何把握尚不明确。
 - 1：误读用户重点，只有剧情简介、设定标签或泛化氛围。
 交互范式：
 - 5：站位、人称视角、逐类描写权限、后果裁定与停笔时机都可执行，且在保护核心体验。
 - 3：有站位与停笔，但描写权限笼统，或某类行为（言语、行动、反应）谁来写仍不清。
 - 1：只有口号式描述，或权限设置与核心体验矛盾。
 背景与规则：
 - 5：找到让核心体验成立的最小内核——关键关系、背景前提或作用规则，并说明它怎样持续制造该体验。
 - 3：找到相关前提，但内核过宽、因果不清，或混有较多装饰设定。
@@ -105,9 +171,23 @@ feeds: design_only
 ## checklist
 ```checklist
- [ ] 核心体验写的是用户反复获得什么，而非题材或剧情简介？
+- [ ] `体验锚定` 三项（站位、核心感觉、轮转停点）都已写出？
 - [ ] 美学纲领写的是用户反复获得什么、怎样发生，而非题材或剧情简介？体验内核能直接给游玩层读？
 - [ ] 背景与规则是删掉就会破坏体验的最小内核？
- [ ] 参与边界明确模型可代演、用户保留权和停笔时机？
+- [ ] 交互范式逐类写清描写权限、后果裁定和停笔时机，并且在保护美学纲领？
 - [ ] 未扩写舞台百科、硬机制、具体文风或推进方案？
 - [ ] 产物正文不含评分、诊断、追问和开放问题？
 ```
 ## examples
 ```examples
 好：
 - brief 点题「垄断生存资源的绝对掌控感」；美学纲领的体验内核写清掌控感从哪一刻成立、靠什么反复兑现，边界与尺度照用户原话；交互范式写明 user 的抉择只由用户做、模型可补身体反应与习惯动作、NPC 的屈服与反抗由模型裁定、每次 NPC 给出回应后停笔。
 坏：
 - 只有一段散文纲领，三块没有拆成对象。
 - 百科式背景堆砌，看不出体验靠哪条前提成立。
 - 交互范式只写「尊重玩家选择」，没说言语、行动、反应各由谁写。
 - 在正文里写评分、追问或「待确认」清单。
 ```
@@ -58,7 +58,7 @@ modules:
    mount: [world-simulator]
    declaration: >-
      钉清 @玩家 扮演的那个人：名字、背景、特殊设定（身份/金手指等）；
-      自动写入时加性格。代入有名片时排本步；可 设计.主角设定#短码 与开场白同槽绑定；禁止把名字/简介写进开场白正文。
+      自动写入时加性格。代入有名片时排本步，写各开场共通的部分；各开场不同的玩家角色写在开场白的 meta.用户角色，由程序同步为同短码主角设定；禁止把名字/简介写进开场白正文。
    artifact: 设计.主角设定
  # —— 世界与内容 ——
@@ -141,7 +141,7 @@ modules:
    mount: [world-simulator, narrator]
    declaration: >-
      从偏好库选取约束，只选定一种用户输入用法，
-      并写清扩写/续写定义、比例与 OOC 处理；不写遣词
+      并写清每一轮里扩写（演本轮材料）与续写（材料后往下写）的定义、比例与 OOC 处理；不写遣词
    artifact: 设计.故事推进
  # —— 机制与数据 ——
@@ -243,7 +243,7 @@ modules:
    declaration: >-
      普通楼层创作终节点，且可增殖：每条开场各占一个节点（设计.开场白#场景短码）。
      默认 1 条；还要入口就再增殖。全部保存。游玩时左右切换，选中的一条作为 0 层
-    artifact: 设计.开场白与开场变量
+    artifact: 设计.开场白
  - id: zero-layer-opening-setup
    name: 0层开场白与初态
@@ -35,6 +35,8 @@ feeds: gm
 有生成规则时：认定规则的中文名，按规则的字段、池或提示、填写工作流生成这一条；用户已写明的专名与结果只扩写不改写，未写字段从已有材料往下补满。无规则且只是一条字段很少的具名内容时：直接写用户给出的字段。
 规则的一次生成为同批时：一次 insert 写齐本批，`记录` 写成数组，每项一条记录并带上规则里的姓名或名称字段，程序按条拆成多份。先定各条如何互指、对立、同场，再填各条字段。
 材料足够便直接成稿。缺的是合同本身时，先回到生成规则，不在这里补合同。产物正文不放评分、诊断、追问或开放问题。
 ```
@@ -44,10 +46,13 @@ feeds: gm
 1. 有规则：字段名、取值方式、工作流阶段与依赖都以规则为准；不增删字段，不改池。
 2. 池选取按合理度选择，不是程序抽签；提示约束按那句话的范围写开。
 3. 按填写工作流推进：先骨架后血肉；阶段依赖与自检能核对的，生成后要能过。
-4. 一份产物一条记录。多条各自成稿，用中文名称区分。
+4. 一份产物一条记录。单条规则一次写一条；多条各自成稿，用中文名称区分。
-5. 无规则只写用户点名的那一条，字段保持很少；不借机发明完整人设合同。
+5. 同批规则一次写齐本批：先对齐关系，再填字段；各条里互指的专名与关系必须一致（甲记乙为仇敌，乙也记甲，且说的是同一件事）。有关系的人在同一次里写完，不拆到不同轮。
-6. 用户已写明的专名、关系、结果保持原样，只做厚度扩写；未写字段从这些材料延伸。
+6. 句子级字段写到规则 `地板` 规定的可感知程度；词条、档位、数字可以短。句子级字段只丢一个词不算填完。
-7. 给人读的键和专名用中文。材料里的英文名音译成中文，不把英文原名留在字段值里。外壳的 schema、brief、mount 保持既有键。
+7. 分级字段只填档位短值（如「金丹」）；表象留在规则的分级表现里，不复制进每条记录。
 8. 无规则只写用户点名的那一条，字段保持很少；不借机发明完整人设合同。
 9. 用户已写明的专名、关系、结果保持原样，只做厚度扩写；未写字段从这些材料延伸。
 10. 给人读的键和专名用中文。材料里的英文名音译成中文，不把英文原名留在字段值里。外壳的 schema、brief、mount 保持既有键。
 ```
 ## output
@@ -70,7 +75,7 @@ feeds: gm
 ```
 硬规则：
-1. 输出合法 JSON。`记录` 是单个对象。`名称` 用中文，并与这条记录的主名称一致。
+1. 输出合法 JSON。`记录` 是单个对象；规则为同批时写成至少 2 项的对象数组，每项带姓名或名称。`名称` 用中文，并与这条记录的主名称一致。
 2. 有规则时 `记录` 的键必须来自该规则字段，不得增删。
 3. 无规则时省略 `规则`，`记录` 只含用户给出的少量简单字段。
 4. 字段名和专名用中文；英文专名音译为中文。
@@ -81,9 +86,9 @@ feeds: gm
 ```score
 工作流符合度：
- 5：严格按规则填写工作流推进；字段、池选取、依赖与自检都落实；无规则路径则字段简单够用且不越权发明合同。
+- 5：严格按规则填写工作流推进；字段、池选取、依赖与自检都落实；句子级字段达到地板；同批各条互指一致；无规则路径则字段简单够用且不越权发明合同。
- 3：大体按工作流，但有一处阶段跳跃、依赖未咬合，或某字段明显偏薄。
+- 3：大体按工作流，但有一处阶段跳跃、依赖未咬合，或某句子级字段明显低于地板。
- 1：忽略工作流；乱增字段；或把用户已定内容改掉。
+- 1：忽略工作流；乱增字段；句子级只填一个词；同批互指对不上；或把用户已定内容改掉。
 ```
 ## checklist
@@ -91,7 +96,18 @@ feeds: gm
 ```checklist
 - [ ] 有规则则按字段与填写工作流执行；无规则则只是一条字段很少的具名内容？
 - [ ] 一份产物只有一条记录，名称是中文？
 - [ ] 同批规则已一次写齐，各条互指的专名与关系一致？
 - [ ] 句子级字段达到地板？分级字段只填档位短值？
 - [ ] 记录键值合法，用户已定专名未改写，英文专名已音译？
 - [ ] 未改合同？
 - [ ] 产物正文不含评分、诊断、追问？
 ```
 ## examples
 ```examples
 好：规则一次生成=同批、关系=开局仇敌二人 → 一次写齐 2 条，甲的仇敌字段写乙与夺位之事，乙的写甲与同一件事，两条对得上。
 坏：记录里加了规则没有的字段（规则无「性别」却写进去）。
 坏：规则要求句子级的「气质」只填「阴郁」，没达到地板。
 坏：同批的仇敌二人分两轮各写各的，互指的名字和事由对不上。
 ```
@@ -31,7 +31,7 @@ feeds: gm,auditor
 ## task
 ```task
-为单一对象族写出一份生成合同，写入 `设计.生成规则#中文规则名`。先写名称与用途，再按用途推出字段与每项填充要求；需要封闭选取的字段绑池，更适合一句话约束的字段写提示；最后写填写工作流（含依赖、自检、反模式），供具体实例与游玩期动态生成共用。
+为单一对象族写出一份生成合同，写入 `设计.生成规则#中文规则名`。先写名称与用途，再按用途推出字段与每项填充要求；描写类字段写明地板，标签看不懂的分级另写分级表现；需要封闭选取的字段绑池，更适合一句话约束的字段写提示；最后写填写工作流（含依赖、自检、反模式），供具体实例与游玩期动态生成共用。
 每个产物只含一条规则。材料足够便直接成稿；真正会改合同的缺口（生命周期、必填字段、单条/同批关系）交给 `self_score.gap`。产物正文不放评分、诊断、追问或开放问题。
 ```
@@ -39,15 +39,20 @@ feeds: gm,auditor
 ## principles
 ```principles
-1. 用途决定字段：每个字段都要能回答「对这个用途是否必要」；女 NPC 不写性别；药水要写清效果参数，不要只写外观。
+1. 用途决定字段：每个字段都要能回答「对这个用途是否必要」；女 NPC 不写性别；药水要写清效果参数，不要只写外观；怪物这类要接战斗的，等级、攻击骰等玩法接口不能漏。
 2. 字段不多不少、互不重叠：资产与存款这类同义字段只留一个。
-3. 取值分三类：自由生成；从池中选取（填写方按合理度选，不是伪随机程序）；提示约束（如「现代都市中正常的职业」）。默认优先提示约束；只有需要封闭一致或分阶段选型时才建池。
+3. 取值分三类：自由生成；从池中选取（填写方按合理度选，不是伪随机程序）；提示约束（如「现代都市中正常的职业」）。默认优先提示约束；只有能数完、必须全员一致的封闭集合（阶层、强度档、武器种类）或分阶段选型时才建池。
-4. 填写工作流按重要性推进：先锚定会约束后续的选项，再填血肉；阶段、依赖、自检、反模式都服务于「怎么填对」，写短写准。
+4. 姓名、绰号、能力概念、外貌、气质写不完：用自由或提示约束，不建池，也不在填充要求或提示里列一串可选值冒充穷举。要反复生成又怕雷同时，`提示` 可写 2～6 个「方向名：一句概括」划多样的范围；方向不挂作品名、不堆例句。
-5. 生命周期三选一：`仅游玩期`（创作期不预填）、`只预生成`（预填完即可丢掉规则）、`预生成并游玩期`（既写种子，开场后仍可再生成）。选哪一档不改变「要不要先写这份合同」。
+5. 描写类字段（外貌、能力现象、限制、互动手感等）写 `地板`：最低要写到读者能看见、听见或碰到什么，对手能抓住什么空隙。词条、档位、数字、骰子可以短，不写地板。规则里出现的示例必须达到地板，不用「气质：阴郁」「能力：时空斩」这种单标签当示例。
-6. `只预生成` 为中间层；另两类为最终层，挂主世界层与旁观。
+6. 标签本身看不懂的分级（境界、品阶、强度档、好感档）另写 `分级表现`：每档一句概括 + 一段可感知表象，相邻档必须能分清。实例字段只填档位短值，叙事按此表展开。
-7. 上游舞台/机制只短引用；不在本步发明共通前提百科。
+7. 外貌、服装、仪式等几面拼成一格的字段，在该字段 `填充要求` 里写配方：用哪几面、每面写什么、怎么拼成一段。字段仍是一个扁平值，不拆嵌套对象，也不为每一面各建池。
-8. 不输出最终实例记录。
+8. 填写工作流按重要性推进：先锚定会约束后续的选项，再填血肉；阶段、依赖、自检、反模式都服务于「怎么填对」，写短写准。会反复生成的规则，自检清单要含去重：与已有记录不撞名、不撞核心特征。
-9. 给人读的键和专名用中文。材料里的英文名音译成中文。外壳的 schema、brief、mount 保持既有键。
+9. 生命周期三选一：`仅游玩期`（创作期不预填）、`只预生成`（预填完即可丢掉规则）、`预生成并游玩期`（既写种子，开场后仍可再生成）。选哪一档不改变「要不要先写这份合同」。
 10. `只预生成` 为中间层；另两类为最终层，挂主世界层与旁观。
 11. `数量` 与 `一次生成` 是两件事：`数量` 是总共几条；`一次生成` 看记录之间有没有必须一起钉死的关系（互指、对立、同场），不看总数。有 → 同批，`关系` 只写谁对谁；彼此独立 → 单条。「总共 5 个」不等于同批。
 12. 多张名片共享的台上格局、世界状况、既成法则归舞台骨架或实现机制：已有则在 `用途` 或 `填充要求` 里短引用；没有则只写填写时必须守的最短条款，缺口交 `self_score.gap`。不在规则里重抄「共通前提」长文，也不借 `关系` 写前史与社会律。
 13. 不输出最终实例记录。
 14. 给人读的键和专名用中文。材料里的英文名音译成中文。外壳的 schema、brief、mount 保持既有键。
 ```
 ## output
@@ -78,10 +83,11 @@ feeds: gm,auditor
    "字段": [
      {
        "名": "顶层字段名",
-        "填充要求": "填什么、填到多厚、为何本用途需要它",
+        "填充要求": "填什么、填到多厚、为何本用途需要它；几面拼一格的写配方（哪几面、各写什么）",
        "取值方式": "自由|池选取|提示约束",
        "绑定池": "池选取时填写池名称；其它省略",
-        "提示": "提示约束时写可执行的一句范围；其它省略"
+        "提示": "提示约束时写可执行的一句范围，或 2～6 个「方向名：一句概括」；其它省略",
        "地板": "描写类字段写：最低填到什么可感知程度；词条、档位、数字省略"
      }
    ],
    "池": [
@@ -91,6 +97,18 @@ feeds: gm,auditor
        "条目": ["封闭可选项；只列必须一致的有限集合"]
      }
    ],
    "分级表现": [
      {
        "字段": "标签看不懂的分级字段名；无此类分级则省略整个键",
        "档位": [
          {
            "值": "档位短值，与实例所填一致",
            "概括": "一句：这档能做到什么量级",
            "表象": "看见、听见、碰到什么；须能和上下档分清"
          }
        ]
      }
    ],
    "填写工作流": {
      "工作流": {
        "阶段1 骨架锚定": "先选哪些池/字段、定下什么内核",
@@ -119,29 +137,30 @@ feeds: gm,auditor
 硬规则：
 1. 输出合法 JSON；每个产物只描述一条规则，禁止 `rules` 数组堆多条。
 2. `字段` 由用途推出；可省略的字段不写；重叠字段合并。
-3. `池` 可 `[]`；池选取字段必须能对应到某个池；提示约束字段必须有 `提示`。
+3. `池` 可 `[]`；池选取字段必须能对应到某个池；提示约束字段必须有 `提示`。姓名、绰号、能力概念、外貌、气质不绑池。
 4. `填写工作流` 必含 `工作流`；`依赖关系` / `自检清单` / `反模式` 为子字段，无则 `[]`，不要拆成正文顶层并列大段。
 5. `一次生成` 为同批时关系必填且本批至少 2 条；为单条时一次只交 1 条。
-6. 字段值为扁平可填内容；不要嵌套对象当字段值契约。
+6. 字段值为扁平可填内容；不要嵌套对象当字段值契约。几面拼一格的配方写在 `填充要求`。
-7. 不在产物正文写自评、追问、开放问题或最终记录。
+7. 描写类字段必须有 `地板`；规则里任何示例都要达到地板。标签看不懂的分级必须在 `分级表现` 写齐每档；没有此类分级则省略 `分级表现`。
-8. `只预生成` 时程序记为中间层；`仅游玩期` / `预生成并游玩期` 记为最终层。
+8. 不在产物正文写自评、追问、开放问题或最终记录。
-9. 字段名和专名用中文；英文专名音译为中文。
+9. `只预生成` 时程序记为中间层；`仅游玩期` / `预生成并游玩期` 记为最终层。
 10. 字段名和专名用中文；英文专名音译为中文。
 ## score
 ```score
 字段妥当：
- 5：字段由用途推出，不多不少、不重叠；该有的玩法/效果接口齐全，该省略的已省略。
+- 5：字段由用途推出，不多不少、不重叠；该有的玩法/效果接口齐全，该省略的已省略；描写类字段有达到可感知的地板，难懂分级有分级表现。
- 3：大体可用，但有 1 个冗余、重叠或明显缺失字段。
+- 3：大体可用，但有 1 个冗余、重叠或明显缺失字段，或个别描写字段地板含糊、某档分级只有阶名。
- 1：通用名片乱塞，或关键效果/接口字段缺失。
+- 1：通用名片乱塞，或关键效果/接口字段缺失；描写字段与示例都是单标签。
 池与提示：
- 5：该用池的用了，不该用的改成一句提示约束；池精炼可选取；提示具体可执行。
+- 5：只有封闭集合用池，不可穷举项用提示或自由；提示具体可执行，方向式提示以「方向名：一句概括」为主、不挂作品名。
 - 3：大体合理，但个别字段误用/漏用池，或池过泛、提示含糊。
- 1：大段假穷举，或本该一句话提示却做成巨型词表。
+- 1：为姓名、气质、能力等建词池，大段假穷举，或本该一句话提示却做成巨型词表。
 填写工作流：
- 5：阶段简洁有力，依赖与自检/反模式能引导按重要性推进，不臃肿。
+- 5：阶段简洁有力，依赖与自检/反模式能引导按重要性推进，反复生成时含去重，不臃肿。
 - 3：有阶段但顺序或依赖不清，或清单偏长却抓不住关键咬合。
 - 1：无工作流，或与字段脱节，无法指导动态生成。
 ```
@@ -151,8 +170,30 @@ feeds: gm,auditor
 ```checklist
 - [ ] 名称与用途已写清？
 - [ ] 字段由用途推出，无冗余重叠、无关键缺失？
- [ ] 池与提示分工正确？
+- [ ] 池与提示分工正确？姓名、绰号、能力、外貌、气质没有建池？
- [ ] 填写工作流含子字段：工作流 / 依赖关系 / 自检清单 / 反模式？
+- [ ] 描写类字段有地板，示例不是单标签？难懂分级有分级表现？
- [ ] 生命周期与一次生成已钉？
+- [ ] 几面拼一格的字段在填充要求里写了配方？
 - [ ] 填写工作流含子字段：工作流 / 依赖关系 / 自检清单 / 反模式？反复生成时自检含去重？
 - [ ] 生命周期已钉？一次生成按关系定，而非按总数？
 - [ ] 共享格局只引用舞台骨架，没有重抄共通前提？
 - [ ] 未输出最终实例、百科长文、评分或追问？
 ```
 ## examples
 ```examples
 好：
 - 武功典籍：字段为名字 / 效果 / 阶层。阶层池选取封闭档位，另写 `分级表现`，每阶一句概括 + 可感知表象；名字与效果用提示约束。
 - 女主规则：不设「性别」；池为 `[]`；内在冲突自由写，地板是「能在一场戏里演出来的两难」。
 - D&D 怪物：名称、等级、攻击骰齐全；气质用提示约束，地板写到一个可观察的习性。
 - 外貌：`填充要求` 写配方「轮廓一句 + 质感一句 + 一个旁人会记住的细节」，拼成扁平的一段「外貌」。
 - 互为仇敌的两名开局 NPC → 一次生成=同批，关系写谁夺了谁的什么；可互换的酒馆路人 → 单条；总共要 5 个但彼此无关 → 数量 5、一次生成单条。
 坏：
 - 为气质、绰号、能力各建一个 8～20 词的池，填出来全是标签。
 - 提示里的方向每条挂作品名或例句，变成假选项库。
 - 示例写「气质：阴郁」「能力：时空斩」，地板被示例教坏。
 - 阶层只写「A」「金丹」，没有分级表现，叙事时无从下笔。
 - 把社会格局、前史写成「共通前提」长文塞进规则，而不是引用舞台骨架。
 - 女主规则塞「性别」；怪物规则只有名字和性格，没有等级、攻击骰。
 ```
@@ -11,8 +11,7 @@ declaration: >
 when: |
  本局存在拿掉后会改变故事骨架的既成法则，且后续需要据此推演环境变化、事件后果或人物反应时使用。
 when_not: |
-  只有熟悉常识，没有特殊因果法则 → 不使用。
+  只有熟悉常识，没有特殊因果法则 → 不使用。  「特殊」只是身份或开场处境、能被舞台骨架、具体实例或开场白覆盖（如现实世界里模拟一名普通大学生）→ 不使用。  地点、势力与社会格局 → 舞台骨架；多份人物或要先审字段的名片 → 生成规则，单条字段很少的具名内容才归具体实例；字段合同 → 生成规则。
  地点、势力与社会格局 → 舞台骨架；多份人物或要先审字段的名片 → 生成规则，单条字段很少的具名内容才归具体实例；字段合同 → 生成规则。
 boundary: |
  本能力交稳定因果，不预写唯一剧情，也不把所有人物钉成同一种反应。
  不解释起源，不扩写世界百科，不制定推进节奏、变量表或检定公式。
@@ -39,12 +38,16 @@ feeds: gm
 ```principles
 1. 机制是稳定因果：写世界承认什么、何时生效、会带来什么后果。
-2. 内部使用移除检验筛选承重法则；只能回答“更丰富”或“以后也许有用”的候选不纳入。缺失后果不输出。
+2. 法则可以是超常前提、约束性公理，也可以是社会性或规范性的既成事实，如“这个世界没有花里胡哨的魔法，只有繁衍到极致的斗气”“这个西幻世界里男尊女卑是常态”“这里以三国杀高手为尊”。同一设定有很多面向，只写后续推演必须承认的那一面。
-3. 因果影响写行动可能性、代价、资源与关系怎样改变；推演口径写推演情节和人物反应时必须考虑什么。
+3. 身份特殊、开场处境特殊不是法则：能由舞台骨架、具体实例或开场白承担的（如现实世界里的普通大学生），不写成机制。
-4. 人物反应保持开放：同一机制下，人物可因认知、利益、身份和性格不同而隐藏、合作、利用、抵抗或误判。
+4. 内部使用移除检验筛选承重法则；只能回答“更丰富”或“以后也许有用”的候选不纳入。缺失后果不输出。
-5. 多条机制可一次生成。分别写清后，再说明它们是前提、叠加、制衡还是反馈循环；没有关系则不硬连。
+5. 内部按基准世界做最小充分继承，校验过程不写入产物：现实地球沿用现实物理、心理与社会规律；变造地球只在用户已表达或体验依赖处承认变造；具体作品世界优先最近一层作品设定，原作未定义处再参考其底层世界；类型世界只继承与当前体验有关的类型约定；从头创造以显式设定为准，未定义处用最少常识；混合或二创只处理与当前法则有关的继承与变造。
-6. 机制不等于题材标签。“灵气复苏”“全民直播求生”必须拆成可推演的生效方式与因果链。
+   候选法则超出基准世界已知可能性时，只有用户材料已明示或体验确实依赖才写入，不暗中变造；拿不准是否在用户设想中，就不写进产物，把这处变造交给 `self_score.gap`。
-7. 一句话够用便停止；不补起源史、体系百科、人物卡、剧情大纲或推进节奏。
+6. 因果影响写行动可能性、代价、资源与关系怎样改变；推演口径写推演情节和人物反应时必须考虑什么。
 7. 人物反应保持开放：同一机制下，人物可因认知、利益、身份和性格不同而隐藏、合作、利用、抵抗或误判。
 8. 多条机制可一次生成。分别写清后，再说明它们是前提、叠加、制衡还是反馈循环；没有关系则不硬连。
 9. 机制不等于题材标签。“灵气复苏”“全民直播求生”必须拆成可推演的生效方式与因果链；题材标签也不能代替“这条法则缺了故事会换”。能指明它支撑美学纲领里哪段体验时，写进 `服务体验`。
 10. 一句话够用便停止；不补起源史、体系百科、人物卡、剧情大纲或推进节奏。
 ```
 ## output
@@ -60,7 +63,8 @@ feeds: gm
    "既成机制": [
      {
        "名称": "简短稳定的人话名",
-        "法则内容": "世界中稳定成立什么",
+        "法则内容": "世界中稳定成立什么；可以是超常前提、公理，也可以是社会常态或规范",
        "服务体验": "一句话说明它支撑美学纲领里的哪段体验；无明确对应则省略",
        "生效方式": [
          "对谁、在什么条件下、以什么方式起作用"
        ],
@@ -89,7 +93,7 @@ feeds: gm
 硬规则：
 1. 输出合法 JSON；`既成机制` 可含多条承重机制。
 2. `缺失后果`、移除检验和被淘汰候选只用于内部推理，不得进入正文。
-3. 每条机制必须写 `法则内容 / 生效方式 / 因果影响 / 推演口径`。
+3. 每条机制必须写 `法则内容 / 生效方式 / 因果影响 / 推演口径`；`服务体验` 与 `边界或例外` 可选。
 4. `共同作用` 只写真实存在的机制关系；无则 `[]`。
 5. 推演口径提供因果依据，不指定唯一剧情，也不规定所有人物作同一种反应。
 6. 不在产物正文写自评、追问、开放问题、起源百科或检定公式。
@@ -101,7 +105,7 @@ feeds: gm
 骨架必要度：
 - 5：每条都是拿掉后会改变故事骨架的承重法则，没有常识、装饰或下游细节。
 - 3：主体承重，但夹有一条作用较弱或可交给其它能力的内容。
- 1：只有题材标签或装饰设定，没有稳定承重法则。
+- 1：只有题材标签或装饰设定，或把身份、开场处境、暗中加入的变造写成法则。
 因果清晰度：
 - 5：生效条件与影响链清楚，能据此推演环境、事件和关系怎样变化。
@@ -121,6 +125,7 @@ feeds: gm
 - [ ] 法则内容、生效方式、因果影响与推演口径均可执行？
 - [ ] 多条机制的共同作用已写清，或明确无须关联？
 - [ ] 能支持不同人物作出不同但合理的反应？
 - [ ] 未把身份或开场处境写成法则？超出基准世界的变造都来自用户材料或体验依赖？
 - [ ] 未写成题材标签、世界百科、剧情大纲或裁定表？
 - [ ] 产物正文不含评分、诊断、追问？
 ```
@@ -136,4 +141,14 @@ feeds: gm
 - 可拆为“强制进入求生场”“关键行为公开直播”“观众反馈可进入场内（若本局采用）”等多条机制。
 - 公开评价与即时生存会共同改变选择代价；人物是否表演、隐藏或利用镜头，应由其是否在乎声誉、是否相信能返回现实等条件推出。
 - 观众若只能观看，就不能推演出打赏资源；边界会直接改变因果链。
 好：
 - 社会常态类法则“这个西幻世界里男尊女卑是常态”：生效方式写继承、婚配、对外交涉由谁做主；因果影响写女性角色行动的额外代价与绕行渠道；推演口径写人物可能顺从、利用或反抗，不规定人人同一态度。
 - “这个世界没有花里胡哨的魔法，只有繁衍到极致的斗气”：只写斗气是唯一超常力量、怎样决定地位与胜负，不展开境界百科。
 - 公理“黑暗森林”：一句话钉“暴露坐标即招来打击，文明默认隐藏”；后续情节不能靠对外广播求援收场，不写宇宙社会学论文。
 坏：
 - 现实世界模拟普通大学生，把“主角是普通大学生”写成机制：这是身份与开场处境，交给具体实例或开场白；没有特殊法则就不使用本能力。
 - 二创里暗中加入原作没有的力量体系（如在无超能力的原作里写入“觉醒异能”）：用户未设想的变造不写入，拿不准时交给 `self_score.gap`。
 - 只写“灵气复苏”“末世”等题材标签，没有生效方式与因果链：主世界层无法据此推演任何后果。
 ```
@@ -7,18 +7,18 @@ name: 叙事指南
 id: narrative-guide
 artifact: 设计.叙事指南
 declaration: >
-  从文风库选取本局写法，落成可执行的遣词要求、笔墨落点、少量禁忌与可选写法档；不钉故事怎么往前。
+  继承美学纲领与交互范式，从文风库选取本局写法，落成可执行的遣词要求、视角执行、段落形态、笔墨落点、少量禁忌与可选写法档；不钉故事怎么往前。
 when: |
-  已有美学纲领（或等价），但游玩正文仍不知道怎么写：遣词什么要求、笔墨落谁身上、场合是否要换写法档、有哪些绝对不能写。
+  已有美学纲领（或等价），但游玩正文仍不知道怎么写：遣词什么要求、视角怎么落笔、笔墨落谁身上、场合是否要换写法档、有哪些绝对不能写。
-  用户主动谈文风、措辞、写法档时也使用。
+  用户主动谈文风、措辞、叙述声音、写法档时也使用。
 when_not: |
  本技能只给对话落盘。工序编排不排本步（编排池是「叙事指南与故事推进」）。
  美学未钉 → 先「美学纲领与交互范式」。
  用户明确说本局不用文风细则，且美学里已有可执行遣词方向 → 可不使用。
-  只谈推进、输入用法 → 「故事推进」。版式 → 「正文组成」。字数与可见区域 → 「回复呈现」。
+  只谈推进、输入用法 → 「故事推进」。单轮字数与篇幅 → 「故事推进」；可见区域 → 「回复呈现」。版式 → 「正文组成」。
 boundary: |
-  本能力只交怎么写：选用文风、遣词要求、笔墨落点、少量绝对禁忌、可选写法档。
+  本能力只交怎么写：选用文风、遣词要求（含叙述声音、视角执行、段落形态）、笔墨落点与代入取向、少量绝对禁忌、可选写法档。
-  推进与输入用法归故事推进；体验契约归美学纲领。
+  推进、输入用法、单轮字数与篇幅归故事推进；体验契约、人称与叙事视角的定义归美学纲领与交互范式。
 feeds: narrator,gm
 ```
@@ -31,9 +31,9 @@ feeds: narrator,gm
 ## task
 ```task
-把本局写法整理为叙事指南，写入 `设计.叙事指南`。先用 `read_library_entry` 从绑定的文风库读取最相关条目（默认 1～2；确需第三种时须写 reason 并标明适用场合），再按本局体验本局化，写成可执行的风格推荐与要求。
+把本局写法整理为叙事指南，写入 `设计.叙事指南`。先继承上游「美学纲领与交互范式」：把 `美学纲领.体验内核`、`呈现要点.描写焦点` 与 `呈现要点.边界与尺度` 改写成做法向句子；`交互范式` 已定的人称与叙事视角不重定义，只在 `遣词.视角` 写怎么执行。再用 `read_library_entry` 从绑定的文风库读取最相关条目（默认 1～2；确需第三种时须写 reason 并标明适用场合），按本局体验本局化，写成可执行的风格推荐与要求。
-产物回答：选了哪些文风、各自用在什么场合；遣词与笔墨要怎么做；只有少数绝对禁忌。除禁忌外，少写“不要怎样”，多写“要怎样”。不写示范段落，不写推进与输入用法。
+产物回答：选了哪些文风、各自用在什么场合；遣词、视角执行、段落形态与笔墨要怎么做；叙述声音与代入取向（推得出才写）；只有少数绝对禁忌。除禁忌外，少写“不要怎样”，多写“要怎样”。不写示范段落，不写推进、输入用法或单轮字数。
 材料足够便直接成稿；真正会改写法的缺口交给 `self_score.gap`。产物正文不放评分、诊断、追问或开放问题。
 ```
@@ -41,12 +41,16 @@ feeds: narrator,gm
 ## principles
 ```principles
-1. 文风库是参考，不是照抄：读取后改成本局可执行要求，并记下适用场合与微调。
+1. 美学写要什么感受，本步写怎么遣词、笔墨落哪。已在美学写清的感受不重问，直接改写成做法：体验内核与描写焦点落成详写对象和写法要求；边界与尺度按美学给的用法写进写法要求或写法档，只把其中真正碰不得的收进禁忌。
-2. 优先 1～2 种文风；确需第三种时，每种都必须有清晰切换场合，禁止无差别堆叠。
+2. 文风库是参考，不是照抄：读取后改成本局可执行要求，并记下适用场合与微调。
-3. 写法用“风格推荐 + 要求”表达：对象、节奏、注意力落点、句段形态都写成要做什么。示范段落不写。
+3. 优先 1～2 种文风；确需第三种时，每种都必须有清晰切换场合，禁止无差别堆叠。
-4. 绝对禁忌只留真正碰不得的少数几条；其余偏好都改成正向做法。
+4. 写法用“风格推荐 + 要求”表达：对象、节奏、注意力落点、句段形态都写成要做什么。示范段落不写。
-5. 写法档是多文风/多调性容器：有切换才写，无切换整项省略。场合名要能指导何时切入，不是具体剧情桥段清单。
+5. 段落形态默认值：用户未提段落形态时，`遣词.写法要求` 写入「完整长自然段叙述，不要单句成段」；用户另定则按用户写。段落形态归本步，单轮字数与篇幅归故事推进。
-6. 不写故事推进、输入用法、字数区间或版式壳。
+6. 视角只写执行：人称、主要视角、可写内心、不呈现的信息以交互范式为准，本步写落笔做法——镜头距离（贴身 / 中景 / 远观，何时拉近）；内心写到哪（只写交互范式允许写内心的一方，其余人物用外显言行与身体反应表现）；如何不漂人称（全文固定一种称呼，回忆、转述与内心独白也不换人称）。交互范式未定视角时按美学站位取最贴的写法，并在 gap 写明。
 7. `叙述者` 写叙述声音：冷眼旁观、调侃、贴身低语等，以及它对人物的态度。`代入取向` 写笔墨替谁看、读者站在谁那边。两项都从美学站位与体验推出；推不出或与视角执行重复时省略。
 8. 绝对禁忌只留真正碰不得的少数几条；其余偏好都改成正向做法。
 9. 写法档是多文风/多调性容器：有切换才写，无切换整项省略。场合名要能指导何时切入，不是具体剧情桥段清单。用户报出「当众折辱」「独处一室」这类具体场合时，判断它要哪种写法，升一档写进对应写法档的适用场合与写法要求（感官密度、节奏、对话长短、详略），场合本身不单列；每档写清切入与切回。
 10. 不写故事推进、输入用法、单轮字数与篇幅（归故事推进）或版式壳。
 ```
 ## output
@@ -68,19 +72,34 @@ feeds: narrator,gm
    ],
    "遣词": {
      "整体取向": "本局叙述应呈现的风格方向",
      "叙述者": "可选：叙述声音，如冷眼旁观 / 调侃 / 贴身低语，及它对人物的态度；无则省略",
      "风格推荐": ["优先采用的节奏、用词层级、句段形态"],
-      "写法要求": ["要写到什么密度、如何处理对话与叙述、注意力放哪"]
+      "写法要求": [
        "完整长自然段叙述，不要单句成段（用户另定段落形态则改写）",
        "要写到什么密度、如何处理对话与叙述、注意力放哪"
      ],
      "视角": {
        "镜头距离": "如：贴身跟随 user，冲突时拉近到手与眼神，转场时拉远一句带过",
        "内心": "如：只写 user 的内心；NPC 只写外显言行与身体反应",
        "人称": "如：全文第二人称「你」，回忆与内心独白不换人称"
      }
    },
    "笔墨焦点": {
      "代入取向": "可选：笔墨替谁看、读者站在谁那边；无则省略",
      "详写": ["应花笔墨的对象与感受"],
      "可略": ["可一带而过的部分"]
    },
    "禁忌": ["仅少数绝对不能写的内容；无则省略"],
    "写法档": [
      {
-        "名字": "档名，如展示情色 / 网文爽文",
+        "名字": "展示情色",
-        "适用场合": "何时切到这一档",
+        "适用场合": "切到身体与权力交换时；用户报的「独处一室」这类场合升到这一档",
-        "写法要求": "这一档要怎么写、笔墨落哪、如何切回"
+        "写法要求": "感官词加重、节奏放慢、对话变短；切回日常则收"
      },
      {
        "名字": "网文爽文",
        "适用场合": "打脸、反转时；用户报的「当众折辱」之后的反击升到这一档",
        "写法要求": "可复述对方原话、结果写满、过程可略；反转落定后切回默认文风"
      }
    ]
  }
@@ -91,41 +110,53 @@ feeds: narrator,gm
 1. 输出合法 JSON；`选用文风` 默认 1～2 项，最多 3 项，每项必须有适用场合与本局要求。
 2. 不写示范段落、示例正文或仿写样章。
 3. 除 `禁忌` 外，正文以正向要求为主；空话氛围词改成可执行做法。
-4. `写法档` 无切换时整项省略；有则每档写清场合与写法要求。
+4. 用户未定段落形态时，`遣词.写法要求` 必含「完整长自然段叙述，不要单句成段」。
-5. 不在产物正文写自评、追问、开放问题或推进/输入用法。
+5. `遣词.视角` 只写交互范式人称与视角的执行，不改人称、不扩大可写内心的范围。`叙述者`、`代入取向` 可选，无则省略。
-6. `mount` 固定包含 `narrator` 与 `world-simulator`。
+6. `写法档` 无切换时整项省略；有则每档写清场合与写法要求；具体场合升档写入，不单列桥段。
 7. 不在产物正文写自评、追问、开放问题，或推进、输入用法、单轮字数。
 8. `mount` 固定包含 `narrator` 与 `world-simulator`。
 ## score
 ```score
 遣词可执行：
- 5：风格推荐与要求具体到能直接落笔，无需再猜味道。
+- 5：风格推荐与要求具体到能直接落笔，无需再猜味道；视角执行与段落形态写清。
- 3：大方向清楚，但仍有几处停留在氛围概括。
+- 3：大方向清楚，但仍有几处停留在氛围概括，或视角执行含糊。
 - 1：只有题材或情绪标签，无法指导遣词。
 笔墨与禁忌：
- 5：详略落点清楚；绝对禁忌少而可执行；其余多为正向要求。
+- 5：详略落点清楚，贴合美学的描写焦点与边界尺度；绝对禁忌少而可执行；其余多为正向要求。
 - 3：落点大体有，但禁忌偏多或详略仍含糊。
 - 1：几乎不谈笔墨，或堆满否定句却无正向做法。
 文风选用：
- 5：1～2（偶发 3）条贴合本局；多档时切换场合清楚，无重复堆叠。
+- 5：1～2（偶发 3）条贴合本局；多档时切换场合清楚，具体场合已升档写入，无重复堆叠。
 - 3：选用相关，但场合区分弱，或有一条不够贴。
 - 1：未读库硬编，或多种文风无差别并列。
 本局化：
- 5：库内容已改成本局说法与要求，能看出针对本局体验的取舍。
+- 5：库内容与美学感受已改成本局说法与要求，能看出针对本局体验的取舍。
- 3：有微调，但仍有整段近乎原文搬用。
+- 3：有微调，但仍有整段近乎原文搬用，或重问了美学已写清的感受。
 - 1：基本照抄库条目，或与本局体验脱节。
 ```
 ## checklist
 ```checklist
 - [ ] 已继承美学的体验、描写焦点与边界尺度，改写成做法？
 - [ ] 已按需读取文风库并本局化？
 - [ ] 选用文风 1～2（最多 3），各有适用场合？
- [ ] 遣词是风格推荐与要求，不是示范段落？
+- [ ] 遣词是风格推荐与要求，不是示范段落？用户未定段落形态时已写长自然段默认？
 - [ ] 视角只写执行，未改交互范式的人称与可写内心？
 - [ ] 具体场合已升档写入写法档，未单列桥段？
 - [ ] 除少数禁忌外，多为“要怎样”？
- [ ] 未写入推进、输入用法、字数或版式？
+- [ ] 未写入推进、输入用法、单轮字数或版式？
 - [ ] 产物正文不含评分、诊断、追问？
 ```
 ## examples
 ```examples
 好：美学的「掌控感」落成详写对方的迟疑与屈从、user 的动作从容简短；视角写「第二人称贴身镜头，只写你的内心，NPC 只写外显」；写法要求含长自然段默认；用户提的「当众折辱」升进「网文爽文」档，写清切入与切回。
 坏：重新定义人称或扩大可写内心；把「当众折辱」「独处一室」列成桥段清单；写示范段落；在本步写单轮字数或推进方式。
 ```
@@ -5,10 +5,10 @@
 ```meta
 name: 开场白与开场变量
 id: opening-setup
-artifact: 设计.开场白与开场变量
+artifact: 设计.开场白
 declaration: >
  普通楼层创作终节点，且可增殖：每条开场是一个节点，落成 `设计.开场白#场景短码`。
-  默认写 1 条；用户要多个入口时再增殖。每条自带 present.v1、同真相初态与可选用户角色。
+  默认写 1 条；用户要多个入口时再增殖。每条自带 present.v1、同真相初态与这条开场的最少玩家角色事实。
  全部保存。游玩时左右切换，选中的一条作为 0 层。
 when: |
  回复呈现、正文组成和其它本局内容能力均已完成，且程序已依次编译信息可见范围、游玩执行方式、上下文排序与运行配置后，需要可开玩的第一屏时使用。
@@ -34,22 +34,25 @@ feeds: gm,narrator
 ## task
 ```task
-读取程序已组装的 `设计.worker集` 和全部最终层产物，写入 `设计.开场白与开场变量`。这是普通楼层创作终节点；不得在本步首次整理执行单元或上下文顺序。
+读取程序已组装的 `设计.worker集` 和全部最终层产物，把每一张开场写成 `设计.开场白#场景短码`。这是普通楼层创作终节点；不得在本步首次整理执行单元或上下文顺序。
-默认只生成 1 条开场。用户要多个入口时，每条再增殖一份产物，对话落盘写入 `设计.开场白#场景短码`（如 dorm、gate）；改某一条则覆盖同一完整 tag。不要把多条入口收成聊天里的选择题。每条候选各自携带：
+position 必须带场景短码，例如 `设计.开场白#opening-cycle2`。改某一条就再 insert 同一个完整 tag。裸 `设计.开场白` 和整包 `设计.开场白与开场变量` 会和带短码的卡抢同一条写入，不要使用。
- 稳定 id 与一句区分说明
+
- 可选用户角色名片（不同候选可不同）
+默认只生成 1 条，仍然要带场景短码。用户要多个入口时，每条再 insert 一个新的短码。不要把多条入口收成聊天里的选择题，也不要把多条塞进同一次 insert。游玩时按这些短码左右切换，选中的一条作为 0 层，并整套换该条正文、初态与角色。
- 与该条叙述同真相的变量初值
+
- 若本局有拓扑：当前位置/焦点与已揭示范围
+每一张卡携带：
 - 符合正文组成数据契约的 `present.v1`（只填模型生成区）
-
+- 可选一句区分说明
-全部候选都保存。每条正文只写在该候选的 `正文` 里，不要再抄一份全文或初值。`默认候选id` 指向第一次进入 0 层的那条；程序按这个 id 读取它的正文和初值。游玩时左右切换，选中的一条作为 0 层，并整套换该条正文、初态与角色。
+- 这一条开场的玩家角色 `meta.用户角色`（名字 + 简介）：不同开场的玩家可以不同，写在各自卡里；程序会同步成同短码的主角设定，游玩切到这条时替换 `@玩家`
 - 与该条叙述同真相的变量初值：这张卡有要开场定下的变量才写 `开场变量`；没有就不写，卡仍然是 `设计.开场白#场景短码`
 - 若本局有拓扑：当前位置/焦点与已揭示范围
 硬规格：
-1. 每条可见正文至少出现一次字面 `@玩家`；不写死具体姓名顶名字位。
+1. 可见正文里凡指称玩家角色的名字位都写字面 `@玩家`，每条至少出现一次。「你」可以和 `@玩家` 并用（如「你（@玩家）站在闸机前」），但全文只有「你」、零个 `@玩家` 不合格；不写死具体姓名，也不用「用户」「主角」顶名字位。
 2. `present.v1` 的区域只覆盖正文组成声明的模型生成 blocks；程序投影区留空给程序灌。
 3. 不输出 `名称.随机数` 的具体数组；随机行由程序在第一次正式回复前或回复时补齐。
 4. 开场宜短，愿点进游玩即可，不抄故事推进的单轮篇幅预算当第一章。
 5. 人物、地点、势力只引用已有产物里的；第一拍需要的路人只写身份，不在开场新造有名有姓的设定。
 材料足够便直接成稿；会改变第一拍成立的缺口交给 `self_score.gap`。产物正文不放评分、诊断、追问或开放问题。
 ```
@@ -57,12 +60,13 @@ feeds: gm,narrator
 ## principles
 ```principles
-1. 开场为主，初态配套。叙述与该条变量、拓扑初态必须同真相。
+1. 开场为主，初态配套。叙述与该条变量、拓扑初态必须同真相；写完发现两者对不上时以叙述为准，改初值。
-2. 默认一条。多条是不同入口，每条一个可增殖节点，不是同文换皮，也不是先让用户选唯一开场。
+2. 默认一条。多条是不同入口，每条一个 `设计.开场白#场景短码`，不是同文换皮，也不是先让用户选唯一开场。没有变量的卡省略 `开场变量`，短码照旧。
-3. 用户角色可按候选不同；没有名片时仍用 `@玩家` 占位，进游玩再替换。
+3. 玩家角色最少化：把这个角色交还给用户扮演。`用户角色.简介` 只写这条开场成立所必需的客观事实——身份、处境、与在场人物的已知关系，一到三句；不写性格、心理、动机、口癖、外貌细节，也不替玩家定态度或下一步。共通的主角设定已有的事实不重抄，只写这条开场独有或与它不同的部分。
-4. 只写模型生成区。状态芯片、地图等权威显示由程序投影，不在开场正文里重编一份。
+4. 用户没给名字时不编名字，省略 `用户角色`，正文照用 `@玩家`；这条开场必需的身份事实写进叙述里让玩家看见。
-5. 不剧透隐藏档，不写成第一章，不在本步改前端模板。
+5. 只写模型生成区。状态芯片、地图等权威显示由程序投影，不在开场正文里重编一份。
-6. 本步结束后创作收口；不要再排后续内容能力。
+6. 文风、视角和人称跟叙事指南与交互范式；不剧透隐藏档，不写成第一章，不在本步改前端模板。
 7. 本步结束后创作收口；不要再排后续内容能力。
 ```
 ## probe
@@ -74,22 +78,20 @@ feeds: gm,narrator
 ## output
 ```output
 position: 设计.开场白#场景短码
 content:
 {
-  "schema": "context-fragment.v1",
+  "schema": "present.v1",
-  "技能": "开场白与开场变量",
+  "shell": "与正文组成一致",
-  "brief": "一句话：默认开场场景 + 有几条候选",
+  "blocks": {
-  "mount": ["world-simulator", "narrator"],
+    "body": "清晨，@玩家推开门。……",
-  "稳变": "stable",
+    "其余模型生成区": "read_module 回包 reply_contract.model_blocks 里的每一项都要出现，类型按契约"
-  "正文": {
+  },
    "默认候选id": "opening-1",
    "开场白候选": [
      {
        "id": "opening-1",
        "区分": "这条入口与其它条差在哪；仅一条时可写「默认」",
  "meta": {
    "区分": "多条时写这一入口和其它条差在哪；仅一条可省略",
    "用户角色": {
-            "名字": "可选；无则省略整段",
+      "名字": "用户给过的名字；没给就省略整个用户角色",
-            "简介": "可选"
+      "简介": "一到三句客观事实：这条开场里玩家是谁、处境如何、与在场人物的已知关系"
    },
    "开场变量": [
      {
@@ -104,32 +106,20 @@ feeds: gm,narrator
        "当前位置": "节点 id",
        "已揭示": ["节点或连接 id"]
      }
-          ]
+    ],
        },
        "正文": {
          "schema": "present.v1",
          "blocks": {
            "body": "清晨，@玩家推开门。……"
          },
          "meta": {
    "suggested_actions": ["若正文组成启用文字选项则给短建议；否则 []"]
  }
        }
      }
    ],
    "用户可行动空间": "开场结束后玩家显然能尝试什么"
  }
 }
 ```
 硬规则：
-1. 输出合法 JSON；`开场白候选` 默认 1 条，仅用户明确要求时 2～3 条。
+1. 每次 insert 只写一张卡。position 是 `设计.开场白#场景短码`，content 是这一张的 `present.v1`。
-2. `默认候选id` 必须指向候选之一。正文和初值只写在该候选上，不另抄全文或开场变量。
+2. 这张卡有初值才写 `meta.开场变量`；没有变量就省略该字段，position 仍带场景短码。
-3. 每条 `正文` 必须是 `present.v1`，只含正文组成允许模型生成的 blocks；每条可见正文须含字面 `@玩家`。
+3. `present.v1` 只含正文组成允许模型生成的 blocks；可见正文须含字面 `@玩家`。
-4. 不同候选可有不同用户角色与初态；切换时整套替换，不混用。
+4. 不同卡可有不同用户角色与初态；切换时整套替换，不混用。
 5. 不输出随机数具体值，不重写前端，不把程序投影区填成模型编造状态。
 6. 产物正文不含自评、追问或开放问题。
-7. `mount` 固定为 `["world-simulator", "narrator"]`。
+7. 玩家角色只写在 `meta.用户角色`，名字不进 blocks 正文；程序据此写入同短码的 `设计.主角设定#场景短码`，不要另 insert 一份。
 ```
 ## score
@@ -150,9 +140,9 @@ feeds: gm,narrator
 - 1：叙述与初值冲突，或多条共用一套却声称不同入口。
 角色占位：
- 5：每条含字面 `@玩家`；有名片时不把姓名写进正文名字位。
+- 5：每条含字面 `@玩家`；`用户角色.简介` 只有这条开场必需的客观事实，玩家性格与决定留给用户。
- 3：占位大体正确，有一条名片与正文关系略乱。
+- 3：占位正确，但简介多写了性格、动机或与共通主角设定重复的内容。
- 1：写死姓名，或全文没有 `@玩家`。
+- 1：写死姓名、全文只有「你」没有 `@玩家`，或简介替玩家定了性格和态度。
 收口可切换：
 - 5：默认条明确，全部候选可保存；多条时入口差异成立。
@@ -163,17 +153,22 @@ feeds: gm,narrator
 ## checklist
 ```checklist
- [ ] 默认 1 条；仅用户要求时才有 2～3 条？
+- [ ] position 是 `设计.开场白#场景短码`，没有另写裸 `设计.开场白` 或 `设计.开场白与开场变量`？
- [ ] `默认候选id` 指向一条候选，且该条正文、初值没有在外面再抄一份？
+- [ ] 默认 1 条；仅用户要求时才再增殖别的短码？
- [ ] 每条含 `@玩家`，present.v1 只含模型生成区？
+- [ ] 有初值才写 `开场变量`；没有变量就省略，卡名不变？
- [ ] 各候选初态自洽，未填写随机数具体值？
+- [ ] 含 `@玩家`，present.v1 只含模型生成区？
 - [ ] `用户角色.简介` 只有必需客观事实，没有性格、心理和替玩家做的决定？
 - [ ] 初态与这条叙述同真相，未填写随机数具体值？
 - [ ] 未重开前端、篇幅或区域清单？
 ```
 ## examples
 ```examples
- 单条：堂屋债契，body 含 `@玩家`，开场变量写债额初值；状态栏由程序投影。
+- 单条：`设计.开场白#debt-hall`，堂屋债契，body 含 `@玩家`，开场变量写债额初值；状态栏由程序投影。
- 用户要两条入口：一条放贷人名片、一条社畜穿越名片；各带自己的初态，默认指定其中一条开玩。
+- 用户要两条入口：`设计.开场白#lender` 与 `设计.开场白#office`，各带自己的初态。没有初值的那条省略开场变量。
- 不合适：开场里填写 `敏捷.随机数=[…]`；或把地图权威数据写成模型散文却不给拓扑初态。
+- 单条带玩家角色：`meta.用户角色` 为 `{"名字":"沈聿","简介":"本地放贷人，持有这家的债契；与这对母女相识但不熟。"}`，body 写「清晨，@玩家推开堂屋门，债契还摊在桌上。」
 - 不合适：再写一份裸 `设计.开场白` 或 `设计.开场白与开场变量`；开场里填写 `敏捷.随机数=[…]`。
 - 不合适：全文只有「你推开门」，零个 `@玩家`。
 - 不合适：简介写「沉稳果决，内心渴望被认可，决定今天收回债款」——性格、心理和决定都该留给玩家。
 ```
@@ -37,11 +37,14 @@ feeds: gm
 ```principles
 1. 只设计用户已明确给出、核心体验依赖或运行确实需要的内容。
-2. “首富之子”“唯我独法”等若是核心体验成立条件，属于必要设定，不算过度设计。
+2. 一张脸测试：逐句问「删掉这句，玩家还知道自己是谁吗？」删了仍知道的句子不落盘。
-3. 特殊能力写“能做什么 + 限制”；世界为何如此由实现机制处理。
+3. “首富之子”“唯我独法”等若是核心体验成立条件，属于必要设定，不算过度设计。
-4. `称呼` 可写固定名字，也可写 `@玩家` 表示刻意留白；不要因无名阻塞成卡。
+4. 特殊能力写“能做什么 + 限制”；世界为何如此由实现机制处理。
-5. 行为依据随推进权增减：用户控制越多越简；LLM 代演越多越具体。
+5. `称呼` 可写固定名字，也可写 `@玩家` 表示刻意留白；不要因无名阻塞成卡。
-6. 不写 NPC 名片、世界百科、文风规则或开场事件。
+6. 身份与背景一两句；用户没给就写「未定」或省略，不代编来历。
 7. 行为依据随推进权增减：用户控制越多越简；LLM 代演越多越具体。
 8. 本能力只写各开场共通的玩家角色。不同开场白里玩家身份、处境不同的部分，由开场白写在自己的 `meta.用户角色`，程序会同步成 `设计.主角设定#场景短码`；本能力不为各开场另写 `设计.主角设定#短码`。
 9. 不写 NPC 名片、世界百科、文风规则或开场事件。
 ```
 ## output
@@ -101,3 +104,12 @@ feeds: gm
 - [ ] 称呼允许固定名字或 `@玩家` 留白？
 - [ ] 未写 NPC、世界百科、文风或开场事件？
 ```
 ## examples
 ```examples
 - 好：称呼「林晚」；身份与背景一句穿来当日的处境；特殊设定「能看见别人对她的好感数字」，限制「别人看不见」。
 - 坏：把侯府地理、朝堂势力写进背景。
 - 坏：把开场羞辱戏全文写进名片。
 - 坏：为宿舍开场和天台开场各写一张 `设计.主角设定#短码`；各开场不同的处境应写进对应开场白的 `meta.用户角色`。
 ```
@@ -30,7 +30,7 @@ feeds: gm
 ## task
 ```task
-写入 `设计.随机范围整理`。每项是 `变量.当前` 的一行，行名写成「名称.随机数」，玩家默认不可见。值是剩余数字组成的数组，下一个可用的是第一个。
+先扫实现机制、生成规则、变量设计、叙事与故事推进、美学，列出所有需要随机数才能裁定的点，再写入 `设计.随机范围整理`。每项是 `变量.当前` 的一行，行名写成「名称.随机数」，玩家默认不可见。值是剩余数字组成的数组，下一个可用的是第一个。
 用掉第一个后，程序改写这一行，去掉那个数。改完后如果只剩 1 个，就按范围补到预备个数，不要等这一行空了。模型不自己编数字。
@@ -41,9 +41,10 @@ feeds: gm
 ```principles
 1. 只登记上游已经成立的掷法，不新写法则。
-2. 一行一项，行名是「名称.随机数」，例如 `敏捷.随机数`。
+2. 一行一项，一项只管一类用途，行名是「名称.随机数」，例如 `敏捷.随机数`。不要把「战斗」糊成一行却含命中、伤害、闪避几种掷法，拆成 `命中.随机数`、`伤害.随机数`、`闪避.随机数`。
-3. 和别的隐藏变量一样存在现有表里：能改、有版本；不对玩家默认展示。
+3. 范围写成人与程序都能读的形式，如 `1～100`、`力量*5～10`，并注明单位（整数、闭区间等）；不写「中等偏高」这类散文。
-4. 预备个数够连用即可，少了靠「只剩 1 个就补」，不要一次放很多。
+4. 和别的隐藏变量一样存在现有表里：能改、有版本；不对玩家默认展示。
 5. 预备个数够连用即可，少了靠「只剩 1 个就补」，不要一次放很多。
 ```
 ## probe
@@ -68,6 +69,7 @@ feeds: gm
        "用途": "敏捷检定",
        "范围": "1～100",
        "表达式": "无表达式时省略",
        "单位": "整数，闭区间",
        "依赖真值": [],
        "预备个数": 3,
        "来源": "上游短引用"
@@ -18,7 +18,8 @@ when_not: |
 boundary: |
  回复呈现决定“有什么、何时出现、来自哪里”；本能力决定“在前端哪里、如何渲染”。
  状态和拓扑数据由程序投影，本能力只写绑定与渲染器；不得让正文模型重写权威数据。
-  隐藏维护区不进 DOM。随机数是变量表隐藏行，也与本能力无关。
+  隐藏维护区不进 DOM；表由旁观副 LLM 维护，主回复不建填表通道。
  随机数是变量表隐藏行，也与本能力无关。
  壳参考库只提供布局与交互方法参考，不是必须照抄的固定产品模板。
 feeds: gm,narrator
 ```
@@ -35,11 +36,11 @@ feeds: gm,narrator
 为普通楼层生成一份可复用前端，写入 `设计.正文组成`。每条助手消息仍各自形成一个气泡；程序把当轮 `present.v1` 灌入同一模板。
 执行顺序：
-1. 读取回复呈现，只处理其中实际启用的语义区域。
+1. 读取回复呈现，只处理其中实际启用的语义区域。同时读美学纲领的呈现要点与叙事指南，作为配色、字体层级和纹样的依据；不照搬参考壳的样子。
 2. 从【壳参考库】选一只与本局已启用区域最接近的壳。按该壳备注改写样本里的名称、栏目、配色和内部小节。本局没有的区从样本骨架删除并重排，不留空位。
 3. 为每个用户可见区域定义 block、位置、显示名和渲染方式。模型生成区读取对应 block；程序投影区直接绑定权威数据。
 4. 隐藏 `state_ops` 等维护区列入非渲染处理，不创建 DOM 节点。
-5. 写完整 HTML/CSS/JS，创作时一次生成并固定；游玩只灌数据，不再重写前端。美化用配色、字体层级、边框、间距，以及 CSS 或简单内联 SVG，按本次能写稳的程度完成。JS 通过 `present.onData(render)` 接收数据；地图所需的 SVG 从拓扑数据绘制，游玩模型不输出 SVG。
+5. 写完整 HTML/CSS/JS，创作时一次生成并固定；游玩只灌数据，不再重写前端。每个可见区放一个空节点，`data-block` 等于数据契约里的 id。程序按契约把当轮内容填进这些节点；JS 只做拓扑图和本地切换，通过 `present.onData(cb)` 拿当轮数据；不要用 `textContent` 写 markdown/text 正文。根容器（如 `#app`）`width: 100%`，铺满宿主气泡/iframe，禁止整壳 `max-width` + `margin: 0 auto` 收成居中卡片；若要控阅读行长，只给正文柱设 `max-width`（可 `margin-inline: auto`）。气泡随内容增高，禁止 `100vh` 和整页或侧栏滚动条，滚动只留在外层对话。美化用配色、字体层级、边框、间距，以及 CSS 或简单内联 SVG，按本次能写稳的程度完成。地图所需的 SVG 从拓扑数据绘制，游玩模型不输出 SVG。
 6. 给一份非正史 `present.v1` 预览数据，覆盖所有可见区域与空态。
 模板总量不超过 60 KB。材料足够便直接成稿；会改变阅读结构的缺口交给 `self_score.gap`。产物正文不放评分、诊断、追问或开放问题。
@@ -51,12 +52,14 @@ feeds: gm,narrator
 1. 语义区域必须全部有去处；未启用区域不补齐，隐藏维护区不渲染。
 2. 正文是主阅读面。辅助状态、线索、地图和文字选项按用途确定层级，不平均分割注意力。
 3. 程序投影区只消费权威 block：变量、拓扑和程序结果不要求模型重复填写。
-4. HTML 只放稳定骨架；数据由 `present.onData` 注入。缺 block 时按合同省略或显示空态。
+4. HTML 只放稳定骨架，每个可见区一个 `data-block` 空节点。程序按数据契约灌数；`present.onData` 只留给拓扑和本地交互。markdown/text 正文禁止用 `textContent` 写入（会挤掉换行并露出 `**`）；若本地必须写正文，用 `present.markdown` 再赋 `innerHTML`。缺 block 时按合同省略或显示空态。不要把气泡做成独立窗口。
-5. Tab、折叠、缩放等纯本地交互可以使用；不得联网、提交表单、弹窗、顶层导航或向宿主发送用户行动。
+5. 外壳铺满宿主可用宽度（`width: 100%`、背景与顶栏跟宽走）。行长只限正文柱，不限整壳；缺则按宿主全宽排，不另造居中窄卡片。
-6. Markdown 使用宿主提供的安全渲染能力；动态文字使用安全 API 或转义后写入，不能拼接未清洗 HTML。
+6. Tab、折叠、缩放等纯本地交互可以使用；不得联网、提交表单、弹窗、顶层导航或向宿主发送用户行动。
-7. 地图/关系图由 JS 根据结构化拓扑绘制；显示坐标只属于布局，不回写世界真相。
+7. Markdown 使用宿主提供的安全渲染能力；动态文字使用安全 API 或转义后写入，不能拼接未清洗 HTML。
-8. 预览只用于验收前端，不写成开场白或正史。
+8. 地图/关系图由 JS 根据结构化拓扑绘制；显示坐标只属于布局，不回写世界真相。
-9. 美化落在配色、字体层级、边框、间距和简单内联 SVG 上，写进 CSS，按本次能写稳的程度完成。
+9. 预览只用于验收前端，不写成开场白或正史。示例灌数不为好看新造人名、地名、势力，用已有产物里的；文笔及格即可。
 10. 美化落在配色、字体层级、边框、间距和简单内联 SVG 上，写进 CSS，按本次能写稳的程度完成。
 11. 改稿以最新产物为底。用户只提美化时只改样式，`数据契约` 和 `区域落点` 保持不变；要换阅读结构必须用户明确提出。
 ```
 ## probe
@@ -121,8 +124,8 @@ feeds: gm,narrator
      }
    ],
    "frontend": {
-      "html": "<div id=\"app\">完整稳定骨架</div>",
+      "html": "<div id=\"app\"><article data-block=\"body\"></article><section data-block=\"本局其它可见区域 id\"></section></div>",
-      "css": "完整样式；正文优先；含窄屏规则",
+      "css": "完整样式；根容器 width:100%；正文优先；行长只限正文柱；含窄屏规则",
      "js": "使用 present.onData(render) 的完整渲染代码"
    },
    "示例灌数": {
@@ -139,7 +142,7 @@ feeds: gm,narrator
 硬规则：
 1. 输出合法 JSON；`数据契约.blocks` 必须覆盖回复呈现的全部用户可见区域，id 保持一致。
 2. 程序投影区不得改成模型生成；隐藏维护区只能进入 `不渲染`，不得出现在 DOM 或预览 blocks。
-3. `frontend.html/css/js` 均须给出可执行内容；合计不超过 60 KB。JS 必须调用 `present.onData(render)`。
+3. `frontend.html/css/js` 均须给出可执行内容；合计不超过 60 KB。每个可见 block 对应一个 `data-block` 空节点，id 与契约一致。JS 可以调用 `present.onData` 画拓扑或做本地切换，但文本区由程序填充。根容器铺满宿主宽度；不要整壳 `max-width` 居中卡片；不要 `100vh`，不要整页或侧栏滚动条。
 4. HTML 不嵌入本轮数据；动态文字安全渲染。禁止网络、表单、弹窗、顶层导航和宿主行动回传。
 5. topology 渲染读取结构化节点与连接；不得要求游玩模型输出 SVG。
 6. `示例灌数` 是非正史预览，schema 固定 `present.v1`，只含用户可见 blocks。
@@ -156,9 +159,9 @@ feeds: gm,narrator
 - 1：漏区，或擅自添加回复呈现没有的内容。
 阅读结构：
- 5：正文始终是主阅读面，辅助信息层级与响应式布局服务本局体验。
+- 5：正文始终是主阅读面；外壳铺满宿主宽度；辅助层级与响应式服务本局体验。
- 3：总体可读，但某个并列区略抢正文或窄屏处理不足。
+- 3：总体可读，但并列区略抢正文、窄屏不足，或整壳被限宽成居中卡片。
- 1：区域平均堆叠，阅读焦点混乱。
+- 1：区域平均堆叠，阅读焦点混乱，或外壳明显窄于宿主。
 权威绑定：
 - 5：变量、拓扑和程序结果只读权威投影，模型生成区边界清楚。
@@ -182,7 +185,7 @@ feeds: gm,narrator
 - [ ] 回复呈现的全部可见区域均有 block、落点与渲染方式？
 - [ ] 隐藏维护区未进入 DOM 或预览？
 - [ ] 程序投影的变量和拓扑没有要求模型重写？
- [ ] HTML/CSS/JS 完整，JS 使用 present.onData(render)，总量不超 60 KB？
+- [ ] HTML/CSS/JS 完整，每个可见区有 `data-block` 空节点，总量不超 60 KB，根容器铺满宿主宽度，正文不用 textContent 灌 markdown，没有整壳居中窄卡片或独立滚动窗口？
 - [ ] 美化已用配色、字体层级、边框、间距或简单 SVG 写进 CSS，程度限于本次能写稳的部分？
 - [ ] 本地交互不联网、不回传行动，动态内容安全渲染？
 - [ ] present.v1 预览覆盖可见区域并明确非正史？
@@ -196,5 +199,5 @@ feeds: gm,narrator
 - 正文 + 地图：JS 根据 topology block 绘制 SVG；节点名称安全转义，窄屏可切到列表降级。
 - 多个辅助区：确有必要时使用本地 Tab；切换只改变当前气泡显示，不向宿主发送消息。
 - 武侠阅读：纸色、墨色、细线框和一条简单 SVG 纹样；只保留本局启用的区。
- 不合适：把隐藏 state_ops 做成折叠面板；只写“机械风界面”却不给代码；让模型每轮输出地图 SVG。
+- 不合适：把隐藏 state_ops 做成折叠面板；只用 textContent 写正文导致不分段、露出 `**`；只写“机械风界面”却不给代码；让模型每轮输出地图 SVG。
 ```
@@ -39,9 +39,9 @@ feeds: gm,narrator
 - 对应的上游引用与正向内容要求。
 - 没有内容时是省略、给空态，还是仍须输出。
-正文区域只引用 `设计.故事推进` 的单轮篇幅与扩写/续写预算，不复制数值。状态、地图等权威内容使用程序投影，正文模型不重复生成。选项若启用，只定义文字建议的组成规则，不声明点击交互。
+正文区域只引用 `设计.故事推进` 的单轮篇幅与扩写/续写预算，不复制数值。状态、地图等权威内容使用程序投影，正文模型不重复生成。选项若启用，写清数量、各项的差异维度（如冒险/稳重）和每项的组成规则，让选项彼此不同；不声明点击交互。
-简单变量采用 `inline_tool / inline_structured` 内联维护时，回复合同包含用户不可见的变量更新语义区；程序优先把它投递为 tool call，工具不可用时改为结构化 `state_ops`。`auditor_bundle` 由副 Worker 维护，不建立主回复更新区。
+表维护由旁观副 LLM 固定承担；本步**不**建立主回复里的隐藏变量更新区（无 `state_ops` / maintenance_channel）。可见区只投影权威数据。
 材料足够便直接成稿；真正会改变区域合同的缺口交给 `self_score.gap`。产物正文不放评分、诊断、追问或开放问题。
 ```
@@ -54,10 +54,10 @@ feeds: gm,narrator
 3. 模型生成区写内容要求；程序投影区写权威 ref 与字段选择。程序已有的数据不让模型复述一份。
 4. 正文篇幅、扩写和续写预算只引用故事推进；文风只引用叙事指南。
 5. 状态与拓扑的真相来自运行数据。可见区域只选择投影字段，不在这里修改变量或拓扑。
-6. 简单变量的隐藏更新也是语义区域；运行期可投递为 tool call 或结构化 `state_ops`。副 Worker 路径不在主回复伪造空区域。
+6. 不在主回复建隐藏填表区；表由旁观副 LLM 维护。
 7. 选项是文本建议。是否有交互、点击后做什么，只有正文组成和宿主前端真正实现时才声明。
 8. 区域要求使用正向规格；没有特殊要求便保持短，不为完整感堆区域。
-9. 每个可见区属于一种：抬头、正文、小故事、数据卡、结构、文字选项。抬头是页首一行短内容；条目一多或当前值一长则改用数据卡。数据卡和结构要写出露出的列或字段。隐藏的变量更新不占这些区。
+9. 每个可见区属于一种：抬头、正文、小故事、数据卡、结构、文字选项。抬头是页首一行短内容；小故事是旁支短文，不推进主线，也不复述正文；条目一多或当前值一长则改用数据卡。数据卡和结构要写出露出的列或字段。
 ```
 ## probe
@@ -119,6 +119,33 @@ feeds: gm,narrator
          "正向说明该区域应该提供什么"
        ],
        "空值处理": "omit|empty_state|error"
      },
      {
        "id": "choices",
        "名称": "文字选项",
        "用途": "给用户几条方向不同的行动参考",
        "用户可见": true,
        "出现": {
          "方式": "every_turn",
          "条件": ""
        },
        "内容类型": "list",
        "区域种类": "文字选项",
        "来源": {
          "方式": "model_generated",
          "ref": "设计.故事推进"
        },
        "选项": {
          "数量": 2,
          "各项": [
            { "差异维度": "冒险", "组成": "一句推进风险或探索的具体行动" },
            { "差异维度": "稳重", "组成": "一句观察、保守或缓和局面的具体行动" }
          ]
        },
        "内容要求": [
          "每项是用户角色此刻能直接采取的一句行动，按各自差异维度写，彼此不重复"
        ],
        "空值处理": "omit"
      }
    ]
  }
@@ -130,8 +157,8 @@ feeds: gm,narrator
 2. 普通楼层至少含 `body`；正文只引用故事推进，不复制目标字数、占比或字数预算。
 3. 每个区域必须声明出现方式、内容类型、区域种类、来源、内容要求和空值处理。可见区的区域种类只能是抬头、正文、小故事、数据卡、结构、文字选项。
 4. `program_projection` 必须给稳定 ref；状态和拓扑数据不得标为临场或要求模型重新生成。
-5. 内联变量更新区必须 `用户可见:false`、内容类型为 `state_ops`、来源为 `maintenance_channel`；程序按 API 能力选择 tool call 或结构化区域。`auditor_bundle` 不建立该区。
+5. 不建立主回复隐藏填表区（无 `state_ops` / `maintenance_channel`）；表由旁观副 LLM 维护。
-6. 文字选项只规定数量、差异维度和内容要求；不写可点击、按钮动作或回传协议。
+6. 文字选项须含 `选项`：数量，以及每项的差异维度和组成；不写可点击、按钮动作或回传协议。
 7. 不选壳，不写布局、HTML、CSS、JS、Tab、SVG 或槽位替换；这些属于正文组成。
 8. 产物正文不含自评、追问或开放问题。
 9. `mount` 固定为 `["world-simulator", "narrator"]`；artifact tag 暂时保留 `设计.监控栏`。
@@ -184,4 +211,5 @@ feeds: gm,narrator
 - 展示地图：新增 topology 区域，说明用户应看到哪些节点、连接或当前位置；具体 SVG、表格或 Tab 留给正文组成。
 - 简单变量内联维护：新增用户不可见的 state_ops 语义区域；运行期优先投递为 tool call，工具不可用时进入结构化整包。
 - 文字选项：写数量、彼此差异和应提供的行动方向；不声明点击行为。
 - 坏：只写「要选项」，不定数量、各项差异维度与组成，结果每轮几条选项大同小异。
 ```
@@ -7,33 +7,37 @@ name: 故事推进
 id: story-progression
 artifact: 设计.故事推进
 declaration: >
-  从偏好库选取本局约束，只选定一种用户输入用法，并写清单轮目标字数、扩写与续写的定义和篇幅分配、OOC 处理；不写遣词。
+  继承交互范式的描写权限与停笔时机，从偏好库选取本局约束，钉推进方式（可无专门推进），只选定一种用户输入用法；每一轮正文分成扩写（演本轮材料）与续写（材料后往下写），写清定义、字数分配与 OOC 处理；不写遣词。
 when: |
-  已有美学纲领（或等价），但尚未钉死唯一的用户输入用法，或扩写/续写边界与比例仍不清。
+  已有美学纲领（或等价），但尚未钉死唯一的用户输入用法，或扩写/续写边界与比例仍不清，或还不知道故事靠场面自推、等用户决策还是无专门推进。
-  用户主动谈推进、节奏、停笔、大纲扩写、续写、自动写入时也使用。
+  用户主动谈推进、节奏、停笔、大纲扩写、续写、自动写入、单轮字数时也使用。
 when_not: |
  本技能只给对话落盘。工序编排不排本步（编排池是「叙事指南与故事推进」）。
  美学未钉 → 先「美学纲领与交互范式」。
-  只改遣词、笔墨、写法档 → 「叙事指南」。
+  只改遣词、笔墨、写法档、段落形态 → 「叙事指南」。可见区域 → 「回复呈现」。
  好感公式、进度表、事件池等表规格 → 「变量设计与更新规则」/「生成规则」。
  固定输入标记（裸写 / `#行动#` / 引号）由程序解析，不在本步重定义或按局反转。
 boundary: |
-  本能力只交推进合同：唯一输入用法、单轮目标字数、扩写要求、续写要求、篇幅分配、OOC 处理策略。
+  本能力只交推进合同：推进方式及可选的驱动力、成败与难度、变量钩子；唯一输入用法、单轮目标字数、扩写要求、续写要求、篇幅分配、OOC 处理策略。
-  叙事指南管怎么写；变量与生成规则管表与合同；主角详略只写偏好钩子。
+  单轮字数与篇幅只在本步定义；段落形态（长段不碎行）归叙事指南，可见区域归回复呈现。
  叙事指南管怎么写；变量与生成规则管表与合同，本步只写钩子；主角详略只写偏好钩子。
 feeds: gm,narrator
 ```
 ## opening
 ```opening
-先选定这局唯一的输入用法：大纲扩写、续写，或自动写入。再说清楚单轮大约写多长、扩写和续写各做什么及各占多少；上帝视角/OOC 指令准备怎么处理。
+先选定这局唯一的输入用法：大纲扩写、续写，或自动写入。再说清楚单轮大约写多长；扩写（主路径不动，在用户已给的节拍之间补连接小动作，把场面写顺）和续写（从材料结束后往下写他人与世界反应）各做什么、各占多少。上帝视角/OOC 指令准备怎么处理。故事要不要专门往前推、用户会不会失败，也可以一并说；没想过就按体验先定。
 ```
 ## task
 ```task
-把本局推进合同写入 `设计.故事推进`。先用 `read_library_entry` 从绑定的偏好库读取最相关 1～2 条并本局化，再只选定一种用户输入用法，按该用法写清单轮目标字数、扩写定义、续写定义、两者各自篇幅预算，以及裸写（上帝视角/OOC）指令如何处理。
+把本局推进合同写入 `设计.故事推进`。先继承上游「美学纲领与交互范式」：把 `交互范式.描写权限`（思考与抉择、言语、主动行动、用户输入后）、`后果与叙事控制` 与 `停笔时机` 改写成推进做法；交互范式已写过停笔权限，也要落进本步的用法与续写要求，不因已有而省略。再用 `read_library_entry` 从绑定的偏好库读取最相关 1～2 条并本局化，然后钉推进方式（不明则写「无专门推进」），只选定一种用户输入用法。
-禁止混用两种用法或写成半套规则。固定标记怎么识别交给程序；本步只写识别之后怎么服从与落笔。不写遣词、示范段落或版式。
+扩写与续写是每一轮正文里的两段工作，不是两种输入用法。按所选用法写清单轮目标字数、扩写做什么、续写做什么、两者各自篇幅预算，以及裸写（上帝视角/OOC）指令如何处理。
 禁止混用两种用法或写成半套规则。固定标记怎么识别交给程序；本步只写识别之后怎么服从与落笔。不写遣词、段落形态、示范段落或版式。
 材料足够便直接成稿；多种用法都像、必须用户点选时，把缺口交给 `self_score.gap`。产物正文不放评分、诊断、追问或开放问题。
 ```
@@ -41,16 +45,28 @@ feeds: gm,narrator
 ## principles
 ```principles
-1. 全局只允许一种用户输入用法。切分依据是扩写与续写的定义，以及两者在本局的职责和篇幅预算。
+1. `用户输入用法` 与「扩写 / 续写」不是同一层。用法是本局选哪一种合同（三选一）；扩写、续写是每一轮正文里先后做的两段工作。产物必须先按所选用法写清这两段各自做什么，再分配篇幅。
-2. 三种用法互斥，写入时只保留一个完整合同：
+2. 扩写：主路径不动，把用户本轮已经给出的材料演成流畅场面。人、事、话、结果保持不变；允许在节拍之间增加使动作接得上的小动作、感官和当场小纠正。只加形容词、比喻或气氛、不增加这些连接动作，不算扩写。另起新冲突、新目标、新决定，或改掉已定结果，算出界。
-   - 大纲扩写：输入是待演成场面的大纲。扩写要把每个节拍演满，节拍上的人、事、话、结果保持不变，节拍之间补具体动作把处境写出来；续写短，且不代用户做新决定。
+   例：用户写「打开冰箱门、放入大象、关闭冰箱门」——主路径就是这三步，结果仍是大象进了冰箱。只写这三句会不流畅，扩写应补门怎么拉开、大象怎么塞进去、门关不上再用力扣上等细节；不能改成没放进去、或中途改去别的房间。
-   - 续写：扩写只跟用户本轮已声明的行为与对话；续写为主，停在其他角色等待用户抉择处，不替用户做态度或推进性决定。
+   - 用法为「大纲扩写」时：材料是待演成场面的大纲，不是终稿句子。每个节拍都要演到；节拍之间必须补连接动作，大纲没写这些动作也要写。另例：大纲「我去相亲、坐了下来，她说要婚后自由出轨权，我拒绝了」——坐下前写先要一杯咖啡，又急忙改成两杯，显出局促；她的要求和拒绝的结果不动。
-   - 自动写入：输入多为短 meta 或极简扮演；续写宜长；可按主角设定代演用户角色言行。
+   - 用法为「续写」或「自动写入」时：材料是用户本轮已声明的行为与对话。扩写只在这些声明之间补过程与连接动作，可写他人怎么接这一下；不另写用户没声明的新决定。
-3. 多写“要怎样完成扩写/续写”，少写否定清单；只有会破坏该用法边界的禁点才保留。
+3. 续写：从用户材料结束后往下写。写其他角色与世界如何反应、把场面推到下一个停笔点。默认不可再写用户角色的实际行动、说话或带倾向抉择；最多被动占位（望去、让开）。整轮停在其他角色等用户角色行动抉择之刻。
-4. OOC/上帝视角内容由程序从裸写识别；本步写处理策略：服从到什么程度、是否打断当前场面、如何与既定扩写/续写比例兼容。
+   - 用法为「大纲扩写」或「续写」时：禁止替用户角色做决定，不引入材料外的新剧情事实。
-5. 偏好库是参考：读取后改成本局可执行要求，不照抄。
+   - 用法为「自动写入」时：可按主角设定代演用户角色言行，把续写写长；关键抉择仍按交互范式的权限处理。
-6. 单轮篇幅在这里一次钉死：给目标字数或窄区间，并把扩写、续写的占比与字数预算对应起来；其它节点直接消费，不重复定义。
+4. 三种输入用法互斥，按体验与交互范式选一种，写入时只保留一个完整合同。差别在输入是什么、扩写/续写谁长谁短、续写能不能代演用户角色：
-7. 不写遣词、写法档、版式或事件池公式。
+   - 大纲扩写：用户是写手、要大纲成稿，输入多为剧情节拍时选它。扩写充分、续写短。
   - 续写（旧称扮演停笔）：代入扮演、轮转等用户决策时选它（交互范式规定关键抉择或言语只由用户做、停笔时机是等用户回应）。输入往往较短；扩写只跟已声明内容，续写多于大纲扩写、短于自动写入。
   - 自动写入：用户只给短 meta 指令或极简扮演、希望 AI 代演用户角色，且交互范式允许模型代写 user 言行（旁观、操控站位常见）时选它。扩写少、续写宜长。
 5. 多写“要怎样完成扩写/续写”，少写否定清单；只有会破坏该用法边界的禁点才保留。
 6. 推进可轻可无：`推进方式` 写「场面自推 / 等用户决策 / 无专门推进」之一，不明则写「无专门推进」。不自己发明好感公式、进度表或事件池；表规格交给「变量设计与更新规则」与「生成规则」。
 7. 推进子维度按需填，推进方式为「无专门推进」时可全省：
   - `驱动力`：故事靠谁、靠什么往前（NPC 主动作为、世界压力与时限、用户决策），承接交互范式的 `世界对user的影响` 与 `引入新内容`。
   - `成败与难度`：用户行动会不会失败、失败怎么写（代价落在哪、挫败场面写多重），承接 `行为后果判定` 与 `设计困境`。体验本身要顺遂碾压时写明「不设失败」以及仍保留的阻力；未写明时不默认无条件顺遂。
   - `变量钩子`：推进挂在哪些变量上，每条一句「变量名：推进如何看它」；只写钩子，不写公式、阈值或数值表。
 8. OOC/上帝视角内容由程序从裸写识别；本步写处理策略：服从到什么程度、是否打断当前场面、如何与既定扩写/续写比例兼容。
 9. 偏好库是参考：读取后改成本局可执行要求，不照抄。
 10. 单轮篇幅在这里一次钉死：给目标字数或窄区间，并把扩写、续写的占比与字数预算对应起来；其它节点直接消费，不重复定义。段落形态归叙事指南，本步不写。
 11. 不写遣词、写法档、段落形态、版式或事件池公式。
 ```
 ## output
@@ -70,9 +86,18 @@ feeds: gm,narrator
      }
    ],
    "推进方式": "场面自推 / 等用户决策 / 无专门推进",
    "驱动力": "可选：故事靠谁、靠什么往前；无专门推进时省略",
    "成败与难度": "可选：用户行动会不会失败、失败怎么写、代价落在哪；无专门推进时省略",
    "变量钩子": ["可选：变量名：推进如何看它（只写钩子，不写公式）"],
    "用户输入用法": "大纲扩写 | 续写 | 自动写入",
-    "扩写要求": ["该用法下扩写要做什么、守住什么结果"],
+    "扩写要求": [
-    "续写要求": ["该用法下续写写到哪里、何时停笔"],
+      "主路径（人、事、话、结果）不动；节拍之间补连接小动作，把场面写顺。例：打开冰箱、放入大象、关上冰箱——补怎么塞、门怎么扣，不能改成没放进去",
      "所选用法下材料是什么、节拍之间补什么（按 principles 第 2 条写具体）"
    ],
    "续写要求": [
      "从材料结束后写他人与世界反应，停在等用户角色回应之刻",
      "所选用法下能否代演用户角色、续写写到哪停（按 principles 第 3 条写具体）"
    ],
    "单轮篇幅": {
      "目标字数": "明确数字或窄区间",
      "扩写占比": "百分比",
@@ -89,24 +114,25 @@ feeds: gm,narrator
 硬规则：
 1. 输出合法 JSON；`用户输入用法` 只能是三者之一，不得并列或混装半套。
-2. `扩写要求`、`续写要求`、`单轮篇幅` 必须与所选用法一致；两项占比合计 100%，字数预算与目标字数对应。
+2. `扩写要求` 只写「把本轮材料演成场面」怎么做；`续写要求` 只写「材料结束后往下写」怎么做。不要把另一种输入用法的规则抄进这两项。两项占比合计 100%，字数预算与目标字数对应。
-3. `选用偏好` 默认 1～2 项；无合适条目时可 `[]`，但仍须钉死唯一用法。
+3. `推进方式` 是单个字符串；`驱动力`、`成败与难度`、`变量钩子` 可选，`变量钩子` 不写公式或数值。
-4. 不重定义裸写 / `#行动#` / 引号的识别规则；只写 OOC 处理策略。
+4. `选用偏好` 默认 1～2 项；无合适条目时可 `[]`，但仍须钉死唯一用法。
-5. 不在产物正文写自评、追问、开放问题或遣词示范。
+5. 不重定义裸写 / `#行动#` / 引号的识别规则；只写 OOC 处理策略。
-6. `mount` 固定包含 `world-simulator` 与 `narrator`。
+6. 不在产物正文写自评、追问、开放问题、遣词示范或段落形态。
 7. `mount` 固定包含 `world-simulator` 与 `narrator`。
 ## score
 ```score
 唯一性与切分：
- 5：只选定一种用法；扩写/续写定义、目标字数和预算切分清楚，无第二种用法残留。
+- 5：只选定一种用法，且与交互范式的权限和停笔时机相符；扩写（演本轮材料）与续写（材料后往下写）定义清楚，目标字数和预算切分清楚，无第二种用法残留。
 - 3：主用法明确，但仍有一处边界、占比或字数预算含糊。
- 1：混用多种用法，或扩写/续写职责无法区分。
+- 1：混用多种用法，或把扩写/续写当成另一种输入用法、两段职责无法区分。
 可执行性：
- 5：按该合同可直接开玩，扩写、续写、停笔与 OOC 处理都能执行。
+- 5：按该合同可直接开玩，推进方式、扩写、续写、停笔与 OOC 处理都能执行；有推进时成败与难度写清，不默认无条件顺遂。
- 3：大方向可用，但停笔或 OOC 处理仍需猜测。
+- 3：大方向可用，但停笔、成败或 OOC 处理仍需猜测。
- 1：只有用法名称，没有可执行要求。
+- 1：只有用法名称，没有可执行要求，或自行发明公式与进度表。
 偏好本局化：
 - 5：已读偏好并改成本局要求，与唯一用法咬合。
@@ -117,10 +143,22 @@ feeds: gm,narrator
 ## checklist
 ```checklist
- [ ] 只选定一种用户输入用法？
+- [ ] 已继承交互范式的描写权限与停笔时机并落进本步？
 - [ ] 推进方式已写（不明则「无专门推进」），未发明公式、进度表或事件池？
 - [ ] 只选定一种用户输入用法，且符合它的适用场景？
 - [ ] 扩写与续写已按两段工作分别写清（扩写=演本轮材料，续写=材料后往下写），且与所选用法相符？
 - [ ] 扩写已写明「主路径不动、节拍之间补连接小动作」？只加形容词、或改掉已定结果，都不算写清。
 - [ ] 单轮目标字数、扩写/续写定义、占比与字数预算已写清且互相一致？
 - [ ] OOC/裸写处理策略已写，且未重定义固定标记语法？
 - [ ] 偏好已按需读取并本局化？
- [ ] 未写入遣词、写法档或半套混用规则？
+- [ ] 未写入遣词、写法档、段落形态或半套混用规则？
 - [ ] 产物正文不含评分、诊断、追问？
 ```
 ## examples
 ```examples
 好：用法钉「续写」；用户写「我推开门」——扩写补门轴、屋里人抬头，不另写用户没说的台词；续写写屋里人的反应，停在等用户开口之刻。
 好：用法钉「大纲扩写」；用户写「打开冰箱门、放入大象、关闭冰箱门」——扩写补门怎么拉开、大象怎么塞、门关不上再扣上，三步结果不变；续写短。
 坏：把「扩写」理解成另一种输入用法；只把三句动作各加形容词、场面仍不接；中途改成没放进冰箱或另起新目标；续写里替用户角色补一句台词。
 ```
@@ -7,7 +7,7 @@ name: 变量设计与更新规则
 id: variable-design
 artifact: 设计.变量设计与更新规则
 declaration: >
-  定义必须跨轮保存的最少真值、合法更新条件、权限与派生映射，供程序选择简单状态工具或复杂维护副 Worker。
+  定义必须跨轮保存的最少真值、合法更新条件、权限与派生映射；有真值时由程序固定启用旁观副 LLM 按准则填表。
 when: |
  某项状态若不持久保存，就会导致数值、阶段、资源、门控或已发生事实跨轮漂移时使用。
 when_not: |
@@ -15,8 +15,8 @@ when_not: |
  节点与连接构成的地图、关系或路径 → 拓扑图谱。
  大段设定或同类对象合同 → 舞台骨架 / 生成规则。
 boundary: |
-  本能力定义什么是真值、什么事实允许它改变，以及改变后的约束；不决定 API 投递方式。
+  本能力定义什么是真值、什么事实允许它改变，以及改变后的约束。
-  少量简单变量由程序生成主世界层状态工具；复杂变量与拓扑等由维护合同编译工具汇总。
+  表维护固定走旁观副 LLM（读上一份表、本产物维护准则、本轮主世界正文）；不在此决定内联 tool / state_ops。
  变量控制上下文负责详细可见范围；正文组成负责展示。本能力不写隐藏段、正则、maintain 包或界面格式。
 feeds: gm,auditor
 ```
@@ -38,7 +38,7 @@ feeds: gm,auditor
 若真值只用于选择分档文本或实例切片，保存真值并引用映射来源，不把派生结果建立成第二个可写真值。若跨越阈值会触发一次性或边沿效果，写成触发规则。
-最后根据变量数量、相互依赖、判断方式和触发复杂度给出维护复杂度事实，供程序选择 `none / inline_tool / inline_structured / auditor_bundle`；这是建议，不绑定 API 能力。
+可写简短「维护复杂度」备注（交叉依赖、须结合正文推断的点），供旁观副 LLM 参考；**程序有真值即固定开旁观填表**，不再按建议在内联/旁观间切换。勿手写 `play_slots`。
 材料足够便直接成稿；真正会改变变量合同的缺口交给 `self_score.gap`。产物正文不放评分、诊断、追问或开放问题。
 ```
@@ -52,8 +52,8 @@ feeds: gm,auditor
 4. 类型决定操作：number/integer 可 `set|delta`；enum/string/boolean 可 `set`；set 可 `add|remove`。不用散文值绕过类型。
 5. 公开性只区分用户可见与隐藏；更细的主世界层、转述、旁观投影交给变量控制上下文。
 6. 阈值映射只保存引用和选取条件；长文内容仍在生成规则/具体实例中。
-7. 维护复杂度按实际依赖判断，不机械按数量：一个简单余额可走 inline tool；一个可扩展关系图不属于简单变量。
+7. 「维护复杂度」只写给旁观看的难点备注（交叉依赖、叙事推断证据），不决定开不开旁观；有真值即旁观填表。
-8. 不在正文中设计隐藏标签、正则或维护 JSON；投递方式由程序根据 API 能力选择。
+8. 不在正文中设计隐藏标签、正则或维护 JSON；主世界不承担隐藏填表通道。
 ```
 ## probe
@@ -133,7 +133,7 @@ feeds: gm,auditor
      }
    ],
    "维护复杂度": {
-      "建议": "inline_tool|auditor_bundle",
+      "备注": "交叉依赖、须结合正文推断的点；给旁观副 LLM 参考，不驱动开槽",
      "依据": [
        "变量数量、交叉依赖、narrative_inference、触发规则与其它可变产物"
      ],
@@ -150,7 +150,7 @@ feeds: gm,auditor
 2. 类型与允许操作必须相容；number/integer 的边界、enum 的枚举值必须明确；不适用的约束字段省略。
 3. `narrative_inference` 必须写证据要求；正文没有该证据时不更新。
 4. 派生映射与触发规则可为空；存在时必须引用已声明变量，且派生结果不得成为第二个可写真值。
-5. `维护复杂度.建议` 只在 `inline_tool|auditor_bundle` 中选择；程序仍按 API 能力决定具体投递方式。
+5. `维护复杂度` 可选；有则写备注与依据给旁观，勿再写 `建议: inline_*` 指望关旁观。有真值时程序固定 `play_slots.auditor=true`。勿手写 `play_slots`。
 6. 不输出隐藏段、正则、`maintain.v1/v2`、tool schema、Worker 提示或界面字段。
 7. 产物正文不含自评、追问或开放问题。
 8. `mount` 固定为 `["world-simulator", "auditor"]`。
@@ -191,15 +191,15 @@ feeds: gm,auditor
 - [ ] 类型、初值、允许操作、约束和写入者互相一致？
 - [ ] 每条更新规则都有事实证据和可执行的值规则？
 - [ ] 派生映射未被重复建成可写真值？
- [ ] 维护复杂度依据实际依赖，而不是只按变量数量？
+- [ ] 维护复杂度若写了，是旁观备注而非开槽开关？
 - [ ] 未写隐藏标签、正则、维护包或界面格式？
 ```
 ## examples
 ```examples
- 单个数值真值、只有 set/delta 和上下界、无交叉依赖：建议 inline_tool；程序按 API 探测生成类型明确的小工具。
+- 单个数值真值或关系矩阵：都写清更新规则；有真值即由旁观副 LLM 填表，主世界只写正文。
- 多个真值需要结合正文共同判断，且阈值会触发映射或补实例：建议 auditor_bundle；维护编译工具统一收集。
+- 多个真值需结合正文共同判断：在维护复杂度.备注里点出推断难点与证据，供旁观读。
 - 当前态度由好感区间映射得到：只保存好感，态度作为派生映射，不建立第二个可写“当前态度”。
 - 不合适：每轮重写一段“当前性格”长字符串，或只写“随剧情变化”而没有证据与操作。
 ```
@@ -14,7 +14,7 @@ artifact: 设计.worker规格
 declaration: >
  程序根据前面已经确认的写作、维护和秘密隔离需求，整理本局需要启用的固定执行单元
 when: |
-  落档或开玩时自动执行；从叙事、维护复杂度、信息隔离和写作路径中推导固定槽位。
+  落档或开玩时自动执行；从叙事、信息隔离、写作路径推导固定槽位；有变量真值时程序固定开旁观填表。
 when_not: |
  前置语义尚未确定时沿用安全默认值，不向用户重复询问。
 boundary: |
@@ -57,7 +57,8 @@ boundary: |
 2. 默认世界模拟：`gm: true, narrator: false, auditor: false, perspective: false`；
   调度序 gm → perspective? → narrator? → auditor?；
   主世界层必开（用户明确只要旁观/写手路径除外）；
-   要独立文风改写才 narrator true；有变量设计/表维护需求 → auditor true；
+   要独立文风改写才 narrator true；
   **旁观填表由程序固定**：有「设计.变量设计与更新规则」真值时落档会开 `auditor=true`，本步不必猜；手写 play_slots 时旁观与之对齐即可。
   仅信息隔离才开 perspective。
 3. 写手路径：`outline` + `chapter-writer` 默认都开；用户明确只要正文则可关 outline。
 4. 可写简短 `mount_notes`（哪类上游产物挂哪槽），不粘贴长文。
@@ -70,8 +71,8 @@ boundary: |
 ```principles
 1. 只勾选，不发明：ref 必须在白名单内；无机遇裁定槽。
-2. 默认：世界模拟 = 仅主世界层；转述/旁观/perspective 默认关。主世界层必要。
+2. 默认：世界模拟 = 仅主世界层；转述/perspective 默认关。主世界层必要。
-3. 要独立文风层再开转述；有变量/表/规则要盯再开旁观。
+3. 要独立文风层再开转述。表维护固定旁观副 LLM：有变量真值即 auditor true，不再按 inline 建议关旁观。
 4. 变量 / Data / Progressive 不是执行单元；旁观维护只出 maintain.v1，不写真相。
 5. 删掉检验仍适用：关某个槽要说得清损失什么。
 6. 本步不输出完整 Worker 集、不写 tables 全文、不写随机范围表（交给细化终稿 / 变量设计 / 随机范围整理）。
@@ -85,10 +86,9 @@ boundary: |
 - 是否必须独立转述改写正文？（要才 narrator=true；默认不要，主世界层原文即终稿）
 - 是否有「主世界层不该知道的角色秘密」？（有才 perspective=true）
 - 有变量/表要盯却关了旁观？或无状态却硬开旁观？
 - 扩写：要不要先验大纲再写章？
-不要问「还想加什么 Worker」；不要问要不要机遇裁定。
+不要问「还想加什么 Worker」；不要问要不要机遇裁定；旁观开否由程序按有无变量真值固定。
 ```
 ## output
@@ -123,7 +123,7 @@ boundary: |
 - `path=writing` 时必须有 `writing_slots`；`play_slots` 可省略。
 - `play_slots.gm` 世界模拟路径下应为 true。
 - `narrator` 缺省按 false（主世界层兼呈现）；仅用户明确要独立文风层时 true。
- `auditor` 缺省按 false；有变量/表维护意图才 true。
+- `auditor` 缺省按 false；有变量真值时落档程序固定为 true（旁观副 LLM 填表）。对话落盘不必本步猜。
 - 不要输出 `chance` 字段；旧产物若有 `chance: true`，本步改为 false/删除，并指向「随机范围整理」。
 - 不要输出自造 `actors[]` / 自由 `workers[]`。
 - 旧产物若含 `actors[]`：本步应改写为槽位勾选，不再追加自定义 ref。
@@ -132,8 +132,8 @@ boundary: |
 ```checklist
 - [ ] 是否只有白名单槽，无自造 ref、无机遇裁定？
- [ ] 主世界层是否开启（世界模拟路径）？旁观是否与变量需求一致？
+- [ ] 主世界层是否开启（世界模拟路径）？有变量真值时旁观是否按程序约定开启？
- [ ] auditor / perspective / 只要正文等非常规选择是否有理由？
+- [ ] perspective / 只要正文等非常规选择是否有理由？
 - [ ] 是否误把变量管理做成槽？是否误交完整 设计.worker集？
 ```
@@ -12,8 +12,7 @@ when: |
  核心体验依赖外部环境、社会力量或世界状况持续作出一致反馈，而现有材料还不足以支撑这些反馈时使用。
  是否换区不是判断标准：跨越多地可以需要舞台骨架；一室之内的朝堂、审讯或家庭关系同样可以需要。
 when_not: |
-  熟悉现实基底已经够用，地点和外部格局不会改变核心体验或世界反馈时不使用。
+  熟悉现实基底已经够用，地点和外部格局不会改变核心体验或世界反馈时不使用。  既成硬法则归实现机制；多份人物或要先审字段的名片归生成规则，单条字段很少的具名内容才归具体实例；重点在节点与连接本身时归拓扑图谱。
  既成硬法则归实现机制；多份人物或要先审字段的名片归生成规则，单条字段很少的具名内容才归具体实例；重点在节点与连接本身时归拓扑图谱。
 boundary: |
  本能力只交会上台并反复有用的外部事实，其余沿用熟悉常识或明确留白。
  不重写核心体验，不解释硬法则起源，不制作人物名片、完整地图、历史或百科。
@@ -38,11 +37,12 @@ feeds: gm
 ```principles
 1. 舞台以世界怎样回应玩家为准，不以是否换区、地图大小或题材类型为准。
-2. 熟悉常识默认继承，只写相对基底的必要变造，以及会反复参与体验的外部事实。
+2. 尺度由核心体验会碰到的边界决定。同是“现代都市”基底：体验作为韩国顶级财阀，尺度升到地球级势力、国家与资本网络，主要舞台写到财团、宴会、听证层；体验普通大学生活，尺度是一座城或一所学校，主要舞台写到系馆与社团层。按体验正推，写“需要跨国资本压迫感 → 升到国家层”，不写“因为是校园文所以不要国际政治”。
-3. 核心运转可以是社会力量、阶层关系、周期事件、资源条件、禁忌或日常秩序；只说明它如何作用于玩家和主要舞台。
+3. 熟悉常识默认继承，只写相对基底的必要变造，以及会反复参与体验的外部事实。
-4. 主要舞台可以是空间、机构、社会层或一间房；详细度以能稳定反馈为止。
+4. 核心运转可以是社会力量、阶层关系、周期事件、资源条件、禁忌或日常秩序；只说明它如何作用于玩家和主要舞台。用户已点名的灾变、祭祀、异界出口等世界状况必须写进核心运转。
-5. 既成硬法则只引用其结果，规则本身交给实现机制；多份或要先审字段的具名人物交给生成规则，单条字段很少的具名内容才交给具体实例。
+5. 主要舞台可以是空间、机构、社会层或一间房；写到能稳定反馈为止：玩家在这里做什么、会碰到谁或什么、得到什么反馈，不只点名。
-6. 用户未触及的地区、历史、物种、民俗和势力不补全，在留白边界中说明即可。
+6. 既成硬法则只引用其结果，规则本身交给实现机制；多份或要先审字段的具名人物交给生成规则，单条字段很少的具名内容才交给具体实例。多张名片共享的台上格局与世界状况写在本能力，生成规则只引用，不在规则里重抄。
 7. 用户未触及的地区、历史、物种、民俗和势力不补全，在留白边界中说明即可。类型（西幻、修仙、末日等）只作体裁与氛围参照，不是必选题单：不因题材自动塞入该类型常见的地理与势力；不为显得严谨补起源史、伪科学或神话谱系，除非它们本身会上台。
 ```
 ## output
@@ -57,6 +57,7 @@ feeds: gm
  "正文": {
    "舞台基底": {
      "熟悉基底": "现实或常见类型中可直接继承的最短描述",
      "尺度": "体验会碰到的边界，如国家与资本网络、一座城、一所学校、一间殿；熟悉基底已说明时省略",
      "必要变造": ["只列会改变世界反馈的差异；无则省略"]
    },
    "核心运转": [
@@ -69,7 +70,7 @@ feeds: gm
    "主要舞台": [
      {
        "名称": "会反复上台的空间、机构或社会层",
-        "玩家如何接触": "玩家在这里做什么、受到什么反馈",
+        "玩家如何接触": "玩家在这里做什么、会碰到谁或什么、受到什么反馈；写到能稳定反馈的具体程度，不只点名",
        "关键运转": ["仅引用与此处直接相关的核心运转"]
      }
    ],
@@ -96,7 +97,7 @@ feeds: gm
 克制度：
 - 5：只写会上台且反复有用的内容，熟悉常识默认继承，其余明确留白。
 - 3：夹带少量暂时不会影响游玩的地图、历史或设定。
- 1：写成完整世界百科，核心舞台反而不突出。
+- 1：写成完整世界百科，或因题材自动塞满该类型常见地理与势力，核心舞台反而不突出。
 ```
 ## checklist
@@ -107,5 +108,20 @@ feeds: gm
 - [ ] 核心运转只含会反复作用的关系与状况？
 - [ ] 主要舞台详细度够用即止，未触及范围已留白？
 - [ ] 未重写体验、硬法则、人物名片、完整历史或百科？
 - [ ] 尺度由体验正推？多张名片共享的格局已写在本步？
 - [ ] 产物正文不含评分、诊断、追问和开放问题？
 ```
 ## examples
 ```examples
 好：
 - 体验普通大学生活：熟悉基底为现代都市，尺度是一所学校；主要舞台写到系馆、宿舍、社团，各写玩家在那里做什么、受到什么反馈；国家政治列入留白边界。
 - 核心运转写世界状况：“每年寒灾”“南极通往怪物世界的出口”“村中活人祭祀”各写如何作用，如寒灾按年逼近、决定储粮与迁徙的代价；祭祀每年要交出活人，决定村里谁有话语权。
 - 一室朝堂：主要舞台只有一座殿，核心运转是皇权、派系与言官的相互牵制，如何作用写清每次奏对会被谁记账、牵动哪一方。
 坏：
 - 只写山脉河流，不写用户已点名的祭祀、灾变、异界出口：世界怎样回应玩家仍无从判断。
 - “地点1：XX咖啡馆，店主叫…”：这是具体实例的活；本能力只写这类场所在舞台上怎样作用于玩家。
 - 把多张名片共享的台上格局丢给生成规则写“共通前提”：格局写在本能力，生成规则只引用。
 ```
@@ -39,7 +39,7 @@ feeds: gm,narrator
   - `append`：按顺序追加记录，由程序执行上限或压缩规则。
   - `data`：对程序权威数据应用结构化投影，不接收模型伪造的完整状态。
 5. 隐藏维护通道不创建 DOM。模型只提交允许它生成的槽位；状态和拓扑更新由程序投影。
-6. 写完整 HTML/CSS/JS，创作时一次生成并固定。美化用配色、字体层级、边框、间距，以及 CSS 或简单内联 SVG，按本次能写稳的程度完成。JS 使用宿主提供的 `zeroLayer.onInit(renderCard)` 与 `zeroLayer.onPatch(applyPatch)`；不得依赖正则替换。地图 SVG 只从结构化数据绘制。
+6. 写完整 HTML/CSS/JS，创作时一次生成并固定。每个可见槽位一个空的 `data-block` 节点，程序按契约把内容灌进去。markdown/text 槽禁止用 `textContent` 写入；本地必须写时用 `present.markdown`（若宿主提供）或等价安全渲染。根容器（如 `#zero-layer-app`）`width: 100%`，铺满宿主可用宽度，禁止整壳 `max-width` + `margin: 0 auto` 收成居中卡片；若要控阅读行长，只给正文柱设 `max-width`。不要 `100vh`，不要整页或侧栏滚动条。美化用配色、字体层级、边框、间距，以及 CSS 或简单内联 SVG，按本次能写稳的程度完成。JS 使用宿主提供的 `zeroLayer.onInit(renderCard)` 与 `zeroLayer.onPatch(applyPatch)`；不得依赖正则替换。地图 SVG 只从结构化数据绘制。
 7. 给一份非正史初始卡和一次更新预览，覆盖所有可见槽位与空态。
 HTML、CSS、JS 合计不超过 60 KB。材料足够便直接成稿；会改变主工作面的缺口交给 `self_score.gap`。产物正文不放评分、诊断、追问或开放问题。
@@ -50,13 +50,14 @@ HTML、CSS、JS 合计不超过 60 KB。材料足够便直接成稿；会改变
 ```principles
 1. 固定外壳只创建一次；每轮只更新目标槽位，不重发整页代码。
 2. 正文或核心工作面保持最高阅读优先级，辅助 Tab 不平均争夺注意力。
-3. 更新模式来自 0层回复呈现，前端不能擅自把 replace 改成 append。
+3. 外壳铺满宿主可用宽度（`width: 100%`）；行长只限正文柱，不限整壳；缺则按宿主全宽排。
-4. 程序投影槽只消费权威数据；正文模型不输出状态副本、地图 SVG 或完整卡快照。
+4. 更新模式来自 0层回复呈现，前端不能擅自把 replace 改成 append。
-5. 每次更新带目标槽位和模式；程序校验允许列表与 revision 后原子提交。
+5. 程序投影槽只消费权威数据；正文模型不输出状态副本、地图 SVG 或完整卡快照。
-6. 动态文字安全渲染；Markdown 使用宿主安全能力，不能拼接未清洗 HTML。
+6. 每次更新带目标槽位和模式；程序校验允许列表与 revision 后原子提交。
-7. 允许本地 Tab、折叠、缩放和 SVG 图谱；禁止联网、表单、弹窗、顶层导航和宿主行动回传。
+7. 动态文字安全渲染；Markdown 使用宿主安全能力，不能拼接未清洗 HTML。
-8. 正规路径使用结构化 slot_updates；正则只属于外部兼容适配器，不写进本产物。
+8. 允许本地 Tab、折叠、缩放和 SVG 图谱；禁止联网、表单、弹窗、顶层导航和宿主行动回传。
-9. 美化落在配色、字体层级、边框、间距和简单内联 SVG 上，写进 CSS，按本次能写稳的程度完成。
+9. 正规路径使用结构化 slot_updates；正则只属于外部兼容适配器，不写进本产物。
 10. 美化落在配色、字体层级、边框、间距和简单内联 SVG 上，写进 CSS，按本次能写稳的程度完成。
 ```
 ## probe
@@ -130,7 +131,7 @@ HTML、CSS、JS 合计不超过 60 KB。材料足够便直接成稿；会改变
    ],
    "frontend": {
      "html": "<div id=\"zero-layer-app\">完整稳定外壳</div>",
-      "css": "完整样式与响应式规则",
+      "css": "完整样式；根容器 width:100%；行长只限正文柱；含响应式规则",
      "js": "使用 zeroLayer.onInit(renderCard) 与 zeroLayer.onPatch(applyPatch) 的完整代码"
    },
    "预览": {
@@ -153,7 +154,7 @@ HTML、CSS、JS 合计不超过 60 KB。材料足够便直接成稿；会改变
 硬规则：
 1. 输出合法 JSON；槽位落点覆盖 0层回复呈现的全部可见槽位，id 与更新模式一致。
-2. `frontend.html/css/js` 完整且总量不超过 60 KB；JS 必须实现初始化与增量更新入口。
+2. `frontend.html/css/js` 完整且总量不超过 60 KB；JS 必须实现初始化与增量更新入口。根容器铺满宿主宽度；不要整壳 `max-width` 居中卡片。
 3. 后续回合只提交 `zero-layer.update.v1`，不重发 HTML 或完整卡。
 4. `data` 槽只接受程序权威投影；隐藏维护通道不进入 DOM。
 5. 更新必须带 `base_revision`，由程序校验后原子提交；失败时保持旧卡。
@@ -182,9 +183,9 @@ HTML、CSS、JS 合计不超过 60 KB。材料足够便直接成稿；会改变
 - 1：模型每轮重编权威状态。
 界面结构：
- 5：主工作面明确，Tab 和辅助区服务本局体验，窄屏仍可用。
+- 5：主工作面明确；外壳铺满宿主宽度；Tab 与辅助区服务本局体验，窄屏仍可用。
- 3：总体可读，但一个辅助区抢占注意力。
+- 3：总体可读，但一个辅助区抢占注意力，或整壳被限宽成居中卡片。
- 1：机械地堆满 Tab，没有主次。
+- 1：机械地堆满 Tab，没有主次，或外壳明显窄于宿主。
 实现与安全：
 - 5：代码完整、安全渲染、无联网与回传，结构化区域有降级。
@@ -199,7 +200,7 @@ HTML、CSS、JS 合计不超过 60 KB。材料足够便直接成稿；会改变
 - [ ] 外壳只初始化一次，后续只应用 slot_updates？
 - [ ] revision、原子提交与失败保持旧值完整？
 - [ ] 权威状态没有被模型重复生成，隐藏维护区未进 DOM？
- [ ] 前端完整、安全、无正则依赖与外部联网？
+- [ ] 前端完整、安全、根容器铺满宿主宽度、无正则依赖与外部联网？
 - [ ] 美化已用配色、字体层级、边框、间距或简单 SVG 写进 CSS，程度限于本次能写稳的部分？
 ```
@@ -23,7 +23,7 @@ id: alongside
 ## note
 ```note
-不替换：正文和结构同屏。窄屏改为上下。选项在最下，直接可见。结构用创作时固定的绘图器，游玩灌入拓扑。
+不替换：外壳铺满宿主宽度；正文和结构同屏。窄屏改为上下。选项在最下，直接可见。结构用创作时固定的绘图器，游玩灌入拓扑。
 可替换：两栏谁更宽、抬头文字、结构块的短名、配色和字体。本局没有结构时改用阅读或正文为主。
 ```
@@ -32,19 +32,19 @@ id: alongside
 ```sample
 html:
 <div id="app">
-  <p id="heading"></p>
+  <p id="heading" data-block="heading"></p>
  <div class="pair">
-    <article id="body"></article>
+    <article id="body" data-block="body"></article>
    <section id="structure">
-      <div id="graph"></div>
+      <div id="graph" data-block="structure"></div>
    </section>
  </div>
-  <ol id="options"></ol>
+  <ol id="options" data-block="options"></ol>
 </div>
 css:
 :root { color: #1c1915; background: #f7f3ea; }
-#app { max-width: 56rem; margin: 0 auto; padding: 1.25rem; font: 16px/1.6 "Palatino Linotype", "Songti SC", serif; }
+#app { width: 100%; box-sizing: border-box; margin: 0; padding: 1.25rem; font: 16px/1.6 "Palatino Linotype", "Songti SC", serif; }
 .pair { display: grid; grid-template-columns: 1.2fr 0.8fr; gap: 1rem; }
 #structure { border: 1px solid #d5cbb8; border-radius: 6px; padding: 0.8rem; background: #fffdf8; }
 #graph { min-height: 8rem; }
@@ -54,17 +54,8 @@ css:
 js:
 present.onData(function (data) {
  var blocks = (data && data.blocks) || {};
  putText("heading", blocks.heading);
  putText("body", blocks.body);
  putGraph("graph", blocks.structure);
  putList("options", blocks.options);
 });
 function putText(id, value) {
  var el = document.getElementById(id);
  if (!el) return;
  if (value == null || value === "") { el.remove(); return; }
  el.textContent = String(value);
 }
 function putGraph(id, value) {
  var el = document.getElementById(id);
  if (!el) return;
@@ -110,15 +101,4 @@ function putGraph(id, value) {
  });
  el.appendChild(svg);
 }
 function putList(id, value) {
  var el = document.getElementById(id);
  if (!el) return;
  el.replaceChildren();
  if (!Array.isArray(value) || !value.length) { el.remove(); return; }
  value.forEach(function (line) {
    var li = document.createElement("li");
    li.textContent = String(line);
    el.appendChild(li);
  });
 }
 ```
@@ -25,7 +25,7 @@ id: data-cards
 ## note
 ```note
-不替换：数据区在抬头下一直展开。正文在其下较宽的一栏，篇幅仍是数百字。窄栏在较窄的一栏。选项在两栏之下，直接可见。窄屏时宽栏在上。
+不替换：外壳铺满宿主宽度；数据区在抬头下一直展开。正文在其下较宽的一栏，篇幅仍是数百字。窄栏在较窄的一栏。选项在两栏之下，直接可见。窄屏时宽栏在上。
 可替换：数据项的名称、条数和当前值，窄栏的标题和条目，配色和字体。本局没有窄栏时删掉窄栏，正文占回整宽。
 ```
@@ -34,21 +34,21 @@ id: data-cards
 ```sample
 html:
 <div id="app">
-  <p id="heading"></p>
+  <p id="heading" data-block="heading"></p>
  <div id="cards"></div>
  <div class="pair">
-    <article id="body"></article>
+    <article id="body" data-block="body"></article>
    <aside class="side">
-      <p id="side-title"></p>
+      <p id="side-title" data-block="side_title"></p>
      <div id="side"></div>
    </aside>
  </div>
-  <ol id="options"></ol>
+  <ol id="options" data-block="options"></ol>
 </div>
 css:
 :root { color: #1c2420; background: #d5ddd4; }
-#app { max-width: 52rem; margin: 0 auto; padding: 1rem; font: 15px/1.75 "Segoe UI", "PingFang SC", "Microsoft YaHei", sans-serif; }
+#app { width: 100%; box-sizing: border-box; margin: 0; padding: 1rem; font: 15px/1.75 "Segoe UI", "PingFang SC", "Microsoft YaHei", sans-serif; }
 #heading { margin: 0 0 0.6rem; font-size: 13px; }
 #cards { display: grid; grid-template-columns: repeat(4, 1fr); gap: 0.45rem; margin-bottom: 0.75rem; }
 #cards.stack { grid-template-columns: 1fr; }
@@ -66,19 +66,9 @@ css:
 js:
 present.onData(function (data) {
  var blocks = (data && data.blocks) || {};
  putText("heading", blocks.heading);
  putText("side-title", blocks.side_title);
  putText("body", blocks.body);
  putCards("cards", blocks.cards);
  putLines("side", blocks.side);
  putList("options", blocks.options);
 });
 function putText(id, value) {
  var el = document.getElementById(id);
  if (!el) return;
  if (value == null || value === "") { el.remove(); return; }
  el.textContent = String(value);
 }
 function putCards(id, value) {
  var el = document.getElementById(id);
  if (!el) return;
@@ -111,15 +101,4 @@ function putLines(id, value) {
    el.appendChild(p);
  });
 }
 function putList(id, value) {
  var el = document.getElementById(id);
  if (!el) return;
  el.replaceChildren();
  if (!Array.isArray(value) || !value.length) { el.remove(); return; }
  value.forEach(function (line) {
    var li = document.createElement("li");
    li.textContent = String(line);
    el.appendChild(li);
  });
 }
 ```
@@ -14,7 +14,7 @@ id: dual-text
 可加: 短文、结构、数据、抬头、文字选项
 摆放:
  抬头: 最上的一行短内容
-  正文: 占满阅读宽度，按数百字来写
+  正文: 占满宿主阅读面；行长可限在正文柱，按数百字来写
  短文、结构: 标签或折叠，点开才看。标签用短显示名
  数据: 若有，默认可收起
  文字选项: 始终直接可见，不放进标签或折叠
@@ -24,8 +24,8 @@ id: dual-text
 ## note
 ```note
-不替换：正文占满阅读宽度。其余块收在标签或折叠里，默认不展开。选项在这些控件之外，直接可见。
+不替换：外壳铺满宿主宽度；正文是主阅读面。其余块收在标签或折叠里，默认不展开。选项在这些控件之外，直接可见。
-可替换：标签和折叠的短名、收起块里的文字、配色和字体。本局没有的块删掉。数据要一直展开时改用数据常驻。
+可替换：标签和折叠的短名、收起块里的文字、配色和字体、正文柱行长上限。本局没有的块删掉。数据要一直展开时改用数据常驻。
 ```
 ## sample
@@ -33,47 +33,26 @@ id: dual-text
 ```sample
 html:
 <div id="app">
-  <p id="heading"></p>
+  <p id="heading" data-block="heading"></p>
-  <article id="body"></article>
+  <article id="body" data-block="body"></article>
  <details>
-    <summary id="vignette-title"></summary>
+    <summary id="vignette-title" data-block="vignette_title"></summary>
-    <div id="vignette"></div>
+    <div id="vignette" data-block="vignette"></div>
  </details>
-  <ol id="options"></ol>
+  <ol id="options" data-block="options"></ol>
 </div>
 css:
 :root { color: #1c1915; background: #f7f3ea; }
-#app { max-width: 40rem; margin: 0 auto; padding: 1.25rem; font: 17px/1.75 "Palatino Linotype", "Songti SC", serif; }
+#app { width: 100%; box-sizing: border-box; margin: 0; padding: 1.25rem; font: 17px/1.75 "Palatino Linotype", "Songti SC", serif; }
 #heading, #body, details, #options { max-width: 40rem; margin-inline: auto; }
 #heading { margin: 0 0 0.8rem; font-size: 0.95rem; }
 #vignette { font-size: 0.92rem; margin-top: 0.6rem; }
-#options { margin: 0.8rem 0 0; padding-left: 1.2rem; }
+#options { margin: 0.8rem auto 0; padding-left: 1.2rem; }
 summary { cursor: pointer; }
 js:
-present.onData(function (data) {
+present.onData(function () {
-  var blocks = (data && data.blocks) || {};
+  /* 文本区由程序按 data-block 灌数；折叠开合是浏览器原生行为 */
  putText("heading", blocks.heading);
  putText("body", blocks.body);
  putText("vignette-title", blocks.vignette_title);
  putText("vignette", blocks.vignette);
  putList("options", blocks.options);
 });
 function putText(id, value) {
  var el = document.getElementById(id);
  if (!el) return;
  if (value == null || value === "") { el.remove(); return; }
  el.textContent = String(value);
 }
 function putList(id, value) {
  var el = document.getElementById(id);
  if (!el) return;
  el.replaceChildren();
  if (!Array.isArray(value) || !value.length) { el.remove(); return; }
  value.forEach(function (line) {
    var li = document.createElement("li");
    li.textContent = String(line);
    el.appendChild(li);
  });
 }
 ```
@@ -23,8 +23,8 @@ id: paged
 ## note
 ```note
-不替换：同时只显示一页。页用一行标签切换。抬头在标签之外。
+不替换：外壳铺满宿主宽度；同时只显示一页。页用一行标签切换。抬头在标签之外。
-可替换：每个标签的短名、页内文字和数据项、配色和字体。本局未启用的页不建标签。
+可替换：每个标签的短名、页内文字和数据项、配色和字体、页内正文柱行长上限。本局未启用的页不建标签。
 ```
 ## sample
@@ -32,14 +32,15 @@ id: paged
 ```sample
 html:
 <div id="app">
-  <p id="heading"></p>
+  <p id="heading" data-block="heading"></p>
  <div id="tabs"></div>
-  <div id="page"></div>
+  <div id="page" data-block="page"></div>
 </div>
 css:
 :root { color: #1c1915; background: #f7f3ea; }
-#app { max-width: 44rem; margin: 0 auto; padding: 1.25rem; font: 16px/1.65 "Segoe UI", "Source Han Sans SC", sans-serif; }
+#app { width: 100%; box-sizing: border-box; margin: 0; padding: 1.25rem; font: 16px/1.65 "Segoe UI", "Source Han Sans SC", sans-serif; }
 #heading, #tabs, #page { max-width: 44rem; margin-inline: auto; }
 #tabs { display: flex; gap: 0.4rem; margin-bottom: 0.9rem; }
 #tabs button { border: 0; border-bottom: 2px solid transparent; background: transparent; padding: 0.35rem 0.6rem; font: inherit; color: inherit; }
 #tabs button[aria-current="true"] { border-bottom-color: #8a5a2b; }
@@ -49,7 +50,6 @@ var pages = [];
 var current = 0;
 present.onData(function (data) {
  var blocks = (data && data.blocks) || {};
  putText("heading", blocks.heading);
  pages = Array.isArray(blocks.pages) ? blocks.pages : [];
  current = 0;
  drawTabs();
@@ -73,12 +73,7 @@ function drawTabs() {
 }
 function drawPage() {
  var el = document.getElementById("page");
-  el.textContent = pages[current] ? pages[current].text : "";
+  var text = pages[current] ? pages[current].text : "";
-}
+  el.innerHTML = text ? present.markdown(String(text)) : "";
 function putText(id, value) {
  var el = document.getElementById(id);
  if (!el) return;
  if (value == null || value === "") { el.remove(); return; }
  el.textContent = String(value);
 }
 ```
@@ -13,7 +13,7 @@ id: piece
 主区: 一份成稿
 可加窄带: 文字选项
 摆放:
-  成稿: 居中。内部小节在创作时按范例重写
+  成稿: 外壳铺满宿主；成稿正文柱可限行长并水平居中
  文字选项: 成稿之后，始终直接可见
 未启用的区不留空位。
 ```
@@ -21,8 +21,8 @@ id: piece
 ## note
 ```note
-不替换：一份成稿容器居中。选项在容器之后，直接可见。
+不替换：外壳铺满宿主宽度；一份成稿容器。选项在容器之后，直接可见。
-可替换：容器内部的标记、分段、配色和字体。按本局这一份成品重写内部。样本内部与本局不同时整段替换，保留容器和选项的前后关系。
+可替换：容器内部的标记、分段、配色和字体、成稿柱行长上限。按本局这一份成品重写内部。样本内部与本局不同时整段替换，保留容器和选项的前后关系。
 ```
 ## sample
@@ -30,37 +30,19 @@ id: piece
 ```sample
 html:
 <div id="app">
-  <article id="piece"></article>
+  <article id="piece" data-block="piece"></article>
-  <ol id="options"></ol>
+  <ol id="options" data-block="options"></ol>
 </div>
 css:
 :root { color: #1c1916; background: #ebe6dc; }
-#app { max-width: 34rem; margin: 0 auto; padding: 1.6rem 1.25rem 2rem; font: 16px/1.65 "Segoe UI", "PingFang SC", "Microsoft YaHei", sans-serif; }
+#app { width: 100%; box-sizing: border-box; margin: 0; padding: 1.6rem 1.25rem 2rem; font: 16px/1.65 "Segoe UI", "PingFang SC", "Microsoft YaHei", sans-serif; }
-#piece { margin: 0; }
+#piece, #options { max-width: 34rem; margin-inline: auto; }
-#options { margin: 1rem 0 0; padding-left: 1.15rem; }
+#piece { margin: 0 auto; }
 #options { margin: 1rem auto 0; padding-left: 1.15rem; }
 js:
-present.onData(function (data) {
+present.onData(function () {
-  var blocks = (data && data.blocks) || {};
+  /* 成稿与选项由程序按 data-block 灌数 */
  putText("piece", blocks.piece);
  putList("options", blocks.options);
 });
 function putText(id, value) {
  var el = document.getElementById(id);
  if (!el) return;
  if (value == null || value === "") { el.remove(); return; }
  el.textContent = String(value);
 }
 function putList(id, value) {
  var el = document.getElementById(id);
  if (!el) return;
  el.replaceChildren();
  if (!Array.isArray(value) || !value.length) { el.remove(); return; }
  value.forEach(function (line) {
    var li = document.createElement("li");
    li.textContent = String(line);
    el.appendChild(li);
  });
 }
 ```
@@ -14,7 +14,7 @@ id: reading
 可加窄带: 抬头、文字选项
 摆放:
  抬头: 正文之前的一行短内容
-  正文: 阅读柱，占主要宽度
+  正文: 阅读柱；外壳铺满宿主，行长可限在正文柱
  文字选项: 正文之后，始终直接可见，不放进标签或折叠。不显示「文字选项」这个区名
 未启用的区不留空位。
 ```
@@ -22,8 +22,8 @@ id: reading
 ## note
 ```note
-不替换：单栏阅读柱。抬头在正文前，独占一行。选项在正文后，直接可见。
+不替换：外壳铺满宿主宽度；单栏阅读柱。抬头在正文前，独占一行。选项在正文后，直接可见。
-可替换：抬头文字、正文文字、配色和字体。本局没有抬头时删掉抬头。
+可替换：抬头文字、正文文字、配色和字体、正文柱行长上限。本局没有抬头时删掉抬头。
 ```
 ## sample
@@ -31,53 +31,21 @@ id: reading
 ```sample
 html:
 <div id="app">
-  <p id="heading"></p>
+  <p id="heading" data-block="heading"></p>
-  <article id="body"></article>
+  <article id="body" data-block="body"></article>
-  <ol id="options"></ol>
+  <ol id="options" data-block="options"></ol>
 </div>
 css:
 :root { color: #1c1915; background: #f7f3ea; }
-#app { max-width: 38rem; margin: 0 auto; padding: 1.5rem 1.25rem 2.5rem; font: 17px/1.75 "Palatino Linotype", "Songti SC", serif; }
+#app { width: 100%; box-sizing: border-box; margin: 0; padding: 1.5rem 1.25rem 2.5rem; font: 17px/1.75 "Palatino Linotype", "Songti SC", serif; }
 #heading, #body, #options { max-width: 38rem; margin-inline: auto; }
 #heading { margin: 0 0 0.85rem; font-size: 0.95rem; letter-spacing: 0.04em; }
 #body { font-size: 1.05rem; }
-#options { margin: 1.25rem 0 0; padding-left: 1.2rem; }
+#options { margin: 1.25rem auto 0; padding-left: 1.2rem; }
 js:
-present.onData(function (data) {
+present.onData(function () {
-  var blocks = (data && data.blocks) || {};
+  /* 正文/抬头/选项由程序按 data-block 灌数；本地交互再写这里 */
  putHeading("heading", blocks.heading);
  putText("body", blocks.body);
  putList("options", blocks.options);
 });
 function putHeading(id, value) {
  var el = document.getElementById(id);
  if (!el) return;
  el.replaceChildren();
  if (value == null || value === "") { el.remove(); return; }
  if (typeof value === "string") { el.textContent = value; return; }
  Object.keys(value).forEach(function (key) {
    var item = document.createElement("span");
    item.textContent = key + " " + String(value[key]);
    item.style.marginRight = "1rem";
    el.appendChild(item);
  });
 }
 function putText(id, value) {
  var el = document.getElementById(id);
  if (!el) return;
  if (value == null || value === "") { el.remove(); return; }
  el.textContent = String(value);
 }
 function putList(id, value) {
  var el = document.getElementById(id);
  if (!el) return;
  el.replaceChildren();
  if (!Array.isArray(value) || !value.length) { el.remove(); return; }
  value.forEach(function (line) {
    var li = document.createElement("li");
    li.textContent = String(line);
    el.appendChild(li);
  });
 }
 ```