# 拓扑图谱

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

## meta

```meta
name: 拓扑图谱
id: topology
artifact: 设计.拓扑图谱
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
{
  "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
好：家门→小区门→花园↑——地图拓扑，连接带方向。
好：家族谁连谁——关系拓扑，连接是称谓。
好：功法一阶接到二阶、旁支接到某秘术——升级路径。
坏：其实该按规则反复生成的对象族（如心之彩）硬写成拓扑。
坏：把舞台活动区再抄一遍，没有连接。
坏：描述主世界层谁读谁写 → 游玩拓扑，不是本步。
```