@cloud411716/fancy-webnovel 1.0.45 → 2.2.0

package/plugins/fancy-story-builder/prompts/02-flesh-prompt.md

@@ -0,0 +1,540 @@
+# 02 血肉阶段产物契约
+
+> 本文件是血肉阶段的**产物契约**：它定义每个文件长什么样、哪些写法会被判错。
+>
+> **流程由插件驱动**：插件会分批派活，每轮告诉你写哪个文件、哪些条目、写到哪里；
+> 插件自己跑校验脚本、判定通过与否，并把判定出来的错误清单回喂给你。
+> 你**不需要**自己调校验脚本，**不要**自己判断"通过没通过"，**不要**输出"已完成"之类的结论。
+
+@meta-only
+
+---
+
+<!-- contract:overview -->
+## 你的职责
+
+你只做一件事：**按插件每轮给的指令，把指定的条目写成指定格式的 JSON**。
+
+- 每轮指令会明确给出：要写的文件路径、要写的条目（id + name + 类型）、字段要求。
+- 你把结果**写进指令指定的那个文件**，不要写别的文件，不要改别的文件。
+- 插件会校验你写的内容。如果没过，插件会把错误清单发回给你，让你**只改被点名的那几条**。
+- 写完就停。不要附带解释、不要输出总结、不要宣布完成。
+
+**不要做的事**：
+
+- 不要自己运行校验脚本（插件会跑，跑了也没有意义）。
+- 不要修改 `模板/`、`references/` 下的任何文件。
+- 不要修改 `设定/raw/sources/骨架/` 下的任何文件（只读上游）。
+- 不要写指令范围之外的文件。
+
+---
+
+<!-- contract:input -->
+## 一、任务输入
+
+> 本节由插件注入，只读，不得修改。
+> 数据源：骨架阶段 `设定/raw/sources/骨架/框架.json` 的 `input_snapshot`（目标章节/目标字数取自同文件的 `capacity`）。
+> 骨架阶段已经把这次选题的完整输入固化成了这份快照，血肉阶段直接用它，不要另做推测或改写。
+
+${input_snapshot_block}
+
+**注**：
+
+- 血肉阶段的**实体信息**从骨架的 4 个 JSON 读，不从任务输入读。
+- 但任务输入里的**硬门禁**和**反套路**是血肉阶段的硬约束：写实体的目标、资源、压制手段、成员关系时不得违背。
+- **核心冲突**决定血肉往哪个方向细化：每个势力的资源、内部结构、压制手段，都要能解释它怎么参与（或被排除在）核心冲突。
+- 任务输入的**书名 / 题材 / 目标章节**只用于确认"读的是同一个项目"，不要拿它们当硬约束。
+
+---
+
+<!-- contract:output-list -->
+## 二、本阶段产出清单
+
+| # | 文件 | 路径 | 顶层数组 |
+|---|---|---|---|
+| 1 | 角色.json | `设定/raw/sources/血肉/角色.json` | `characters` |
+| 2 | 冲突.json | `设定/raw/sources/血肉/冲突.json` | `conflicts` |
+| 3 | 势力.json | `设定/raw/sources/血肉/势力.json` | `factions` |
+| 4 | 剧情.json | `设定/raw/sources/血肉/剧情.json` | `main_lines` + `branches` |
+| 5 | 地点.json | `设定/raw/sources/血肉/地点.json` | `locations` |
+| 6 | 结局.json | `设定/raw/sources/血肉/结局.json` | `endings` |
+| 7 | 世界观规则.json | `设定/raw/sources/血肉/世界观规则.json` | `core_rules` + `information_rules` + `social_rules` + `rule_conflict_plan` |
+| 8 | 关键道具.json | `设定/raw/sources/血肉/关键道具.json` | `core_items` + `branch_items` + `symbolic_items` + `details` |
+
+**你每次只写其中一个文件的**。插件会分批发指令，每条指令只涉及一个文件、一个数组。
+
+**血肉脚本的 `FLESH_XREF_MISSING` 只查引用骨架的实体名（角色/势力/冲突），不查血肉间引用。**所以血肉之间的引用（成员、关系、关联冲突）写错，脚本查不出来，得你自己对。
+
+---
+
+<!-- contract:rules -->
+## 三、核心铁律（7 条，违反任意一条都会被判错）
+
+1. **不得出现任何章节号**——单章号字段（`chapter` / `ch` / `start` / `end` / `turning` / `midpoint` / `resolution` / `resolution_chapter` / `appear_start` / `appear_end` / `exit_chapter` / `buried_chapter` / `recovered_chapter` / `hook_chapter` / `climax_chapter` / `pleasure_chapter`）、区间字段（`appearance_chapters` / `chapter_range`）、嵌套形式（`escalation_nodes[].chapter` / `info_gaps[].created` / `key_nodes[].chapter` / `arc_stages[].chapter` / `interweaves[].chapter` / `foreshadow_recovery[].chapter`）**全部禁止**；完整清单见 glossary 第六节（脚本按它判定，别自己猜字段名）。血肉脚本会拦截 `FLESH_CHAPTER_FORBIDDEN`。
+
+2. **id 和 name 必须从骨架取**（插件会在指令里给你本批要写的条目清单）。不得自创实体、新编号、自造名字。`FLESH_REF_MISSING` / `FLESH_XREF_MISSING` 会拦截。
+
+3. **关键道具的 details 数组 id 必须与 summary 数组（core_items / branch_items / symbolic_items）一一对应**。details 是每个 summary 道具的详情副本，不是独立 ID 池。`FLESH_DETAILS_ORPHAN` 会拦截错位。
+
+4. **不得自创字段**。每个文件的字段必须严格在 `模板/血肉/<文件名>模板.json` 的 `structure.properties` 中定义。`EXTRA_FIELD` 会拦截。
+
+5. **世界观规则 id 前缀与所属数组匹配**：`core_rules` 用 `R`，`information_rules` 用 `I`，`social_rules` 用 `SR`。`FLESH_WORLD_RULE_CATEGORY` 会拦截。
+
+6. **关系类型必须与骨架完全一致**。`relationships[].relationship_type` 只能取 glossary 第五节 `relation_kind` 的 12 个值（血缘/师徒/雇佣/服从/提携/合作/利益交换/利用/对立/敌对/竞争/中立），而且**必须等于骨架里同一对角色的关系类型**。骨架写"A 服从 B"，这里就不能写"上下级"或"盟友"。`REL_TYPE_MISMATCH` / `ENUM` 会拦截。
+
+7. **描述要写实，不能写空话**。`description` / `core_flaw` / `goals.*` 这类叙述字段要写出一个具体事实，而不是"很好""详细设定。"。`TEXT_TOO_SHORT` / `TEXT_PLACEHOLDER` 会拦截；不同角色不能共用同一段话（`TEXT_DUPLICATE`）。
+
+---
+
+<!-- contract:refs -->
+## 四、参考文件
+
+### 4.1 必读
+
+- `references/glossary.md` —— 术语、ID 前缀、枚举、章节号字段清单
+
+### 4.2 按本轮文件选读
+
+| 本轮生成文件 | 读 |
+|---|---|
+| 角色.json | `references/血肉指导/01-character.md` |
+| 冲突.json | `references/血肉指导/01-character.md`（反派）、`references/血肉指导/04-emotion-methods.md` |
+| 势力.json | `references/血肉指导/02-worldbuilding.md` |
+| 剧情.json | `references/血肉指导/03-relations.md` |
+| 地点.json | `references/血肉指导/02-worldbuilding.md` |
+| 结局.json | `references/血肉指导/04-emotion-methods.md` |
+| 世界观规则.json | `references/血肉指导/02-worldbuilding.md` |
+| 关键道具.json | `references/血肉指导/02-worldbuilding.md` |
+
+### 4.3 模板
+
+每个文件的字段结构以 `模板/血肉/<文件名>模板.json` 为准。**写之前先读它**，不要凭记忆写字段名。
+
+${benchmark_refs_block}
+
+### 4.4 规则
+
+- 必读文件不可读时，停止本轮，把原因写进 `设定/raw/sources/血肉/.flesh-build/备注.md`。
+- 选读文件不可读时，跳过它继续写。
+- **不要整段读入骨架 JSON**（上下文会爆炸）。插件已经把本批要用的 id+name 和相关关系列在指令里了。
+- 需要骨架里某个实体的完整档案时，用只读查询脚本精确取：
+
+```bash
+node references/upstream-query.js --stage=骨架 --file=实体 --id=C001     # 取单个实体
+node references/upstream-query.js --stage=骨架 --file=关系 --list        # 看该文件有哪些记录分组
+```
+
+- 不得声称"已读取"参考文件。
+
+---
+
+<!-- contract:file:角色 -->
+## 五、角色.json 的字段契约
+
+**顶层数组**：`characters`　**模板**：`模板/血肉/角色模板.json`
+
+### 字段清单
+
+| 字段 | 写什么 |
+|---|---|
+| `id` | 骨架给的角色 id（如 `C001`），**原样抄，不得改** |
+| `name` | 骨架给的角色名，**逐字一致**（改一个字就是 `FLESH_NAME_MISMATCH`） |
+| `description` | 一段具体处境：这个人是谁、现在被什么困住。**不是**"性格坚强"这种评价 |
+| `goals.short_term` | 眼下最想要的一件事，可验证 |
+| `goals.medium_term` | 一段时间内要达成的目标 |
+| `goals.long_term` | 最终要抵达的状态 |
+| `core_flaw` | 会让他判断失手的性格缺陷，写成一句话的行为逻辑 |
+| `golden_finger` | 他唯一的优势（专业能力/特殊经验/性格特质）。没有就给空字符串 |
+| `information_state.known_secrets` | 他已经知道的关键事实 |
+| `information_state.unknown_secrets` | 他还不知道但读者该知道的关键事实 |
+| `information_state.false_beliefs` | 他坚信但其实错了的事 |
+| `arc_type` | 弧光类型，取 glossary `arc_type` 词表里的值 |
+| `arc_stages` | 弧光阶段数，正整数 |
+| `arc_change_descriptions.start` | 起点状态：开头时他是什么样的人 |
+| `arc_change_descriptions.turning` | 转折：他因为什么变了 |
+| `arc_change_descriptions.midpoint` | 中段状态（可空） |
+| `arc_change_descriptions.end` | 终点状态：结尾时他变成什么样 |
+| `language_profile.catchphrase` | 口头禅，一句能认出他的话 |
+| `language_profile.speech_rhythm` | 说话节奏（短促/迂回/书面/爱用反问……） |
+| `language_profile.info_preference` | 偏好用什么方式传递信息（讲故事/摆证据/打比方/先问再答） |
+| `language_profile.stance` | 面对冲突时的姿态（对抗/回避/迂回/拉拢） |
+| `language_profile.identity_wording` | 介绍自己时用什么词（"我师父"/"局里的"/"沈家的"） |
+| `language_profile.personality_tone` | 性格基调（冷硬/温和/尖刻/木讷） |
+| `language_profile.relationship_stage_tone` | 对不同关系的人说话语气怎么变 |
+| `behavior_repeat_points` | 反复出现的小动作或口头习惯，字符串数组 |
+| `mirror_type` | 反派专用：与主角互为镜像的类型，取 glossary `mirror_type` 词表。非反派不填 |
+| `relationships[]` | 关系条目，见下 |
+| `arc_changes[]` | 弧光变化条目：`stage`（阶段序号）+ `description`（这一阶段他变了什么） |
+| `memory_points.appearance` | 外貌记忆点（一个具体特征就够） |
+| `memory_points.personality` | 性格记忆点 |
+| `memory_points.catchphrase` | 口癖记忆点 |
+| `exclusive_needs.experience_count` | 他独有的经历次数 |
+| `exclusive_needs.presentation_method` | 呈现方式，取 glossary `presentation_method` 词表 |
+| `exclusive_needs.expected_volume` | 期望出场卷 id（可选；填了必须是骨架层级里存在的卷 id） |
+| `exit.type` | 退场类型，取 glossary `exit_type` 词表。有退场才填 |
+| `exit.description` | 怎么退的、退场后留下什么 |
+
+### `relationships[]` 的写法
+
+每条三个必填字段：`target_name` / `relationship_type` / `description`，可选 `changes[]`（`from` / `to` / `description`，写关系随剧情怎么变）。
+
+- `target_name` 写**对方的角色名**（不是 id）。
+- `relationship_type` 只能取 glossary 第五节 `relation_kind` 的 12 个值。
+- **必须和骨架给的关系完全一致**：插件会在指令里把本批角色涉及的关系列出来，照抄 `relation_kind` 即可。
+- **方向不能反**：骨架 `C001 → C002 = 师徒`，意思"C001 是 C002 的师父"，所以关系写在 **C001** 的文件里，`target_name` 写 C002 的名字。写在 C002 文件里就是 `REL_DIRECTION_FLIP`。
+- 骨架里没写过的关系**不要自己加**（`REL_NOT_IN_SKELETON`）。骨架写的是双向关系时，两个方向都要写。
+- 不要把自己写进 `target_name`（`FLESH_SELF_RELATION`）。
+
+### 不填的字段
+
+- **不要加章节号字段**（`chapter` / `ch` / `appearance_chapters` / `chapter_range` / `exit_chapter` / `arc_stages[].chapter` 等）：血肉的 `角色.json` 模板里**没有这些字段**——`arc_stages` 是阶段序号（number），`exit` 是 `{type, description}`。写进去会被 `EXTRA_FIELD` 拦下；章节号一律留给节奏阶段。
+- **不填** `faction_membership`（角色→势力的 ID 关系）—— 在骨架 `关系.json` 的 `faction_membership`。
+
+---
+
+<!-- contract:file:冲突 -->
+## 六、冲突.json 的字段契约
+
+**顶层数组**：`conflicts`　**模板**：`模板/血肉/冲突模板.json`
+
+| 字段 | 写什么 |
+|---|---|
+| `id` | 骨架冲突 id（`X001` 起），原样抄 |
+| `name` | 骨架冲突名，逐字一致 |
+| `description` | 这个冲突具体是什么场面：谁要什么、挡路的是谁 |
+| `core_goal` | 冲突双方各自的核心诉求（写清是谁的什么诉求） |
+| `influence_scope` | 影响范围：波及哪些人、哪些势力、哪条线 |
+| `focus_points[]` | 冲突的着力点，字符串数组（哪几件事让冲突撕起来） |
+| `surface_contradiction` | 表面矛盾：一眼能看出来的对立 |
+| `deep_contradiction` | 深层矛盾：价值观/利益层面的对立（可空） |
+| `ultimate_contradiction` | 终极矛盾：全书最后要解决的那层对立（可空） |
+| `escalation_path[]` | 升级路径条目：`node_type`（取 glossary `node_type` 词表）+ `description`（这一步怎么恶化） |
+| `resolution_plan.method` | 怎么收场 |
+| `resolution_plan.residual_impact` | 收完还剩什么后遗症（余韵） |
+| `information_gaps[]` | 信息差条目：`info_name` / `who_knows[]` / `who_does_not_know[]` / `resolution_method` |
+
+### 不填的字段
+
+- **不要加章节号字段**：血肉的 `冲突.json` 里 `escalation_path[]` 只有 `node_type`/`description`、`resolution_plan` 只有 `method`/`residual_impact`、`information_gaps[]` 只有 `info_name`/`who_knows`/`who_does_not_know`/`resolution_method`——**本来就没有章节号的位置**。冲突的章节号在节奏阶段：`escalation_nodes[].chapter` / `resolution_chapter` / `info_gaps[].created`。
+- **不填** `protagonist_side` / `main_antagonist` 等 —— 在骨架 `关系.json` 的 `conflict_participants`。
+
+---
+
+<!-- contract:file:势力 -->
+## 七、势力.json 的字段契约
+
+**顶层数组**：`factions`　**模板**：`模板/血肉/势力模板.json`
+
+| 字段 | 写什么 |
+|---|---|
+| `id` | 骨架势力 id（`F001` 起），原样抄 |
+| `name` | 骨架势力名，逐字一致 |
+| `goal` | 这个势力自己要什么（不是"维护正义"，是具体的利益/位置） |
+| `resources[]` | 它手上有什么牌：钱、人、渠道、权限、信息，字符串数组 |
+| `internal_structure` | 内部结构：分几层、谁管谁、派系怎么分 |
+| `suppression_method` | 压制手段：它怎么让不听话的人闭嘴 |
+| `resource_seizure_path` | 资源被夺走的路径：它靠哪条链子把资源拿走 |
+| `main_line_connection` | 它和主线的关系：参与还是被排除，排除的理由是什么 |
+| `members[]` | 成员条目：`name`（**角色名，不是 id**）/ `position_description`（这个人在势力里的位置）/ `relation_description`（他为什么在这里） |
+| `relations[]` | 势力关系条目：`target_name`（**对方势力名**）/ `description`（关系是什么样的） |
+
+### 不填的字段
+
+- **不填** `faction_membership`（角色→势力的 ID 关系）—— 在骨架 `关系.json`。
+- **不填** `faction_relations`（势力间的 ID 关系）—— 在骨架 `关系.json`。
+- 本文件的 `members` 和 `relations` 是"人读的描述"，引用的是 `name` 不是 `id`。
+
+---
+
+<!-- contract:file:剧情 -->
+## 八、剧情.json 的字段契约
+
+**顶层数组**：`main_lines` + `branches`　**模板**：`模板/血肉/剧情模板.json`
+
+### `main_lines[]`（主线）
+
+| 字段 | 写什么 |
+|---|---|
+| `id` | 骨架主线 id（`M001` 起），原样抄 |
+| `name` | 骨架主线名，逐字一致 |
+| `core_drive` | 主线的核心驱动：这个故事"之所以在发生"的那个持续推力 |
+
+### `branches[]`（支线）
+
+| 字段 | 写什么 |
+|---|---|
+| `id` | 骨架支线 id（`B001` 起），原样抄 |
+| `name` | 骨架支线名，逐字一致 |
+| `goal` | 这条支线要达成什么 |
+| `main_relation` | 它和主线的关系（怎么挂上去、挂在哪一段） |
+| `expected_outcome` | 预期结果：这条线走完给出什么 |
+
+### 不填的字段
+
+- **支线就上面这 5 个字段，不要自己加**：血肉的 `剧情.json` 里支线只有这 5 个字段，章节号的位置留给节奏阶段的 `branch_timeline`（`start` / `turning` / `resolution` / `interweaves`）。自己加 `chapter` / `appearance_chapters` 这类会被 `EXTRA_FIELD` 拦下。
+
+---
+
+<!-- contract:file:地点 -->
+## 九、地点.json 的字段契约
+
+**顶层数组**：`locations`　**模板**：`模板/血肉/地点模板.json`
+
+| 字段 | 写什么 |
+|---|---|
+| `id` | 骨架地点 id（`L001` 起），原样抄 |
+| `name` | 骨架地点名，逐字一致 |
+| `features.layout` | 空间布局：这个地方长什么样、走进去是什么感觉 |
+| `features.key_elements[]` | 关键陈设/要素，字符串数组 |
+| `key_event_descriptions[]` | 这里发生过什么关键事件，字符串数组 |
+| `narrative_role_description` | 叙事作用：这个地点在故事里承担什么（人物主场/线索源头/压迫空间……） |
+
+### 不填的字段
+
+- **不要加章节号字段**（`appearance_chapters` / `chapter_range` 等）：血肉的 `地点.json` 模板里没有这些字段（写进去会被 `EXTRA_FIELD` 拦下）；地点的章节号在节奏阶段。
+- **不填** `related_conflicts` —— 在骨架 `关系.json` 的 `location_conflict`。
+
+---
+
+<!-- contract:file:结局 -->
+## 十、结局.json 的字段契约
+
+**顶层数组**：`endings`　**模板**：`模板/血肉/结局模板.json`
+
+| 字段 | 写什么 |
+|---|---|
+| `id` | 骨架结局 id（`E001` 起），原样抄 |
+| `name` | 骨架结局名，逐字一致 |
+| `conflict_summary` | 这个结局收的是哪个核心冲突、收成了什么样 |
+| `conflict_solution` | 具体怎么解的：靠什么代价/什么转折/什么选择 |
+| `anti_trope_design[]` | 反套路设计：这个结局刻意避开了哪种常见写法，字符串数组 |
+| `aftermath.special_remaining` | 特别残留：哪个悬念/哪笔账故意没清 |
+| `aftermath.character_destinations` | 主要角色的去向（写名字 + 去处） |
+| `aftermath.suspense_blanks[]` | 留白的悬念，字符串数组 |
+| `emotion_trajectory` | 情绪轨迹：从什么情绪到什么情绪，中间怎么转 |
+| `core_emotion` | 核心情绪：读者该被击中的那一下是什么 |
+| `final_point` | 落点：最后一句话意义上的那个结论 |
+| `chapter_design.climax_design` | 高潮怎么设计 |
+| `chapter_design.turning_design` | 转折怎么设计 |
+| `chapter_design.cost_design` | 代价怎么落 |
+| `chapter_design.resolution_design` | 收束怎么设计 |
+| `memorable_scenes[]` | 值得记住的场面，字符串数组 |
+| `epilogue_hints[]` | 尾声暗示，字符串数组 |
+| `foreshadow_recovery_plan[]` | 伏笔回收条目：`foreshadow_id`（**必须是骨架 `实体.json` 里真实存在的伏笔 id**）+ `method`（怎么回收） |
+
+### 不填的字段
+
+- **不要加章节号字段**：血肉的 `结局.json` 里 `foreshadow_recovery_plan[]` 只有 `foreshadow_id`/`method`，本来就没有章节号的位置；结局伏笔的章节号在节奏阶段的 `foreshadow_recovery[].chapter`。
+- **不填** `level` / `type` —— 在骨架 `实体.json`。
+
+---
+
+<!-- contract:file:世界观规则 -->
+## 十一、世界观规则.json 的字段契约
+
+**顶层数组**：`core_rules` + `information_rules` + `social_rules` + `rule_conflict_plan`
+**模板**：`模板/血肉/世界观规则模板.json`
+
+### `core_rules[]` / `information_rules[]`（核心规则 / 信息规则）
+
+| 字段 | 写什么 |
+|---|---|
+| `id` | 骨架规则 id，原样抄。**前缀必须与数组匹配**：`core_rules` 是 `R` 前缀，`information_rules` 是 `I` 前缀 |
+| `name` | 骨架规则名，逐字一致 |
+| `content` | 规则本身：这个世界的什么必须永远成立 |
+| `applicable_scope` | 适用范围：对谁、在什么情境下生效 |
+| `exception` | 唯一的例外（可空） |
+| `impact_on_protagonist` | 这条规则怎么限制主角、逼他付出什么 |
+
+### `social_rules[]`（社会规则）
+
+| 字段 | 写什么 |
+|---|---|
+| `id` | 骨架规则 id。**前缀必须是 `SR`** |
+| `name` | 骨架规则名，逐字一致 |
+| `content` | 规则本身 |
+| `violation_consequence` | 违反这条会付出什么代价 |
+| `impact_on_plot` | 这条规则怎么推着剧情走 |
+
+### `rule_conflict_plan[]`（规则冲突预案）
+
+| 字段 | 写什么 |
+|---|---|
+| `contradiction` | 哪两条规则（或规则与核心冲突）互相打架 |
+| `solution` | 怎么化解这条矛盾 |
+
+**前缀规则会判错**（`FLESH_WORLD_RULE_CATEGORY`）：`R`→`core_rules`，`I`→`information_rules`，`SR`→`social_rules`。
+
+---
+
+<!-- contract:file:关键道具 -->
+## 十二、关键道具.json 的字段契约
+
+**顶层数组**：`core_items` + `branch_items` + `symbolic_items` + `details`
+**模板**：`模板/血肉/关键道具模板.json`
+
+### `core_items[]` / `branch_items[]`（核心道具 / 支线道具）
+
+| 字段 | 写什么 |
+|---|---|
+| `id` | 骨架道具 id（`P001` 起），原样抄 |
+| `name` | 骨架道具名，逐字一致 |
+| `function` | 这个道具在故事里干什么用（推动哪件事） |
+| `relation` | 它和主线/核心冲突的关系：为什么它必须在场 |
+
+### `symbolic_items[]`（象征道具）
+
+| 字段 | 写什么 |
+|---|---|
+| `id` | 骨架道具 id，原样抄 |
+| `name` | 骨架道具名，逐字一致 |
+| `symbolic_meaning` | 它象征什么（对应主角的哪种心结/困境） |
+| `usage_scenario` | 什么时候会被拿出来用 |
+
+### `details[]`（道具详情）
+
+**每个 item 必须有且仅有一条 details，id 完全相同。**
+
+| 字段 | 写什么 |
+|---|---|
+| `id` | 与 summary 道具**完全相同**的 id |
+| `name` | 与 summary 道具完全相同的名字 |
+| `type` | 道具类别（核心/支线/象征） |
+| `appearance` | 外观：什么材质、什么样子、有没有磨损 |
+| `origin` | 来历：谁做的、怎么到这个角色手里 |
+| `function_detail` | 功能细节：具体怎么起作用（工艺/机制/用法） |
+| `limit` | 限制：它做不到什么（可空） |
+| `related_characters[]` | 相关角色**名字**，字符串数组 |
+| `related_conflicts[]` | 相关冲突**名字**，字符串数组 |
+
+### 不填的字段
+
+- **不填** `belong_to`（归属）—— 在骨架 `关系.json` 的 `item_owner`。
+- **不要加章节号字段**（`appearance_chapters` / `chapter_range` 等）：血肉的 `关键道具.json` 模板里没有这些字段（写进去会被 `EXTRA_FIELD` 拦下）；道具的章节号在节奏阶段。
+
+---
+
+<!-- contract:quality -->
+## 十三、关系类型与内容质量（照着正例写）
+
+脚本不只查结构，也查"写的东西是不是真的"、"两个阶段说的是不是同一件事"。
+
+**关系类型**——`relationships[].relationship_type` 只从这 12 个值里选，且必须与骨架一致：
+
+| 词表值 | 正例（骨架 `关系.json` → 血肉 `角色.json`） |
+|---|---|
+| 血缘 | 骨架 `C001 → C002` = `血缘` → 陆子仲的 relationships 里写 `target_name: "沈砚"`（对方的**角色名**，不是称谓）, `relationship_type: "血缘"` |
+| 师徒 | 骨架 `C001 → C002` = `师徒` → 师父角色的 relationships 里写 `师徒` |
+| 雇佣 | 骨架 `C001 → C002` = `雇佣` → 雇主角色的 relationships 里写 `雇佣` |
+| 服从 | 骨架 `C001 → C002` = `服从` → 陆子仲的 relationships 里写 `服从` |
+| 提携 | 骨架 `C001 → C002` = `提携` → 提携者的 relationships 里写 `提携` |
+| 合作 | 骨架 `C001 → C002` = `合作` → 写 `合作` |
+| 利益交换 | 骨架 `C001 → C002` = `利益交换` → 写 `利益交换` |
+| 利用 | 骨架 `C001 → C002` = `利用` → 利用者写 `利用` |
+| 对立 / 敌对 / 竞争 / 中立 | 同理，逐一照抄骨架的值 |
+
+**不要写的**（不在词表，`ENUM` 拦截）：`盟友`→`合作`；`对手`→`对立` 或 `敌对`；`上下级`→先想清楚是`师徒`/`雇佣`/`服从`哪一个；`血亲`→`血缘`。
+
+**关系方向**：`relationships[]` 表达的是"**本角色**对 `target_name` 的关系"，方向与骨架的 `from`→`to` 一致。
+
+- 反例：骨架 `C001 → C002` = `服从`，血肉在 C002 的文件里写 `target_name: "陆子仲"`, `relationship_type: "服从"` → 方向反了，`REL_DIRECTION_FLIP`。
+- 反例：骨架里 A 和 B 没有任何关系，血肉却给 A 加了一条指向 B 的关系 → `REL_NOT_IN_SKELETON`。
+- 反例：某角色把自己写进 `target_name` → `FLESH_SELF_RELATION`。
+- 反例：骨架 `C001 → C002` = `合作`，血肉写 `敌对` → `REL_TYPE_MISMATCH`。
+
+**内容质量**——叙述字段要写出一个具体事实：
+
+| 反例（会被拦下） | 正例 |
+|---|---|
+| `description: "详细设定。"` | `description: "刑侦支队队长，二十年没破过命案，却记得每一个死者的名字。"` |
+| `core_flaw: "多疑"` | `core_flaw: "凡事留后手，谁都信不过，连自己开的枪也要复检一遍。"` |
+| `goals.short_term: "a"` | `goals.short_term: "两周内拿到妹妹的尸检报告，确认她到底死于哪一天。"` |
+| `language_profile.catchphrase: "x"` | `language_profile.catchphrase: "证据不会撒谎，人才会。"` |
+| 所有角色的 `description` 复制同一段 | 每个角色写各自的处境与说话方式 |
+
+**同质化**：不同实体的同一字段不能几乎一字不差（`TEXT_DUPLICATE`）。写每个人的不同处境，不要把一句话复制给所有人。
+
+---
+
+<!-- contract:errors -->
+## 十四、常见错误代码速查
+
+插件回喂给你的错误清单里的 `code` 对应下表。**只改被点名的字段**，其余不要动。
+
+| code | 含义 | 修复方向 |
+|---|---|---|
+| `FLESH_CHAPTER_FORBIDDEN` | 血肉出现章节号 | 删除，移到节奏阶段 |
+| `FLESH_REF_MISSING` | 血肉 id 不在骨架中 | 改用骨架的 id |
+| `FLESH_NAME_MISMATCH` | 同一 id 的 name 与骨架不一致 | 改为骨架的 name |
+| `FLESH_XREF_MISSING` | 名称引用不存在于骨架 | xrefCheck 同时支持 id 和 name。如果检查 id，请确认写对了（如 'C001' 而不是空字符串）；检查 name，请确认与骨架 name 完全一致。**报错信息里如果带了"疑似拼错"，直接照着它给的正确名字改** |
+| `FLESH_FORESHADOW_REF_MISSING` | 结局的伏笔回收计划里的 `foreshadow_id` 不在骨架的 foreshadows 里 | 改成骨架 实体.json 里真实存在的伏笔 id（格式对不代表这个 id 存在） |
+| `FLESH_WORLD_RULE_CATEGORY` | 规则 id 前缀与所属数组不匹配 | R→core_rules，I→information_rules，SR→social_rules |
+| `FLESH_DETAILS_ORPHAN` | 道具 details 与 items 不对应 | 补齐或删除 |
+| `FLESH_EXTRA_ENTITY` | 血肉有骨架没有的 id | 删除该实体；若它确实是骨架缺的内容，记进 `.flesh-build/备注.md` 的骨架缺口，由用户重新运行骨架阶段补全 |
+| `FLESH_FREETEXT_CHAPTER_REF` | 自由文本里出现"第 N 章"这类章节引用 | 章节号属于节奏阶段。改成"某阶段/某卷"，或留到节奏阶段处理 |
+| `FLESH_INCOMPLETE`（warning） | 骨架里的某个实体在血肉中没出现 | 全量写完时应该覆盖所有骨架实体。补上该实体 |
+| `ENUM_MISSING` | 模板引用的枚举词表在 glossary 里没定义 | 这是参考文件本身的问题（`references/glossary.md` 缺该枚举小节），不是你写错了。照模板里写的值填，并把这个码原样报给用户 |
+| `REL_KIND_META_DRIFT` | 关系类型词表与关系类型元数据不同步 | 同样是参考文件/脚本的一致性问题，不是你写错了。照 glossary 第五节的词表填，并把这个码原样报给用户 |
+| `NEED_ALL_CHECK`（warning） | 本文件单检通过，但跨文件一致性要等全量校验 | 不用管，插件会自己跑全量校验 |
+| `UPSTREAM_MISSING` / `UPSTREAM_NOT_READY` / `UPSTREAM_NOT_PASSED` | 上游骨架没准备好（读不到实体 / 没跑过校验 / 没通过校验） | 不是你写错了。停下这一轮，把这三个码原样报给用户，让用户先修骨架阶段 |
+| `FLESH_ARC_INCONSISTENT`（warning） | arc_type 与 arc_stages 不兼容 | 调整 arc_stages 或 arc_type |
+| `FLESH_ARC_STAGES_INVALID`（warning） | arc_stages 不是正整数 | 改为正整数 |
+| `REL_TYPE_MISMATCH` | 血肉的关系类型与骨架不一致 | 改成骨架里同一对角色的关系类型 |
+| `REL_NOT_IN_SKELETON` | 血肉声明了骨架没有的关系对 | 骨架补上，或删掉血肉这条 |
+| `REL_DIRECTION_FLIP` | 有向关系被写到了反方向 | 写回关系起点那个角色的文件里 |
+| `REL_UNDECLARED`（warning） | 骨架的关系还没在血肉里展开 | 补该角色的 relationships 条目 |
+| `FLESH_SELF_RELATION` | 角色把自己列为关系对象 | 删掉；自我矛盾写进 description / core_flaw |
+| `FLESH_GROUP_CATEGORY_MISMATCH` | 分组与所属数组不匹配 | 调整分组 |
+| `FLESH_EXPECTED_VOLUME_MISSING`（warning） | exclusive_needs.expected_volume 不在骨架卷里 | 改为骨架层级里已存在的卷 id |
+| `NAME_PLACEHOLDER` | 实体名是"主角1"这类占位名 | 换成有辨识度的专名 |
+| `TEXT_PLACEHOLDER` | 字段内容是"待补充/TBD/xxx"这类占位 | 写实内容 |
+| `TEXT_TOO_SHORT` | 字段内容过短，承载不了信息 | 补成一句具体的事实 |
+| `TEXT_DUPLICATE` | 两个实体的同一字段几乎一字不差 | 各写各的具体内容 |
+| `EXTRA_FIELD` | 模板外字段 | 删除 |
+| `REQUIRED` / `TYPE` / `PATTERN` / `ENUM` | 模板结构不符 | 按 `模板/血肉/` 模板与 `references/glossary.md` 改 |
+| `CHARSET_KO` / `CHARSET_JP` / `PLACEHOLDER` | 字符集 | 删除 |
+| `ID_DUP` | 同文件 id 重复 | 检查重复。**注意**：`关键道具.json` 的 details 的 id 与 summary 数组里道具 ID 一一对应是**正确**结构，不会被判重复 |
+
+---
+
+<!-- contract:forbidden -->
+## 十五、本阶段禁令（11 条）
+
+1. **不得出现任何章节号**——单章号字段（`chapter` / `ch` / `start` / `end` / `turning` / `midpoint` / `resolution` / `resolution_chapter` / `appear_start` / `appear_end` / `exit_chapter` / `buried_chapter` / `recovered_chapter` / `hook_chapter` / `climax_chapter` / `pleasure_chapter`）、区间字段（`appearance_chapters` / `chapter_range`）、嵌套形式（`escalation_nodes[].chapter` / `info_gaps[].created` / `key_nodes[].chapter` / `arc_stages[].chapter` / `interweaves[].chapter` / `foreshadow_recovery[].chapter`）**全部禁止**；完整清单见 glossary 第六节（脚本按它判定，别自己猜字段名）。
+
+2. **`id` 必须从骨架取**。不得自己编号。血肉是骨架的"档案补充"，不是"独立实体表"。
+
+3. **`name` 必须与骨架一致**。同一 `id` 的 `name` 在血肉和骨架必须完全相同。
+
+4. **不填骨架关系**。`faction_membership` / `faction_relations` / `conflict_participants` / `branch_protagonist` / `item_owner` / `location_conflict` / `ending_character` 的 ID 关系在骨架 `关系.json`，血肉只填"描述层"（如 `势力.json` 的 `members[].name` 是文本，不是 ID 数组）。
+
+5. **不得出现模板外字段**。
+
+6. **`details` 的 id 必须与三类 items 一一对应**。每个 item 有且仅有一条 details。
+
+7. **世界观规则的 id 前缀必须与所属数组匹配**。
+
+8. **不得声称"已读取"参考文件**。
+
+9. **不得在 JSON 字符串外使用中文标点**。字符串内容用中文标点，JSON 语法符号必须英文。
+
+10. **不得输出"通过/完成/PASS"等结论词**，不得宣布阶段结束。阶段成败由插件判定。
+
+11. **不得修改 `模板/` 和 `references/` 下的任何文件**，也不得修改 `设定/raw/sources/骨架/` 下的任何文件。这三者都是**只读输入**。严禁为了"通过校验"而修改校验脚本或规则文件——所有脚本与参考文件的修改由项目维护者通过 plugin 升级路径完成。**本阶段的输出目录 `设定/raw/sources/血肉/` 是你要写的产物**。
+
+---
+
+<!-- contract:semantic -->
+## 十六、语义检查（可选，由用户显式开启）
+
+上面的校验全是**确定性脚本**：id 在不在、名字对不对、枚举合不合法、配额对不对得上、关系有没有声明。凡是脚本能判死的问题，都已经被判死了。
+
+**脚本判不了的是"内容咬不咬合"**：同一个角色的两段描述对不对得上、伏笔的埋设和回收是不是同一件事、关系类型和描述里的态度是不是矛盾。这类问题需要读懂全文才能判断。
+
+用户在血肉阶段命令后加 `--semantic` 时，插件会在产出完成后**另起一轮**，让你做一次设定审校，并把发现的问题列给用户。
+
+**这一轮你需要做的只有一件事**：如果插件给了你一份 LINT 任务（要求把 `---LINT:---` 块写进指定文件），就**按格式把结论写进那个文件**，不要额外解释、不要用代码块包住。
+
+**如果没发现值得报的问题，就写一个空文件**。不要为了凑数硬编问题——审校结果会被本地脚本复核，指认的实体如果明明存在，会被直接丢弃。
+
+**语义检查不阻断血肉阶段**：血肉阶段成不成功，由确定性脚本说了算。语义检查的结果是给人参考的，改不改由用户决定。