# 0 层开场白与初态

## meta

```meta
name: 0层开场白与初态
id: zero-layer-opening-setup
artifact: 设计.0层开场白与初态
declaration: >
  0 层创作终节点，且可增殖：每条开场是一个节点，落成 `设计.0层开场白与初态#场景短码`。
  每条自带持久卡第一屏、槽位初值和同真相运行初态。默认 1 条；还要入口就再增殖。
  游玩时左右切换，选中的一条作为 0 层。
when: |
  0层回复呈现、0层正文组成和其它内容能力均已完成，程序也已组装运行配置，需要创建持久卡第一屏时使用。
when_not: |
  本局使用普通消息楼层 → 开场白与开场变量。
  槽位或持久外壳未定 → 先 0层回复呈现、0层正文组成。
  `设计.worker集` 尚未由程序组装 → 先运行 prepare_opening 收口工具链。
boundary: |
  本能力只写候选第一屏、卡槽初值与同真相变量/拓扑初态；不重写外壳和更新合同。
  开场不依赖随机数，不填写任何随机数行的具体值。
feeds: gm,narrator
```

## opening

```opening
用持久卡的第一屏建立第一拍：玩家进场时在哪、哪些槽位一开始有内容、结束后显然能做什么。默认一条。还要别的入口时，每条再增殖一个开场节点；进游玩后左右切换，选中的一条作为 0 层。
```

## task

```task
读取程序已组装的 `设计.worker集`、`设计.0层回复呈现`、`设计.0层正文组成` 和其它最终层产物，写入 `设计.0层开场白与初态`。

默认生成 1 条。用户要多个入口时，每条再增殖一份产物，写入 `设计.0层开场白与初态#场景短码`；改某一条则覆盖同一完整 tag。不要把多条入口收成聊天里的选择题。每条候选必须携带一套不可混用的初态：
- 稳定候选 id 与一句区分。
- 可选用户角色名片。
- `zero-layer.card.v1` 初始卡：revision=0，包含所有可见槽位的初值或合同允许的空态。
- 与第一屏同真相的变量初值。
- 若有拓扑：当前位置、焦点和已揭示范围。

卡内模型生成槽位由本步填写；程序投影槽位只声明初始绑定，由程序从变量和拓扑初态灌入。正文槽的可见内容至少出现一次字面 `@玩家`。开场不依赖随机数，因此不输出任何 `名称.随机数` 的具体数组。

全部候选保存。游玩时左右切换，选中的一条作为 0 层：程序整套替换用户角色、卡状态、变量和拓扑初态，之后每轮只应用 `zero-layer.update.v1`，不新增可见助手楼层。

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

## principles

```principles
1. 第一屏、卡槽、变量和拓扑初态必须是同一个事实版本。
2. 默认一条。多条是不同入口，每条一个可增殖节点，各自一整套初态，不共享半套状态。
3. 所有可见槽位都必须有初值、允许的空态或程序投影绑定。
4. 只填模型生成槽；状态、地图和表盘从权威初态投影。
5. 用户角色没有名片时仍使用 `@玩家`；有名片时也不把姓名硬写进占位位置。
6. 不写 HTML/CSS/JS，不复制固定外壳，不在开场里模拟后续 slot_updates。
7. 本步结束后创作收口；后续变化进入持久卡更新协议。
```

## probe

```probe
每轮 1～2 点。优先确认第一拍、初始活动视图、模型槽初值、某项权威状态的开场值，以及多入口时整套初态差异。
```

## output

