@cloud411716/fancy-webnovel 1.0.46 → 3.0.0

package/plugins/fancy-story-builder/references//350/241/200/350/202/211/346/214/207/345/257/274/01-character.md

@@ -0,0 +1,243 @@
+# 人物深化
+
+> 血肉阶段第 1 份。在骨架角色卡基础上，补描述、目标、缺陷、弧光类型、语言档案、执念、行为重复点、镜像类型。
+> 本文件不写枚举值（→ glossary），不写数据结构（→ 角色模板.json），不写验证（→ flesh-validate.js）。
+
+---
+
+## 一、决策路由
+
+| 你在做什么 | 用哪节 |
+|---|---|
+| 深化主角 | §2 主角深化 |
+| 深化配角 | §3 配角深化 |
+| 深化反派 | §4 反派深化 |
+| 设计执念 | §3.3 执念 |
+| 设计行为重复点 | §3.4 行为重复点 |
+| 写语言档案 | §5 语言档案 |
+
+---
+
+## 二、主角深化
+
+### 2.1 骨架字段与血肉字段的分工
+
+骨架阶段的主角卡只有 `id` + `name` + `type` + `gender` + `age_group`（见 `模板/骨架/实体模板.json`）。
+
+血肉阶段在 `模板/血肉/角色模板.json` 的 `characters` 数组中补：
+- `description`：一段话描述（性格/背景/特质）
+- `goals`：短期/中期/长期目标（三层，具体到"想做什么"）
+- `core_flaw`：核心缺陷（**声明类型**，类型值见 glossary 的 defect 相关枚举，本文件不重复枚举值）
+- `golden_finger`：金手指描述（如适用）
+- `information_state`：已知秘密 / 未知秘密 / 误信信息
+- `arc_type`：弧光类型（枚举值见 glossary 的 `arc_type`）
+- `arc_stages`：弧光阶段数（数字）
+- `arc_change_descriptions`：起点/转折/中点/终点的**文本描述**（不填章节号）
+- `language_profile`：语言档案 7 维（见 §5）
+- `behavior_repeat_points`：行为重复点（见 §3.4）
+- `traits`：3-5 条独有特征/习惯/感官锚点（见 §3.4）
+- `extensions`：题材特有的扩展设定（如灵异题材的阴气/附身痕迹），键用中文
+- `relationships`：关系数组（见 §6）
+- `arc_changes`：弧光变化数组（stage + description）
+- `memory_points`：记忆点（外貌/性格/口头禅）
+- `exclusive_needs`：专属剧情需求（段数/呈现方式/预期卷）
+- `exit`：退场（类型 + 描述，**不填章节号**）
+
+### 2.2 缺陷五类
+
+缺陷类型见 `references/glossary.md` 的 `character_defect_type` 枚举。选择原则：
+
+- **性格缺陷**：傲慢、多疑、逃避、复仇心等。**必须在关键情节导致主角犯错**。适用成长文、正剧、复仇。
+- **生理缺陷**：天阉、残疾、病弱等。**不要求犯错**，制造关系障碍。适用年代、虐恋、治愈。
+- **身份缺陷**：私生子、赘婿、废柴等。**不要求犯错**，制造社会障碍。适用逆袭、宅斗、赘婿。
+- **能力缺陷**：战力低、没钱、没背景等。**不要求犯错**，制造成长空间。适用升级文、逆袭。
+- **道德缺陷**：内核邪恶、圣母等。**主角禁用**，仅反派/配角。
+
+**规则**：写"主角有缺陷"时，先声明是哪一类。只有性格缺陷走"致命化"（在关键情节导致失败），其余四类只做障碍。
+
+### 2.3 成长弧题材决策
+
+| 题材 | 成长是否必须 |
+|---|---|
+| 升级流、玄幻、逆袭 | 能力成长必须，心智可稳定 |
+| 追妻/追夫、虐恋 | 心智成长必须 |
+| 无敌流、轻松搞笑、日常 | 不必须，稳定人设是魅力 |
+| 正剧、文学向 | 必须 |
+
+**规则**：成长弧可写"不变型"（稳定人设），但必须用"行为重复点 + 记忆点"补足魅力。不声明 = 默认必须成长。
+
+### 2.4 设计要点
+
+- 动机必须是情感层（"为妹妹复仇"优于"要变强"）
+- 弱点必须会在关键情节导致犯错（仅性格缺陷）
+- 外貌和口头禅是记忆锚点，必须写
+- 起名跟设定时代/地域/文化走
+
+### 2.5 主角逼格与红线
+
+- 主角必须有逼格——读者代入基础
+- 不写太多降智内心戏和爆粗口
+- 红线（绝对不写）：圣母型、无脑战斗机器、内核邪恶、因蠢/圣母犯错、自暴自弃
+- 阶段豁免："主角牛逼了必须有所得"只在兑现段/释放段适用。谷底段/压制段允许无回报，但兑现段必须加倍回报
+
+---
+
+## 三、配角深化
+
+### 3.1 配角的功能
+
+配角在血肉阶段补的字段：`description` / `goals` / `core_flaw` / `language_profile` / `behavior_repeat_points` / `traits` / `extensions` / `relationships` / `memory_points` / `exclusive_needs` / `exit`。
+
+配角的设计核心是"功能"。每个配角至少占一个功能（可兼两个）：
+
+- **导师**：指引、传信息。必须有盲区。
+- **盟友**：协助、支持。不能只是工具人。
+- **情报源**：提供信息差。不能当"科普嘴"。
+- **牺牲品**：制造情绪冲击。退场要有意义。
+- **镜像对照**：映衬主角选择。与主角同起点不同选择。
+- **搞笑担当**：缓解紧张。高压 beat 收敛。
+- **叛徒**：制造转折。背叛要有前期铺垫。
+
+**规则**：无功能角色不出场。功能在 `description` 中体现，不单独建字段。
+
+### 3.2 配角与反派的关系
+
+中反派及以上的配角（在骨架中 `type = 贯穿级核心反派` 或 `卷级反派`）必须有独立动机，不能只是"主角的障碍物"。
+
+### 3.3 执念
+
+给支线配角一个执念，所有行为围绕执念。极端执念加"亲民"小细节。
+
+**执念合理性检查**：执念是否与题材/人设/道德底线冲突？"每天杀一人"加亲民细节也救不回。适用支线配角，不适用频繁出现的主要配角。
+
+执念写进 `description`，不单独建字段。
+
+### 3.4 行为重复点
+
+抓住行为特质反复写维持长篇。每个角色 2-3 个行为重复点，落在 `behavior_repeat_points` 数组。
+
+`traits` 则是更具体的“这个人独有”的细节：紧张时摸腕环、说话前先看门口、袖口永远沾着墨。写 3-5 条，每条都能在场景里演出来；不要用“善良”“勇敢”“聪明”这类评价词凑数。
+
+**疲劳边界**：同一行为连续多次无差异化时，换场景/换对象/换后果，否则读者疲劳。
+
+---
+
+## 四、反派深化
+
+### 4.1 反派在血肉阶段补的字段
+
+在骨架 `type = 贯穿级核心反派` 或 `卷级反派` 的角色，血肉阶段额外补：
+- `mirror_type`：相似镜像 / 相反镜像（枚举值见 glossary 的 `mirror_type`）
+- `description` 中写：完整人弧（仅核心反派）、理念冲突（仅核心反派）、恨不起来的侧面（仅核心反派）、合理化平衡（核心反派）
+- `golden_finger` 通常不填（反派不用金手指）
+
+### 4.2 镜像两种
+
+| 类型 | 定义 | 效果 | 适用 |
+|---|---|---|---|
+| 相似镜像 | 同起点不同选择，反派是主角"走错路"的版本 | 悲剧感、宿命感 | 贯穿级核心反派 |
+| 相反镜像 | 反派长处反映主角弱点，完全相反 | 摩擦感、互补对抗 | 卷级反派、日常对手 |
+
+**规则**：贯穿级核心反派用相似镜像；卷级反派及以下用相反镜像。
+
+### 4.3 反派铁律
+
+- 反派智商/实力决定主角含金量——反派弱 = 主角赢没意义
+- 反派行为从其视角说得通
+- 不降智送赢
+- 反派渲染公式：明确动机 → 动机驱动行为 → 行为形成障碍 → 障碍强度来自反派分量
+
+### 4.4 合理化平衡
+
+贯穿级核心反派做到"70/30"：
+- 合理化到 70%：反派逻辑自洽
+- 留 30% 读者恨点：一个读者无法接受的底线行为
+
+---
+
+## 五、语言档案 7 维
+
+写进 `language_profile` 的 7 个字段：
+
+| 维度 | 说明 | 示例 |
+|---|---|---|
+| 口癖 | 标志性用词 | "啧" / "行吧" / "有意思" |
+| 说话节奏 | 长句 vs 短句 | 长篇大论 vs 短句连击 |
+| 信息偏好 | 专业术语/江湖切口/大白话 | 技术型带术语，江湖人带切口 |
+| 立场 | 永远从某角度发言 | 悲观派/乐观派/务实派 |
+| 身份措辞 | 自称/敬谦词 | 老者/少年/贵族/市井 |
+| 性格语气 | 话里有话/想到就说/措辞精确 | 智谋型/鲁莽型/冷静型 |
+| 关系阶段语气 | 初见/熟悉/对立/亲密 | 语气与信息量随阶段变 |
+
+**规则**：遮住角色名，能区分是谁在说话，语言档案才算合格。
+
+**与写作阶段的对接**：写作阶段的 `04-04-dialogue-mastery.md` 在写对话时直接从 `language_profile` 取。
+
+---
+
+## 六、关系变化
+
+在 `relationships` 数组中，每个关系是一对（`target_name` + `relationship_type` + `description`）。
+
+**变化的表达**：`changes` 数组记录关系的变化，每项是 `{from, to, description}`。**不填章节号**——关系在什么时间点变化，属于节奏阶段的 `时序映射.json`。
+
+**规则**：每次关系变化必须有触发事件（在 `changes[].description` 中写），不能"说变就变"。
+
+---
+
+## 七、示例
+
+一本都市复仇文的主角：
+
+- `description`：前特种兵，退伍后做保安。冷静、话少、算计深，但对妹妹极尽温柔。
+- `goals`：
+  - short_term：找到妹妹失踪的线索
+  - medium_term：渗透进缅北园区，摸清结构
+  - long_term：端掉整个园区，让所有涉案者付出代价
+- `core_flaw`：性格缺陷——极度自我，拒绝求助，宁可自己扛也不让战友卷入
+- `arc_type`：成长型
+- `arc_stages`：4
+- `arc_change_descriptions`：
+  - start：独狼式复仇，不信任任何人
+  - turning：发现独自行动导致战友牺牲
+  - midpoint：开始接受帮助，学会指挥
+  - end：从独狼变成领袖，复仇成功但代价沉重
+- `language_profile`：口癖"嗯"；短句连击；专业术语（特种作战）；务实派；自称"我"、称呼别人直呼其名；话里有话；熟悉后话略多
+- `behavior_repeat_points`：紧张时摸左手腕旧伤；不信任时说"我自己来"；痛苦时沉默
+- `mirror_type`：不适用（主角不是反派）
+- `relationships`：与妹妹（亲情，描述"妹妹是他唯一柔软的地方"）、与坤沙（敌对，描述"我必须杀他"）、与老王（盟友，描述"唯一能信任的老战友"）
+
+---
+
+## 八、常见反例
+
+| 反例 | 为什么错 | 正确做法 |
+|---|---|---|
+| 主角动机写"要变强" | 不是情感层 | 写"为妹妹复仇" |
+| 配角没有功能 | 工具人 | 补功能（导师/盟友/叛徒等） |
+| 反派没有独立动机 | 工具人 | 从反派视角写"他想要什么" |
+| 语言档案 7 维只填 3 维 | 不完整 | 7 维全填 |
+| 关系变化没有触发事件 | 说变就变 | 在 changes[].description 写触发事件 |
+| 填了 `appearance_chapters` 或 `arc_stages[].chapter` | 违反血肉阶段禁令 | 删掉，章节号属于节奏阶段 |
+
+---
+
+## 九、与其他文件的关系
+
+| 本文件输出 | 落到哪个字段 | 参考哪个公式 | 由哪个脚本验证 |
+|---|---|---|---|
+| 主角/配角/反派档案 | `角色.json` 的 `characters` | 无公式 | `flesh-validate.js` 的 `FLESH_REF_MISSING` / `FLESH_NAME_MISMATCH` / `FLESH_ARC_INCONSISTENT` / `FLESH_CHAPTER_FORBIDDEN` |
+| 语言档案 7 维 | `characters[].language_profile` | 无公式 | `REQUIRED` |
+| 关系变化 | `characters[].relationships[].changes` | 无公式 | `FLESH_XREF_MISSING`（target_name 必须存在于骨架角色） |
+
+**不输出到**：
+- 关系变化的"章节号" → 属于节奏阶段 `时序映射.json` 的 `character_timeline`
+- 退场章 → 属于节奏阶段 `时序映射.json` 的 `character_timeline.exit_chapter`
+
+---
+
+## 十、版本记录
+
+| 版本 | 变更 |
+|---|---|
+| v1.0 | 从原 02-01 精简重组。删除所有章节号相关内容（arc_change_states 的章节号字段改为 arc_change_descriptions 的文本）；删除"配角完整档案模板"中的 x- 字段；新增"与其他文件的关系"节 |

