novelws 3.0.0 → 4.0.0

package/templates/commands/track.md

@@ -2,10 +2,11 @@
 name: track
 description: 综合追踪小说创作进度和内容
 argument-hint: [--brief | --plot | --stats | --check [--volume vol-XX] | --fix | --sync [--incremental] | --migrate [--auto | --volumes "1-100,101-200"] | --log]
-allowed-tools: Read(//spec/tracking/**), Read(//spec/tracking/**), Read(//stories/**), Read(//stories/**), Bash(find:*), Bash(wc:*), Bash(grep:*), Bash(*)
+recommended-model: claude-haiku-4-5-20251001 # --sync 数据更新速度优先；--check 深度检查可用 sonnet
+allowed-tools: Read(//tracking/**), Read(//tracking/**), Read(//stories/**), Read(//stories/**), Bash(find:*), Bash(wc:*), Bash(grep:*), Bash(*)
 scripts:
-  sh: .specify/scripts/bash/track-progress.sh
-  ps: .specify/scripts/powershell/track-progress.ps1
+  sh: resources/scripts/bash/track-progress.sh
+  ps: resources/scripts/powershell/track-progress.ps1
 ---
 
 # 综合进度追踪
@@ -44,7 +45,7 @@ resource-loading:
 - `--brief` - 显示简要信息
 - `--plot` - 仅显示情节追踪
 - `--stats` - 仅显示统计数据
-- `--check` - **[增强]** 执行深度一致性检查（包含角色验证），支持 `--volume vol-XX` 限定范围
+- `--check` - **[增强]** 执行深度一致性检查（包含角色验证），支持 `--volume vol-XX` --volume 范围限定，只检查该卷的 tracking 数据
 - `--fix` - **[新增]** 自动修复发现的简单问题
 - `--sync` - **[新增]** 批量同步多章节的 tracking 数据，支持 `--incremental` 增量同步
 
@@ -52,12 +53,12 @@ resource-loading:
 
 整合多个追踪文件的信息：
 - `progress.json` - 写作进度
-- `spec/tracking/plot-tracker.json` - 情节追踪
-- `spec/tracking/timeline.json` - 时间线
-- `spec/tracking/relationships.json` - 关系网络
-- `spec/tracking/character-state.json` - 角色状态
-- `spec/tracking/narrative-threads.json` - **[新增]** 多线叙事追踪（POV调度、信息差、线程交汇）
-- `spec/tracking/validation-rules.json` - **[新增]** 验证规则（用于--check和--fix）
+- `tracking/plot-tracker.json` - 情节追踪
+- `tracking/timeline.json` - 时间线
+- `tracking/relationships.json` - 关系网络
+- `tracking/character-state.json` - 角色状态
+- `tracking/narrative-threads.json` - **[新增]** 多线叙事追踪（POV调度、信息差、线程交汇）
+- `tracking/validation-rules.json` - **[新增]** 验证规则（用于--check和--fix）
 
 ---
 
@@ -151,7 +152,7 @@ resource-loading:
 
 #### 详细查看单条记录
 
-当用户选择"[查看详情]"时，显示完整的 diff 和更新依据：
+选择"[查看详情]"时，显示完整的 diff 和更新依据：
 
 ```markdown
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
@@ -162,140 +163,60 @@ resource-loading:
 
 ### 命令执行
 - **命令**: `/write chapter-05 --focus emotion`
-- **执行者**: AI
 - **状态**: 已自动更新
 
 ### 更新内容
 
 #### character-state.json
-```diff
-  "林晓": {
-    "lastAppearance": "chapter-04",
-+   "lastAppearance": "chapter-05",
-    "emotion": "平静",
-+   "emotion": "焦虑",
-    "location": "训练场"
-  }
-```
+- 林晓：lastAppearance chapter-04 → chapter-05，emotion 平静 → 焦虑
 
 #### relationships.json
-```diff
-+ {
-+   "from": "林晓",
-+   "to": "队长",
-+   "type": "信任",
-+   "strength": 0.6,
-+   "evidence": "Ch.5 首次合作任务",
-+   "lastUpdate": "chapter-05"
-+ }
-```
++ 新增：林晓 → 队长（信任，strength: 0.6，evidence: Ch.5 首次合作任务）
 
 #### plot-tracker.json
-```diff
-  "plotLines": [
-    {
-      "id": "主线-001",
-      "progress": 0.2,
-+     "progress": 0.3,
-      "lastUpdate": "chapter-04",
-+     "lastUpdate": "chapter-05"
-    }
-  ]
-```
+- 主线-001：progress 0.2 → 0.3，lastUpdate chapter-04 → chapter-05
 
 #### timeline.json
-```diff
-+ {
-+   "day": 15,
-+   "time": "14:00",
-+   "chapter": "chapter-05",
-+   "event": "首次合作任务"
-+ }
-```
++ 新增：Day 15 14:00 chapter-05 首次合作任务
 
 ### 更新依据
-- **角色分析**: Ch.5 林晓的对话和行为显示焦虑情绪
-- **关系分析**: Ch.5 林晓与队长首次合作，建立初步信任
-- **情节推进**: 主线进展 10%，发现第一条线索
-- **时间线**: Ch.5 情节推进到第 15 天
-
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-```
-
-#### 过滤查看示例
-
-**按命令过滤**:
-```markdown
-📜 /write 命令的更新历史（12 条记录）
-
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-## 2026-02-08 14:30:25 - /write chapter-05
-[摘要...]
-
-## 2026-02-07 16:15:00 - /write chapter-04
-[摘要...]
-
-[继续列出其他 /write 记录...]
-```
-
-**按文件过滤**:
-```markdown
-📜 character-state.json 的更新历史（8 条记录）
-
+- 角色分析: Ch.5 林晓对话和行为显示焦虑情绪
+- 关系分析: 林晓与队长首次合作，建立初步信任
+- 情节推进: 主线进展 10%，发现第一条线索
+- 时间线: Ch.5 推进到第 15 天
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-## 2026-02-08 14:30:25 - /write chapter-05
-**变更**: 林晓情绪 平静 → 焦虑
-
-## 2026-02-07 16:15:00 - /write chapter-04
-**变更**: 林晓位置更新
-
-[继续列出其他记录...]
 ```
 
-**按时间范围过滤**:
-```markdown
-📜 2026-02-01 至 2026-02-08 的更新历史（15 条记录）
+#### 过滤查看
 
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-[列出时间范围内的所有记录...]
-```
+支持按命令、文件、时间范围过滤：
+- **按命令**: `/track --log --command=write` → 只显示 /write 命令的更新记录
+- **按文件**: `/track --log --file=character-state.json` → 只显示该文件的变更记录
+- **按时间**: `/track --log --since=2026-02-01 --until=2026-02-08` → 时间范围内的记录
 
 ### 实现逻辑
 
-**读取 tracking-log.md**:
-1. 读取 `spec/tracking/tracking-log.md`
-2. 解析日志格式，提取所有更新记录
-3. 根据过滤条件筛选记录
-4. 按时间倒序排列（最新的在前）
+1. 读取 `tracking/tracking-log.md`，解析日志格式
+2. 根据过滤条件筛选，按时间倒序排列
+3. 默认仅加载摘要（轻量级），选择"查看详情"时加载完整 diff
+4. 大型日志（>1000 条）分页显示
 
-**解析日志条目**:
-- 提取时间戳、命令类型、更新状态
-- 提取更新文件列表
-- 提取摘要信息（从 diff 中生成）
-- 保留完整的 diff 和更新依据
-
-**性能考虑**:
-- 默认仅加载摘要信息（轻量级）
-- 用户选择"查看详情"时才加载完整 diff
-- 对于大型日志文件（>1000 条记录），分页显示
+**注意**：如果 `tracking-log.md` 不存在，说明尚未执行过 tracking 更新命令，执行 `/write` 或 `/plan` 后会自动创建。
 
 ### 错误处理
 
 #### 如果 tracking-log.md 不存在
 
-```markdown
+```
 ℹ️ 提示：tracking-log.md 不存在
-- 位置：spec/tracking/tracking-log.md
+- 位置：tracking/tracking-log.md
 - 原因：尚未执行过任何 tracking 更新命令
 - 建议：执行 /write 或 /plan 命令后会自动创建
 ```
 
 #### 如果日志格式无法解析
 
-```markdown
+```
 ⚠️ 警告：日志文件格式异常
 - 文件：tracking-log.md
 - 问题：无法解析部分日志条目
@@ -338,151 +259,73 @@ resource-loading:
 
 ### 叙事线同步（--check 扩展）
 
-当故事使用多线叙事时（检测到 `narrative-threads.json` 存在或 `specification.md` 中标记了多线结构），`/track` 在章节同步流程中自动提取和更新叙事线数据。
-
-#### 章节同步提取规则
+当检测到 `narrative-threads.json` 或多线叙事结构时，自动提取和更新叙事线数据：
+- **视角角色** → 更新 `povSchedule`
+- **叙事线推进** → 更新 thread 的 `chapters` 和 `lastActiveChapter`
+- **信息揭示** → 更新 `informationState`
+- **叙事线交汇** → 更新 `intersections`
 
-从每个新写章节的内容中提取：
-
-1. **视角角色** → 更新 `povSchedule`（记录本章的 POV 角色和对应线程）
-2. **叙事线推进** → 更新对应 thread 的 `chapters` 和 `lastActiveChapter`
-3. **信息揭示** → 更新 `informationState`（读者/角色的已知信息变化）
-4. **叙事线交汇** → 更新 `intersections`（如本章有多条线交汇）
-
-#### 叙事线健康度检测（--check 内）
+检测内容：叙事线活跃度（冷线警告）、视角分布比例、活跃信息差数量。
 
 ```
 📊 叙事线健康度
 ━━━━━━━━━━━━━━━━━━━━
+| 叙事线 | 最后活跃 | 冷线章数 | 状态 |
+|--------|---------|---------|------|
+| 主线   | 第 15 章 | 0       | ✅ 活跃 |
+| 支线1  | 第 12 章 | 3       | ⚠️ 注意 |
+| 暗线   | 第 5 章  | 10      | 🔴 危险 |
 
-| 叙事线 | 类型 | 最后活跃 | 冷线章数 | 状态 |
-|--------|------|---------|---------|------|
-| 主线 | main | 第 15 章 | 0 | ✅ 活跃 |
-| 支线1 | sub | 第 12 章 | 3 | ⚠️ 注意 |
-| 暗线 | hidden | 第 5 章 | 10 | 🔴 危险 |
-
-⚠️ 警告：
-- 暗线已 10 章未推进，读者可能遗忘
-- 支线1 接近冷线阈值，建议近 2 章内推进
-
-📊 视角分布
-━━━━━━━━━━━━━━━━━━━━
-主角视角：60%  ████████████░░░░░░░░
-角色B视角：25%  █████░░░░░░░░░░░░░░
-角色C视角：15%  ███░░░░░░░░░░░░░░░░
-
-📊 活跃信息差：[N] 个
-- 最长持续信息差：[描述]（已持续 [M] 章）
+视角分布：主角 60% / 角色B 25% / 角色C 15%
+活跃信息差：[N] 个
 ```
 
 
 ### 伏笔健康度检测（--check 扩展）
 
-在 `--check` 模式下，对 `plot-tracker.json` 中的伏笔数据执行健康度检测。
+在 `--check` 模式下，对 `plot-tracker.json` 中的伏笔执行健康度检测，包含三项检测：
+
+1. **伏笔热度管理** — 基于 `heat` 字段（current/trend/lastMentioned/readerAwareness）检测冷却伏笔
+2. **伏笔回收时机** — 基于 `urgency` 和持续章数，按紧急/建议/可持有三级分类
+3. **伏笔链完整性** — 基于 `chain` 字段（parentId/childIds/chainName）检测孤立伏笔
 
 #### 增强后的伏笔数据结构
 
-`plot-tracker.json` 的 foreshadowing 条目支持以下增强字段：
+`plot-tracker.json` 的 foreshadowing 条目增强字段：
 
 ```json
 {
-  "foreshadowing": [
-    {
-      "id": "fs-001",
-      "content": "[伏笔内容]",
-      "plantedChapter": 3,
-      "plantedContext": "[埋设时的上下文摘要]",
-      "status": "planted|hinted|partially_resolved|resolved|abandoned",
-      "urgency": 0.5,
-
-      "heat": {
-        "current": 0.6,
-        "trend": "rising|stable|cooling",
-        "lastMentioned": 12,
-        "mentionCount": 3,
-        "readerAwareness": "high|medium|low"
-      },
-
-      "chain": {
-        "parentId": null,
-        "childIds": ["fs-003", "fs-005"],
-        "relatedIds": ["fs-002"],
-        "chainName": "[伏笔链名称，如「身世之谜」]"
-      },
-
-      "resolution": {
-        "plannedChapter": 25,
-        "plannedMethod": "[计划的回收方式]",
-        "actualChapter": null,
-        "actualMethod": null,
-        "impact": "major|moderate|minor"
-      },
-
-      "hints": [
-        {
-          "chapter": 8,
-          "content": "[提示内容]",
-          "subtlety": "obvious|moderate|subtle"
-        }
-      ]
-    }
-  ]
+  "id": "fs-001",
+  "content": "[伏笔内容]",
+  "plantedChapter": 3,
+  "status": "planted|hinted|partially_resolved|resolved|abandoned",
+  "urgency": 0.5,
+  "heat": { "current": 0.6, "trend": "rising|stable|cooling", "lastMentioned": 12, "readerAwareness": "high|medium|low" },
+  "chain": { "parentId": null, "childIds": ["fs-003"], "chainName": "身世之谜" },
+  "resolution": { "plannedChapter": 25, "plannedMethod": "[回收方式]", "impact": "major|moderate|minor" },
+  "hints": [{ "chapter": 8, "content": "[提示内容]", "subtlety": "obvious|moderate|subtle" }]
 }
 ```
 
-#### 检测 1：伏笔热度管理
+#### 检测输出示例
 
 ```
-🔮 伏笔热度状态
+🔮 伏笔健康度
 ━━━━━━━━━━━━━━━━━━━━
-
 | 伏笔 | 热度 | 趋势 | 上次提及 | 状态 |
 |------|------|------|---------|------|
 | [身世之谜] | 🔥🔥🔥 高 | ↑ 上升 | 第 15 章 | ✅ 健康 |
-| [神秘宝物] | 🔥🔥 中 | → 稳定 | 第 12 章 | ✅ 健康 |
 | [失踪事件] | 🔥 低 | ↓ 冷却 | 第 5 章 | ⚠️ 需要提示 |
 | [预言] | ❄️ 极低 | ↓ 冷却 | 第 2 章 | ❌ 读者可能已遗忘 |
 
-💡 建议：
-- [失踪事件]：在近 2 章内添加一个 subtle 提示
-- [预言]：在近 1 章内添加一个 obvious 提示，或考虑放弃
-```
-
-#### 检测 2：伏笔回收时机
-
-```
 ⏰ 伏笔回收建议
-━━━━━━━━━━━━━━━━━━━━
-
-🔴 紧急回收（紧急度 > 0.8）：
-- [身世之谜]：已持续 20 章，读者期待值极高
-  建议：在第 [N]-[N+3] 章内回收
-  推荐方式：[基于情节的具体建议]
-
-⚠️ 建议回收（紧急度 0.5-0.8）：
-- [神秘宝物]：已持续 12 章，热度中等
-  建议：在第 [M]-[M+5] 章内回收
-
-✅ 可继续持有（紧急度 < 0.5）：
-- [预言]：刚埋设 5 章，可继续持有
-```
-
-#### 检测 3：伏笔链完整性
+  🔴 紧急：[身世之谜] 已持续 20 章，建议第 [N]-[N+3] 章内回收
+  ⚠️ 建议：[神秘宝物] 已持续 12 章，建议第 [M]-[M+5] 章内回收
+  ✅ 可持有：[预言] 刚埋设 5 章
 
-```
-🔗 伏笔链检查
-━━━━━━━━━━━━━━━━━━━━
-
-伏笔链「身世之谜」：
-fs-001（身世暗示）→ fs-003（血脉觉醒）→ fs-005（真相揭示）
-状态：fs-001 ✅ 已提示 → fs-003 🔄 进行中 → fs-005 ⏳ 待回收
-
-伏笔链「远古秘密」：
-fs-002（古籍线索）→ fs-004（遗迹发现）
-状态：fs-002 ✅ 已提示 → fs-004 ⏳ 待回收
-
-⚠️ 孤立伏笔（未关联到任何链）：
-- fs-006（[内容]）— 考虑是否需要关联或放弃
+🔗 伏笔链「身世之谜」：fs-001 ✅ → fs-003 🔄 → fs-005 ⏳
+🔗 伏笔链「远古秘密」：fs-002 ✅ → fs-004 ⏳
+⚠️ 孤立伏笔：fs-006 — 考虑关联或放弃
 ```
 
 ### 模式：创作数据统计（`--stats`）
@@ -491,10 +334,8 @@ fs-002（古籍线索）→ fs-004（遗迹发现）
 
 **数据收集**：
 - 读取所有章节文件（`content/*.md`）
-- 读取 `tasks.md`
-- 读取 `spec/tracking/character-state.json`
-- 读取 `spec/tracking/plot-tracker.json`
-- 读取 `creative-plan.md`
+- 读取 `tasks.md`、`creative-plan.md`
+- 读取 `tracking/character-state.json`、`tracking/plot-tracker.json`
 
 #### 总览面板
 
@@ -502,241 +343,115 @@ fs-002（古籍线索）→ fs-004（遗迹发现）
 📊 创作统计 — [故事名]
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
-📖 总字数：[N] 字
-📝 章节数：已写 [M] / 计划 [K]
+📖 总字数：[N] 字 | 📝 章节：已写 [M] / 计划 [K]
 📈 完成度：▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░░░░ [X]%
-👥 活跃角色：[A] 个
-🔮 活跃伏笔：[B] 个
-📋 待办任务：[C] 个
+👥 活跃角色：[A] 个 | 🔮 活跃伏笔：[B] 个 | 📋 待办：[C] 个
 ```
 
-#### 字数详情
+#### 字数详情与角色
 
 ```
-📝 字数详情
+📝 字数统计
 ━━━━━━━━━━━━━━━━━━━━
-
 每章字数分布：
 第 01 章 ████████████████ 3,200 字
 第 02 章 ██████████████░░ 2,800 字
 第 03 章 ████████████████████ 4,100 字
 ...
 
-统计摘要：
-  平均每章：[N] 字
-  最长章节：第 [X] 章（[N] 字）
-  最短章节：第 [Y] 章（[M] 字）
-  字数标准差：[S] 字
-
-每卷字数：
-  第 1 卷：[N] 字（[M] 章）✅ 已完成
-  第 2 卷：[N] 字（[M] 章）🔄 进行中
-```
+统计：平均 [N] 字/章 | 最长：第[X]章([N]字) | 最短：第[Y]章([M]字)
+每卷：第 1 卷 [N] 字（[M] 章）✅ | 第 2 卷 [N] 字（[M] 章）🔄
 
-#### 角色出场频率
-
-```
-👥 角色出场频率（Top 10）
+👥 角色出场频率（Top 5）
 ━━━━━━━━━━━━━━━━━━━━
+| 角色 | 出场率 | 最近 | 缺席 |
+|------|--------|------|------|
+| [主角] | 100% | 第[K]章 | 0 |
+| [角色A] | 72% | 第[K]章 | 1 |
+| [角色B] | 48% | 第[K]章 | 5 ⚠️ |
 
-| # | 角色 | 出场 | 出场率 | 最近 | 缺席 |
-|---|------|------|--------|------|------|
-| 1 | [主角] | [N]/[M] | 100% | 第[K]章 | 0 |
-| 2 | [角色A] | [N]/[M] | 72% | 第[K]章 | 1 |
-| 3 | [角色B] | [N]/[M] | 48% | 第[K]章 | 5 ⚠️ |
-...
-
-⚠️ 长期缺席角色：
-- [角色C]：10 章未出场
-- [角色D]：8 章未出场
+⚠️ 长期缺席：[角色C] 10 章未出场、[角色D] 8 章未出场
 ```
 
-#### 内容构成分析
+#### 内容构成与伏笔状态
 
 ```
 📊 内容构成（全书平均）
 ━━━━━━━━━━━━━━━━━━━━
-
-对话：[X]% ████████░░
-描写：[Y]% ██████░░░░
-叙述：[Z]% ████░░░░░░
-动作：[W]% ███░░░░░░░
-
-参考范围（网文）：
-  对话 30-40% | 描写 20-30% | 叙述 15-25% | 动作 15-25%
-
+对话 [X]% | 描写 [Y]% | 叙述 [Z]% | 动作 [W]%
+参考范围：对话 30-40% | 描写 20-30% | 叙述 15-25% | 动作 15-25%
 状态：[✅ 均衡 / ⚠️ 偏向描述]
-```
-
-#### 伏笔状态汇总
-
-```
-🔮 伏笔状态
-━━━━━━━━━━━━━━━━━━━━
-
-总计：[N] 个
-  已回收：[A] 个 ✅
-  进行中：[B] 个 🔄
-  待回收：[C] 个 ⏳
-  已放弃：[D] 个 ❌
 
+🔮 伏笔状态：[N]个（已回收[A] ✅ | 进行中[B] 🔄 | 待回收[C] ⏳）
 回收率：[X]%（建议 > 80%）
+紧急伏笔：[伏笔内容] — 紧急度 [X]，持续 [N] 章
 
-紧急伏笔（紧急度 > 0.8）：
-1. [伏笔内容] — 紧急度 [X]，持续 [N] 章
-2. [伏笔内容] — 紧急度 [Y]，持续 [M] 章
-```
-
-#### 情节线进度
-
-```
 📋 情节线进度
 ━━━━━━━━━━━━━━━━━━━━
-
-主线：[名称]
-▓▓▓▓▓▓▓▓▓▓▓▓░░░░░░░░ 60%
-
-支线 1：[名称]
-▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░ 90%
-
-支线 2：[名称]
-▓▓▓▓▓▓░░░░░░░░░░░░░░ 30%
+主线 [名称] ▓▓▓▓▓▓▓▓▓▓▓▓░░░░░░░░ 60%
+支线1 [名称] ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░ 90%
+支线2 [名称] ▓▓▓▓▓▓░░░░░░░░░░░░░░ 30%
 ```
 
 ### 节奏健康度检测（--check 扩展）
 
-当使用 `--check` 参数时，除了基础一致性验证外，还执行节奏健康度检测：
+`--check` 时执行四项节奏检测：
 
-#### 检测 1：节奏单一性
+1. **节奏单一性** — 分析最近 N 章情绪强度分布（健康：高/中/低各占 20%-50%；偏单一：某项 >60%；严重：>80% 或连续 5+ 章同强度）
+2. **爽点间隔** — 检测爽点分布（正常 ≤3 章；偏长 4-5 章；过长 >5 章）
+3. **钩子连续性** — 检查最近章节是否有钩子（悬念/反转/信息/情感），标记无钩子章节
+4. **情绪曲线合理性** — 基于张弛有度原则，检测连续高强度导致的读者疲劳
 
-分析最近 N 章的情绪节奏（高/中/低），检测是否过于单一：
+#### 检测输出示例
 
 ```
 📊 节奏分布（最近 10 章）
 ━━━━━━━━━━━━━━━━━━━━
-高强度：[N] 章（[X]%）
-中强度：[N] 章（[X]%）
-低强度：[N] 章（[X]%）
-
-判定：
-✅ 节奏多样（高/中/低分布均匀）
-⚠️ 节奏偏单一（连续 [N] 章 [高/中/低] 强度）
-❌ 节奏严重单一（[X]% 章节为同一强度）
-```
-
-**判定标准**：
-- ✅ 健康：高/中/低各占 20%-50%
-- ⚠️ 偏单一：某一强度占比 > 60%
-- ❌ 严重单一：某一强度占比 > 80%，或连续 5+ 章同一强度
-
-#### 检测 2：爽点间隔
-
-检查最近章节中爽点的分布间隔：
-
-```
-⭐ 爽点间隔检测
-━━━━━━━━━━━━━━━━━━━━
-最近爽点：第 [N] 章（[类型]）
-当前间隔：[M] 章无爽点
+高强度：[N] 章（[X]%）| 中强度：[N] 章（[X]%）| 低强度：[N] 章（[X]%）
+判定：[✅ 节奏多样 / ⚠️ 偏单一 / ❌ 严重单一]
 
-判定：
-✅ 间隔正常（≤ 3 章）
-⚠️ 间隔偏长（4-5 章）— 建议在下一章安排爽点
-❌ 间隔过长（> 5 章）— 读者流失风险！
-```
+⭐ 爽点间隔：最近爽点第 [N] 章，当前间隔 [M] 章 [✅/⚠️/❌]
 
-#### 检测 3：钩子连续性
+🪝 钩子连续性（最近 5 章）：
+第[A]章 ✅ 悬念 | 第[B]章 ✅ 反转 | 第[C]章 ❌ 无钩子 | 第[D]章 ✅ 信息 | 第[E]章 ✅ 情感
 
-检查最近章节的钩子是否连续：
+📈 情绪曲线：
+第[A]章 ████████░░ 高 → 第[B]章 ██████████ 高 → 第[C]章 █████████░ 高
+⚠️ 连续 3 章高强度，建议下一章安排过渡/日常
 
-```
-🪝 钩子连续性
+🏥 综合节奏健康度
 ━━━━━━━━━━━━━━━━━━━━
-最近 5 章钩子状态：
-第 [A] 章：✅ 悬念 ⭐⭐⭐
-第 [B] 章：✅ 反转 ⭐⭐⭐⭐
-第 [C] 章：❌ 无钩子
-第 [D] 章：✅ 信息 ⭐⭐
-第 [E] 章：✅ 情感 ⭐⭐⭐
-
-判定：
-⚠️ 第 [C] 章无钩子，建议补充
-```
-
-#### 检测 4：情绪曲线合理性
-
-基于张弛有度原则，检查情绪曲线是否合理：
-
-```
-📈 情绪曲线
-━━━━━━━━━━━━━━━━━━━━
-第 [A] 章 ████████░░ 高
-第 [B] 章 ██████████ 高
-第 [C] 章 █████████░ 高
-第 [D] 章 ████████░░ 高
-第 [E] 章 ███████░░░ 中高
-
-⚠️ 警告：连续 4 章高强度，读者可能疲劳
-💡 建议：下一章安排过渡/日常/角色互动
-```
-
-#### 综合节奏健康度评分
-
-```
-🏥 节奏健康度
-━━━━━━━━━━━━━━━━━━━━
-节奏多样性：[✅/⚠️/❌]
-爽点间隔  ：[✅/⚠️/❌]
-钩子连续性：[✅/⚠️/❌]
-情绪曲线  ：[✅/⚠️/❌]
+节奏多样性：[✅/⚠️/❌]  高[X]% 中[Y]% 低[Z]%
+爽点间隔  ：[✅/⚠️/❌]  当前间隔 [M] 章
+钩子连续性：[✅/⚠️/❌]  最近 5 章中 [N] 章有钩子
+情绪曲线  ：[✅/⚠️/❌]  连续 [K] 章高强度
 
 综合评定：[健康 / 需关注 / 需改进]
 ```
 
 ---
 
-### 数据一致性验证
+### 数据一致性验证与深度检查
 
-基础检查（默认执行）：
-- plot-tracker.json 与 creative-plan.md 的一致性
-- timeline.json 的时间逻辑
-- relationships.json 的关系冲突
-- character-state.json 的位置合理性
+**基础检查**（默认执行）：验证 plot-tracker / timeline / relationships / character-state 的一致性、时间逻辑、关系冲突、位置合理性。
 
-### 深度验证模式 (--check)
+**深度验证 (--check)**：在基础检查之上，增加角色深度验证（名称一致性、称呼规则、行为人设匹配），基于 `validation-rules.json`。支持 `--volume vol-XX` 限定范围。MCP 可用时优先调用 `stats_consistency`。
 
-当使用 `--check` 参数时，执行程序化的深度验证：
-
-#### --volume 范围限定
+#### 内部任务流程（自动执行）
 
-支持 `--volume vol-XX` 限定检查范围：
-- 带 --volume：只检查该卷的 tracking 数据和对应章节
-- 不带 --volume：检查当前卷（分片模式）或全部（单文件模式）
+```
+Phase 1: 基础验证 [并行]
+  T001-T004: 情节一致性 / 时间线验证 / 关系验证 / 世界观验证
 
-**MCP 优先：** 如果 MCP 可用，调用 `stats_consistency` 获取一致性报告，避免逐文件扫描。
+Phase 2: 角色深度验证
+  T005: 加载 validation-rules.json
+  T006-T007: 扫描章节角色名称，对比 character-state.json
+  T008-T009: 检查称呼规则，验证角色行为人设
 
-#### 内部任务流程（自动执行）
-```markdown
-# Phase 1: 基础验证 [并行执行]
-- [x] T001 [P] 执行情节一致性检查 (plot-check逻辑)
-- [x] T002 [P] 执行时间线验证 (timeline逻辑)
-- [x] T003 [P] 执行关系验证 (relations逻辑)
-- [x] T004 [P] 执行世界观验证 (world-check逻辑)
-
-# Phase 2: 角色深度验证
-- [x] T005 加载validation-rules.json验证规则
-- [x] T006 扫描所有章节中的角色名称
-- [x] T007 对比character-state.json验证名称一致性
-- [x] T008 检查称呼是否符合relationships.json
-- [x] T009 验证角色行为是否符合人设
-
-# Phase 3: 生成综合报告
-- [x] T010 汇总所有验证结果
-- [x] T011 标记问题严重程度
-- [x] T012 生成修复建议
+Phase 3: 生成综合报告
+  T010-T012: 汇总结果 → 标记严重程度 → 生成修复建议
 ```
 
-#### 验证报告示例
 ```
 📊 深度验证报告
 ━━━━━━━━━━━━━━━━━━━━━━━━━━
@@ -747,32 +462,13 @@ fs-002（古籍线索）→ fs-004（遗迹发现）
 2. [中] 第7章: 沈玉卿称呼错误，用了"师兄"
 3. [低] 第12章: 时间线跳跃未说明
 
-🔧 可自动修复: 2个
-📝 需人工确认: 1个
-
-运行 /track --fix 自动修复简单问题
+🔧 可自动修复: 2个 → 运行 /track --fix
 ```
 
 ### 自动修复模式 (--fix)
 
-当使用 `--fix` 参数时，基于验证报告自动修复：
-
-#### 自动修复范围
-1. **角色名称错误** - 根据validation-rules.json自动替换
-2. **固定称呼错误** - 自动修正为正确称呼
-3. **简单拼写错误** - 修正明显的typo
+基于验证报告自动修复：角色名称错误、固定称呼错误、简单拼写错误（根据 validation-rules.json）。不可自动修复的问题标记为需人工处理。修复后建议重新运行 `--check` 验证。
 
-#### 修复流程
-```markdown
-# 内部修复任务（自动执行）
-- [x] F001 读取验证报告中的问题列表
-- [x] F002 [P] 修复第3章角色名称错误
-- [x] F003 [P] 修复第7章称呼错误
-- [x] F004 生成修复报告
-- [x] F005 更新追踪文件
-```
-
-#### 修复报告示例
 ```
 🔧 自动修复报告
 ━━━━━━━━━━━━━━━━━━━
@@ -788,26 +484,8 @@ fs-002（古籍线索）→ fs-004（遗迹发现）
 
 ### 智能分析与建议
 
-1. **进度分析**
-   - 对比计划进度和实际进度
-   - 预测完成时间
-   - 识别写作瓶颈
-
-2. **内容分析**
-   - 伏笔覆盖率（已埋设/已回收）
-   - 角色出场频率
-   - 冲突强度曲线
+根据追踪数据自动分析：进度对比（计划 vs 实际）、完成时间预测、伏笔覆盖率、角色出场频率、冲突强度曲线。基于分析结果提供下一步写作重点、待处理伏笔、关系线和时间线调整建议。
 
-3. **行动建议**
-   根据分析结果提供：
-   - 下一步写作重点
-   - 需要处理的伏笔
-   - 建议加强的关系线
-   - 时间线调整建议
-
-### 可视化报告
-
-生成结构化报告：
 ```
 📊 综合追踪报告
 ━━━━━━━━━━━━━━━━━━━━━━━━━━
@@ -821,27 +499,23 @@ fs-002（古籍线索）→ fs-004（遗迹发现）
 ⚠️ 需要关注：
 - 角色B已5章未出场
 - 支线剧情进度滞后
-- 第45章的时间跳跃需要说明
 ```
 
 ### 数据导出
 
-支持导出追踪数据为：
-- Markdown 格式的完整报告
-- JSON 格式的原始数据
-- 可视化图表（关系图、时间轴）
+支持导出为 Markdown 报告、JSON 原始数据、可视化图表（关系图、时间轴）。
 
 ---
 
 ### 批量同步模式 (--sync)
 
-当使用 `--sync` 参数时，批量扫描并同步多个章节的 tracking 数据：
+批量扫描并同步多个章节的 tracking 数据。适用于连续写了多章但忘记更新 tracking、导入外部内容、数据严重不同步等场景。
 
 #### 增量同步（--sync --incremental）
 
-不扫描所有章节，只处理上次同步后的新章节：
+只处理上次同步后的新章节：
 
-1. 读取 `spec/tracking/tracking-log.md` 最后一条记录，获取 last_sync_chapter
+1. 读取 `tracking/tracking-log.md` 最后一条记录，获取 last_sync_chapter
 2. 扫描 `stories/[current]/content/` 中编号 > last_sync_chapter 的章节
 3. 只对这些新章节执行 tracking 更新
 4. 更新 tracking-log.md 记录本次同步
@@ -863,16 +537,9 @@ fs-002（古籍线索）→ fs-004（遗迹发现）
 ```
 📊 同步差异检测
 ━━━━━━━━━━━━━━━━━━━━
-已写章节：[N] 章
-tracking 最后更新：第 [M] 章
-
-需要同步的章节：第 [M+1] - [N] 章（共 [K] 章）
-
-差异类型：
-- 角色状态：[X] 处需更新
-- 关系网络：[Y] 处需更新
-- 情节进度：[Z] 处需更新
-- 时间线：[W] 处需更新
+已写章节：[N] 章 | tracking 最后更新：第 [M] 章
+需要同步：第 [M+1]-[N] 章（共 [K] 章）
+差异：角色 [X] 处 | 关系 [Y] 处 | 情节 [Z] 处 | 时间线 [W] 处
 ```
 
 ##### Step 2: 批量分析
@@ -924,17 +591,17 @@ tracking 最后更新：第 [M] 章
 
 读取 tracking 数据时按以下优先级：
 1. **MCP 查询（优先）**：调用对应 MCP 工具获取精确数据
-2. **分片 JSON（次优）**：读取 `spec/tracking/volumes/[currentVolume]/` 下的分片文件
-3. **单文件 JSON（兜底）**：读取 `spec/tracking/` 下的单文件
+2. **分片 JSON（次优）**：读取 `tracking/volumes/[currentVolume]/` 下的分片文件
+3. **单文件 JSON（兜底）**：读取 `tracking/` 下的单文件
 
 **分片模式写入：**
 1. 确定当前章节属于哪个卷（从 volume-summaries.json 的 chapters 范围判断）
-2. 更新该卷的分片文件（如 `spec/tracking/volumes/vol-03/character-state.json`）
+2. 更新该卷的分片文件（如 `tracking/volumes/vol-03/character-state.json`）
 3. 同步更新全局摘要文件（如 characters-summary.json 的 activeCount）
 4. 如果 MCP 可用，调用 `sync_from_json` 同步到 SQLite
 
 **单文件模式写入：**
-- 直接更新 `spec/tracking/` 下的文件（现有逻辑）
+- 直接更新 `tracking/` 下的文件（现有逻辑）
 
 ---
 
@@ -952,7 +619,7 @@ tracking 最后更新：第 [M] 章
 
 ### 迁移流程
 
-#### 阶段 1：检测与备份
+**阶段 1：检测与备份**
 
 1. 运行脚本检测当前状态：
 ```powershell
@@ -965,105 +632,63 @@ powershell -File {SCRIPT_DIR}/migrate-tracking.ps1 -Mode check -Json
 powershell -File {SCRIPT_DIR}/migrate-tracking.ps1 -Mode backup -Json
 ```
 
-#### 阶段 2：确定卷边界
+**阶段 2：确定卷边界**
+- `--auto`：从 `plot-tracker.json` 的 `checkpoints.volumeEnd` 获取，无则按 100 章一卷
+- `--volumes`：解析用户提供的边界字符串，验证连续性
+- 交互式（默认）：分析情节弧线建议卷边界，用户确认
 
-**--auto 模式：**
-- 读取 `plot-tracker.json` 的 `checkpoints.volumeEnd` 确定已有的卷边界
-- 如果没有卷边界信息，按每 100 章一卷自动划分
-- 最后一卷可以不满 100 章
-
-**--volumes 模式：**
-- 解析用户提供的卷边界字符串，如 `"1-100,101-250,251-400"`
-- 验证边界连续且覆盖所有已写章节
-
-**交互式模式（默认）：**
-- 读取 `plot-tracker.json` 和 `creative-plan.md`
-- 分析情节弧线，建议合理的卷边界
-- 向用户展示建议并确认
-
-#### 阶段 3：数据拆分
+**阶段 3：数据拆分**
 
 运行脚本创建目录结构：
 ```powershell
 powershell -File {SCRIPT_DIR}/migrate-tracking.ps1 -Mode auto -Json
 ```
 
-然后按卷边界拆分每个 tracking 文件：
-
-**character-state.json 拆分规则：**
-- `protagonist` 复制到每个卷（状态更新为该卷末尾的状态）
-- `supportingCharacters` 按 `lastSeen.chapter` 分配到对应卷
-- `appearanceTracking` 按 `chapter` 分配到对应卷
-- `characterGroups` 每卷独立维护
+按卷边界拆分 character-state / timeline / relationships / plot-tracker 四个文件：
+- 拆分原则：按 chapter 分配数据到对应卷，跨卷数据保留引用
+- 写入 `tracking/volumes/vol-XX/`
 
-**timeline.json 拆分规则：**
-- `events` 按 `chapter` 分配到对应卷
-- `storyTime` 每卷记录该卷的时间范围
-- `parallelEvents` 按时间点分配
-- `anomalies` 分配到发现该异常的卷
+拆分规则概要：
+| 文件 | 拆分方式 |
+|------|---------|
+| character-state.json | protagonist 复制到每卷（状态为卷末）；supportingCharacters 按 lastSeen.chapter 分配；appearanceTracking 按 chapter 分配 |
+| timeline.json | events 按 chapter 分配；storyTime 每卷记录时间范围；parallelEvents 按时间点分配 |
+| relationships.json | characters 复制到每卷（只保留活跃角色）；history 按 chapter 分配；factions 复制到每卷（状态为卷末） |
+| plot-tracker.json | foreshadowing 按 planted.chapter 分配（跨卷未解决伏笔保留引用）；plotlines 每卷记录进展；checkpoints 按卷分配 |
 
-**relationships.json 拆分规则：**
-- `characters` 复制到每个卷（只保留该卷活跃的角色）
-- `history` 按 `chapter` 分配到对应卷
-- `factions` 复制到每个卷（状态更新为该卷末尾）
+**阶段 4：生成全局摘要**
+- 生成 4 个摘要文件到 `tracking/summary/`：
+  - characters-summary.json — 活跃/归档角色统计
+  - plot-summary.json — 未解决伏笔汇总、回收统计
+  - timeline-summary.json — 每卷关键里程碑、故事时间范围
+  - volume-summaries.json — 每卷摘要（id, title, chapters, wordCount, keyEvents, unresolvedPlots, newCharacters, exitedCharacters）
 
-**plot-tracker.json 拆分规则：**
-- `foreshadowing` 按 `planted.chapter` 分配到对应卷
-- 跨卷未解决的伏笔在后续卷中保留引用
-- `plotlines` 每卷记录该卷的进展
-- `checkpoints` 按卷分配
+**阶段 5：初始化 SQLite**（MCP 可用时）
+- 调用 `sync_from_json` 导入 + `sync_status` 验证
 
-将拆分后的数据写入 `spec/tracking/volumes/vol-XX/` 对应文件。
-
-#### 阶段 4：生成全局摘要
-
-基于拆分后的数据，生成 4 个摘要文件到 `spec/tracking/summary/`：
-
-**characters-summary.json：**
-- 遍历所有卷的 character-state.json
-- active：最后一卷中仍活跃的角色
-- archived：已退场/死亡的角色
-- 统计 totalCount 和 activeCount
-
-**plot-summary.json：**
-- 汇总所有卷的伏笔状态
-- unresolvedForeshadowing：所有 status=active 的伏笔
-- resolvedCount / totalPlanted 统计
-
-**timeline-summary.json：**
-- 提取每卷的关键里程碑事件
-- 记录故事时间范围
-
-**volume-summaries.json：**
-- 每卷生成一条摘要记录
-- 包含：id, title, chapters, wordCount, keyEvents, unresolvedPlots, newCharacters, exitedCharacters
-
-#### 阶段 5：初始化 SQLite（如果 MCP 可用）
-
-如果检测到 novelws-mcp 已安装：
-- 调用 MCP 工具 `sync_from_json` 将分片数据导入 SQLite
-- 调用 `sync_status` 验证同步结果
-
-如果 MCP 不可用，跳过此步骤。
-
-#### 阶段 6：验证与清理
+**阶段 6：验证与清理**
 
 1. 验证每个卷的文件都存在且 JSON 格式正确
 2. 验证摘要文件的统计数据与分卷数据一致
 3. 确认无误后，删除原始单文件（备份已保存）
 4. 输出迁移报告：
-   - 迁移前：单文件模式，总大小 XXX KB
-   - 迁移后：N 卷分片，每卷平均 XX KB
-   - 备份位置：spec/tracking/backup/YYYYMMDD-HHMMSS/
+
+```
+📦 分片迁移报告
+━━━━━━━━━━━━━━━━━━━
+迁移前：单文件模式，总大小 XXX KB
+迁移后：N 卷分片，每卷平均 XX KB
+备份位置：tracking/backup/YYYYMMDD-HHMMSS/
+```
 
 ### 错误处理
 
-- 任何步骤失败时，提示用户从备份恢复：
-  ```
-  迁移失败。备份文件在 spec/tracking/backup/YYYYMMDD-HHMMSS/
-  可以手动将备份文件复制回 spec/tracking/ 恢复原状。
-  ```
-- 不自动删除备份，由用户手动清理
+任何步骤失败时，提示用户从备份恢复：
+```
+迁移失败。备份文件在 tracking/backup/YYYYMMDD-HHMMSS/
+可以手动将备份文件复制回 tracking/ 恢复原状。
+```
+不自动删除备份，由用户手动清理。
 
 ---