wq-rules

Imported from wq1131173682/wqsumeru (skills/wq-rules/SKILL.md). Install upstream with npx skills add wq1131173682/wqsumeru --skill wq-rules. Copyright stays with the author.

WQ 写作全局约束规则

所有 WQ 写作 Skill 必须遵守以下规则。本文档是唯一全局约束源。

第一部分：系统架构

技能清单

调用链路

用户需求 → worldbuilder → scan(可选,→trends.md + benchmarks/ + writing-guide.md)
                        → topic(→plan.md, 可读取trends.md)
                        → outline(→outline.md + chapters.json + characters/)
                        → intro.md + creative-anchors.md (worldbuilder 内置)
                         → write(→chapters/*.md, 子Agent并行, 可注入writing-guide.md)
                         → review(→issues.md + fix-plan.json, 子Agent并行审查)
                         → write(修复重写, 读 fix-plan.json)
                         → polish(→chapters/*.md, 子Agent并行润色)
                         → score(可选,→.sumeru/score/, 输出 deficientChapters)
                          → revise(条件,→.sumeru/revise/, 消费 deficientChapters 收敛式修稿)
                         → finalize(→publish/)

独立调用：每个 skill 都可以脱离 worldbuilder 单独启动，执行自举协议。

状态机

项目状态流转

init →scan(可选) →topic →outline →intro →anchor →write →review →fix →polish →[score?] →[revise?] →finalize →build/release

> `[score?]` 为可选中间节点：worldbuilder 编排时可选择在 polish 完成后、finalize 前插入评分阶段；用户也可手动调用 `/wq-score` 触发。评分阶段不修改章节文件，仅输出评估报告（含 `deficientChapters` 字段）。
>
> `[revise?]` 为条件中间节点：score 产出 `deficientChapters`（低于等级阈值的章节）后才插入，由 `wq-revise` 执行评分驱动·收敛式修稿。revise 自带硬收敛（每章默认 2 次重试、全局 3 轮硬停），**低分回头改的唯一合法入口是 revise，禁止 `score → write` 回环**。无低分章节则跳过直接进 finalize。
>
> 旧项目需先执行 `wq-migrate` 完成迁移规整（参见 `wq-migrate/SKILL.md`），再进入 `init` 阶段。

章节状态流转

planned →drafted →reviewed →fixed →polished →finalized →exported
                              →                              │(反审未通过时回退)
                              └──────────────────

推进规则

状态字段语义对照

文件索引

.sumeru/（中间数据）

旧路径兼容（只读）

第二部分：子Agent并行处理规则

批次间串行摘要

每批子Agent完成后，父Agent生成"实际摘要"（≤300字），作为下一批 context pack 的输入。context pack 中只保留最近3 批摘要，更早的合并为一行概述。 摘要格式（纯事实列表）：

## 批次摘要: 第1-6章
- 事件：主角觉醒系统(001)、通过宗门考核(003)、击败外门弟子(005)
- 人物：主角练气三层→五层，苏瑾轻伤恢复，赵无极首次出场
- 道具：黑色残片归主角，回春丹消耗
- 伏笔：v1黑衣人身份(mentioned)，v2残片来历(active)
- 情绪：压抑→突破→暗爆

存储位置（< 150 章）：.sumeru/continuity/batch-summaries/batch-001.md、batch-002.md... 存储位置（≥ 150 章，分卷模式）：.sumeru/volumes/vol-N/continuity/batch-summaries/batch-001.md...

卷边界重置：卷切换时执行"软重置"——最后1批摘要 + 卷级总结（~500字）保留到新卷 batch-summaries 第一项，更早的摘要归档到 vol-N-archived/。

第三部分：子Agent职责边界

核心原则：子Agent直接写入本组正文章节文件，返回精简状态标记；父Agent负责备份、状态同步、缓存刷新和汇总。

父Agent职责

子Agent职责

第四部分：Context Pack 格式与生成规则

为减少同批次内容重复，context pack 拆为 2 个文件：

子Agent先读共享上下文，再读本组任务卡，两者合并作为完整context。

一、通用共享上下文格式（v1.4.9 补充预算约束）

# Shared Context: {task} (batch {N})

## Project Brief（≤50字）
题材、平台、字数范围、整体风格。
## Current Volume（≤100字）
本卷目标、当前冲突、卷级反转、阶段情绪。
## Relevant Characters（≤300字）
仅列本批次涉及的 3-5 个角色：当前状态、目标、关系、语言风格。
## Relevant World & Glossary（≤200字）
仅列本批次会用到的地点、组织、功法、道具、禁用变体。
## Continuity State（≤200字）
上一章结尾、关键道具状态、未回收伏笔、时间线位置。
## Creative Strategy（≤200字）
创意目标、要避开的套路、情绪节拍变化、读者记忆点。
## Batch Summary（预算硬限）
最近 3 批摘要，每批 ≤150 字。超出的旧摘要不写入 context pack（卷切换 handoff 摘要保留 1 条）。
## Output Requirements
**文件路径（必须明确写出，子Agent 按此路径写入）**：
- 第X章 → `chapters/001-标题.md`
- 第Y章 → `chapters/002-标题.md`
- ...
**状态更新**：由父Agent执行，子Agent 不碰状态文件。
## Opening & Style Diversity
- 同一批次各章开场方式必须不同
- 同一批次各章结尾钩子句式必须不同
- 同一章内连续超过 5 句完整主谓宾结构 → 必须插入破碎句/口语短句
## ⚠️ 本批次禁止项（有发现时注入，v1.4.8）
- 具体禁止项（来自批次反例扫描）

预算原则：context pack 总字符数应 ≤ 2000 字（约 2500 tokens），为子 Agent 留出充足输出预算。以上各字段字数上限为硬性约束，父 Agent 生成时必须遵守。长章节（目标 >2500 字）场景下，每子 Agent 最多分配 1-2 章，确保单章输出预算 ≥ 4000 tokens。

二、通用任务卡格式

# Task Cards: {范围}

## Chapter Cards
### 第{N}章「标题」
- purpose: ...
- events: ...（≥3个具体事件）
- openingHook: 本章开场方式（可执行的场景描述）
- acceptanceCriteria: ...
- creativeGoal: ...
- emotionalBeat: ...

## 本章执行提醒（≥3 条）
具体可执行的过程提醒

二·五、Context Pack 基准缓存（v1.5.0 新增）

问题：write/polish/revise/review 四个技能各自生成 context pack，但 Project Brief、Characters、World、Continuity 完全相同，每次都重新读取和写入，浪费 ~30% 读取时间。

解决：生成一次共享基准文件 shared-base.md，各技能只追加自己特有的部分。

基准文件

路径：.sumeru/cache/shared-base.md

内容（4 个技能共用）：

# Shared Base Context
> 由父Agent生成，所有技能 context pack 的基础层。各技能在此之上追加专用部分。
> 生成时间：{timestamp} | 章节范围：{range}

## Project Brief（≤50字）
{题材、平台、字数范围、整体风格}

## Relevant Characters（≤300字）
{本批次涉及的 3-5 个角色状态}

## Relevant World（≤200字）
{本批次会用到的地点/组织/功法/道具}

## Continuity State（≤200字）
{上一章结尾、关键道具、未回收伏笔、时间线位置}

## Batch Summary（≤450字）
{最近 3 批摘要，每批 ≤150 字}

各技能追加部分

刷新规则

• 同一技能连续批次（如 write 第1-3章后写第4-6章）：复用 shared-base.md，只更新 Batch Summary 和 Continuity State
• 跨技能切换（write → review → polish）：不复用，各自生成新的 shared-base.md
• 章节范围变更 > 50%：重新生成 shared-base.md

Token 节省估算

四、文件位置

所有 context pack 写入 .sumeru/context-packs/：

• shared-{task}.md：共享上下文
• cards-{范围}.md：本组任务卡

五、分卷数据源作用域规则（≥ 150 章时强制）

当项目章节数 ≥ 150（volumes/ 目录存在时），context pack 各字段的数据源必须按以下规则限定作用域：

跨卷引用：仅当 outlines/chapters.json 目标章节的 protectedElements 或伏笔涉及跨卷依赖表中注册的项时，才从 cross-volume/dependency-table.md 做一次额外查询。不预加载全量。

第五部分：子Agent输出状态标记

每个子Agent写入的章节文件首行必须包含状态标记（供重启恢复），同时向父Agent返回同一标记（供实时状态同步）。

格式

<!-- SUMERU_STATUS: chapter=037, status=drafted, state_diff={"location_change":{"苏瑾":"北域冰原"},"state_change":{"苏瑾":"minor_injury"},"item_change":{"黑色残片":"acquired"}}, char_update={"苏瑾":{"status":"minor_injury","location":"北域冰原"},"主角":{"status":"healthy","buff":"龙血狂暴","remaining":"3天"}}, plot_update={"foreshadowing":{"v3":"黑衣人身份暗示推进"}}, batch=002, timestamp=2026-05-18T10:30:00Z -->

字段说明

state_diff 分类

各分类键可选，只包含本章有变化的分类。state_diff 必须是合法JSON 单行。

关键约束

• 状态标记必须在输出第一行
• 标记缺失、JSON 不合法、章节号不匹配时，不得更新状态文件

父Agent处理流程

1. 提取每章的<!-- SUMERU_STATUS --> 标记
2. 解析 state_diff 更新 .sumeru/continuity/consistency-rules.json
3. 解析 char_update 更新人物状态
4. 依据 status 写入 .sumeru/status.json
5. 重启后扫描 chapters/*.md 标记即可重建状态

第六部分：独立调用自举协议

任何 Skill 单独启动时必须执行：

1. 定位项目：从当前目录向上查找 .sumeru/project.json / plan.md / outline.md / chapters/ / outlines/
2. 识别版本：存在.sumeru/project.json 按新协议，否则进入兼容模式
3. 最小初始化：缺配置时根据已有文件生成最小配置
4. 补齐目录：按需创建 .sumeru/cache/ / context-packs/ / continuity/ / issues.md
5. 兼容输入：旧版.sumeru/outline/chapter-outlines.json 只读兼容
6. 刷新缓存：相关 cache 缺失或过期时生成最小摘要
7. 生成 context pack：缺 context pack 时生成临时 pack
8. 执行并回写：更新 .sumeru/status.json、cache、issue 文件
9. 记录变更：追加到 .sumeru/changelog.md 和.sumeru/decisions.md

Canonical 路径

旧路径兼容策略

原则：旧路径只读兼容，新写入一律使用canonical 路径。

迁移规则：

1. 读取旧路径时，先检查 canonical 路径是否存在
2. canonical 路径存在 → 直接使用 canonical 路径
3. canonical 路径不存在 + 旧路径存在 → 读取旧路径，写入时使用 canonical 路径
4. 两者都不存在 → 按新协议创建

独立调用原则

• 不要求先运行 worldbuilder
• 能从现有文件推断的信息不重复询问
• 缺信息但不阻塞任务时用合理默认值
• 不因缓存/context pack 缺失而失责

第六点五部分：标点符号规范

全局标点规范，所有 Skill 在正文写作、润色、审查时必须遵守。脚本检测见 anti-ai-scan.py（破折号密度/省略号格式/感叹号叠用）和 format-validator.py（重复标点/中英文混排/标点空格/引号闭合/书名号/括号格式/省略号格式/破折号格式）。

一、破折号（——）使用规范

—— 只用于需要制造停顿感或意外感的场景：

• 对话中突然中断："你要是敢——"他没说完。
• 揭示意外发现：他推开门——屋里空无一人。
• 话题突转：正要动手——门外传来一阵脚步声。

以下场景不用 ——：

• 简单承接（用 ，）：他看了一眼天空——是蓝色的。 → 他看了一眼天空，是蓝色的。
• 并列分句（用 ，或 ；）：北域极寒——妖兽横行——散修聚集。 → 北域极寒，妖兽横行，散修聚集。
• 平铺直叙的解释（用 ，或另起一句）：他找到了一本书——上面写着心法。 → 他找到了一本书，上面写着心法。

判断标准：删掉 —— 后，如果前后两句用 ， 连接读起来也顺，就不该用 ——。只有当你希望读者在这个位置"停一下"的时候，才用 ——。

二、省略号（……）使用规范

• 标准格式：……（两个 … 组成），不得使用 ...（英文）或单个 …
• …… 后不得加句号（省略号已含句末功能）：……。 → ……
• …… 用于话语中断、未尽之言、沉默停顿

三、感叹号/问号使用规范

• 叠用精简：！！！ → ！，？？？ → ？
• 混合叠用：！？ / ？！ → 根据语境保留一种
• 感叹号密度：≥3次/千字触发警告，AI 写作通过堆叠感叹号制造虚假戏剧感

四、中英文标点混排

• 中文正文中不得出现英文标点：, → ，、. → 。、! → ！、? → ？、: → ：、; → ；
• 例外：数字小数点（3.14）、英文缩写（Mr.）、URL
• 检测方式：中文标点前后有中文字符时判定为混排

五、标点前后空格

• 中文标点前不得有空格：你好 ， → 你好，
• 中文标点后不得有连续 2 个以上空格

六、引号闭合

• 中文双引号 "" 和直角引号 「」 必须成对出现
• 引号数量为奇数 → 报告未闭合
• 嵌套规则：外层 ""，内层 「」

七、书名号《》规范

• 书名/篇名/影视/歌曲 → 《》
• 必须成对出现，不得使用英文 <>

八、括号（）规范

• 中文正文 → （），英文 () → 替换为 （）
• 必须成对闭合

九、顿号与逗号边界

• 并列词语（≤3字）→ 用 、：刀、剑、枪
• 并列分句（>3字/含谓语）→ 用 ， 或 ；

十、脚本检测阈值

阈值配置文件：skills/wq-review/config/anti-ai-thresholds.json

第七部分：项目配置Schema

{
  "schemaVersion": 1,
  "title": "未命名作品",
  "genre": "玄幻",
  "targetPlatform": "番茄",
  "audience": "男频",
  "plannedWords": 800000,
  "plannedChapters": 300,
  "chapterWordRange": [2000, 3000],
  "style": "快节奏爽文",
  "tone": "热血",
  "currentStage": "outline",
  "outputLevel": "quiet",
  "volumeCount": 0,
  "currentVolume": "",
  "volumes": {},
  "createdAt": "2026-05-16T00:00:00Z",
  "updatedAt": "2026-05-16T00:00:00Z"
}

volumeCount：分卷数。0 或缺失 = 扁平模式。≥ 2 时启用分卷隔离。 currentVolume：当前活跃卷 ID（如 "vol-003"）。扁平模式下为空字符串。 volumes：卷详情映射。格式见第十五部分·四。volumes[vol-N].status 取值：planned / active / completed / archived。

阶段状态： pending / in_progress / blocked / completed / skipped

章节状态： planned / drafted / reviewed / fixed / polished / finalized / exported

修复后经反审验证通过进入 fixed；润色发现逻辑硬伤时触发反审验证。

consistency-rules.json 格式

由父Agent从每章的 SUMERU_STATUS 解析合并生成，写入 .sumeru/continuity/consistency-rules.json：

{
  "characters": {
    "苏瑾": { "status": "minor_injury", "location": "北域冰原" }
  },
  "items": {
    "黑色残片": "acquired"
  },
  "foreshadowing": {
    "v3": { "status": "mentioned", "last_mentioned": 42 }
  },
  "timeline": {
    "current_location": "北域冰原",
    "current_chapter": 42
  }
}

更新规则 每批次完成后，父Agent汇总本批所有子Agent的state_diff/char_update/plot_update，合并写入该文件。持续累积，不重置。

分卷模式：consistency-rules.json 按卷隔离存储于 .sumeru/volumes/vol-N/continuity/consistency-rules.json。 每卷独立累积，卷切换时通过 Phase B 的 state-start.json 继承前卷状态子集。

第八部分：各 Skill 子Agent职责明细

各技能核心职责见 §一·技能清单。子Agent I/O 详情见各 SKILL.md。

第九部分：修改边界

• wq-review 直接修复错别字、轻微逻辑补丁、字数不足，不大量重写- wq-polish 优化文笔/节奏/对话/爽点，不改变主线事实和角色关系- wq-finalize 专注技术校验和发布格式，不承担剧情重构
• 下游 Skill 不直接调用上游；需返工时输出结构化计划
• 正文修改默认产出最终版，修改前保留最小备份

第十部分：剧情统一门禁与反AI扫描

所有写作重写/润色必须先校验剧情事实再写入，写入后执行反AI扫描。

一、剧情统一检查项

父Agent写入前检查：

1. 承接检查：本章必须承接上一章实际结局
2. 人物检查：位置、伤势、战力、关系与 consistency-rules.json 一致
3. 道具检查：归属、消耗、损坏状态一致
4. 时间线检查：事件顺序不倒置；回忆/梦境/插叙显式标记
5. 伏笔检查：已回收伏笔不重复激活；新伏笔记录 ID/首次章节/预期回收方向
6. 任务卡检查：不违反 protectedElements 和 acceptanceCriteria

处理规则：critical/high 冲突→暂停写入，写 issue 等待仲裁；medium→允许草稿但标记待修复；low→自动修复或记入 changelog

二、父Agent校验流程

写作/润色完成后，父Agent必须执行以下校验：

1. 提取 SUMERU_STATUS 中的 state_diff、char_update、plot_update
2. 比对 consistency-rules.json、最近3 批摘要、上一章实际结尾对比检查：
   - 人物位置冲突（unique_location）
   - 道具状态冲突（destroyed_item_used）
   - 时间线倒置（timeline_order）
   - 战力无因跳跃（power_level_consistency）
   - 伤势无因恢复（character_state_regression）
   - 已回收伏笔重复激活（foreshadowing_recycled）
3. 汇总冲突清单，标注严重程度
4. 发现 critical/high 冲突 → 暂停写入，生成 issue
5. 校验通过 → 更新 chapters/、status.json、continuity cache

三、反AI句式扫描

剧情校验通过后，父Agent对每批子Agent输出执行以下扫描。 v1.2.2 修订：扫描由"不阻塞"改为"分层处理"——水文硬指标命中即自动触发 polish 轻量级 + fix-plan 标记，不再等用户手动跑 polish。

A. 扫描入口

python skills/wq-review/scripts/anti-ai-scan.py <chapters_dir> \
    [--outlines outlines/chapters.json] \
    [--output .sumeru/review] \
    [--quiet]

脚本实现 wq-review/SKILL.md §反 AI / 反水文扫描 中定义的检查项。共 22 个检查码，分四类：

编号说明：B 表与 C 表各自独立编号（B-1…B-11 / C-1…C-7），避免此前两表共用序号导致的 10、11 号重复。 其中 B-10 / B-11 由 detect_global_template_repeat() 以动态 code 传入（anti_ai_global_opening_template / anti_ai_global_hook_template）， 静态扫描 "code": 字面量只能数到 20 个，实际运行共 22 个检查码。

B. 反 AI 句式扫描（11 项，v1.2.4 扩展至 9 维 + v1.4.1 增 2 项全书级；与脚本阈值同步）

C. 水文硬指标（7 项；v1.2.2 新增，v1.2.3 扩展黑名单，v1.2.4 增项；与脚本同步）

编号说明：B 表与 C 表各自独立编号（B-1…B-11 / C-1…C-7）， 修复了此前两表共用数字序号导致 10、11 号在两表中重复、且正文「共 19 项」与表内 18 行对不上的问题。 下文「扫描结果处理」中的编号一律指本表编号。

D. 扫描结果处理（v1.2.3 修订）

• critical 命中（无 —— 当前规则无 critical 级，保留扩展位）→ 立即暂停批次
• high 阻断命中（C-3 / C-4 / C-6 任一）→ 写 fix-plan.json type=anti_ai_blocked，触发 write 重写流程；父 Agent 不得用"插入 2-4 段描写"方式补字数
• medium 命中（B-1 / B-2 / B-5 / B-7 / B-8 / B-9 / B-10 / B-11 / C-1 / C-2 / C-5 / C-7 任一）→ 自动触发 polish 轻量级（不再仅写 changelog 提醒用户）；连续 2 批同章节同问题升级为 high
• low 命中（B-3 / B-4 / B-6 任一）→ 写 changelog，留待 polish 中度时处理
• B-7 / B-8 / B-9 新检查说明：micro_arc / dialog_marker / dialog_emotion_commentary 留 medium 不进阻断，先观察一轮后视情况升级（v1.2.3/v1.2.4 灰度策略）

历史兼容性：v1.2.1 及之前的"anti-ai-flagged 章节 → 记录到 changelog，不阻塞"已废弃。新行为：从 passive 提醒升级为 active 联动。

四、冲突检测规则

五、伏笔管理

伏笔状态流转

设置(active) →推进(mentioned) →回收(resolved)，期望回收章节已过时自动提醒

伏笔字段

{
  "id": "v1",
  "description": "伏笔描述",
  "status": "active|pending|resolved",
  "first_appeared": 15,
  "last_mentioned": 42,
  "expected_payoff_chapter": 80,
  "importance": "high|medium|low",
  "related_chapters": [15, 28, 42],
  "payoff_chapter": null,
  "payoff_detail": null
}

管理建议

• 过期提醒：期望回收章节已过时提醒
• 数量控制：活跃伏笔超过 20 个时建议回收低优先级
• 新伏笔规则：近期设置多个新伏笔时规划回收时间

第十一部分：输出级别与安全约定

输出级别规范

quiet 模式只输出： 阶段开始完成通知、进度条、错误和警告。-2 行阶段总结。不输出脚本详细输出、中间报告、技术细节。

写作安全与原创性

• 避免直接复刻现实公众人物、真实组织、地名、知名 IP 角色
• 参考作品时只学节奏和类型结构，不抄具体内容
• 涉及敏感内容时优先合规化改写并说明风险

标题与文件命名规范

禁止叙事性标题

章节标题（显示在正文中的标题）和文件名均不得使用叙事性标题。叙事性标题指描述文本在故事结构中的功能/位置而非具体内容的标题，这类标题不具备信息量且容易造成混乱。

禁止列表

以下类型的标题一律禁止作为章节标题或文件名：

命名规范

章节文件名格式：三位编号-描述性标题.md

• 正确：001-觉醒仙脉.md、042-北域截杀.md
• 错误：001-第一章.md、042-最后一章.md

章节标题（文件中显示）：必须反映该章的核心事件或场景，使用具体名词或动宾短语。

• 正确：第001章 觉醒仙脉 / 第042章 北域截杀
• 错误：第001章 第一章 / 第042章 最后一章

卷标题：必须反映本卷的核心冲突或主题，而非卷在全书中的位置。

• 正确：第一卷 仙门初入 / 第二卷 北域风云
• 错误：第一卷 / 最后一卷

例外规则

如果叙事性标题在故事中有特殊叙事意义（如小说中的人物写了一篇题为"最后一章"的文章作为剧情伏笔），需在章节任务卡中注明理由并经 review 确认。此类用例必须在 outlines/chapters.json 的对应章节任务卡中标记 narrative_title_exception: true。

校验规则

• 写入章节文件前，父Agent必须校验标题和文件名是否包含禁止的叙事性标题模式
• 发现违规 → 拒绝写入，提示修改为描述性标题
• wq-review 审查阶段增加标题合规性检查项
• wq-finalize 导出阶段执行最终标题校验

第十二部分：子Agent精简版规则

子Agent专用规则见 subagent-rules.md。子Agent只读 context pack + 该文件，不读取本全局规则。

第十三部分：平台适配规则索引

平台适配规则按阶段拆分，各阶段职责不重叠：

核心指标定义

第十四部分：质量检查

执行任一 Skill 后检查：

1. 预期输出文件是否生成
2. .sumeru/ 结构化数据与用户可见输出是否一致
3. 章节文件按三位编号排序，无缺章重章
4. 修改型Skill 是否生成备份和变更记录
5. 写作/重写/润色后是否通过 SUMERU_STATUS 与 continuity cache 校验
6. 章节标题和文件名是否符合命名规范（禁止叙事性标题，参见"标题与文件命名规范"）
7. 发布导出是否剥离 SUMERU_STATUS 注释
8. 正文是否残留元信息标注（"视角：""伏笔：""下一章""预告""本章完"等）——写作/润色后自检，finalize 导出时剥离

跨卷连续性检查

定义见 wq-outline/SKILL.md "大纲自检项·跨卷连续性检查"（#25-#32）。

大纲阶段和审查阶段必须执行跨卷连续性检查。使用以下跨卷依赖表格式记录跨卷依赖：

跨卷依赖表格式（写入 outline.md）

## 跨卷依赖表

| 依赖类型 | 内容 | 源卷 | 目标卷 | 依赖说明 |
|----------|------|------|--------|----------|
| 伏笔 | F3 黑衣人身份 | 卷1·005 | 卷3·012 | 卷1埋设，卷3回收 |
| 成长 | 主角练气三层→筑基 | 卷1→卷2 | 卷2尾 | 卷1末尾练气三层→卷2经历3次战斗后突破 |
| 关系 | 主角↔苏瑾 信任→怀疑 | 卷2·008 | 卷3·010 | 卷2结盟 → 卷3因误会生嫌 |
| 设定 | 黑色残片吸收上限 | 卷1·intro | 卷3 | 卷1限定吸收3次 → 卷3突破上限需新设定补充 |

跨卷检查的执行时机

跨卷冲突检测规则（新增）

第十五部分：分卷隔离与卷切换协议

适用条件：项目 chapters/ ≥ 150 章，或 project.json 中 volumeCount ≥ 2。 少于 150 章的项目继续使用扁平模式，无需 volumes/ 目录。

一、分卷目录结构

当分卷模式激活时，父Agent在自举阶段自动创建以下目录结构：

.sumeru/volumes/
├── vol-001-仙门初入/
│   ├── outline.md              # 本卷剧情框架（由 wq-outline 生成）
│   ├── characters/              # 本卷活跃人物（从全局 characters/ 筛选的副本）
│   ├── continuity/
│   │   ├── state-start.json    # 本卷开场全局状态
│   │   ├── state-current.json  # 当前最新状态
│   │   ├── batch-summaries/    # 批次摘要（见第二部分·批次间串行摘要）
│   │   └── checkpoints/        # 卷内阶段性快照
│   ├── status.json             # 本卷章节状态（200 条，非全局 1500 条）
│   └── world-addendum.md       # 本卷新增设定（可选，不覆盖 world.md）
├── vol-002-北域风云/
│   └── ...
└── vol-003-...

此外，自举阶段创建跨卷骨架数据：

.sumeru/cross-volume/
├── dependency-table.md         # 跨卷依赖表（同 outline.md 末尾格式）
├── master-timeline.md          # 全局时间线主干（每卷起止时间 + 关键事件）
└── master-characters.md        # 全局人物索引（每卷出场标记）

二、卷切换协议（Volume Handoff）

Phase A — 当前卷完结

由 wq-write 父Agent检测到当前卷最后一批写作完成时自动触发：

1. 最终快照：将 state-current.json 复制为 state-final.json，写入 vol-N/continuity/
2. 卷级总结：生成 ≤ 500 字卷级总结，包含：
   • 本卷起止章节号、时间跨度的
   • 本卷核心事件清单（5-8 条）
   • 本卷结束时各主要人物状态
   • 本卷埋设的跨卷伏笔（指向目标卷）
   • 本卷结束时未回收的伏笔列表
3. 更新跨卷骨架：
   • cross-volume/master-timeline.md 追加卷条目
   • cross-volume/dependency-table.md 追加本卷新注册的跨卷依赖
   • cross-volume/master-characters.md 更新人物状态
4. 存档批次摘要：vol-N/continuity/batch-summaries/ → 移入 vol-N-archived/（保留只读）
5. 标记卷完成：project.json → volumes[vol-N].status = "completed"
6. 回写 changelog：.sumeru/changelog.md 追加卷完结记录

Phase B — 新卷启动

由 wq-worldbuilder 编排 wq-outline 在新卷写作开始前执行：

1. 加载前卷快照：从 vol-N/continuity/state-final.json 读取
2. 生成本卷开场状态：state-start.json — 继承 state-final 中与本卷相关的子集（过滤掉下卷不再活跃的人物/道具）
3. 创建卷目录：.sumeru/volumes/vol-M/ 及子目录
4. 生成 outline：vol-M/outline.md（本卷剧情框架，由 wq-outline 生成）
5. 筛选活跃人物：从 cross-volume/master-characters.md 筛选本卷出场人物，复制到 vol-M/characters/
6. 加载跨卷承诺：从 cross-volume/dependency-table.md 筛选 目标卷 = vol-M 的条目，注入 vol-M/outline.md 的"本卷必须兑现"清单
7. 初始化状态：vol-M/status.json（空状态，章节状态 = planned）
8. 清空批次缓存：vol-M/continuity/batch-summaries/ 写入唯一的软重置条目（上一卷最后 1 批摘要 + 卷级总结）
9. 更新 project.json：currentVolume = "vol-M"

Phase C — 跨卷引用查询

任何技能需要读取跨卷数据时，不扫描全量 continuity，而是：

1. 查询 .sumeru/cross-volume/dependency-table.md 看是否有与本卷相关的条目
2. 如果有 → 只读取对应卷的 state-final.json 或 state-start.json
3. 如果没有 → 不做跨卷读取

此规则适用于所有技能（write/review/polish/finalize）。

三、分卷模式的文件操作规则

四、分卷模式的激活与降级

激活条件

• 自动：wq-worldbuilder 自举时发现 chapters/ ≥ 150 章或 outline.md 中分卷数 ≥ 2
• 手动：用户在任意阶段要求 启用分卷模式 或 /wq-migrate 启用分卷

降级条件

• 自动：全书完稿后（所有章节状态为 finalized），可选取消除卷隔离归档到扁平结构
• 手动：用户要求 合并卷结构，由 wq-migrate 执行逆向合并

volumeCount 配置

见 project.json Schema（第七部分）。volumeCount 可选，缺失时按扁平模式运行。 分卷模式激活后 project.json 新增字段：

{
  "volumeCount": 5,
  "currentVolume": "vol-003",
  "volumes": {
    "vol-001": { "title": "仙门初入", "chapterRange": [1, 200], "status": "completed" },
    "vol-002": { "title": "北域风云", "chapterRange": [201, 400], "status": "completed" },
    "vol-003": { "title": "秘境探秘", "chapterRange": [401, 600], "status": "active" }
  }
}

六、子Agent 负载策略（v1.4.4 新增）

代价模型

每次子Agent 调用成本 ≈ 3-5 分钟（上下文加载 + 模型推理 + 结果回传），每轮 token 消耗：

关键约束：模型 API 有并发限制（通常 3-10 路），超出会触发限流或排队。

并行度推荐

分流原则

纯字数不足（deficiencies == ["字数不足"]）
  → wq-revise 轻量路径：5 并发，单次往返，不占收敛门轮次

有质量缺陷（叙事/节奏/伏笔）
  → wq-revise 收敛门：2 并发，允许 1-2 轮迭代

写新章节（wq-write）
  → 3 并发，每子 Agent 2-3 章

审查（wq-review）
  → 3 并发，每子 Agent 3-5 章

避免的陷阱

1. 不要全并发：3+ 个收敛门任务同时跑会耗尽 token 配额，导致 API 限流
2. 不要混用批次大小：轻量路径用 1 章/子Agent，write 用 2-3 章/子Agent——混用会让调度混乱
3. 不要让子Agent 自决下一步：收敛判定归父Agent，子Agent 只负责"改这一轮"
4. 不要超过 globalMaxRounds：轻量路径也受全局硬停约束（默认 3 轮），防止死循环

时间估算参考

七、子 Agent 输出截断检测与自动续写（v1.4.9 新增）

问题：子 Agent 输出 token 受限（通常 4096-8192），写长章节（≥2500 字）时可能中途截断，导致章节不完整。

截断检测规则（父 Agent 回收时执行）

子 Agent 返回后，父 Agent 检查输出是否截断：

满足任意一项即判定为「疑似截断」，触发续写。

续写协议

第 1 次续写：
  父 Agent 派子 Agent，context pack 附加：
  "续写指令：上文在第X段末尾截断，请从「{截断前最后20字}」之后继续写，
  直接接上，不要重复已写内容。输出末尾仍用完整句号结束。"
  子 Agent 返回 Part 2。

拼接：
  Part 1 + Part 2（去除 Part 2 开头与 Part 1 结尾的重复片段，默认去重 1 段）
  → 合并写入 chapters/{章号}-标题.md

最多续写 1 次。第 2 次仍截断 → 标 truncated，记 issue，不进 finalize。

与 context pack 预算的关系

截断的根本原因是 context pack 过大挤占了输出预算。v1.4.9 已压缩 context pack（各字段字数上限 + Batch Summary 限 3 批），正常情况下 2500 字章节不应截断。截断检测是兜底机制。

轻量路径节省的核心原因：收敛门每章平均 1.5 轮 × 每轮 2 个子Agent（2 并发）× 3 分钟 = 9 分钟/章；轻量路径 1 轮 × 5 个子Agent（5 并发）× 3 分钟 = 0.6 分钟/章。