package/plugins/fancy-story-builder/references//350/241/200/350/202/211/346/214/207/345/257/274/02-worldbuilding.md

@@ -0,0 +1,245 @@
+# 世界观建设
+
+> 血肉阶段第 2 份。在骨架势力格局基础上，建世界背景、力量体系、势力卡完整版、物品卡、地点卡、设定校验表。
+> 本文件不写枚举值（→ glossary），不写数据结构（→ 模板），不写验证（→ 脚本）。
+>
+> v1.1 变更：§4.3 明确 `relations[].target_name` 必须是骨架已存在的势力名（问题 38）。
+
+---
+
+## 一、决策路由
+
+| 你在做什么 | 用哪节 |
+|---|---|
+| 建世界背景 | §2 世界背景 |
+| 建力量体系 | §3 力量体系 |
+| 建势力卡完整版 | §4 势力卡 |
+| 建物品卡 | §5 物品卡 |
+| 建地点卡 | §6 地点卡 |
+| 建设定校验表 | §7 设定校验表 |
+
+---
+
+## 二、世界背景
+
+### 2.1 世界背景的核心要素
+
+写进 `世界观规则.json` 的 `core_rules`（若是力量体系/物理规则）、`information_rules`（若是信息规则）、`social_rules`（若是社会规则）。
+
+世界背景的核心是"世界本质"——它必须能推导出至少三个具体冲突。
+
+### 2.2 世界本质写法
+
+- 弱："弱肉强食""实力为尊"（空话，不可执行）
+- 强："修行者每突破一境，需消耗一座灵矿；灵矿不可再生，故高阶修行者必须争夺低阶修行者的灵矿——这决定了宗门战争的根本动机"
+
+**规则**：世界本质必须能推导出至少三个具体冲突。写不出 = 世界本质太虚。
+
+### 2.3 三类规则的分工
+
+- **核心规则**：世界运行的根本规则（力量体系、物理规则、时间规则）
+- **信息规则**：信息传播/隐藏/揭示的规则（谁知道什么、怎么传播、怎么隐藏）
+- **社会规则**：社会结构/文化/禁忌
+
+**三类规则的 id 前缀必须与所属数组匹配**（R / I / SR），由 `flesh-validate.js` 的 `FLESH_WORLD_RULE_CATEGORY` 检查。
+
+**同时，血肉的分组必须与骨架的 `world_rules[].category` 一致**（由 `FLESH_GROUP_CATEGORY_MISMATCH` 检查）：骨架中 category="核心规则"的规则，必须放在血肉的 `core_rules` 数组；category="信息规则"的放在 `information_rules`；category="社会规则"的放在 `social_rules`。
+
+---
+
+## 三、力量体系
+
+### 3.1 三类体系
+
+| 体系 | 说明 |
+|---|---|
+| 等级制 | 明确等级划分 |
+| 天赋制 | 天赋决定上限 |
+| 学习制 | 努力决定成就 |
+
+力量体系写进 `core_rules` 中。
+
+### 3.2 必填要素
+
+- 等级名称（从低到高）
+- 每级战力差（具体数值或比例）
+- 突破条件（需要什么）
+- 突破代价（付出什么）
+- 成长上限（最高等级）
+- 跨级挑战的合理解释（如适用）
+
+**规则**：缺"突破代价"或"成长上限"，后期必战力崩。跨级挑战必须有合理解释（金手指/特殊条件/对手受伤），不能"主角光环"。
+
+### 3.3 力量体系与升级感对接
+
+升级感的"缺口"来自力量体系的突破条件。具体升级节奏由节奏阶段的 `01-upgrade-rhythm.md` 展开，本文件不涉及。
+
+---
+
+## 四、势力卡完整版
+
+### 4.1 势力在血肉阶段补的字段
+
+骨架 `实体.json` 的 `factions` 只有 `id` + `name` + `type`。血肉在 `势力.json` 的 `factions` 数组中补：
+
+- `goal`：核心诉求（一句话，具体）
+- `resources`：掌握资源（权力/财富/武力/信息/人脉/地盘）
+- `internal_structure`：内部结构（层级/派系/晋升规则）
+- `suppression_method`：压制手段（该势力用什么手段压制主角所在群体）
+- `resource_seizure_path`：资源被夺取方式（主角可如何瓦解/夺取其资源）
+- `main_line_connection`：主线关联（该势力在主线中起什么作用）
+- `members`：核心成员（描述层，`name` + `position_description` + `relation_description`）
+- `relations`：势力关系（描述层，`target_name` + `description`）
+
+**注**：`members` 和 `relations` 是"人读的详细描述"，引用的是 `name` 不是 `id`。ID 关系在骨架 `关系.json` 的 `faction_membership` / `faction_relations`。
+
+### 4.2 设计要点
+
+- **压制手段**：必须写"该势力用什么手段压制主角所在群体"。没有压制手段的势力是背景板。
+- **资源被夺取方式**：主角如何瓦解/夺取其资源。没有夺取方式的势力，主角推翻后读者觉得白干。
+- **内部结构**：没有内部结构的势力，写到中后期会变成铁板一块，无法制造内部分化。
+- **主线关联**：没有主线关联的势力可删。
+
+### 4.3 新增势力回填
+
+**血肉阶段不能创建新势力**。骨架 `实体.json` 的 `factions` 数组是唯一的势力清单，血肉 `势力.json` 只能为骨架已存在的势力补档案。
+
+**具体约束**：
+- `势力.json` 的 `factions[].id` 必须存在于骨架 `实体.json` 的 `factions`（`FLESH_REF_MISSING` 会拦截）
+- `势力.json` 的 `factions[].name` 必须与骨架同名（`FLESH_NAME_MISMATCH` 会拦截）
+- `势力.json` 的 `factions[].members[].name` 必须是骨架 `characters` 已存在的角色名（`FLESH_XREF_MISSING` 会拦截）
+- `势力.json` 的 `factions[].relations[].target_name` 必须是骨架 `factions` 已存在的势力名（`FLESH_XREF_MISSING` 会拦截）
+
+**为什么 `relations[].target_name` 也必须存在**：势力关系是双向的（虽然 `faction_relations` 只记录有向边，但"势力 A 与势力 B 有关系"这件事本身要求 B 存在）。如果 LLM 在 `relations` 中提及一个骨架没有的势力名，等于在血肉阶段"凭空创建"了一个势力——这违反了"新 ID 只能出现在骨架阶段"的核心规则。
+
+**如果需要描述一个"未正式建立势力卡"的背景势力**：可以在 `description` / `main_line_connection` 等自由文本字段中提及（如"据传北方还有一股不明势力"），但**不要**在 `relations` 数组中建条目。
+
+---
+
+## 五、物品卡
+
+### 5.1 三类道具
+
+道具在骨架 `实体.json` 的 `items` 数组中按 `category` 分为三类（核心/支线/象征，枚举值见 glossary 的 `item_category`）。
+
+血肉在 `关键道具.json` 中补：
+
+- **核心道具**（`core_items`）：`function` + `relation`
+- **支线道具**（`branch_items`）：`function` + `relation`
+- **象征道具**（`symbolic_items`）：`symbolic_meaning` + `usage_scenario`
+- **详情**（`details`）：`type` / `appearance` / `origin` / `function_detail` / `limit` / `related_characters` / `related_conflicts`
+
+**分组一致性**：骨架中 category="核心道具"的 item，必须放在血肉的 `core_items`；category="支线道具"的放在 `branch_items`；category="象征道具"的放在 `symbolic_items`（由 `FLESH_GROUP_CATEGORY_MISMATCH` 检查）。
+
+### 5.2 details 与 items 的一一对应
+
+每个道具（无论在 `core_items` / `branch_items` / `symbolic_items`）必须有一条 `details`，`id` 完全对应。
+
+**由 `flesh-validate.js` 的 `FLESH_DETAILS_ORPHAN` 检查**：双向对应，任一方向缺失报 error。
+
+### 5.3 金手指类道具
+
+若骨架 `items` 中的某项是金手指类，`details` 中必须写：
+- `function_detail`：能力描述
+- `limit`：使用代价 / 失效条件 / 成长上限
+
+示例：系统类道具的 `limit`："每次使用消耗寿命或积分，积分不足则失效，最高只能兑换到 A 级"
+
+---
+
+## 六、地点卡
+
+### 6.1 地点在血肉阶段补的字段
+
+骨架 `实体.json` 的 `locations` 只有 `id` + `name` + `type` + `narrative_function`。血肉在 `地点.json` 的 `locations` 数组中补：
+
+- `features`：空间特征（`layout` + `key_elements`）
+- `key_event_descriptions`：关键事件**文本描述**（不是章节，是"发生了什么"）
+- `narrative_role_description`：叙事作用描述
+
+**不填 `appearance_chapters`**——地点在哪些章节出场属于节奏阶段。
+
+### 6.2 地点与冲突的关联
+
+骨架 `关系.json` 的 `location_conflict` 已经记录了"地点 → 冲突"的 ID 关系。血肉 `地点.json` 不重复，但在 `narrative_role_description` 中说明"这个地点承载了什么冲突"。
+
+**规则**：地点卡缺"承载冲突/弧线阶段"，会变成旅游手册。每个地点必须服务至少一个冲突。
+
+---
+
+## 七、设定校验表
+
+### 7.1 设定校验表的作用
+
+防"战力漂移/规则漂移/称谓漂移"。写作阶段每次使用旧设定前对照。
+
+### 7.2 设定校验表的内容
+
+设定校验表**不单独建 JSON**，而是体现在 `世界观规则.json` 的规则内容中：
+- `core_rules[].content`：规则本体
+- `core_rules[].applicable_scope`：适用范围
+- `core_rules[].exception`：例外
+- `core_rules[].impact_on_protagonist`：对主角的影响
+
+### 7.3 必须登记的设定类型
+
+- 金手指能力边界（在 `关键道具.json` 的 `details[].limit`）
+- 力量体系等级/突破条件（在 `世界观规则.json` 的 `core_rules`）
+- 势力规模/资源（在 `势力.json`）
+- 人物称谓/官职/爵位（在 `角色.json` 的 `description`）
+- 地名/组织名（在 `实体.json` 的 `name`）
+- 世界观规则（能不能飞/能不能复活/时间流速）
+
+---
+
+## 八、示例
+
+一本都市复仇文的世界观：
+
+- `core_rules`（R001）：缅北园区的电诈利润支撑当地军阀，军阀反过来保护园区。园区的"治安"是相对的——园区内部有规矩，但警察进不来。
+- `information_rules`（I001）：园区内部信息隔离严重——不同楼栋的人互不知道对方。消息只能通过"出园区"的人带出去。
+- `social_rules`（SR001）：园区内的"员工"按业绩分级——业绩好的住单间、能吃肉；业绩差的一律关铁笼、打断手指。这种分级是公开的，所有人都知道。
+- `rule_conflict_plan`：主角作为"外人"不知道怎么混进园区 → 找旧部帮忙做假身份
+
+---
+
+## 九、常见反例
+
+| 反例 | 为什么错 | 正确做法 |
+|---|---|---|
+| 世界本质写"弱肉强食" | 空话，推导不出冲突 | 写具体规则 |
+| 势力没有压制手段 | 变成背景板 | 补压制手段 |
+| 势力没有资源被夺取方式 | 主角推翻后读者白干 | 补夺取方式 |
+| 道具 details 与 items 不对应 | `FLESH_DETAILS_ORPHAN` 报错 | 一一对应 |
+| 地点没有承载冲突 | 变成旅游手册 | 关联至少一个冲突 |
+| 世界观规则 id 前缀与数组不匹配 | `FLESH_WORLD_RULE_CATEGORY` 报错 | R→core_rules，I→information_rules，SR→social_rules |
+| **血肉分组的 category 与骨架不一致** | **`FLESH_GROUP_CATEGORY_MISMATCH` 报错** | **按骨架 category 放对应数组** |
+| **`relations[].target_name` 是骨架没有的势力名** | **`FLESH_XREF_MISSING` 报错** | **只引用骨架已有的势力名** |
+| 填了 `appearance_chapters` | 违反血肉阶段禁令 | 删掉，章节号属于节奏阶段 |
+
+---
+
+## 十、与其他文件的关系
+
+| 本文件输出 | 落到哪个字段 | 参考哪个公式 | 由哪个脚本验证 |
+|---|---|---|---|
+| 世界背景 | `世界观规则.json` 的 `core_rules` / `information_rules` / `social_rules` | 无公式 | `flesh-validate.js` 的 `FLESH_REF_MISSING` / `FLESH_NAME_MISMATCH` / `FLESH_WORLD_RULE_CATEGORY` / `FLESH_GROUP_CATEGORY_MISMATCH` |
+| 力量体系 | `core_rules` 中的内容 | 无公式 | 同上 |
+| 势力卡 | `势力.json` 的 `factions` | 无公式 | `FLESH_REF_MISSING`（id 必须在骨架中）/ `FLESH_XREF_MISSING`（members[].name / relations[].target_name 必须在骨架中） |
+| 物品卡 | `关键道具.json` 的 `core_items` / `branch_items` / `symbolic_items` / `details` | 无公式 | `FLESH_DETAILS_ORPHAN`（双向对应）/ `FLESH_GROUP_CATEGORY_MISMATCH`（分组一致性） |
+| 地点卡 | `地点.json` 的 `locations` | 无公式 | `FLESH_REF_MISSING`（id 必须在骨架中） |
+
+**不输出到**：
+- 势力成员的 ID 关系 → 属于骨架 `关系.json` 的 `faction_membership`
+- 势力间的 ID 关系 → 属于骨架 `关系.json` 的 `faction_relations`
+- 道具归属 → 属于骨架 `关系.json` 的 `item_owner`
+- 地点关联冲突 → 属于骨架 `关系.json` 的 `location_conflict`
+
+---
+
+## 十一、版本记录
+
+| 版本 | 变更 |
+|---|---|
+| v1.0 | 从原 02-02 精简重组。删除"设定校验表"作为独立 JSON 的设计（现在体现在规则内容中）；删除"首次出现章"；删除"关系表"（ID 关系在骨架）；新增"与其他文件的关系"节 |
+| v1.1 | §4.3 明确 `relations[].target_name` 必须是骨架已存在的势力名（问题 38）；§2.3 / §5.1 明确分组 category 必须与骨架一致（问题 18/19）；§九 常见反例补 2 行 |

