@cloud411716/fancy-webnovel 1.0.45 → 2.2.0

package/plugins/fancy-story-builder/references//351/252/250/346/236/266/346/214/207/345/257/274/01-positioning.md

@@ -0,0 +1,208 @@
+# 选题定位与卖点提炼
+
+> 开书前第一份文件。先定"写给谁、在哪发、卖什么"，再定"写什么"。
+
+---
+
+## 一、决策路由
+
+| 你在做什么 | 用哪节 |
+|---|---|
+| 找读者需求 | §2 需求矩阵 |
+| 选平台 | §3 平台矩阵 |
+| 找差异化 | §4 赛道差异化 |
+| 提炼一句话故事 | §5 一句话故事五步法 |
+| 定核心梗 | §6 核心梗三分法 |
+| 检查卖点是否偏移 | §7 卖点一致性检查 |
+
+---
+
+## 二、读者需求矩阵
+
+### 2.1 十六种底层需求
+
+| # | 需求 | 男频典型 | 女频典型 | 免费平台典型 |
+|---|---|---|---|---|
+| 1 | 被尊重/认同 | 身份揭露、打脸 | 被偏爱、追妻 | 战神归来、赘婿翻身 |
+| 2 | 优越感 | 碾压、扮猪吃虎 | 打脸绿茶、手撕渣男 | 神医下山、透视 |
+| 3 | 不劳而获 | 系统签到、传承 | 空间灵泉、锦鲤 | 签到成神、开局万亿 |
+| 4 | 惩恶扬善 | 复仇、除害 | 复仇、虐渣 | 打脸虐渣 |
+| 5 | 公平 | 底层逆袭 | 庶女翻身 | 赘婿逆袭 |
+| 6 | 安全感 | 护短、势力 | 被保护、偏爱 | 萌宝、宠妻 |
+| 7 | 冒险欲 | 副本、秘境 | 穿越、快穿 | 无限流 |
+| 8 | 好奇心 | 解谜、揭秘 | 悬疑、马甲 | 规则怪谈 |
+| 9 | 成长 | 升级、变强 | 事业线、技能 | 系统升级 |
+| 10 | 收获 | 爆装备、资源 | 空间、财富 | 签到奖励 |
+| 11 | 三情（亲情/爱情/友情） | 兄弟、师徒 | 爱情、亲情 | 萌宝、团宠 |
+| 12 | 大人物幻想 | 称霸、掌权 | 皇后、女帝 | 战神、总裁 |
+| 13 | 暴力欲 | 战斗、杀戮 | 手撕、复仇 | 打脸、虐渣 |
+| 14 | 新鲜感 | 脑洞、设定流 | 反套路、穿书 | 脑洞、反套路 |
+| 15 | 情怀 | 怀旧、年代 | 年代、古言 | 年代重生 |
+| 16 | 弥补遗憾 | 重生、后悔 | 重生、弥补 | 重生复仇 |
+
+### 2.2 配比原则
+
+一本主打一个主需求 + 一个辅需求，最多再加一个辅需求。超过三个，读者认知模糊，卖点偏移。
+
+主需求决定书名、简介、开篇；辅需求做差异化，不抢主需求。
+
+需求冲突时的仲裁方向：
+- 优越感 vs 安全感冲突时，爽文听优越感，虐文听安全感
+- 惩恶 vs 公平冲突时，复仇文听惩恶，逆袭文听公平
+
+### 2.3 需求 → 题材映射
+
+| 主需求 | 男频题材 | 女频题材 |
+|---|---|---|
+| 被尊重 | 都市逆袭、战神、赘婿 | 追妻火葬场、白月光 |
+| 优越感 | 扮猪吃虎、神医、透视 | 打脸虐渣、手撕绿茶 |
+| 不劳而获 | 系统、签到、传承 | 空间、锦鲤、快穿 |
+| 惩恶扬善 | 复仇、都市异能 | 复仇、宅斗 |
+| 公平 | 底层逆袭、赘婿 | 庶女翻身、替嫁 |
+| 安全感 | 护短、势力流 | 被偏爱、萌宝 |
+| 冒险欲 | 无限流、副本 | 快穿、穿越 |
+| 好奇心 | 悬疑、规则怪谈 | 悬疑、马甲 |
+| 成长 | 升级流、玄幻 | 事业线、技能流 |
+| 三情 | 兄弟、师徒 | 爱情、亲情、团宠 |
+| 大人物幻想 | 争霸、掌权 | 女帝、皇后 |
+| 新鲜感 | 脑洞、设定流 | 反套路、穿书 |
+| 弥补遗憾 | 重生 | 重生、年代 |
+
+---
+
+## 三、平台题材矩阵
+
+| 平台 | 付费模式 | 主攻性别 | 章字数基准 | 开篇窗口 | 读者耐心 | 核心指标 |
+|---|---|---|---|---|---|---|
+| 起点 | 付费 | 男频 | 2000-4000 | 黄金三章签约，前 10-20 章首订 | 中 | 追读、首订、均订 |
+| 番茄 | 免费 | 男女 | 1000-2000 | 前 3 章推荐，前 10 章留存 | 低 | 完读率、章末跳出率 |
+| 七猫 | 免费 | 男女 | 1000-2000 | 前 3 章 | 低 | 完读率、追更率 |
+| 晋江 | 付费 | 女频 | 3000-5000 | 前三章收藏，入 V 前 10-20 章 | 中高 | 收藏、评论、入 V 订阅 |
+| 知乎盐选 | 付费短篇 | 女频为主 | 3000-8000/篇 | 前 300 字定生死 | 极低 | 付费转化、读完率 |
+| QQ 阅读 | 付费 | 男女 | 2000-3000 | 前 5 章 | 中 | 追读、订阅 |
+
+**注**：以上"章字数基准"是平台惯例，不是骨架阶段的量化约束。骨架阶段只记录 T（目标章节数）和 target_words（目标字数），不按平台拆分章字数。
+
+平台选择三问：我写男频还是女频？我要付费还是免费？我的读者耐心高还是低？
+
+---
+
+## 四、赛道差异化
+
+### 4.1 同中有异三法
+
+1. **设定差异**：同题材换核心设定（追妻火葬场，但女主是法医/律师/电竞选手）
+2. **人设差异**：同题材换主角人设（战神，但是个社恐；赘婿，但是个真大佬且不想装）
+3. **结构差异**：同题材换叙事结构（重生复仇，但双重生博弈；系统文，但系统是反派）
+
+### 4.2 差异化检查
+
+- 我的书用一句话说清"和同题材最不一样的一点"是什么？
+- 这一点是否在书名/简介/开篇就能看到？
+- 这一点是否可持续（不是一次性噱头）？
+
+---
+
+## 五、一句话故事五步法
+
+### 第一步：填模板
+
+```
+【谁】，因为【什么事件】，要【做什么】，但【什么阻碍】，如果失败【什么代价】。
+```
+
+### 第二步：删形容词，留具体名词
+
+- 弱："一个强大的主角，因为悲惨的过去，要复仇，但敌人很厉害。"
+- 强："前特种兵陈默，因为妹妹被缅北电诈集团害死，要端掉整个园区，但集团背后有当地军阀，失败则妹妹的尸骨永远回不来。"
+
+### 第三步：检查三问
+
+1. 这句话让人想点开吗？（好奇心/情绪冲击）
+2. 这句话能撑 100 万字吗？（冲突可持续）
+3. 这句话的卖点是什么需求？（对应 §2）
+
+### 第四步：从一句话反推书名/简介/开篇事件
+
+一句话故事的"事件"就是第一章的激励事件；"阻碍"就是主线矛盾；"代价"就是死亡赌注。
+
+### 第五步：过不了就换
+
+如果一句话故事平淡，不要往下写。换事件、换阻碍、换代价，直到这句话让人想点开。
+
+---
+
+## 六、核心梗三分法
+
+| 类型 | 运行方式 | 适用 | 检查 |
+|---|---|---|---|
+| 可重复型 | 每个单元重复运行 | 升级、系统、文抄、无限流 | 第一个单元必须完整运行一次 |
+| 不可重复型 | 贯穿全文，最高潮爆发一次 | 追妻、掉马、禁忌之恋、身份揭秘 | 第一个单元必须完成首次铺垫 |
+| 长期铺垫型 | 以期待点贯穿 | 悬疑、复仇、解谜、长线布局 | 每三到五个单元推进一次 |
+
+配比：一本可同时用两种（可重复 + 长期铺垫，或不可重复 + 长期铺垫），不超过两种。
+
+---
+
+## 七、卖点一致性检查
+
+- 主需求是否只有一个？辅需求不超过两个？
+- 书名/简介/开篇是否都指向主需求？
+- 开篇几章是否展示了核心梗？
+- 一句话故事是否让人想点开？
+- 差异化是否在书名/简介/开篇可见？
+- 爽点满足的需求是否与主需求一致？（防止偏移到另一个题材的卖点）
+
+**注**：本节是方法论自检，不是脚本验证。真正的字段验证由 `skeleton-validate.js` 的 `REQUIRED` / `TYPE` 检查执行。
+
+---
+
+## 八、示例
+
+一本复仇文的定位：
+
+- 主需求：惩恶扬善（#4）
+- 辅需求：弥补遗憾（#16）、公平（#5）
+- 平台：起点（男频付费）
+- 一句话故事："前特种兵陆子仲，因为妹妹被缅北电诈集团害死，要端掉整个园区，但集团背后有当地军阀，失败则妹妹的尸骨永远回不来。"
+- 核心梗：不可重复型（复仇贯穿全书）+ 长期铺垫型（园区背后有更大的势力网）
+- 差异化：主角不是特工/警察，而是一个被开除的前特种兵，用民间手段复仇
+
+落到 `框架.json` 的 `input_snapshot`：
+- `book_name`：书名
+- `genre`：都市复仇
+- `core_summary`：一句话故事
+- `core_conflict`：主角 vs 缅北园区
+- `hard_constraints`：无超自然战斗能力
+- `anti_tropes`：主角不加入任何组织
+
+---
+
+## 九、常见反例
+
+| 反例 | 为什么错 | 正确做法 |
+|---|---|---|
+| 主需求写了四个 | 读者认知模糊 | 只保留 1 主 2 辅 |
+| 一句话故事没有"代价" | 读者感受不到紧迫 | 补"如果失败则……" |
+| 书名与主需求不一致 | 读者点开即弃 | 让书名直接体现主需求 |
+| 核心梗超过两种 | 一个单元运行不过来 | 只保留 2 种 |
+
+---
+
+## 十、与其他文件的关系
+
+| 本文件输出 | 落到哪个字段 | 参考哪个公式 | 由哪个脚本验证 |
+|---|---|---|---|
+| 书名 / 题材 / 一句话故事 / 核心冲突 / 硬门禁 / 反套路 | `框架.json` 的 `input_snapshot` | 无公式 | `skeleton-validate.js` 的 `REQUIRED` / `TYPE` 检查 |
+| 平台选择 | 不落入 JSON（创作决策，供血肉/节奏阶段参考） | 无 | 无 |
+
+**注**：平台章字数基准是创作参考，不进入 `capacity.avg_words_per_chapter` 的计算。后者由 `target_words / target_chapters` 决定。
+
+---
+
+## 十一、版本记录
+
+| 版本 | 变更 |
+|---|---|
+| v1.0 | 从原 01-01 精简。删除"需求 → 题材映射"重复段落；明确"平台章字数基准"不进入骨架量化；新增"与其他文件的关系"节 |
+| v1.1 | 按合规检查修订：§4.2 / §7 的"前 3 章"改为"开篇"；§6 "每 3-5 单元"改为"每三到五个单元" |

