# 开场白与开场变量

## meta

```meta
name: 开场白与开场变量
id: opening-setup
artifact: 设计.开场白与开场变量
declaration: >
  普通楼层创作终节点，且可增殖：每条开场是一个节点，落成 `设计.开场白#场景短码`。
  默认写 1 条；用户要多个入口时再增殖。每条自带 present.v1、同真相初态与可选用户角色。
  全部保存。游玩时左右切换，选中的一条作为 0 层。
when: |
  回复呈现、正文组成和其它本局内容能力均已完成，且程序已依次编译信息可见范围、游玩执行方式、上下文排序与运行配置后，需要可开玩的第一屏时使用。
when_not: |
  语义区域或前端模板未钉 → 先回复呈现、正文组成。
  `设计.worker集` 尚未由程序组装 → 先运行收口工具链。
  只改文风或真值规则 → 叙事指南 / 变量设计。
  要做持久 0 层开场 → 0层开场白与初态，不在本步兼顾。
boundary: |
  本能力只写开场候选与各候选初态。不重开篇幅、文风、区域清单或前端模板。
  只填正文组成声明为模型生成的 blocks；状态与拓扑由程序按候选初态投影。
  随机数是变量表隐藏行：本步不写具体数字。0 层玩法不依赖随机；普通楼层在第一次正式回复时由程序补齐随机行。
  每条开场单独落盘。游玩时左右切换，选中的一条作为 0 层；创作里不把入口收成一道先选定的题。
feeds: gm,narrator
```

## opening

```opening
设定已齐时，用几句话说清第一拍：玩家进场时在哪、正发生什么、结束后显然能做什么。默认写一条开场。还要别的入口时，每条再增殖一个开场节点；进游玩后左右切换，选中的一条作为 0 层。
```

## task

```task
读取程序已组装的 `设计.worker集` 和全部最终层产物，写入 `设计.开场白与开场变量`。这是普通楼层创作终节点；不得在本步首次整理执行单元或上下文顺序。

默认只生成 1 条开场。用户要多个入口时，每条再增殖一份产物，对话落盘写入 `设计.开场白#场景短码`（如 dorm、gate）；改某一条则覆盖同一完整 tag。不要把多条入口收成聊天里的选择题。每条候选各自携带：
- 稳定 id 与一句区分说明
- 可选用户角色名片（不同候选可不同）
- 与该条叙述同真相的变量初值
- 若本局有拓扑：当前位置/焦点与已揭示范围
- 符合正文组成数据契约的 `present.v1`（只填模型生成区）

全部候选都保存。每条正文只写在该候选的 `正文` 里，不要再抄一份全文或初值。`默认候选id` 指向第一次进入 0 层的那条；程序按这个 id 读取它的正文和初值。游玩时左右切换，选中的一条作为 0 层，并整套换该条正文、初态与角色。

硬规格：
1. 每条可见正文至少出现一次字面 `@玩家`；不写死具体姓名顶名字位。
2. `present.v1` 的区域只覆盖正文组成声明的模型生成 blocks；程序投影区留空给程序灌。
3. 不输出 `名称.随机数` 的具体数组；随机行由程序在第一次正式回复前或回复时补齐。
4. 开场宜短，愿点进游玩即可，不抄故事推进的单轮篇幅预算当第一章。