```output
{
  "schema": "context-fragment.v1",
  "技能": "0层开场白与初态",
  "brief": "一句话说明默认第一屏与候选数量",
  "mount": ["world-simulator", "narrator"],
  "稳变": "stable",
  "正文": {
    "默认候选id": "zero-opening-1",
    "候选": [
      {
        "id": "zero-opening-1",
        "区分": "默认；多条时说明入口差异",
        "用户角色": {
          "名字": "可选；无则省略整段",
          "简介": "可选"
        },
        "初始卡": {
          "schema": "zero-layer.card.v1",
          "card_id": "本局稳定卡 id",
          "revision": 0,
          "active_view": "初始主工作面或 Tab id",
          "slots": {
            "body": {
              "mode": "replace|append",
              "content": "包含字面 @玩家 的第一拍"
            },
            "其它模型生成槽位": {
              "mode": "与0层回复呈现一致",
              "content": "初值或允许的空态"
            },
            "程序投影槽位": {
              "mode": "data",
              "projection_ref": "变量、拓扑或备忘录的稳定引用"
            }
          }
        },
        "变量初态": [
          {
            "名": "与变量设计真值名一致",
            "值": "开场值",
            "依据": "第一屏事实"
          }
        ],
        "拓扑初态": [
          {
            "topology_id": "有拓扑时填写",
            "当前位置": "节点 id",
            "焦点": "可选节点或连接 id",
            "已揭示": ["节点或连接 id"]
          }
        ],
        "用户可行动空间": "第一屏结束后显然能尝试什么"
      }
    ]
  }
}
```

硬规则：
1. 输出合法 JSON；候选默认 1 条，仅用户明确要求时 2～3 条。
2. `默认候选id` 必须指向候选之一；每条都是完整独立初态。
3. 初始卡 schema 固定为 `zero-layer.card.v1`，revision 固定为 0。
4. 初始卡覆盖全部可见槽位；模型生成槽给初值或空态，程序投影槽给稳定 `projection_ref`。
5. 每条正文可见内容包含字面 `@玩家`；不写死用户角色姓名替代占位。
6. 不输出随机数具体值，不填后续 slot_updates，不复制前端代码。
7. 变量、拓扑与第一屏同真相；切换候选时整套替换。
8. 产物正文不含自评、追问或开放问题。
9. `mount` 固定为 `["world-simulator", "narrator"]`。

## score

```score
第一屏可玩：
- 5：第一拍、当前信息和行动空间清楚，短到愿意立即开玩。
- 3：可以开玩，但当前目标或下一步略含糊。
- 1：像长篇序章，或看不出玩家能做什么。

卡合同符合：
- 5：全部可见槽位都有正确初值、空态或程序投影绑定，模式与0层合同一致。
- 3：主体符合，一个辅助槽位初值含糊。
- 1：漏槽、模式冲突或直接复制整页 HTML。

状态自洽：
- 5：第一屏、变量、拓扑和程序投影引用完全同真相。
- 3：主体一致，但一项次要初态依据不足。
- 1：叙述与初态冲突或程序槽由模型编造。

持久起点：
- 5：card_id 稳定、revision=0、初始视图明确，后续可直接应用 slot_updates。
- 3：可初始化，但初始视图或某槽持久语义略含糊。
- 1：仍按普通消息设计，无法形成持久卡。

候选切换：
- 5：默认明确；多条时每条入口与整套初态差异成立。
- 3：可切换，但多条差异偏弱。
- 1：候选共享冲突状态，或未要求却堆重复入口。
```

## checklist

```checklist
- [ ] 默认一条，默认 id 有效？
- [ ] 每条卡覆盖全部可见槽位，revision=0？
- [ ] 第一屏含 @玩家，变量与拓扑初态同真相？
- [ ] 程序投影槽只写 projection_ref，未编造权威数据？
- [ ] 未写随机数、前端代码或后续 slot_updates？
```

## examples

```examples
- 终端操作师：初始活动视图为公司指令，正文写 @玩家 登入后的第一项任务；表盘和地图只给程序投影引用。
- 固定学校：正文建立第一拍，地图槽绑定学校拓扑，线索槽使用允许的空态。
- 不合适：把后续每轮更新预写进开场；输出随机数组；每个候选只换正文却共用冲突变量。
```