# story-review：多章分批审查

多章、整卷或整本审查需拆成两批及以上时读本文件，full、lean、solo 均适用；一次审完则不读。

## 跨批审查落盘契约

分批时维护 **{项目根}/.story-review/state.md**：

1. 首批确定本次完整审查范围和批次顺序。每批核对完后，用同目录临时文件 + rename 原子重写 state.md，不能只把结果留在对话里。
2. state.md 只记录完整审查范围、已完成范围、下一批，以及“上一批未解决 findings 摘要”。每条摘要保留 location、issue 及预计核查或兑现的章节范围。
3. 下一批开始前先读取 state.md，把未解决摘要注入 reviewer prompt；已解决或用户明确不处理的项不再继承，但须在本批输出中说明。
4. 每个项目同时只维护一条跨批审查；若新一轮与 state.md 中未完成范围不同，先说明会丢弃的旧进度并征得用户确认，确认后在首批完成时覆盖。续接时 state.md 缺失、损坏或本批超出既定范围，应明确报告并停止，不猜测旧内容；非分批审查不创建它。

**.story-review/** 只保存审查进度；不得借维护审查状态修改正文、设定、大纲或 `追踪/`。

## 每批开审前

- **跨批连续性（分批必做）**：审每一批前，先读 `追踪/伏笔.md` 中状态为 `已埋` 且计划回收章 ≤ 本批末章的当前行，再按需读取相关 `追踪/逐章记录/第NNN章.md` 查变更原因；同时读取涉及角色的独立快照，并按上方契约把 state.md 的上一批未解决 findings 摘要作为「继承的开放项」注入 reviewer / consistency-checker prompt（solo 由自己逐条核对）。新发现但尚未登记的开放钩子先列为维护候选，收尾时必须有正文证据才能进入修订事务。
- **乱序/重叠审查提醒**：若已审过靠后的范围（如先审 300-400），之后审靠前的范围（200-300）时，只有当本批**新增/改动了一个开放项、且其预计兑现章落在已审过的靠后范围内**，才提醒用户「200-300 的改动可能影响已审的 300-400」，并让用户选择复审受影响章节 / 全量复审 / 仅记为待办——**默认记为待办，不盲目全量重跑**。无具体跨范围依赖时不提醒。