材料足够便直接成稿；会改变第一拍成立的缺口交给 `self_score.gap`。产物正文不放评分、诊断、追问或开放问题。
```

## principles

```principles
1. 开场为主，初态配套。叙述与该条变量、拓扑初态必须同真相。
2. 默认一条。多条是不同入口，每条一个可增殖节点，不是同文换皮，也不是先让用户选唯一开场。
3. 用户角色可按候选不同；没有名片时仍用 `@玩家` 占位，进游玩再替换。
4. 只写模型生成区。状态芯片、地图等权威显示由程序投影，不在开场正文里重编一份。
5. 不剧透隐藏档，不写成第一章，不在本步改前端模板。
6. 本步结束后创作收口；不要再排后续内容能力。
```

## probe

```probe
每轮 1～2 点。优先确认地点与冲突、某真值开场值是否推得出、多条时入口差异是否成立、每条是否含 `@玩家`。不追问前端重设计或随机骰面。
```

## output

```output
{
  "schema": "context-fragment.v1",
  "技能": "开场白与开场变量",
  "brief": "一句话：默认开场场景 + 有几条候选",
  "mount": ["world-simulator", "narrator"],
  "稳变": "stable",
  "正文": {
    "默认候选id": "opening-1",
    "开场白候选": [
      {
        "id": "opening-1",
        "区分": "这条入口与其它条差在哪；仅一条时可写「默认」",
        "meta": {
          "用户角色": {
            "名字": "可选；无则省略整段",
            "简介": "可选"
          },
          "开场变量": [
            {
              "名": "与变量设计真值名一致",
              "值": "初值",
              "依据": "开场事实"
            }
          ],
          "拓扑初态": [
            {
              "topology_id": "有拓扑时填写",
              "当前位置": "节点 id",
              "已揭示": ["节点或连接 id"]
            }
          ]
        },
        "正文": {
          "schema": "present.v1",
          "blocks": {
            "body": "清晨，@玩家推开门。……"
          },
          "meta": {
            "suggested_actions": ["若正文组成启用文字选项则给短建议；否则 []"]
          }
        }
      }
    ],
    "用户可行动空间": "开场结束后玩家显然能尝试什么"
  }
}
```

硬规则：
1. 输出合法 JSON；`开场白候选` 默认 1 条，仅用户明确要求时 2～3 条。
2. `默认候选id` 必须指向候选之一。正文和初值只写在该候选上，不另抄全文或开场变量。
3. 每条 `正文` 必须是 `present.v1`，只含正文组成允许模型生成的 blocks；每条可见正文须含字面 `@玩家`。
4. 不同候选可有不同用户角色与初态；切换时整套替换，不混用。
5. 不输出随机数具体值，不重写前端，不把程序投影区填成模型编造状态。
6. 产物正文不含自评、追问或开放问题。
7. `mount` 固定为 `["world-simulator", "narrator"]`。

## score

```score
开场必要：
- 5：第一拍清楚、有行动空间，短到愿意开玩。
- 3：能开玩，但入口或下一步略含糊。
- 1：像第一章摘要，或缺冲突与下一步。

前端符合：
- 5：present.v1 只填模型生成区，且与正文组成契约一致。
- 3：主体符合，有一个次要区域或空态处理含糊。
- 1：裸散文，或把程序投影区填成模型重编数据。

状态自洽：
- 5：每条候选的变量与拓扑初态都与该条叙述同真相，互不串味。
- 3：默认条自洽，备选条有一处初态含糊。
- 1：叙述与初值冲突，或多条共用一套却声称不同入口。

角色占位：
- 5：每条含字面 `@玩家`；有名片时不把姓名写进正文名字位。
- 3：占位大体正确，有一条名片与正文关系略乱。
- 1：写死姓名，或全文没有 `@玩家`。

收口可切换：
- 5：默认条明确，全部候选可保存；多条时入口差异成立。
- 3：能收口，但多条差异偏弱。
- 1：默认不清，或未要求多条却堆出重复候选。
```

## checklist

```checklist
- [ ] 默认 1 条；仅用户要求时才有 2～3 条？
- [ ] `默认候选id` 指向一条候选，且该条正文、初值没有在外面再抄一份？
- [ ] 每条含 `@玩家`，present.v1 只含模型生成区？
- [ ] 各候选初态自洽，未填写随机数具体值？
- [ ] 未重开前端、篇幅或区域清单？
```

## examples

```examples
- 单条：堂屋债契，body 含 `@玩家`，开场变量写债额初值；状态栏由程序投影。
- 用户要两条入口：一条放贷人名片、一条社畜穿越名片；各带自己的初态，默认指定其中一条开玩。
- 不合适：开场里填写 `敏捷.随机数=[…]`；或把地图权威数据写成模型散文却不给拓扑初态。
```