@oh-story/dsh 0.1.10 → 0.1.12

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@oh-story/dsh",
-  "version": "0.1.10",
+  "version": "0.1.12",
   "description": "A DSH plugin for fiction, short-drama, interactive-game, and video-recap production",
   "keywords": [
     "deepseek-harness",
@@ -70,26 +70,26 @@
   "license": "MIT",
   "peerDependencies": {
     "@deepseek-ai/cordis": "^4.0.4",
-    "@deepseek-ai/dsh-agent": ">=0.1.7-rc.2 <0.1.8-0",
-    "@deepseek-ai/dsh-api-session-controller": ">=0.1.7-rc.2 <0.1.8-0",
-    "@deepseek-ai/dsh-client-store": ">=0.1.7-rc.2 <0.1.8-0",
-    "@deepseek-ai/dsh-client-ui-chat": ">=0.1.7-rc.2 <0.1.8-0",
-    "@deepseek-ai/dsh-client-ui-conversation": ">=0.1.7-rc.2 <0.1.8-0",
-    "@deepseek-ai/dsh-client-ui-layout": ">=0.1.7-rc.2 <0.1.8-0",
-    "@deepseek-ai/dsh-client-ui-renderer": ">=0.1.7-rc.2 <0.1.8-0",
-    "@deepseek-ai/dsh-client-ui-session": ">=0.1.7-rc.2 <0.1.8-0",
-    "@deepseek-ai/dsh-client-ui-slots": ">=0.1.7-rc.2 <0.1.8-0",
-    "@deepseek-ai/dsh-client-ui-tool": ">=0.1.7-rc.2 <0.1.8-0",
-    "@deepseek-ai/dsh-fs": ">=0.1.7-rc.2 <0.1.8-0",
-    "@deepseek-ai/dsh-host-webserver": ">=0.1.7-rc.2 <0.1.8-0",
-    "@deepseek-ai/dsh-llm": ">=0.1.7-rc.2 <0.1.8-0",
-    "@deepseek-ai/dsh-session": ">=0.1.7-rc.2 <0.1.8-0",
-    "@deepseek-ai/dsh-sandbox-policy": ">=0.1.7-rc.2 <0.1.8-0",
-    "@deepseek-ai/dsh-skill": ">=0.1.7-rc.2 <0.1.8-0",
-    "@deepseek-ai/dsh-subagent": ">=0.1.7-rc.2 <0.1.8-0",
-    "@deepseek-ai/dsh-tools": ">=0.1.7-rc.2 <0.1.8-0",
-    "@deepseek-ai/dsh-typert-registry": ">=0.1.7-rc.2 <0.1.8-0",
-    "@deepseek-ai/dsh-util-values": ">=0.1.7-rc.2 <0.1.8-0",
+    "@deepseek-ai/dsh-agent": ">=0.2.0-rc.1 <0.2.1-0",
+    "@deepseek-ai/dsh-api-session-controller": ">=0.2.0-rc.1 <0.2.1-0",
+    "@deepseek-ai/dsh-client-store": ">=0.2.0-rc.1 <0.2.1-0",
+    "@deepseek-ai/dsh-client-ui-chat": ">=0.2.0-rc.1 <0.2.1-0",
+    "@deepseek-ai/dsh-client-ui-conversation": ">=0.2.0-rc.1 <0.2.1-0",
+    "@deepseek-ai/dsh-client-ui-layout": ">=0.2.0-rc.1 <0.2.1-0",
+    "@deepseek-ai/dsh-client-ui-renderer": ">=0.2.0-rc.1 <0.2.1-0",
+    "@deepseek-ai/dsh-client-ui-session": ">=0.2.0-rc.1 <0.2.1-0",
+    "@deepseek-ai/dsh-client-ui-slots": ">=0.2.0-rc.1 <0.2.1-0",
+    "@deepseek-ai/dsh-client-ui-tool": ">=0.2.0-rc.1 <0.2.1-0",
+    "@deepseek-ai/dsh-fs": ">=0.2.0-rc.1 <0.2.1-0",
+    "@deepseek-ai/dsh-host-webserver": ">=0.2.0-rc.1 <0.2.1-0",
+    "@deepseek-ai/dsh-llm": ">=0.2.0-rc.1 <0.2.1-0",
+    "@deepseek-ai/dsh-session": ">=0.2.0-rc.1 <0.2.1-0",
+    "@deepseek-ai/dsh-sandbox-policy": ">=0.2.0-rc.1 <0.2.1-0",
+    "@deepseek-ai/dsh-skill": ">=0.2.0-rc.1 <0.2.1-0",
+    "@deepseek-ai/dsh-subagent": ">=0.2.0-rc.1 <0.2.1-0",
+    "@deepseek-ai/dsh-tools": ">=0.2.0-rc.1 <0.2.1-0",
+    "@deepseek-ai/dsh-typert-registry": ">=0.2.0-rc.1 <0.2.1-0",
+    "@deepseek-ai/dsh-util-values": ">=0.2.0-rc.1 <0.2.1-0",
     "@deepseek-ai/schemastery": "^3.18.4",
     "react": "^18.3.1",
     "react-dom": "^18.3.1",
@@ -97,26 +97,26 @@
   },
   "devDependencies": {
     "@deepseek-ai/cordis": "4.0.4",
-    "@deepseek-ai/dsh-agent": "0.1.7-rc.2",
-    "@deepseek-ai/dsh-api-session-controller": "0.1.7-rc.2",
-    "@deepseek-ai/dsh-client-store": "0.1.7-rc.2",
-    "@deepseek-ai/dsh-client-ui-chat": "0.1.7-rc.2",
-    "@deepseek-ai/dsh-client-ui-conversation": "0.1.7-rc.2",
-    "@deepseek-ai/dsh-client-ui-layout": "0.1.7-rc.2",
-    "@deepseek-ai/dsh-client-ui-renderer": "0.1.7-rc.2",
-    "@deepseek-ai/dsh-client-ui-session": "0.1.7-rc.2",
-    "@deepseek-ai/dsh-client-ui-slots": "0.1.7-rc.2",
-    "@deepseek-ai/dsh-client-ui-tool": "0.1.7-rc.2",
-    "@deepseek-ai/dsh-fs": "0.1.7-rc.2",
-    "@deepseek-ai/dsh-host-webserver": "0.1.7-rc.2",
-    "@deepseek-ai/dsh-llm": "0.1.7-rc.2",
-    "@deepseek-ai/dsh-session": "0.1.7-rc.2",
-    "@deepseek-ai/dsh-sandbox-policy": "0.1.7-rc.2",
-    "@deepseek-ai/dsh-skill": "0.1.7-rc.2",
-    "@deepseek-ai/dsh-subagent": "0.1.7-rc.2",
-    "@deepseek-ai/dsh-tools": "0.1.7-rc.2",
-    "@deepseek-ai/dsh-typert-registry": "0.1.7-rc.2",
-    "@deepseek-ai/dsh-util-values": "0.1.7-rc.2",
+    "@deepseek-ai/dsh-agent": "0.2.0-rc.1",
+    "@deepseek-ai/dsh-api-session-controller": "0.2.0-rc.1",
+    "@deepseek-ai/dsh-client-store": "0.2.0-rc.1",
+    "@deepseek-ai/dsh-client-ui-chat": "0.2.0-rc.1",
+    "@deepseek-ai/dsh-client-ui-conversation": "0.2.0-rc.1",
+    "@deepseek-ai/dsh-client-ui-layout": "0.2.0-rc.1",
+    "@deepseek-ai/dsh-client-ui-renderer": "0.2.0-rc.1",
+    "@deepseek-ai/dsh-client-ui-session": "0.2.0-rc.1",
+    "@deepseek-ai/dsh-client-ui-slots": "0.2.0-rc.1",
+    "@deepseek-ai/dsh-client-ui-tool": "0.2.0-rc.1",
+    "@deepseek-ai/dsh-fs": "0.2.0-rc.1",
+    "@deepseek-ai/dsh-host-webserver": "0.2.0-rc.1",
+    "@deepseek-ai/dsh-llm": "0.2.0-rc.1",
+    "@deepseek-ai/dsh-session": "0.2.0-rc.1",
+    "@deepseek-ai/dsh-sandbox-policy": "0.2.0-rc.1",
+    "@deepseek-ai/dsh-skill": "0.2.0-rc.1",
+    "@deepseek-ai/dsh-subagent": "0.2.0-rc.1",
+    "@deepseek-ai/dsh-tools": "0.2.0-rc.1",
+    "@deepseek-ai/dsh-typert-registry": "0.2.0-rc.1",
+    "@deepseek-ai/dsh-util-values": "0.2.0-rc.1",
     "@deepseek-ai/schemastery": "3.18.4",
     "@types/react": "18.3.28",
     "@types/react-dom": "18.3.7",

package/lib/oh-story/skills/story-long-analyze/references/material-decomposition.md

@@ -1,538 +0,0 @@
-# 小说素材拆解方法论
-
----
-
-## 拆解流程 5 阶段
-
-### 阶段 1：章节解析与机械索引
-
-- 使用 `"{PYTHON}" "{story-long-analyze skill 根}/scripts/build_chapter_index.py"` 识别章界、标题、卷、本地章号、物理行号和正文字符数
-- 在 `chapter_index.csv` 记录逐章 hash、全源 hash 与解析器版本；相同来源复用，不重复解析
-- 机械索引不包含剧情、人物、情绪、钩子或模型推断
-
-### 阶段 2：连续章节块与已有成果二次提取
-
-先运行 `manage_analysis_run.py plan`，只执行标准输出中的内存计划。Stage 2 不再存在逐章独立调用，也不落盘计划文件。
-
-#### A. 已有成果批次
-
-对 `existing-results` 批次只读取计划列出的旧拆文文件：
-
-1. 上游 `章节/第N章_摘要.md` 优先；
-2. 没有摘要时复用黄金三章；
-3. 同一章只选择一个优先来源。
-
-从旧成果二次提取剧情点、关键事件与披露候选、关系和三维节奏。不得打开原文，不得为了统一格式重写旧逐章文件。旧资料没有的信息留空或写“旧资料未提供”。
-
-#### B. 未拆原文章节块
-
-对 `raw-original` 批次一次读取一个不重叠的连续块：
-
-- 普通短章通常 3 章；
-- 长章或信息密集时 1-2 章；
-- 每块最多 3 章，默认同时受 25,000 字符上限约束；
-- 遇到卷界、来源缺口或空章必须断开；
-- 每章在全书运行计划中只属于一个原文块。
-
-同一次理解产生两层结果：
-
-1. 每章紧凑事实：概要、因果、信息变化、状态变化、三维分数、钩子、证据和 10–20 个情节点（长章最多 30）；
-2. 批次观察：剧情点、关键事件与披露候选、关系、三维异常点和跨批状态。
-
-逐章兼容文件由脚本从紧凑事实机械生成；批次缓存保留全部逐章紧凑事实和跨章观察，作为恢复证据。全局聚合用 `digest` 取跨章观察与所需逐章字段，不整份读缓存，也不逐个打开章节文件。不得第二次读取该块来生成逐章文件，也不得把 50-60 章交给一个 agent 后让它自行拆成多个“批次”。
-
-#### C. 剧情点是主要分析单位
-
-每个剧情点记录：
-
-| 字段 | 说明 |
-|---|---|
-| 章节范围 | 当前可确认的起止章；允许跨批延续 |
-| 起始目标 | 谁想做什么 |
-| 阻碍 | 人物、规则、资源、信息或环境阻碍 |
-| 变化来源 | 改变局面的选择、行动或外部事件 |
-| 局面变化 | 目标、风险、资源、关系、知识或行动方向的前后差异 |
-| 得失 | 收益归谁、代价由谁承担 |
-| 后续影响 | 结果怎样促成或限制后续行动 |
-| 状态 | `open` / `closed` |
-| 证据 | 原文模式用 source locator；已有成果模式用资料路径 |
-
-读取批次不等于剧情点。一个批次可以出现多个剧情点，一个剧情点也可以跨批次。跨批延续时继承剧情点 ID 和当前状态；Stage 3 再统一合并、拆分和校验边界。
-
-#### D. 兼容逐章资料
-
-逐章投影只保留现有导入、写作与查询实际使用的内容：概要、关键事件、因果、局面结果、涉及、信息变化、状态变化、三维节奏、章尾钩子、证据和情节点序列（逐点带基调）。取消逐章重复的长篇写法公式、角色复述和扩写技法长表。写法机制、信息差、关系与节奏集中在剧情点及 Stage 3 权威产物中。
-
-#### E. 跨章观察
-
-批次缓存固定包含：
-
-1. 剧情点；
-2. 仅限主线/关键转折的事件与披露候选；
-3. 有向关系变化；
-4. 事件、情绪、篇幅三维节奏的峰谷与分离点；
-5. 未闭合剧情点、悬念、关系状态和待核事项。
-
-角色实体只记录新别名和状态变化，不在每章重复生成人物小传。
-### 阶段 3：聚合分析（跨章节）
-
-> **语料读取**：用 `manage_analysis_run.py digest --part observations` 读取全部批次已经降维的跨章观察；需要逐章字段（三维节奏、涉及、状态变化等）或情节点简表时用 `--part chapters` 按章节窗口取。只在关键证据冲突时定点读取对应逐章兼容文件，最多增加一次定点核验，不重新扫描原文。旧项目没有批次缓存时，直接复用现有剧情、节奏、情绪、关系和逐章资料；证据不足或冲突时标未知或待核。Stage 3–5 不回读原文；Stage 6 可以按索引定点读取 4–6 段文风锚点，但不得重新扫描整本原文。
-
-#### 0. 故事框架识别（聚合前置）
-
-在剧情聚合之前，先识别全书的故事框架。框架决定聚合策略：
-
-| 框架类型 | 特征 | 聚合策略 |
-|----------|------|----------|
-| 升级流 | 等级体系清晰，按境界分段 | 按等级阶段划分剧情单元 |
-| 复仇线 | 核心矛盾明确，目标驱动 | 按复仇对象/阶段划分 |
-| 日常/单元 | 每卷独立故事，弱连续性 | 按卷/单元划分 |
-| 多线交织 | 多视角/多时间线 | 按线索划分，交叉点单独标记 |
-| 蜕变成长 | 主角内在变化为主线 | 按成长阶段划分 |
-
-识别方法：扫描概要.md（Stage 0 thin first-pass 足够，无需等 Stage 5 全书概要）+ 前3章摘要 + 后3章摘要，判断核心驱动模式。
-输出写入 `剧情/故事线.md` 的框架识别部分。
-
-**预期剧情数量引导**（仅用于发现明显粒度异常，不作为凑数目标）：
-
-| 总章数 | 预期独立剧情数 | 依据 |
-|--------|--------------|------|
-| <30 章 | 3-6 个 | 短篇结构紧凑 |
-| 30-100 章 | 5-15 个 | 每条剧情 5-20 章 |
-| 100-300 章 | 10-25 个 | 含主线+支线+补充 |
-| >300 章 | 15-40 个 | 多卷多线结构 |
-
-偏差超过 ±30% 需重新检查粒度。首要原则：保证核心戏剧目标叙事弧的完整性。
-
-**粒度层级混乱检测**（框架识别后自检）：
-
-| 混乱模式 | 检测方法 | 修正方式 |
-|---------|---------|---------|
-| 包含关系 | 剧情A 章节范围完全包含剧情B | 保留粒度适中的B，拆分过粗的A |
-| 重叠率 >50% | 两剧情共享章节超过一半 | 检查是否混淆「剧情」和「剧情阶段」 |
-| 剧情仅为另一剧情的开端/结尾 | 剧情A 只占剧情B 的首/尾几章 | 合并为同一剧情，B 的阶段 |
-| 剧情无独立目标 | 目标描述是另一剧情的子目标 | 降级为该剧情的阶段 |
-
-**框架识别后自检**（聚合前必须通过）：
-1. 覆盖率检查：所有剧情覆盖的章节数（去重）是否达到 85% 以上
-2. 粒度检查：是否存在过细（单一事件）或过粗（宏观主题）的剧情，执行粒度层级混乱检测
-3. 独立性检查：每条剧情是否满足 4 项独立性标准
-4. 数量检查：剧情总数是否在预期范围内
-
-#### A. 剧情聚合（两步法）
-
-将剧情聚合拆为两步：先从摘要识别剧情大纲，再按大纲分配情节点。
-
-**第一步：剧情大纲识别（从章节摘要）**
-
-基于批次候选单元合并独立剧情，边界或证据不清时再读取相关章节摘要。每条大纲包含：
-
-| 字段 | 说明 |
-|------|------|
-| 标题 | 简洁有力，15字以内 |
-| 概要 | 150-300字，按时序连贯叙述因果，不靠同一连接词反复串联；含核心角色、关键地点、事件发展 |
-| 起始目标 | 谁在本单元开始时想做什么；目标早已建立时引用来源 |
-| 主要阻碍 | 人物、规则、资源、信息或环境造成的阻碍 |
-| 关键变化来源 | 谁的选择/行动或什么外部事件改变局面 |
-| 局面变化 | 目标、风险、关系、资源、知识或行动方向的前后差异 |
-| 得失与后续 | 收益归谁、代价由谁承担，怎样限制或促成后续行动 |
-| 类型 | 主线/爱情/成长/复仇/寻宝/悬疑/战斗/权谋/修炼/危机/谜团/日常/其他 |
-| 主题 | 不超过3个 |
-| 章节范围 | 起止章节号 |
-
-识别完成后执行框架识别自检（4项检查）。
-
-**第二步：情节点分配（按剧情大纲）**
-
-对每条剧情大纲，扫描全部情节点，将直接服务该目标的节点分配进来。
-
-**分配执行逻辑**（4 步）：
-1. **主题溯源与节点收集**：针对每条剧情大纲的核心目标，扫描全部情节点，将直接服务、推动或阻碍该目标的事件节点挑出
-2. **边界识别**：识别剧情的起点（触发事件/前置条件）和终点（完成/失败标志），以及连接两者的关键过渡节点
-3. **索引构建与验证**：将筛选出的情节点按时间顺序排列，验证覆盖完整性
-4. **画像数据补充**：基于最终节点集合，补充完善概要、结构分布等字段
-
-**情节点筛选标准**（判定归属时使用）：
-- **主题相关**：情节点内容与剧情概要、主题一致
-- **角色匹配**：情节点涉及的角色与剧情核心角色相关
-- **因果关系**：情节点与剧情发展有因果或逻辑延续
-- **目标导向**：情节点推动或阻碍剧情目标实现
-- **章节范围**：优先选择剧情章节范围内的情节点
-
-**剧情粒度标准（核心要求）**：
-
-| 粒度 | 示例 | 问题 |
-|------|------|------|
-| 过细（单一事件） | "获得神器"（1-2章）、"首次修炼"（第3章） | 这些是事件，不是独立剧情 |
-| 过粗（宏观主题） | "主角的成长之路"（1-100章） | 这是主题，不是具体剧情 |
-| **合适** | "家族觉醒与传承认知"（1-6章）、"神器获得与导师相遇"（7-13章） | 有独立目标、冲突、角色群和完整叙事弧 |
-
-**剧情独立性判断标准**（必须同时满足）：
-1. **独立的核心目标**：有明确的、可衡量的戏剧目标（不是宏观主题或抽象概念）
-2. **独立的主要冲突**：有具体的对抗力量和冲突事件（不是某个大冲突的子阶段）
-3. **相对独立的角色群**：有该剧情特有的核心角色（可以与其他剧情共享部分角色）
-4. **独立的叙事节奏**：有自己的紧张-缓和节奏
-
-**三层覆盖策略**：
-1. **主线剧情**（优先级最高）：推动整体故事发展，通常占 60-70% 章节
-2. **支线剧情**：感情线、成长线、战斗线等，通常占 20-30% 章节
-3. **补充剧情**：过渡剧情、日常剧情，确保覆盖率 ≥85%
-
-**剧情类型**：
-- 主线（推动整体故事发展的核心剧情）
-- 爱情（感情关系发展）
-- 成长（角色能力/心智/地位提升）
-- 复仇（复仇相关）
-- 寻宝（争夺物品或目标）
-- 悬疑（推理、真相揭露）
-- 战斗（战争、比武、对决）
-- 权谋（政治斗争、权力争夺）
-- 修炼（修炼、突破、传承）
-- 危机（危机应对、解救、逃脱）
-- 谜团（世界观未解之谜、身世秘密、隐藏真相）
-- 日常（日常生活、过渡性内容）
-- 其他（无法归入以上类型）
-
-每条剧情提取：标题、概要（150-300字，按时序连贯叙述因果）、核心目标、核心冲突、类型、章节范围。
-标记结构分布：铺垫期/发展期/高潮期/收尾期 各包含哪些章节。
-
-**核心目标类型参考**：
-- 获得型："赢得大比冠军""获得关键道具/传承""攻占要塞"
-- 解决型："解除家族危机""偿还巨额债务""摆脱追杀"
-- 创造型："创立新宗门""研发新招式""开创一个流派"
-- 探索型："调查父母失踪真相""探索上古遗迹""揭露阴谋"
-
-#### B. 故事线提取
-
-将多条剧情聚合为「故事线」：标题、描述（300-600字发展阶段划分）、主要人物、主题关键词、包含的剧情列表（至少1个剧情）。
-
-**故事线类型**：主线/感情线/成长线/复仇线/夺宝线/冲突线/谜团线/其他
-
-**故事线描述要求**：
-- 划分 3-8 个发展阶段（periodization），寻找关键转折点或里程碑事件作为阶段边界
-- 每个阶段含：核心冲突、关键角色及作用、能力/资源/地位演进、主题母题
-- 独立追踪伏笔与回收关系链（前后呼应的伏笔-回收对）
-- 标注与其他故事线的交织关系（并行/交织/依赖）
-- 包含剧情按时序排列，每条故事线至少包含1个剧情
-
-#### C. 节奏索引与情绪模块生成
-
-Stage 3 聚合后必须生成两个权威产物，供 Stage 5 报告摘要和 `story-long-write` 直接读取：
-
-1. **`剧情/节奏.md`（节奏权威）**
-   - 输入：批次关键事件与披露候选、三维节奏异常点、逐章紧凑事实、剧情单元和故事线。
-   - 输出：全书约 8–15 个节点的关键双时间线表、三维节奏表、关键信息推进、爽点循环、情绪触动点和爆发节奏。
-   - 生成法：只选择改变主线、关系、核心风险或读者判断的事件；客观事件只登记一次，异常、线索、解释和确认写进同一事件的披露路径。对关键区间分别判断事件状态变化、读者情绪触发和篇幅展开/压缩/省略。
-   - 校验：每条 `EV/RV/AX/RH/TR` 都能回指章节、情节点或定位；过程没有展示时写“文本未展示”，不推断作者有意省略。
-
-2. **`剧情/情绪模块.md`（模块权威）**
-   - 输入：故事框架识别、剧情单元、`剧情/节奏.md`、读者需求判断、桥段标签。
-   - 输出：读者需求 / 情绪引擎、故事框架与套路运行图、完整模块卡（至少覆盖前三强，不设数量上限）、其他机制索引、重组与复现指南。
-   - 生成法：先抽象“读者为什么期待兑现”，再把具体剧情抽成情绪链和功能位；完整模块卡必须五个门禁字段齐全（读者想看什么、情绪链、戏剧单元、可替换项、不可照搬），必要铺垫、成立条件、失效情形、反例等按需增列，其他机制只留用途、范围和证据引用。
-   - 校验：best-effort 为模块标注来源（关联 `剧情/节奏.md` 的 RH/TR 条目或章节情节点），无把握时留空、不硬凑、不删模块；禁止把原文专名、独特事件顺序、标志性台词写成可复用模板。
-
-**权威关系**：`剧情/节奏.md` 管节奏/触动点，`剧情/情绪模块.md` 管读者需求/模块复现。`拆文报告.md` 与 `剧情/故事线.md` 只能摘要或引用这两个文件，不能成为并列权威。
-
-#### D. 小说概要生成（在 Stage 5 落盘，覆盖 Stage 0 thin first-pass）
-
-整体故事框架识别 + 500-1000字高密度全书概要（涵盖主要剧情线阶段性发展、核心人物作用、关键转折点、因果关系）。
-
-> **落盘时机**：聚合阶段（Material 阶段 3 ≈ pipeline Stage 3）产出概要文本，但**写入 `概要.md` 的动作放在 pipeline Stage 5 汇总报告**——届时 Stage 3 / 4 全部完成、信息最完整。Stage 5 覆盖 Stage 0 的 thin first-pass 段，章节索引和卷段表保留。
-
-### 阶段 4：世界观与设定提取
-
-Stage 2 紧凑事实中的 `涉及人物`、`状态变化` 与批次 `关系变化` 在此阶段归一为完整档案。
-
-#### 角色两阶段模型
-
-**阶段 A：轻量提及（Stage 2 输出）**
-- 每章 `涉及人物` 记录关键人物，`状态变化` 记录本章可见净变化；
-- 批次 `关系变化` 补充有方向的动作、触发与得失；
-- 不另建出场人物表，不在单章内完成跨章人物定型。
-
-**阶段 B：完整档案（Stage 4 构建）**
-- 合并逐章 `涉及人物`、`状态变化` 和批次关系观察
-- 跨章节别名解析（批次 `跨批状态` 的「已确认别名」是现成线索）
-- 群体称呼、无名路人和泛称（亲属、社交、身份、年龄外貌类称呼，如大哥、掌柜、老师、小伙子）不建档，除非原文固定用它指代某一个人
-- 构建完整角色档案
-
-#### 一人一实体原则
-
-- **绝对禁止**将不同人物的信息合并到同一个实体中
-- 每个角色实体必须对应唯一的一个人物
-- 如果无法确定两个称呼是否指向同一人物，必须分开创建实体
-
-#### 别名解析规则
-
-**别名类型**：
-
-| 类型 | 定义 | 可合并 | 示例 |
-|------|------|--------|------|
-| proper_name | 专名/全名/常用名 | 是 | "希尔曼""林雷·巴鲁克" |
-| nickname | 绰号/外号，须有同指证据 | 是（置信度≥0.85） | "龙血战士林雷" |
-| descriptor | 描述性称谓 | 否 | "红发壮汉""随从""队长" |
-| title | 头衔/职务 | 否 | "护卫队长""家主""族长" |
-
-**合并约束**：
-- 仅 proper_name 和 nickname（置信度 ≥0.85）可用于合并
-- descriptor 和 title **永不**触发实体合并
-- nickname 须提供同指证据：同位说明、括号别名、上下文指代、明确改名
-
-**Archetype 量化判断**：
-
-| 类型 | 标准 |
-|------|------|
-| **主角** | 出现章节 ≥50% 总章节 + 推动主线 + 有完整成长轨迹 |
-| **反派** | 与主角对立 + 推动核心冲突 + 有明确动机 |
-| **核心配角** | 出现章节 ≥20% OR 推动重要支线 OR 有独立人格和成长 |
-| **功能角色** | 出现章节 <20% + 作用有限（提供信息/道具/一次性互动） |
-
-**特殊**：前期 minor 后期 supporting → 判为 supporting。重要导师/伙伴即使出现少也可判为 supporting。
-
-**角色档案结构**（200-500字）：
-1. 身份背景（1-2句）
-2. 核心经历（3-5句，按时序）
-3. 性格特质（1-2句，从行为归纳）
-4. 能力特长（1-2句）
-5. 人际关系（1-2句）
-6. 成长轨迹（如有，1句）
-
-#### 金手指合并规则
-
-- 相互关联、共同作用的元素**合并为一个**（如"戒指+导师灵魂"是一个整体）
-- 同一事物的不同描述角度**不拆分**
-- 只有完全独立、互不依赖的能力来源才拆分为多个
-- 长篇特点：金手指可能复杂多样，需详尽描述演化过程和多重能力
-- 无金手指时注明
-
-**金手指类型**：system（系统）/ space（空间）/ rebirth（重生）/ transmigration（穿越）/ special_physique（特殊体质）/ artifact（神器）/ bloodline（血脉）/ other（其他）
-
-#### 世界观（按主题拆分到多个文件）
-
-字段与落盘位置：
-
-| 字段 | 说明 | 落盘文件 |
-|------|------|----------|
-| 类型 | 奇幻/现实/平行世界 | 各文件 frontmatter 或开头注明 |
-| 力量体系 | 名称、等级、晋升方式（文本描述） | `设定/世界观/力量体系.md`（>=200字独立，否则并入 背景设定） |
-| 地理 | 分布、主要区域、关键地点（文本描述） | `设定/世界观/地理.md`（同上，>=200字独立） |
-| 势力 | 门派/组织/家族/国家 | **每个势力一个文件** `设定/势力/{势力名}.md`（>=200字独立；不足合并到 `设定/世界观/背景设定.md`） |
-| 核心规则 | 世界运转的基本规则 | `设定/世界观/背景设定.md` |
-| 特殊设定 | 区别于现实的独特设定 | `设定/世界观/背景设定.md`（与核心规则同文件） |
-| 金手指 | 见上方「金手指合并规则」 | `设定/世界观/金手指.md`（统一在 `设定/世界观/` 子目录下，不放扁平 `设定/金手指.md`） |
-
-> 模板与示例见 [output-templates.md](output-templates.md) 「Stage 4 设定+关系」节。下游导入只原样同步当前主题文件，不再现场拆分扁平文件。
-
-### 阶段 5：人物关系提取
-
-每对关系：
-
-| 字段 | 说明 |
-|------|------|
-| 主体 → 客体 | 有向关系；反向动作存在时另记一条 |
-| 关系动作/类型 | 保护、依赖、控制、服从、欺骗、竞争等动作及家人/师徒/朋友/敌人/恋人/同事/上下级/商业/其他类型 |
-| 表面/真实状态 | 文本允许区分时分别记录；未证实的真实状态标推断等级 |
-| 触发事件 | 导致关系建立或变化的具体行动/事件 |
-| 双方得失 | 信任、资源、地位、行动空间、风险、债务、暴露或失控 |
-| 变化后状态 | 本阶段结束时的状态及后续约束 |
-| 证据 | A/B/C 强度、章节、情节点或 source locator |
-
-#### 关系提取策略
-
-**数据源**：从已提取的情节点描述中提取关系（不从原文提取），更高效、更聚焦。
-
-**批量提取**：复用 Stage 2 每个连续章节批次的关系观察，只记录新关系或关系变化；不为了固定章数单独重读原文。
-
-**关系演变追踪**：当同一对角色关系发生变化时，记录演变轨迹：
-```
-第{N}章：{关系状态A} → 第{M}章：{关系状态B}
-触发事件：{具体事件}
-情感转变：{正面→负面/负面→正面/中立→复杂 等}
-```
-
-**最终状态合并**：同一有向关系的多阶段状态保留最新状态作为主记录，历史变化写入演变轨迹。反向关系动作不能因角色对相同而被去重。
-
-**隐含关系推断**：当角色间没有直接互动但有间接证据时：
-- 通过第三方的评价/描述推断（置信度标 0.7）
-- 通过共同出现的频率和场合推断（置信度标 0.6）
-- 推断关系标记 `[推断]`，与直接证据关系区分
-
-**关系网络密度**：
-- 统计主要角色（主角+核心配角）的关系数量
-- 关系数 < 3 → 关系网偏薄，检查是否有遗漏
-- 关系数 > 10 → 关系网过密，检查是否有误合并
-
----
-
-## 原子提取六大铁律
-
-1. **双序分离**：逐章事实按文本披露顺序排列；客观事件另标故事内发生顺序，不能把倒叙或回忆挪成当前事件
-2. **客观白描**：记录"发生了什么"和结果，原文明说的起因照写，不推测未写出的动机，不用叙事框架词
-3. **信息保真**：不遗漏改变语境的关键细节
-4. **高度浓缩**：一个情节点一句话概括
-5. **复合合并**：为同一戏剧目的服务的连续微动作合并为一个情节点
-6. **客观事实**：提取客观事实，不做叙事分析
-
-**客观白描 vs 叙事框架词**：
-- 禁止：「通过对话，郑松得知张子豪在韩国训练」
-- 正确：「吴志斌告诉郑松，张子豪在韩国训练」
-- 禁止：「林风展现了自己的实力」
-- 正确：「林风三招击败对手，围观者倒吸一口凉气」
-- 禁止：「邵阳感到心碎和愤怒」
-- 正确：「邵阳目睹宋丽与人拥抱，表情由刺痛转为冷漠」
-
----
-
-## 合成阶段事实保真（阶段 3-5：剧情/设定/角色/报告）
-
-阶段 3-5 从章节摘要二次合成，离原文已两跳，最易把「摘要没说的」用合理推断补成「看似坐实的事实」——这是拆文事实错误的最大来源（典型：给「双系魔法师」凭空补第二系、把坐骑等级安到骑手头上、给原文没给的字段编一个数值、把出场区间填成连续跨度含没出场的章）。强模型也照样漂移，因为越远离原文，模型越靠世界知识与"合理性"填空。三条硬约束：
-
-1. **硬事实必须可溯源**：力量等级、数值、距离、属性、势力数量、谁对谁说了什么、角色出场章节——先检查批次证据或已有事实的章节和定位；命中不到就改写为“资料未明确”或删除，不为聚合二次读取原文。
-2. **缺失写「原文未明确」，禁编造填空**：原文没给的字段，写「原文未明确/节选未涉及」，绝不用近义项、别处的范例或惯例补一个看似合理的值。
-3. **跨指代不串**：相邻实体的属性不互相挪用——坐骑等级≠骑手等级、A 的台词≠B 的台词、本章统计数字≠相邻章数字。
-
-落盘后做一次**事实可溯源自检**：抽查设定、角色和报告里的硬事实，逐条核对到本次允许使用的证据源。`raw-original` 可按 `source_locator` 机械定位原文，`existing-results` 只能核对计划列出的旧成果文件；旧成果没有的细节改写为「旧资料未提供」或删除，不借核证之名回读已覆盖章节原文。此自检独立于下方三个比率——比率查归类质量，它查事实真伪。
-
----
-
-目录结构见 SKILL.md「输出目录结构」。
-
----
-
-## 质量阈值体系
-
-阶段 3 和阶段 4 完成后自检：
-
-| 指标 | 阈值 | 计算 | 不达标处理 |
-|------|------|------|------------|
-| 置信度 | >= 0.85 | 有明确归属的情节点 / 剧情单元内情节点总数 | 低于 0.85 标记「待复核」 |
-| 覆盖率 | 85%-95% | 已归类情节点 / 总情节点数 | <85% 触发孤立情节二次分类；>95% 复核边界 |
-| 关键信息覆盖 | 每章有结论 | 含有效信息行或明确“无独立信息变化”的章节数 / 摘要章节数 | 按原输入类型回到 Stage 2 补提取；旧成果章仍不得回读原文 |
-| 模块来源标注 | best-effort | 情绪模块卡尽量标注 RH/TR 或章节情节点来源 | 无把握的来源留空，不硬凑、不删模块（同桥段标签的 best-effort 处理）|
-| 披露引用完整 | 100% | 关键双时间线中每个 `RV-*` 都属于同一行的 `EV-*` 披露路径，同一客观事件不因多次披露重复建档 | 缺引用或重复事件时回到批次观察合并 |
-| 三维解释完整 | 100% | `AX-*` 的事件、情绪、篇幅三轴都有理由与证据 | 缺轴时补“无明显变化/文本未展示”及依据，不用分数占位 |
-| 重叠率 | <= 35% | 跨剧情单元共享情节点 / 总情节点数 | >35% 提示边界模糊，建议合并 |
-
-> **小体量节选（< 30 章、单主线连续叙事）的特例**：此类素材按时序连续切分时，覆盖率天然接近 100%、散落情节接近 0，这是线性结构的正常结果，不算过度归并。此时复核重点是「有无把不同剧情强行并进同一条」，而非覆盖率数值本身——不必为压到 95% 以下而人为拆分。
-
----
-
-## 散落情节兜底
-
-阶段 3 聚合完成后执行（6 步，含覆盖率验证）：
-
-1. **计算孤立比例**：孤立情节点数 / 总情节点数。若比例 < 5%，跳过后续步骤，直接标记为「少量散落，无需处理」
-2. **筛选未分配情节点**：用 `digest --part chapters --points brief` 按章节窗口列出情节点简表，收集未归类到任何剧情单元的情节点
-3. **三层置信度归入**：按角色重叠、地点重叠、因果关系三条线索计算相关性
-   - **强相关**（0.8-1.0）：角色匹配 + 主题相关 → 归入现有剧情单元，标记 `[孤立情节归入]`
-   - **中等相关**（0.5-0.8）：角色匹配 或 主题相关 → 归入并标记 `[低置信归入]`，待复核
-   - **弱相关**（<0.5）：不建议强行归入，宁可放入未分配
-4. **主题聚类**：弱相关的情节点按主题关键词聚类
-   - 聚类结果 >= 5 个情节点 → 形成候选剧情单元，标记 `[聚类生成]`
-   - 聚类结果 < 5 个 → 不单独建条
-5. **散落情节归档**：仍无法归类的写入 `散落情节.md`，按章节排列，标注原因
-   - 不丢弃任何情节点，不要强行分配到不相关的剧情
-   - 在拆文报告中统计散落情节点数量和占比
-6. **覆盖率验证**：
-   - 覆盖率 = (总数 - 散落数) / 总数 × 100%
-   - 目标：85%-95%
-   - < 85% → 回到步骤 3，降低置信度阈值重试
-   - > 95% → 检查是否有过度归并，复核边界剧情单元
-
----
-
-## 执行指引
-
-### 分块策略
-
-Stage 2 按运行计划分别建立旧成果批次和缺章原文块，每批调用一次 chapter-extractor；原文块同次返回逐章事实和跨章观察，旧成果批次只返回跨章观察。其他阶段只消费这些结果和可复用旧资料。
-
-> **先分清两个互不相干的轴**，本节此前把它们混在一个「块」字里，导致 >500 章出现「50-200 章/块」与「6-8K token/块」两套差 30-100 倍的规格：
-> - **语义分块**＝*在哪里切*。按叙事弧切，产出「块元数据」用于组织分析结果，块可以很大（一个 914 章的书通常 5-10 个弧）。它不决定一次读多少。
-> - **处理批次**＝*一次读多少*。受上下文容量约束，原文块按索引字数切分，旧成果批次按资料体积切分。下面表格的「块大小」列指的是**处理批次**。
-
-| 单章与上下文情况 | 读取批次策略 | 常见章数 |
-|------|------|--------|
-| 普通章节、上下文充足 | 连续读取并保留跨章状态 | 3 章/批 |
-| 长章、信息密集或上下文较小 | 缩小批次，不截断明显短因果链 | 1-2 章/批 |
-| 超长书 | 批次数量增加；语义弧仍独立于读取批次 | 仍按上述字数与上下文判断 |
-
-### 语义弧识别
-
-基于批次观察和章节摘要识别自然分界。读取批次只是上下文单位，不能直接当成剧情单元：
-
-**分块原则（四大铁律）**：
-1. **语义连贯**：每块是一个相对独立的内容单元（大故事阶段或主要事件线）
-2. **自然分界**：在内容转折点、场景切换、时间跨越处切分，不在紧密剧情中间切
-3. **大小适中**：语义完整性优先于大小均匀；不设固定章数，也不要求一个语义弧一次读进上下文
-4. **避免割裂**：不在紧密剧情中间切分
-
-**题材特化分块参考**：
-
-| 题材 | 分块依据 | 示例 |
-|------|---------|------|
-| 修仙/升级 | 境界突破、地图切换 | 炼气期→筑基期→金丹期 |
-| 都市 | 事件线、身份转变 | 学生→创业→商业帝国 |
-| 历史 | 历史阶段、战役 | 起兵→统一北方→南征 |
-| 玄幻 | 世界地图、势力变化 | 东域→中州→上界 |
-| 有卷/部/篇 | 优先按原结构 | 按作者划分的卷/部 |
-
-**无明显结构**时保留连续批次边界，并把无法确认的语义归属标为待聚合。**硬约束**：所有确实需要读原文的章节都被唯一读取批次覆盖，已有成果章进入旧资料批次；两者互斥且各自不重叠。剧情单元可以跨批次，也可以在一个批次中出现多个。
-
-每块输出元数据：`块标题 | 起止章节 | 核心主题（2-5个） | 关键事件（2-5个） | 主角阶段`。
-
-每章只保存一组紧凑事实。每批先保存完整缓存，再补缺失摘要，最后只更新 `_progress.md` 受管状态；不生成收据或独立批次账本。
-
-### 处理批次（一次读多少）
-
-Stage 3-5 的语料是 `digest` 输出：全书跨章观察，加按窗口抽取的逐章字段与情节点简表；不整份读批次缓存（其中约七成是与逐章摘要重复的章节块）。只有关键冲突才定点读取对应 `章节/*_摘要.md`。旧项目没有缓存时直接读取已有剧情、节奏、情绪、关系资料；不要为了统一格式先把所有旧摘要重新压缩一遍。
-
-**A. 连续批次模式**
-
-1. **切批**：按 `chapter_index.csv` 连续取 1-3 章，根据原文字数和上下文缩放；完整任务不跳章。
-2. **分派**：每批一个 chapter-extractor，只给该批 `source_locator`、边界、输出文件路径和交接缓存路径；子代理自己读原文与交接批的跨批状态。串行、有限并行或不限顺序由作者在 Stage 1 后选定（见 pipeline-ops「执行与提交一个批次」），并行时边界处的剧情点接续交给下方跨块合并。每个原文范围只有一个 owner。
-3. **双层落盘**：同次产出逐章紧凑事实与批次观察，由子代理直接写进批次输入文件、只回回执；主会话不转贴原文、不读输入文件，直接提交。禁止另起一次模型调用重复分析同一批原文；兼容文件由提交脚本机械生成。
-4. **主线程合并**：主线程用 `digest` 消费全书跨章观察和按窗口抽取的逐章字段做全局合成。全书仍超上下文时按章节窗口分组合并，中间层只保留剧情状态、关键候选和证据引用，不扩写内容。
-5. **进度**：计划阶段只读；完整缓存、所需摘要和输入范围 hash 全部核对后，最后在 `_progress.md` 登记 `completed`。失败不提前写完成，必要时把父块标 `superseded` 并持久化相邻子块；中断从完整缓存恢复。
-
-> 批次数由原文长度和上下文决定，不设“超过 500 章就固定 10-20 章/批”的第二套规则。
-
-**B. 主线程串行模式（agent 不可用时的降级）**
-
-无法 spawn 子代理时由主线程按同一连续批次契约顺序处理。批次可因主线程上下文更小而缩短，但仍须同次产生逐章事实和跨章观察，不能退回每章一次调用。
-
-**C. 不要做的事**
-
-- 不要把大语义弧整块塞进一次上下文。
-- 不要固定章数而忽略原文字数、上下文容量和章界。
-- 不要在 Stage 3、4、5 各自重新读取同一批原文。
-- 不要用跳读锚点冒充完整语义覆盖。
-
-### 跨块合并（大型小说 >500 章）
-
-分块处理后，相邻块的边界剧情可能被机械切分割裂。Stage 3 聚合时执行跨块合并检查：
-
-**合并判断标准**（必须同时满足）：
-1. ✓ 同一核心事件/目标：讲述的是同一个核心事件（不是两个独立事件）
-2. ✓ 主要人物相同：涉及的主要人物相同
-3. ✓ 剧情发展连续：剧情 B 是剧情 A 的自然延续
-4. ✓ 非因果独立事件：不是因果关系的两个独立事件
-
-**应该合并**：
-- "竞选县长秘书（准备阶段）" + "竞选县长秘书（投票阶段）" → 同一事件被分块割裂
-- "修炼突破（前期）" + "修炼突破（后期）" → 同一突破过程
-
-**不应合并**：
-- "在办公室立足" + "竞选县长秘书" → 两个独立目标
-- "炼气期修炼" + "筑基期修炼" → 不同阶段的独立剧情
-- "东域修炼" + "中州历练" → 不同地图的独立剧情
-
-**保守原则**：当不确定时，倾向于不合并（保持独立）。
-
-**边界检测原则**：只检查相邻块中接近块边界的剧情对，远离边界的剧情不参与跨块合并。
-
-### 跨会话恢复
-
-- 进度通过 _progress.md 追踪
-- 新会话读 _progress.md 定位断点
-- 先校验断点批次已有文件；完整且与来源一致则补记进度，缺失或损坏才从该批次起章重做