package/plugins/fancy-story-builder/references//351/252/250/346/236/266/346/214/207/345/257/274/02-packaging.md

@@ -0,0 +1,135 @@
+# 书名、简介与包装
+
+> 定位定完后，用本文件把卖点变成点击率。
+
+---
+
+## 一、决策路由
+
+| 你在做什么 | 用哪节 |
+|---|---|
+| 起书名 | §2 书名 |
+| 写简介 | §3 简介 |
+| 定标签 | §4 标签与一句话卖点 |
+| 检查包装一致性 | §5 一致性检查 |
+
+---
+
+## 二、书名
+
+### 2.1 六种书名类型
+
+| 类型 | 公式 | 适用 | 示例结构 |
+|---|---|---|---|
+| 信息型 | 身份 + 事件 | 战神、赘婿、神医 | 《战神归来》《赘婿当道》 |
+| 悬念型 | 反常事实 | 悬疑、规则怪谈 | 《我死后第七天》《最后一个人类》 |
+| 人设型 | 标签 + 反差 | 追妻、白月光 | 《渣男的白月光是我》《病娇总裁》 |
+| 反差型 | A 其实是 B | 反套路、脑洞 | 《我在末世种田》《大佬装萌新》 |
+| 数字型 | 数字 + 事件 | 系统、签到、重生 | 《开局签到荒古圣体》《重生 99 次》 |
+| 情绪型 | 情绪词 + 对象 | 虐恋、复仇 | 《迟来的道歉》《她死那天》 |
+
+### 2.2 书名四问
+
+1. 是否一眼看出题材？
+2. 是否有钩子（让人想点开）？
+3. 是否与主需求一致？
+4. 是否好记、好搜、好传播？
+
+### 2.3 书名避雷
+
+- 太长（超过十个字，搜索困难）
+- 太文艺（读者看不出题材）
+- 太泛（"重生""系统"单用，无差异化）
+- 与内容不符（书名党，读者点开即弃）
+
+---
+
+## 三、简介
+
+### 3.1 四段式
+
+```
+第一段（1 句）：核心冲突 / 信息炸弹
+第二段（3 句）：展开冲突 + 主角处境 + 代价
+第三段（1 句）：钩子 / 反转 / 期待
+第四段（可选 1 句）：金句 / 情绪收束
+```
+
+### 3.2 平台差异
+
+| 平台 | 简介策略 |
+|---|---|
+| 起点 | 悬念前置 + 世界观暗示 + 升级期待 |
+| 番茄 | 爽点前置 + 打脸预告 + 情绪冲击 |
+| 晋江 | 人设前置 + 感情线暗示 + 文笔质感 |
+| 知乎盐选 | 第一人称 + 冲突前置 + 反转预告 |
+
+### 3.3 简介避雷
+
+- 大段世界观（读者不关心）
+- 大段人物介绍（没有冲突）
+- 没有钩子（读完不知道要看什么）
+- 与正文不符（简介党，读者弃书）
+
+---
+
+## 四、标签与一句话卖点
+
+- **推荐位一句话**：不超过二十个字，说清"谁 + 冲突 + 爽点"
+- **短视频推书**：十几秒内说清"最惨处境 + 最大反转 + 最爽结局"
+- **标签组合**：三到五个标签，一个主标签打流量（如"重生""系统"），两到四个副标签做差异（如"女强""双重生""复仇"）
+
+---
+
+## 五、包装一致性检查
+
+- 书名、简介、标签是否指向同一主需求？
+- 简介第一段是否有信息炸弹？
+- 简介是否能短时间读完并产生好奇？
+- 标签是否主标签 + 副标签组合？
+- 包装承诺的内容，开篇几章是否兑现？
+
+**注**：本节是方法论自检，不是脚本验证。
+
+---
+
+## 六、示例
+
+一本都市复仇文的包装：
+
+- 书名：《她死那天》（情绪型，指向复仇需求）
+- 简介第一段："妹妹死了，死在我给她转学费的那天。"
+- 简介第二段："三年后，我找到了那个园区。园区老板叫坤沙，手下有三百条枪。警方查了三年，什么都没查到。我用了三个月，查到了他的名字。"
+- 简介第三段："他以为没人知道。但我知道，而且我不打算报警。"
+- 标签：都市、复仇、爽文、智斗
+
+---
+
+## 七、常见反例
+
+| 反例 | 为什么错 | 正确做法 |
+|---|---|---|
+| 书名与主需求无关 | 读者点开后失望 | 书名直接体现需求 |
+| 简介全是大段世界观 | 读者不关心设定 | 前置冲突 |
+| 标签太泛（只写"爽文"） | 无法差异化 | 加副标签 |
+| 简介承诺"无敌流"但正文有大量内心戏 | 承诺未兑现 | 简介与正文一致 |
+
+---
+
+## 八、与其他文件的关系
+
+| 本文件输出 | 落到哪个字段 | 参考哪个公式 | 由哪个脚本验证 |
+|---|---|---|---|
+| 书名 / 题材 / 一句话故事 | `框架.json` 的 `input_snapshot` | 无公式 | `skeleton-validate.js` 的 `REQUIRED` 检查 |
+| 简介 / 标签 / 一句话卖点 | 不落入 JSON（包装文案，供血肉/写作阶段参考） | 无 | 无 |
+
+**注**：包装文案（简介、标签）不进入骨架 JSON，因为它是"人读"内容而非"机器用"数据。它在写作阶段的开篇章节中兑现为第一章内容。
+
+---
+
+## 九、版本记录
+
+| 版本 | 变更 |
+|---|---|
+| v1.0 | 从原 01-02 精简。删除"封面文案"中重复的内容；明确"简介/标签不落入骨架 JSON"；新增"与其他文件的关系"节 |
+| v1.1 | 按合规检查修订：§4 "3-5 个标签" → "三到五个标签"；"15 秒内" → "十几秒内"；§5 "前 3 章" → "开篇几章"；"十秒内" → "短时间"；§3.1 的四段式保持（这是结构描述不是区间，示例值用阿拉伯数字） |