package/plugins/fancy-story-builder/references//350/241/200/350/202/211/346/214/207/345/257/274/03-relations.md

@@ -0,0 +1,185 @@
+# 关系与支线
+
+> 血肉阶段第 3 份。细化关系网、设计支线、管理多线。
+> 本文件不写数量（→ formulas），不写数据结构（→ 模板），不写验证（→ 脚本），不写章节号。
+
+---
+
+## 一、决策路由
+
+| 你在做什么 | 用哪节 |
+|---|---|
+| 关系网细化 | §2 关系网 |
+| 支线设计 | §3 支线 |
+| 多线管理 | §4 多线管理 |
+
+---
+
+## 二、关系网细化
+
+### 2.1 关系网的设计原则
+
+关系网的骨架在 `关系.json` 的 `character_relations` / `faction_membership` / `conflict_participants` / `branch_protagonist` 中。
+
+血肉阶段在 `角色.json` 的 `relationships` 数组中补"描述层"：
+- `target_name`：对方姓名（必须存在于骨架角色中）
+- `relationship_type`：关系类型，**必须与骨架里同一对角色的 `relation_kind` 完全一致**，取值见 glossary 第五节 `relation_kind`（血缘 / 师徒 / 雇佣 / 服从 / 提携 / 合作 / 利益交换 / 利用 / 对立 / 敌对 / 竞争 / 中立 / 其他）
+- `relation_label`：`relationship_type=其他` 时必填，写具体关系（附身 / 寄生 / 契约 / 共生…）
+- `description`：一段话描述关系的质地
+- `changes`：关系变化数组，每条写 `stage`（阶段名）/ `from`（变化前）/ `to`（变化后）/ `trigger`（触发事件）/ `description`（怎么变），可加 `timing`（前期/中期/后期，**不含章节号**）
+
+**关系类型只能用词表里的值**，不要写"盟友""对手""上下级""血亲"这类近义词：
+
+| 想表达 | 写这个词表值 |
+|---|---|
+| 盟友、搭档、同伙 | 合作 |
+| 对手、仇人 | 对立（立场对立）/ 敌对（敌视仇视） |
+| 血亲、亲兄妹、父子 | 血缘 |
+| 师父与徒弟 | 师徒（起点写师父） |
+| 老板与下属 | 雇佣（起点写雇主） |
+| 下属与上级 | 服从（起点写服从方） |
+| 谁提携谁 | 提携（起点写提携方） |
+| 各取所需 | 利益交换 |
+| 被当作棋子 | 利用（起点写利用者） |
+| 抢同一个位置 | 竞争 |
+| 互不相干 | 中立 |
+| 附身/寄生/契约等词表外关系 | 人物之间用 `其他` + `relation_label`；灵魂/神魂等非人物存在写骨架 `other_relations` |
+
+**关系会变**：不要把关系写成一条静态边。前期对立、某事件后转为合作，就写两条 `changes`（或一条从“对立”到“合作”的变化），把 `trigger` 写清楚；具体从第几章开始变留给节奏阶段的 `relationship_timeline`。
+
+**方向**：`relationships[]` 表达的是"**本角色**对 `target_name` 的关系"，方向与骨架的 `from`→`to` 一致。有向关系（师徒 / 雇佣 / 服从 / 提携 / 利用）只能写在关系起点的那个角色文件里。
+
+### 2.2 关系揭示三层
+
+表层（表面互动）→ 中层（共同经历后的默契）→ 深层（真实感受/秘密）。按剧情推进逐层揭示，不一次暴露。
+
+三层在 `description` 中体现，不单独建字段。
+
+### 2.3 高戏剧潜力关系
+
+| 关系 | 模式 |
+|---|---|
+| 亦敌亦友 | "我知道你在利用我，但我需要你" |
+| 禁忌之爱 | 身份/立场对立但无法控制感情 |
+| 师徒 | "教会徒弟饿死师父"的潜在张力 |
+| 兄弟竞争 | 同起点不同选择，此消彼长 |
+
+### 2.4 关系网与势力交叉
+
+关系网中的每个角色都应该标注所属势力（在骨架 `关系.json` 的 `faction_membership` 中已登记）。
+
+跨势力关系（如主角与敌对势力中的某人）是后续冲突的种子，必须在 `relationships[].description` 中点明。
+
+**规则**：关系网中不能有"孤立角色"（与主角无关系、无功能）。由 `skeleton-validate.js` 的 `G_ISOLATED` 在骨架阶段检查。
+
+---
+
+## 三、支线设计
+
+### 3.1 支线三问
+
+每条支线必须回答：
+1. 这条线的主角是谁？
+2. 目标是什么？
+3. 结局是什么？
+
+答不上来 = 不是支线，是插曲。
+
+支线在骨架 `实体.json` 的 `branches` 中登记（id + name + type）。血肉在 `剧情.json` 的 `branches` 数组中补：
+- `goal`：支线的目标
+- `main_relation`：如何与主线关联
+- `expected_outcome`：预期结局（文本描述，不含章节）
+
+### 3.2 支线的"由谁主导"
+
+骨架 `关系.json` 的 `branch_protagonist` 记录了"支线 → 角色"的 ID 关系。血肉 `剧情.json` 的 `branches[].expected_outcome` 中写"这条支线由谁主导、怎么收束"。
+
+### 3.3 支线的章节归属
+
+**支线在哪些卷、哪些章展开，属于节奏阶段**。血肉阶段 `剧情.json` 的 `branches` 不填 `start` / `turning` / `resolution` / `interweaves`——这些是节奏阶段 `时序映射.json` 的 `branch_timeline` 里每条支线的字段（字段真名以该模板为准）。
+
+### 3.4 支线与主线的交织
+
+骨架 `关系.json` 的 `main_line_branch_relation` 记录了"主线 ↔ 支线"的交织关系。血肉 `剧情.json` 的 `branches[].main_relation` 是"人读的描述"，说明这条支线如何挂到主线。
+
+**规则**：支线必须服务主线，不能独立成篇。
+
+---
+
+## 四、多线管理
+
+### 4.1 多线管理表
+
+多线管理表**不单独建 JSON**，而是体现在：
+- 骨架 `关系.json` 的 `main_line_branch_relation`（主线 ↔ 支线的交织关系）
+- 血肉 `剧情.json` 的 `branches[].main_relation`（描述层）
+- 节奏阶段的 `时序映射.json` 的 `main_line_timeline` 和 `branch_timeline`（章节归属）
+
+### 4.2 切线与接线规则
+
+- **切线时机**：在 A 线的钩子处切（悬念/危机/情感转折）
+- **接线方式**：B 线开头用时间并列/因果呼应/意象呼应/反差对照
+- **切线频率**：一条线连续写几个章再切，不频繁跳
+- **读者记忆**：切走的线隔得久，回来时加"前情唤醒"（一句回顾/一个物件复现）
+
+### 4.3 收敛原则
+
+- 各线最终必须交汇
+- 交汇前各线都已推进到交汇点
+- 交汇方式：物理汇合/信息汇合/因果汇合
+- 交汇后合并成一条线或继续分线
+
+### 4.4 多线的时间一致性
+
+**每条线的时间戳必须一致**。同一时刻，各线的时间要对得上。这由节奏阶段的 `时序映射.json` 统一表达，本文件不重复。
+
+---
+
+## 五、示例
+
+一本都市复仇文的关系网与支线：
+
+- **关系网**：
+  - 主角 → 妹妹（血缘，"我唯一柔软的地方"）
+  - 主角 → 坤沙（敌对，"我必须杀他"）
+  - 主角 → 老王（合作，"唯一能信任的老战友"）
+  - 主角 → 陈队（利用，"他想要证据，我想要武器"）
+- **支线**：
+  - B001 "找妹妹的尸骨"：goal = 找到尸骨让她入土为安；main_relation = 尸骨在园区，必须破园区；expected_outcome = 找到但残缺，让主角彻底断念
+  - B002 "旧部重聚"：goal = 召集当年的战友；main_relation = 战友是攻园区的武力；expected_outcome = 重聚但有人牺牲，主角不再独行
+
+---
+
+## 六、常见反例
+
+| 反例 | 为什么错 | 正确做法 |
+|---|---|---|
+| 支线三问答不上来 | 不是支线 | 补三问，或删除 |
+| 支线独立成篇 | 不服务主线 | 在 `main_relation` 中写清关联 |
+| 关系变化没有触发事件 | 说变就变 | 在 `changes[].description` 中写触发事件 |
+| 有孤立角色 | 关系网断裂 | 补关系，或删除角色 |
+| 多线时间不一致 | 时间轴混乱 | 在节奏阶段用统一的时序映射 |
+| 填了 `start` / `resolution` | 违反血肉阶段禁令 | 删掉，章节归属属于节奏阶段 |
+
+---
+
+## 七、与其他文件的关系
+
+| 本文件输出 | 落到哪个字段 | 参考哪个公式 | 由哪个脚本验证 |
+|---|---|---|---|
+| 关系描述 | `角色.json` 的 `characters[].relationships` | 无公式 | `flesh-validate.js` 的 `FLESH_XREF_MISSING`（target_name 必须在骨架中） |
+| 支线描述 | `剧情.json` 的 `branches[].goal` / `main_relation` / `expected_outcome` | 无公式 | `FLESH_REF_MISSING`（id 必须在骨架中） |
+| 关系变化 | `characters[].relationships[].changes` | 无公式 | 无（章节归属在节奏阶段） |
+
+**不输出到**：
+- 支线的 `start` / `turning` / `resolution` / `interweaves` → 属于节奏阶段 `时序映射.json` 的 `branch_timeline`
+- 主线 key_nodes 的章节 → 属于节奏阶段 `时序映射.json` 的 `main_line_timeline`
+- 多线时间戳 → 属于节奏阶段 `时序映射.json`
+
+---
+
+## 八、版本记录
+
+| 版本 | 变更 |
+|---|---|
+| v1.0 | 从原 02-05 精简重组。删除支线数量公式（移到 formulas-skeleton.json）；删除支线章节区间的所有字段（移到节奏阶段）；删除单元表（属于节奏阶段）；保留关系网/支线三问/多线管理的方法论；新增"与其他文件的关系"节 |