package/plugins/fancy-story-builder/references//351/252/250/346/236/266/346/214/207/345/257/274/03-entities.md

@@ -0,0 +1,305 @@
+# 实体建卡
+
+> 骨架阶段第 3 份。只建实体骨架卡，不建完整档案。完整档案在血肉阶段。
+> 本文件只讲"怎么想"，不讲"数量多少"（→ `formulas-skeleton.json`），不讲"JSON 怎么写"（→ `模板/骨架/实体模板.json`）。
+
+---
+
+## 一、决策路由
+
+| 你在做什么 | 用哪节 |
+|---|---|
+| 建主角卡 | §2 主角卡 |
+| 建反派卡 | §3 反派卡 |
+| 建金手指 | §4 金手指 |
+| 建势力格局 | §5 势力格局 |
+| 画势力对立线 | §5.2 势力对立线 |
+| 定主角势力归属 | §5.3 主角势力归属 |
+| 建其他实体 | §6 其他实体 |
+
+---
+
+## 二、主角卡
+
+### 2.1 骨架最小集
+
+角色在骨架阶段只需要回答"是谁、什么类型、什么年龄段"三类信息。具体的"目标/缺陷/成长弧/关系/语言档案"属于血肉阶段。
+
+骨架阶段的主角卡字段（**具体结构见 `模板/骨架/实体模板.json` 的 `characters`**）：
+- id、name、type（enumRef: character_type）、gender、age_group
+
+血肉阶段会在此基础上补充目标、缺陷、金手指、关系、弧光等。
+
+### 2.2 类型选择指导
+
+角色类型见 `references/glossary.md` 的 `character_type` 枚举。选择原则：
+
+- **主角**：全书第一视角。通常 1 人，特殊结构（双主）可 2 人。
+- **贯穿级核心配角**：贯穿全书或大部分卷。数量少，每个都要有独立弧线。
+- **卷级重要配角**：在某几卷中重要。数量多，弧线可以较简单。
+- **贯穿级核心反派**：全书或大部分卷的主要对手。每个都要有独立动机和镜像关系。
+- **卷级反派**：在某几卷中的主要对手。可以在卷末被击败。
+
+**关键**：角色类型的数量由 `formulas-skeleton.json` 的 `character_elements.*` 约束。本文件不重复具体数字。
+
+### 2.3 设计原则
+
+- 主角动机必须是情感层（"为妹妹复仇"优于"要变强"）
+- 反派必须有独立动机（从反派视角说得通）
+- 反派智商/实力决定主角含金量
+- 每个中反派以上必须有理念冲突
+- 起名跟设定时代/地域/文化走
+
+### 2.4 年龄段选择
+
+年龄段见 `references/glossary.md` 的 `age_group` 枚举。选择原则：
+- 主角通常是"青年"
+- 导师/资深角色通常是"中年"或"老年"
+- 少年角色用于成长线或视角互补
+- 年龄要与身份/阵营/题材自洽（如校园文主角是"少年"，职场文主角是"青年"）
+
+---
+
+## 三、反派卡
+
+### 3.1 反派四层
+
+反派按叙事层级分四层（**篇幅不在骨架阶段定，由节奏阶段细化**）：
+
+| 层级 | 叙事定位 | 与主角关系 |
+|---|---|---|
+| 小反派 | 单个场景/短期障碍 | 不构成主线威胁 |
+| 中反派 | 一个单元/一条支线的主要对手 | 至少赢主角一次 |
+| 大弧 Boss | 一卷或数卷的主要对手 | 完整人弧 + 理念冲突 |
+| 最终 Boss | 全书最终对手 | 与主角目标直接对立 |
+
+**骨架阶段只建中反派及以上**，小反派在章节细纲建。
+
+**关键**：反派在骨架 JSON 中通过 `characters.type` 表达（`贯穿级核心反派` / `卷级反派`），不单独建"反派表"。
+
+### 3.2 反派铁律
+
+- 反派智商/实力决定主角含金量——反派弱 = 主角赢没意义
+- 反派行为从其视角说得通
+- 不降智送赢
+- 反派渲染公式：明确动机 → 动机驱动行为 → 行为形成障碍 → 障碍强度来自反派分量
+
+### 3.3 镜像两种
+
+| 类型 | 定义 | 效果 | 适用 |
+|---|---|---|---|
+| 相似镜像 | 同起点不同选择，反派是主角"走错路"的版本 | 悲剧感、宿命感 | 大弧 Boss、最终 Boss |
+| 相反镜像 | 反派长处反映主角弱点，完全相反 | 摩擦感、互补对抗 | 中反派、日常对手 |
+
+**骨架阶段不填镜像类型**（属于血肉阶段的 `mirror_type` 字段）。本文件只提醒：设计反派时先想清楚是相似还是相反。
+
+### 3.4 反派与势力
+
+每个中反派及以上必须标注所属势力。具体落法：在 `关系.json` 的 `faction_membership` 中登记"角色 → 势力"，`member_relation` 选合适的关系枚举。
+
+没有势力根基的反派，要么补势力来源，要么降为小反派。
+
+---
+
+## 四、金手指
+
+金手指在骨架阶段只记录"有没有、什么类型、和主角是什么关系"。具体的"能力描述、边界、代价、上限"属于血肉阶段。
+
+骨架阶段的处理：
+- 金手指类型不单独字段（不建"金手指表"）
+- 如果金手指是**道具**，在 `实体.json` 的 `items` 中建一个 `item_category = 核心道具` 的条目
+- 如果金手指是**能力**（系统/重生/天赋），在血肉阶段的 `characters.golden_finger` 字段描述，骨架阶段不单独建实体
+
+**骨架阶段只做一个判断**：这个金手指是"道具型"还是"能力型"？
+- 道具型 → 建 `items` 条目，`category = 核心道具`
+- 能力型 → 不建实体，血肉阶段处理
+
+### 4.1 金手指合格五问
+
+（骨架阶段先答一次，答案落到血肉阶段）
+
+1. 能否凸显主角与众不同？能否不断协助克服困难？
+2. 和世界环境/设定是否有紧密联系并拥有反差？
+3. 是否有喧宾夺主可能？是否可预防？
+4. 主角资源提升百倍千倍时，是否还能解决主要矛盾？
+5. 能否通过金手指解决矛盾的同时表达思想和主题？
+
+**代价检查**：使用代价/失效条件/成长上限是什么？缺一项则后期无敌崩。
+
+---
+
+## 五、势力格局
+
+### 5.1 势力类型
+
+势力类型见 `references/glossary.md` 的 `faction_type` 枚举。选择原则：
+
+- **官方组织**：政府、军队、执法机构。有程序约束，适合"程序正义 vs 效率"类冲突
+- **民间组织**：帮派、家族、宗门、商会。有内部竞争，适合"内部嫡庶/长幼之争"类冲突
+- **商业组织**：公司、商会、财团。有利益绑定，适合"商战/并购"类冲突
+- **其他**：不属于以上三类
+
+### 5.2 势力格局表
+
+在 `实体.json` 的 `factions` 数组中建条目，每项只有：
+- id、name、type
+
+血肉阶段会在此基础上补充：核心诉求、掌握资源、与主角关系、内部结构、压制手段、资源被夺取方式、主线关联。
+
+骨架阶段对势力格局的判断原则：
+
+- 每个势力必须有"核心诉求"——没有诉求的势力是背景板
+- 势力之间必须有矛盾——没有矛盾的势力格局无法推导出主线
+- 主角必须与至少一个势力有明确关系——孤立的势力格局没有张力
+
+**数量**：势力数量由 `formulas-skeleton.json` 的 `faction_elements.faction_count` 约束，本文件不重复具体数字。
+
+### 5.3 势力对立线
+
+在 `关系.json` 的 `faction_relations` 数组中登记势力间关系。每项含：
+- from、to、relation_type（enumRef: relation_type）
+
+**规则**：
+- 至少一条对立线不是"主角 vs 反派"（势力间也有矛盾，主角才能借力）
+- 每条对立线在血肉阶段要写清"争什么"：资源/理念/历史恩怨/权力/地盘
+- 中立势力必须有底线（没有底线的中立势力会变成"随时可倒向任何一方"的工具）
+
+**对称性**：`relation_type` 为"对立"的关系必须双向声明（A→B 有"对立"，则 B→A 也必须有"对立"）。这一点由 `skeleton-validate.js` 的 `G_REL_ONE_WAY` / `G_REL_ASYMMETRIC` 检查。
+
+### 5.4 主角势力归属
+
+主角的归属模式（单归属/无归属/多归属/归属变化）是血肉阶段的选择。骨架阶段只落一个判断：
+
+- 主角属于某个势力 → 在 `faction_membership` 登记（character=C001, faction=Fn）
+- 主角无归属 → 不登记
+- 主角多归属 → 登记多条
+- 主角归属变化 → 登记当前归属（初始状态）；变化在血肉阶段处理
+
+**每个中反派及以上必须标注所属势力**（通过 `faction_membership`）。
+
+---
+
+## 六、其他实体
+
+### 6.1 地点
+
+在 `实体.json` 的 `locations` 数组中建条目。每项含：
+- id、name、type（enumRef: location_type）、narrative_function（enumRef: narrative_function）
+
+**原则**：每个地点必须服务至少一个冲突，否则不该列入关键地点。
+
+### 6.2 道具
+
+在 `实体.json` 的 `items` 数组中建条目。每项含：
+- id、name、category（enumRef: item_category）
+
+**原则**：
+- 核心道具必须与主线冲突相关
+- 支线道具必须与某条支线相关
+- 象征道具承载情感/主题，可以没有明确功能
+
+道具归属通过 `关系.json` 的 `item_owner` 登记。
+
+### 6.3 结局
+
+在 `实体.json` 的 `endings` 数组中建条目。每项含：
+- id、name、level（enumRef: ending_level）、type（enumRef: ending_type）
+
+**原则**：
+- 全书级结局必须有且仅有一个
+- 卷级结局的数量由 `ending_count` 与卷数决定（具体见 formulas-skeleton.json）
+- 结局的"冲突解决方式/反套路设计/余韵/章节设计"属于血肉阶段
+
+结局涉及的"谁的结局"通过 `关系.json` 的 `ending_character` 登记。
+
+### 6.4 伏笔 / 高潮 / 爽点
+
+在 `实体.json` 中建条目：
+- `foreshadows`：id、name、type（enumRef: foreshadow_type）
+- `climaxes`：id、name、type（enumRef: climax_type）
+- `pleasures`：id、name、scale（enumRef: pleasure_scale）、kind（enumRef: pleasure_kind）
+
+**原则**：
+- 这些实体只有"存在与类型"在骨架阶段定，"具体内容和章节位置"属于节奏阶段
+- 高潮必须与某个冲突相关（在血肉阶段落实）
+- 爽点的 scale（规模）和 kind（种类）是正交的两个维度，都要填
+
+### 6.5 世界观规则
+
+在 `实体.json` 的 `world_rules` 数组中建条目。每项含：
+- id、name、category（enumRef: world_rule_category）
+
+**三类规则**（见 glossary）：
+- 核心规则：力量体系、物理规则
+- 信息规则：信息传播/隐藏/揭示
+- 社会规则：社会结构、文化、禁忌
+
+骨架阶段只列"有哪些规则"，具体内容属于血肉阶段的 `世界观规则.json`。
+
+### 6.6 主线 / 支线
+
+在 `实体.json` 的 `main_lines` 和 `branches` 数组中建条目：
+- `main_lines`：id、name
+- `branches`：id、name、type（enumRef: branch_type）
+
+**原则**：
+- 主线固定 1 条
+- 支线数量由 `formulas-skeleton.json` 的 `structure.branch_count` 约束
+- 支线的"主角、目标、结局、章节区间"属于节奏阶段
+
+支线的"由谁主导"通过 `关系.json` 的 `branch_protagonist` 登记；主线/支线的交织关系通过 `main_line_branch_relation` 登记。
+
+---
+
+## 七、示例
+
+一本都市复仇文的实体清单（仅示意，实际字段值以 `模板/骨架/实体模板.json` 为准）：
+
+- characters：主角（陆子仲）、妹妹（已故，作为情感驱动）、反派（坤沙）、反派助手（阿豹）、前战友（老王）、刑警（陈队）
+- factions：缅北园区（民间组织）、市刑警队（官方组织）、主角旧部（民间组织）
+- locations：缅北园区（主要场景，冲突）、市局审讯室（次要场景，对话）
+- items：妹妹的照片（象征道具）、园区账本（核心道具）
+- endings：全书级结局（开放式）
+- foreshadows / climaxes / pleasures：按数量和类型建条目
+
+落到 `关系.json`：
+- character_relations：陆子仲→坤沙（敌对）、陆子仲→老王（合作）
+- faction_membership：坤沙→园区、陈队→市刑警队、老王→旧部
+- faction_relations：园区↔刑警队（对立，双向）、园区↔旧部（对立，双向）
+- conflict_participants：核心冲突 X001 的主角阵营=[陆子仲]、主要对手=坤沙
+- branch_protagonist：B001 主角=陆子仲
+- location_conflict：园区→[X001]
+- item_owner：账本→（character, 陆子仲）
+- ending_character：全书级结局→陆子仲
+
+---
+
+## 八、常见反例
+
+| 反例 | 为什么错 | 正确做法 |
+|---|---|---|
+| 角色只写 name 不写 type | 类型是骨架阶段的核心分类 | 按 glossary 的 character_type 选 |
+| 反派没有 faction_membership | 没有势力根基的反派不成立 | 补 faction_membership 或降级 |
+| 势力之间没有 faction_relations | 孤立势力格局无张力 | 至少建 3 条势力关系 |
+| 道具不建 item_owner | 不知道属于谁 | 建 item_owner 关系 |
+| 地点没有 location_conflict | 地点成为旅游手册 | 关联至少一个冲突 |
+| 伏笔没有 type | 无法在节奏阶段规划回收 | 按 foreshadow_type 选 |
+| 爽点只填 scale 不填 kind（或反之） | 两个维度都必要 | 都填 |
+| 世界观规则混用 category | 三类规则分工不同 | 按场景选对类别 |
+
+---
+
+## 九、与其他文件的关系
+
+| 本文件输出 | 落到哪个字段 | 参考哪个公式 | 由哪个脚本验证 |
+|---|---|---|---|
+| 实体清单 | `实体.json` 的 12 类数组 | `formulas-skeleton.json` 的 `character_elements.*` / `conflict_elements.*` / `faction_elements.faction_count` / `location_elements` / `item_elements` / `foreshadow_elements` / `climax_elements` / `pleasure_elements` / `ending_elements` / `fixed.structure.main_line_count` / `structure.branch_count` | `skeleton-validate.js` 的 `PATTERN` / `ENUM` / `ID_DUP` / `NAME_DUP` / `QUANTITY_MISMATCH`（warning） |
+| 关系清单 | `关系.json` 的 9 类数组 | `formulas-skeleton.json` 的 `faction_elements.faction_relation_count`（理论上限） | `skeleton-validate.js` 的 `SKELETON_REF_MISSING` / `G_ISOLATED` / `G_REL_ONE_WAY` / `G_REL_ASYMMETRIC` / `G_DISCONNECTED`（warning） |
+
+---
+
+## 十、版本记录
+
+| 版本 | 变更 |
+|---|---|
+| v1.0 | 从原 01-03 + 01-04 精简重组。删除所有"章节"相关内容；删除所有数量数字（移到 formulas）；删除所有检查清单；删除"反派篇幅"表（篇幅属于节奏阶段）；新增"与其他文件的关系"节 |