chore(task): 登记 rfc-followup 任务 + gap 分析补 D3/D4

- 补 task.json：rfc-followup 任务正式纳入 Trellis 跟踪
- gap 分析新增 §8：补收 freezero2020（06-26）漏评、改为直接对照 spec 实判、
  两缺口收敛为 D3/D4
- prd.md / design.md 落 D3（未登记伏笔检测）、D4（设定大纲单向依赖）决策

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

.trellis/tasks/06-26-rfc-followup/design.md

@@ -0,0 +1,170 @@
+# 技术设计：v7 RFC 后续推进
+
+## 1. 设计范围
+
+本任务是**文档更新任务**，不涉及代码实施。设计范围：
+
+- 更新 4 个文档文件（spec、实施计划、multi-agent-spec）
+- 发布 RFC 跟进评论（Discussion #118）
+- 不涉及代码修改、不涉及 master 分支
+
+## 2. 文档更新边界
+
+### 2.1 决策来源
+
+- **A1/A2/A3**：三个核心决策（来自 RFC 反馈报告 §A）
+- **D1**：两审调整（来自 v6 实践经验 + RFC 反馈）
+- **D2**：审稿终止机制（来自 Discussion #118 遗漏分析）
+- **D3**：未登记伏笔检测（来自 Discussion #118 深度核验，shuimushanjia 06-22）
+- **D4**：设定↔大纲单向依赖不变量（来自 freezero2020 06-26）
+- **B 类澄清**：缓存删除代价、关键词扫描边界、两审模式（来自 RFC 反馈报告 §B）
+
+### 2.2 更新策略
+
+**story-repo-spec 0.6 → 0.7**：
+- 补充内容：A1/A2/A3 决策、D1 两审定义、D2 审稿终止机制、**D3 未登记伏笔检测（§8 第 6 步事实审查职责）**、**D4 设定↔大纲单向依赖不变量（§1 + §4.2）**、B 类澄清
+- 不修改内容：其他章节保持不变
+- 版本号：0.6 → 0.7
+
+**v7-implementation-plan 0.1 → 0.2**：
+- 更新 M1/M4/M6 里程碑描述（反映决策）
+- 更新"下一个可立即开工的任务"章节
+- 版本号：草案 0.1 → 草案 0.2
+
+**multi-agent-adaptation-spec v3.2 → v3.3**：
+- 明确两审模式（完整 vs 兼容）
+- 更新审稿清单定义（参考 v6 review schema）
+- 版本号：v3.2 → v3.3
+
+**v7-prd.md**：
+- 保持 1.0 不变（已定稿）
+- 决策细节只记录在 spec 中
+
+## 3. 两审输出格式设计
+
+### 3.1 参考基准
+
+v6 的 `webnovel-writer/references/review-schema.md` 定义了结构化问题清单：
+
+```json
+{
+  "chapter": 100,
+  "issues": [
+    {
+      "severity": "critical | high | medium | low",
+      "category": "continuity | setting | character | timeline | logic | pacing | other",
+      "location": "第N段 或 具体引用",
+      "description": "问题描述",
+      "evidence": "原文引用 vs 数据记录",
+      "fix_hint": "修复方向",
+      "blocking": true
+    }
+  ],
+  "issues_count": 1,
+  "blocking_count": 1,
+  "has_blocking": true,
+  "dimension_results": [
+    {"dimension": "setting", "conclusion": "pass"},
+    {"dimension": "timeline", "conclusion": "发现1个问题：..."},
+    ...
+  ],
+  "summary": "N个问题：X个阻断，Y个高优"
+}
+```
+
+### 3.2 v7 两审输出格式
+
+**事实审查输出**（AI，新鲜上下文）：
+
+- 维度：设定、时间线、连贯、角色、逻辑（v6 的 5 维度）+ v7 特有项（要写到的事核对、泄密候选判断、履历证据验证、**未登记伏笔检测 D3**）
+- 输出格式：同 v6 review schema
+- category 取值：`setting | timeline | continuity | character | logic | requirement | leak | evidence | unregistered_thread`
+  - `unregistered_thread`（D3）：正文出现疑似伏笔但无对应条目；`severity` low/medium，**`blocking` 恒为 false**，候选制不拦截
+
+**编辑审输出**（AI，新鲜上下文）：
+
+- 维度：结构、节奏、商业性、主角动机
+- 输出格式：同 v6 review schema
+- category 取值：`structure | pacing | commercial | motivation`
+
+### 3.3 阻断规则
+
+- `severity=critical` 自动 `blocking=true`
+- 其他 severity 由 AI 根据上下文判断
+- 存在任何 `blocking=true` 的 issue → 作者审稿时看到明确标识
+- 作者可选择：接受（即使有非阻断问题）/ 改完接受 / 打回重写
+
+## 4. 版本链叠加机制概要
+
+**A1 决策**：支持批次内依赖，打回时传播影响。
+
+**设计要点**（spec 0.7 需明确）：
+- 叠加视图组装规则：`定稿/ + 待定稿/批次预登记`
+- 污染传播：第 K 章打回 → 标记 K+1 到 N 章为"受影响"
+- 作者确认流程：整批重写 vs 逐章确认（待 M6 实施时设计细节）
+
+**不在本次任务范围**：
+- 具体的污染传播算法（M6 实施时设计）
+- 叠加视图的代码实现（M6 实施时完成）
+
+## 5. 文档一致性检查清单
+
+更新完成后需验证：
+
+- [ ] A1/A2/A3 决策在 spec 0.7 中完整体现
+- [ ] D1 两审定义在 spec 0.7 §8 和 multi-agent-spec v3.3 中一致
+- [ ] D2 审稿终止机制在 spec 0.7 §8 中明确
+- [ ] 实施计划 0.2 反映了决策对里程碑的影响
+- [ ] 所有文档的版本号已更新
+- [ ] 术语一致性（伏笔/悬念/感情线、细纲、审稿等）
+
+## 6. RFC 跟进评论结构
+
+**段落结构**：
+1. 感谢反馈（1-2 句）
+2. RFC 征集期总结（收到哪些反馈）
+3. 核心决策说明（A1/A2/A3/D1/D2）
+4. 采纳清单（v7.0 vs 7.x）
+5. 遗漏反馈回应（术语、审稿循环、AI 平庸、伏笔追踪、文风）
+6. 质量承诺边界明确
+7. 后续时间线（如有）
+
+**文案要求**：
+- 易读但不过分口语
+- 每个决策用 1-2 句话说清楚
+- 避免技术细节（链接到 v7 分支文档）
+- 真诚回应用户关切
+
+## 7. 边界与约束
+
+**本次任务不做的事**：
+- ❌ 不实施 O4 设计（`.cache/index.db` DDL）
+- ❌ 不修改 master 分支
+- ❌ 不编写代码
+- ❌ 不设计版本链叠加的具体算法
+- ❌ 不设计两审的具体 prompt
+
+**后续任务接口**：
+- O4 设计应该作为独立任务，在 M1 前完成
+- v7.0 实施时，M4 需要根据 spec 0.7 实现两审
+- M6 需要根据 spec 0.7 实现版本链叠加
+
+## 8. 风险与缓解
+
+**风险 1**：文档更新后与 PRD 1.0 冲突
+- **缓解**：PRD 1.0 是产品法律文本，spec 是技术细化，只要不违背 PRD 原则即可
+
+**风险 2**：两审定义与 v6 reviewer 的区别不够清晰
+- **缓解**：在 spec 中明确"继承 v6 的什么 + v7 新增了什么"
+
+**风险 3**：RFC 跟进评论发布后收到新反馈
+- **缓解**：评论中说明"征集期已结束，后续反馈将记录但不影响 v7.0 范围"
+
+## 9. 验收标准
+
+- [ ] 4 个文档文件已更新，版本号正确
+- [ ] 文档内容与 PRD 决策一致
+- [ ] 术语一致性检查通过
+- [ ] RFC 跟进评论已发布到 Discussion #118
+- [ ] 所有决策和遗漏反馈都有回应
+- [ ] git 状态干净（文档更新已提交到 v7 分支）

.trellis/tasks/06-26-rfc-followup/implement.md

@@ -0,0 +1,434 @@
+# 执行计划：v7 RFC 后续推进
+
+## 执行顺序
+
+按依赖关系排序，必须顺序执行：
+
+1. ✅ **规划阶段**（已完成）
+2. → **文档更新阶段**（4 个文件）
+3. → **RFC 跟进评论**（依赖文档更新完成）
+4. → **提交与清理**
+
+---
+
+## 阶段 1：更新 story-repo-spec（0.6 → 0.7）
+
+### 1.1 更新文件头部版本信息
+
+**文件**：`docs/architecture/story-repo-spec-2026-06-10.md`
+
+**修改**：
+```markdown
+# Story Repo 格式规格（v7 草案 0.7）
+
+> 状态：0.7。相对 0.6 的变更：
+> - 补充 A1 决策：自动模式待定稿批次的版本链叠加机制（§8.1）
+> - 更新 A2 决策：Node >= 22.13.0 运行时要求（§2.2）
+> - 明确 A3 决策：履历证据的章节级验证范围（§5 线索条目格式，§11 缓存重建器职责）
+> - 调整审稿定义：从三审改为两审（事实审查 + 编辑审），去掉读者审（§8 第 6 步）
+> - 补充审稿终止机制：severity + blocking 规则（§8 第 6-7 步）
+> - 澄清 B 类问题：缓存删除代价（§11）、关键词扫描边界（§4.3）、两审模式（§8 第 6 步）
+```
+
+### 1.2 更新 §2.2 Node 版本要求（A2）
+
+**当前文本**：
+```
+Node ≥ 22（零第三方依赖：.cache/index.db 用内置 node:sqlite）
+```
+
+**修改为**：
+```
+**脚本运行时统一 Node ≥ 22.13.0**（零第三方依赖：`.cache/index.db` 用内置 `node:sqlite`，v22.13.0 起无需 `--experimental-sqlite` flag；装任何 agent CLI 的用户必有 Node；无 Python、无 pip、无 .env）。安装器检测 Node 版本，< 22.13.0 时人话提示升级。一切文件 IO 显式 UTF-8（Node 默认即是），禁止依赖系统 locale。
+```
+
+### 1.3 更新 §5 线索条目履历格式（A3）
+
+**找到**：`§5 伏笔 / 悬念 / 感情线` 中的履历示例
+
+**补充说明**：
+```markdown
+**履历证据引用格式**：
+- 格式：`第152章：主角在北境对峙时首次察觉真相`（章节级别 + 自然语言描述）
+- 验证范围：
+  - 重建器验证：章节文件是否存在（脚本能做的）
+  - 两审验证：读取整章验证语义正确性（AI 能做的）
+- 理由：网文章节 2000-3000 字，全文读取压力可接受；避免段落编号维护的复杂性
+```
+
+### 1.4 更新 §8 写章流程第 6 步（D1 + D2）
+
+**当前文本**（第 6 步）：
+```
+| 6 | 三审 | AI ×3（各自新鲜上下文） | **读者审**（爽不爽/哪段想划走，用追读力知识库的标准）、**编辑审**（结构与商业性）、**设定校对**（语义判断都在这里：①"要写到的事"逐条核对正文写没写到；②机检泄密候选是否真泄密；③条目履历引用的章内证据是否属实）→ `工作区/评审报告/` |
+```
+
+**修改为**：
+```
+| 6 | 两审 | AI ×2（各自新鲜上下文） | **事实审查**（v6 的 5 维度：设定一致性、时间线、叙事连贯、角色一致性、逻辑 + v7 特有项：①"要写到的事"逐条核对正文；②机检泄密候选是否真泄密；③条目履历引用的章内证据是否属实）、**编辑审**（结构、节奏、商业性、主角动机：主角每个主要行动是否有即时驱动、可见压力、预期收益、情绪原因，或明确标注为非理性行为）→ `工作区/评审报告/`。输出格式：结构化问题清单（severity + category + blocking），参考 v6 review schema。|
+```
+
+**补充审稿终止机制**（在第 6 步后新增说明段落）：
+```markdown
+**审稿终止机制**（防止无限循环）：
+- 两审输出结构化问题清单，每个问题包含 `severity`（critical/high/medium/low）、`category`、`blocking`（是否阻断定稿）、`description`、`evidence`、`fix_hint`
+- 阻断规则：`severity=critical` 自动 `blocking=true`；其他 severity 由 AI 判断
+- 作者审稿时可选择：接受当前版本（即使有非阻断问题）/ 改完接受（不重新审稿）/ 打回重写
+- **系统不强制完美**：非阻断问题作为"优化建议"，作者可接受现状并定稿
+```
+
+### 1.5 更新 §8.1 自动模式叠加视图（A1）
+
+**找到**：`### 8.1 自动模式（连写，按批次定稿）` 中的"叠加视图"段落
+
+**补充说明**：
+```markdown
+- **叠加视图与版本链**（规范性要求）：写批内后续章时，备料脚本组装"`定稿/` + 待定稿批次预登记"的叠加视图——批内前章的设定变更、条目推进、时间线行在工作区就位，定稿时原样转正。**支持批次内依赖**：第 K+1 章可以使用第 K 章的预登记事实。当第 K 章被作者打回时，标记 K+1 到 N 章为"受影响"，需重新审核或重写（具体污染传播机制由 M6 实施时设计）。
+```
+
+### 1.6 澄清 §11 缓存删除代价（B 类）
+
+**找到**：`§11 .cache/ 派生缓存` 中关于删除的说明
+
+**补充说明**：
+```markdown
+**删除 `.cache/` 后的行为**：
+- 系统从源文件全量重建缓存（所有查询照常回答，这是 CI 验收项）
+- 首次查询会触发冷重建（可能需数秒，视书籍体量），或临时降级为全文件扫描并给出提示
+- 不应暗示"删除缓存零代价"
+```
+
+### 1.7 澄清 §4.3 信息差关键词扫描边界（B 类）
+
+**找到**：`§4.3 信息差` 中关于泄密扫描的说明
+
+**确认当前文本已明确**（如已明确则无需修改）：
+- 关键词扫描 = 机械召回（产出候选清单）
+- 是否真泄密 = 事实审查中的语义判断
+
+### 2.6 补充 v7 架构原则
+
+**找到**：`## 2. 里程碑` 之前
+
+**插入新章节**：
+```markdown
+## 1.5 v7 架构原则（指导实施）
+
+v7 的架构目标是**降低变化影响面**，通过清晰分层和显式用例，避免 v6 "动一个地方其他地方都受影响"的问题。
+
+### 核心原则
+
+1. **AI 永远不接触文件结构**
+   - AI 只看到整理好的上下文 DTO（`CharacterContext`、`ChapterBrief`、`ReviewInput`）
+   - AI 不知道 `定稿/设定/角色/林晚.md` 在哪里，只知道"当前角色是林晚，境界是金丹"
+   - 改文件结构不影响 AI 层
+
+2. **状态机永远不做业务判断**
+   - 状态机只负责流程编排：下一步是备料/写稿/机检/审稿/定稿
+   - 不判断伏笔真假，不解析 Markdown，不拼上下文
+
+3. **脚本层按 Use Case 拆，不按技术动作拆**
+   - 显式用例：`prepareChapterMaterials`、`runMechanicalChecks`、`finalizeChapter`、`rebuildCache`、`analyzeRetconImpact`
+   - 不做通用工具函数到处调用
+
+4. **Markdown 格式变化只影响 Storage Adapter**
+   - front matter 字段、目录命名、履历格式这些变化，收敛在 `MarkdownStoryStore` / parser / serializer
+
+5. **跨层通信用稳定 DTO**
+   - 例如 `Chapter`、`ThreadEntry`、`ReviewIssue`、`ContextPack`
+   - 不跨层传 Markdown 字符串、文件路径、半解析 YAML
+
+### 接口设计：拆小端口，不做大接口
+
+**避免上帝对象**：
+- ❌ 不做 `StoryRepo` 大接口（20 个方法，谁都能干任何事）
+- ✅ 拆成小端口：`ChapterReader`、`ChapterWriter`、`ThreadLedgerReader`、`GitPublisher`
+- 每个 use case 只依赖需要的端口（权限最小化）
+
+### 配置化边界：只调策略，不定义流程
+
+**可以配置**（策略参数）：
+```yaml
+review:
+  max_iterations: 3
+  enable_fact_check: true
+
+auto_mode:
+  batch_size: 8
+```
+
+**不要配置**（自定义流程语言）：
+```yaml
+steps:
+  - id: custom_step
+    command: my_script.js
+```
+
+理由：v7.0 的目标是"可预测"，不是"无限可扩展"。配置化流程会让调试成本暴涨。
+
+### 变化影响面
+
+- ✅ 改格式（front matter 字段）→ 只改 Storage Adapter
+- ✅ 改流程策略（批次大小、审稿轮数）→ 只改配置
+- ✅ 改 AI prompt → 只改 AI 层模板
+- ✅ 换模型 → AI 层封装，对外接口不变
+- ✅ 加新宿主 → 只动 Host Adapter
+- ⚠️ 改领域模型（如伏笔/悬念/感情线概念）→ 合理的跨层影响
+
+### 里程碑对应
+
+- **M1 格式层**：实现 Storage Adapter 接口（ChapterReader/Writer 等）
+- **M2 脚本层**：实现 Use Case（prepareChapterMaterials、finalizeChapter 等）
+- **M3 状态机**：只管流程编排，不管业务逻辑
+- **M4 AI 层**：只吃 DTO，只吐结构化输出
+- **M5 安装器**：Host Adapter 层
+```
+
+**注意**：这个章节编号为 1.5，插入在"排程原则"之后、"里程碑"之前。
+
+
+### 2.1 更新文件头部版本信息
+
+**文件**：`docs/architecture/v7-implementation-plan.md`
+
+**修改**：
+```markdown
+> 状态：草案 0.2（2026-06-26，反映 RFC 后续决策）
+> 上游：`v7-prd.md` 1.0、`story-repo-spec-2026-06-10.md` 0.7、`multi-agent-adaptation-spec-2026-06-05.md` v3.3、`.trellis/spec/backend/` 基线 1.0
+```
+
+### 2.2 更新现状盘点
+
+**找到**：`## 0. 现状盘点` 表格
+
+**修改 RFC 行**：
+```
+| RFC | ✅ 已发 Discussions（06-12），~06-19 收口，06-26 完成后续决策（A1/A2/A3/D1/D2） |
+```
+
+**补充 PRD 开放问题行**：
+```
+| PRD 开放问题 | O2/O3 已消解；**O4 归 M1 第一步**（不在 RFC 后续任务范围，需单独任务） |
+```
+
+### 2.3 更新 M1 里程碑
+
+**找到**：`### M1 格式层核心库 + 派生缓存`
+
+**修改第一步说明**：
+```
+- **第一步消解 O4（设计文档，需单独任务）**：`.cache/index.db` 五表 DDL + 精准读取接口完整清单，成稿后补进 spec §11。**Node 版本要求**：≥ 22.13.0（RFC 后续决策 A2）。
+```
+
+### 2.4 更新 M4 里程碑
+
+**找到**：`### M4 AI 角色层 + 一级宿主壳`
+
+**修改两审说明**：
+```
+- 两审任务书单源（事实审查/编辑审，参考 v6 review schema）、写评分离的上下文编排、降级模式（无 subagent 顺序执行，诚实声明）
+```
+
+### 2.5 更新 M6 里程碑
+
+**找到**：`### M6 自动模式（按批次定稿）`
+
+**补充版本链说明**：
+```
+- `工作区/待定稿/` 批次结构、"定稿+待定稿批次"叠加组装视图（**支持批次内依赖**，RFC 决策 A1）
+- 污染传播机制：第 K 章打回 → 标记 K+1 到 N 章"受影响"，作者确认重审/重写
+```
+
+### 2.6 更新"下一个可立即开工的任务"
+
+**找到**：`## 5. 下一个可立即开工的任务`
+
+**修改为**：
+```
+1. **M0 仓库骨架**（立即可起）：格式无关，不等 RFC。Node 版本门槛 ≥ 22.13.0（RFC 决策 A2）。
+2. **O4 设计文档**（与 M0 并行，需单独任务）：表 DDL + 精准读取接口清单，纸面工作，RFC 改格式时修订成本低。
+3. spec 0.7 / multi-agent-spec v3.3 已完成（RFC 后续任务），M1 可依据新 spec 开工。
+```
+
+---
+
+## 阶段 3：更新 multi-agent-adaptation-spec（v3.2 → v3.3）
+
+### 3.1 更新文件头部版本信息
+
+**文件**：`docs/architecture/multi-agent-adaptation-spec-2026-06-05.md`
+
+**修改**：
+```markdown
+> 版本：v3.3（2026-06-26，反映 RFC 后续决策）
+> 变更：明确两审模式（完整 vs 兼容）；更新审稿清单定义（参考 v6 review schema）
+```
+
+### 3.2 更新审稿清单定义
+
+**找到**：多宿主适配中关于"三审"的章节
+
+**修改为**：
+```markdown
+### 两审任务书
+
+**事实审查**：
+- 维度：设定一致性、时间线、叙事连贯、角色一致性、逻辑（v6 的 5 维度）
+- v7 特有项：①"要写到的事"核对；②泄密候选判断；③履历证据验证
+- 输出格式：结构化问题清单（参考 v6 `review-schema.md`）
+- category 取值：`setting | timeline | continuity | character | logic | requirement | leak | evidence`
+
+**编辑审**：
+- 维度：结构、节奏、商业性、主角动机
+- 输出格式：同上
+- category 取值：`structure | pacing | commercial | motivation`
+
+**阻断规则**：
+- `severity=critical` 自动 `blocking=true`
+- 存在 `blocking=true` 的问题 → 作者审稿时明确标识
+- 作者可选择：接受现状 / 改完接受 / 打回重写
+```
+
+### 3.3 更新两审模式说明
+
+**找到**：宿主能力差异的章节
+
+**补充或修改**：
+```markdown
+### 两审模式
+
+**完整模式**（推荐）：
+- 事实审查 + 编辑审各用独立上下文（subagent 或独立会话）
+- 审稿隔离度高，互不影响
+
+**兼容模式**（降级）：
+- 单 agent 顺序执行两审
+- 输出必须诚实声明："本次使用兼容模式（单上下文顺序审稿），审稿隔离度低于完整两审模式"
+- 审稿报告中标注使用的模式
+
+不支持完整模式的宿主，应在文档中明确说明兼容模式的限制。
+```
+
+---
+
+## 阶段 4：RFC 跟进评论
+
+### 4.1 起草评论文案
+
+**目标**：发布到 Discussion #118
+
+**结构**：
+1. 感谢与总结（1-2 段）
+2. 核心决策说明（A1/A2/A3/D1/D2，每个 1-2 句）
+3. 采纳清单（表格：v7.0 vs 7.x）
+4. 遗漏反馈回应（5 个要点）
+5. 质量承诺边界明确
+6. 后续时间线
+
+**文案要点**：
+- 用词：易读但不过分口语
+- 长度：控制在 500-800 字
+- 格式：Markdown，使用标题、列表、加粗
+- 链接：指向 v7 分支的更新后文档
+
+### 4.2 评论草稿检查清单
+
+- [ ] 所有用户反馈都有回应（Chained1001、wangwwno1、Fahaoxi、shuimushanjia）
+- [ ] 术语反馈已回应
+- [ ] 审稿循环问题已说明解法
+- [ ] AI 平庸倾向已明确边界
+- [ ] 伏笔追踪已说明改进
+- [ ] 文风成本已更新 backlog
+- [ ] 文案符合"易读但不过分口语"
+
+### 4.3 发布流程
+
+1. 在本地起草完整评论（保存为 `rfc-followup-comment.md`）
+2. 复制到 Discussion #118 评论框
+3. 预览检查格式
+4. 发布
+
+---
+
+## 阶段 5：提交与清理
+
+### 5.1 git 提交
+
+**验证修改**：
+```bash
+git status
+git diff docs/architecture/story-repo-spec-2026-06-10.md
+git diff docs/architecture/v7-implementation-plan.md
+git diff docs/architecture/multi-agent-adaptation-spec-2026-06-05.md
+```
+
+**提交**：
+```bash
+git add docs/architecture/story-repo-spec-2026-06-10.md
+git add docs/architecture/v7-implementation-plan.md
+git add docs/architecture/multi-agent-adaptation-spec-2026-06-05.md
+git commit -m "docs(v7): RFC 后续决策落地 - spec 0.7 + 实施计划 0.2
+
+- 补充 A1/A2/A3 核心决策（版本链叠加、Node 22.13.0、章节级锚点）
+- 审稿机制调整为两审（事实审查 + 编辑审），增加终止机制
+- 更新实施计划反映决策，明确 M1/M4/M6 里程碑要点
+- 多宿主 spec 明确两审模式（完整 vs 兼容）
+
+Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>"
+```
+
+### 5.2 最终验收
+
+- [ ] 4 个文档文件版本号正确（spec 0.7, plan 0.2, multi-agent v3.3）
+- [ ] 所有决策在 spec 中完整体现
+- [ ] 术语一致性检查通过
+- [ ] RFC 跟进评论已发布
+- [ ] git 提交已完成，commit message 清晰
+- [ ] 当前任务目录整理完毕
+
+---
+
+## 回滚方案
+
+如果文档更新出现问题：
+
+```bash
+# 查看提交历史
+git log --oneline -5
+
+# 回滚到上一次提交
+git reset --soft HEAD~1
+
+# 或撤销特定文件
+git checkout HEAD~1 -- docs/architecture/story-repo-spec-2026-06-10.md
+```
+
+---
+
+## 验证命令
+
+**检查版本号**：
+```bash
+grep "草案 0.7\|v3.3\|草案 0.2" docs/architecture/*.md
+```
+
+**检查术语一致性**（抽查）：
+```bash
+grep -n "三审\|读者审" docs/architecture/story-repo-spec-2026-06-10.md
+# 预期：应该改为"两审"，无"读者审"
+```
+
+**检查 Node 版本**：
+```bash
+grep "Node.*22" docs/architecture/story-repo-spec-2026-06-10.md
+# 预期：应该是 "22.13.0"
+```
+
+---
+
+## 执行注意事项
+
+1. **顺序执行**：必须先完成所有文档更新，再起草 RFC 评论（评论需要引用更新后的文档）
+2. **验证后再提交**：每个文档更新后用 `git diff` 检查，确认无误再进入下一个
+3. **保留草稿**：RFC 评论先保存为本地文件，检查后再发布
+4. **记录问题**：执行中发现的问题记录到任务研究目录

.trellis/tasks/06-26-rfc-followup/prd.md

@@ -0,0 +1,311 @@
+# PRD: v7 RFC 后续推进
+
+## Goal
+
+根据 v7 RFC 反馈报告（2026-06-16）完成 v7 设计收尾，为实施做好准备，并最终合并到 master 分支。
+
+## Background
+
+v7 RFC 征集期已结束（Discussion #118），反馈报告已完成分析。报告指出：
+- 公开反馈支持 v7 核心方向（精准读取降低 token、增加作者确认点）
+- 提出了具体改进建议（规划流程停顿点、主角动机检查、文风对齐、多宿主编排）
+- 识别出 3 个必须在 v7.0 实施前决策的设计问题（A1/A2/A3）
+- 识别出若干需要澄清的 spec 边界问题（B1-B4）
+- 识别出应放入 7.x backlog 的功能（C1-C4）
+
+## Requirements
+
+### R1: 核心决策（已完成）✓
+
+三个必须在 v7.0 实施前决策的问题已明确：
+
+**A1: 自动模式叠加视图一致性** — 版本链叠加
+**A2: node:sqlite 运行时承诺** — Node >= 22.13.0
+**A3: 履历证据结构化锚点** — 章节级别 + 自然语言
+
+### R2: 文档更新（待执行）
+
+根据决策结果和 RFC 反馈更新相关文档：
+
+**必须更新的文档**：
+1. `story-repo-spec-2026-06-10.md` (0.6 → 0.7)
+   - 补充 A1 决策：自动模式待定稿批次的版本链叠加机制（§8.1）
+   - 更新 A2 决策：Node >= 22.13.0 运行时要求（§2.2）
+   - 明确 A3 决策：履历证据的章节级验证范围（§5 线索条目格式，§11 缓存重建器职责）
+   - **调整三审定义**（§8 写章流程第 6 步）：
+     - 改为**两审**：事实审查 + 编辑审
+     - 事实审查：v6 的 5 维度（设定/时间线/连贯/角色/逻辑）+ v7 特有项（要写到的事核对、泄密候选判断、履历证据验证）
+     - 编辑审：结构、节奏、商业性、**主角动机检查**（新增）
+     - 去掉"读者审"（爽点判断留给作者）
+     - 输出格式参考 v6 review schema（结构化问题清单，severity + blocking 机制）
+   - 澄清 B 类问题：缓存删除代价、关键词扫描边界、两审模式（完整 vs 兼容）
+
+2. `v7-implementation-plan.md` (0.1 → 0.2)
+   - **补充 §1.5 v7 架构原则**（指导实施）：
+     - AI 永远不接触文件结构（只看 DTO）
+     - 状态机只管编排，不做业务判断
+     - 按 Use Case 拆分（不做通用工具函数）
+     - 拆小端口，不做大接口（避免上帝对象）
+     - 配置只调策略，不定义流程
+   - 更新 M1 里程碑：`.cache/index.db` DDL 和精准读取接口清单（O4 消解）
+   - 补充 M6 里程碑：自动模式版本链叠加视图的实施要点
+   - 更新 M4 里程碑：两审任务书单源（事实审查 + 编辑审）
+   - 更新 "下一个可立即开工的任务" 章节
+
+3. `v7-prd.md` (保持 1.0)
+   - 不修改 PRD 1.0（已定稿）
+   - 决策细节只记录在 spec 中
+
+4. `multi-agent-adaptation-spec-2026-06-05.md` (v3.2 → v3.3)
+   - 明确两审的两种模式：完整模式（两个新鲜上下文）vs 兼容模式（单 agent 顺序执行）
+   - 澄清"兼容模式会诚实声明隔离度下降"
+   - 更新审稿清单定义（参考 v6 reviewer schema）
+
+**RFC 反馈采纳清单**（记录在文档中）：
+- ✓ 规划流程确认点 — 已在 PRD §2 体现（建书→卷纲→章纲→初稿→审稿）
+- ✓ 主角动机检查 — 纳入编辑审清单
+- ✓ 多宿主编排模式 — 明确完整模式 vs 兼容模式
+- ✓ 审稿维度优化 — 基于 v6 经验调整为两审（事实审查 + 编辑审）
+- → 文风对齐 — 放入 7.x backlog（文风指纹、scene beat 标签）
+- → 语义召回 — 放入 7.x/plugin backlog（可选能力，不作为事实来源）
+
+## Design Decisions
+
+### D1: 审稿维度调整（基于 v6 经验）
+
+**决策**：从"三审"调整为"两审"，去掉主观的"读者审"
+
+**方案对比**：
+
+| 维度 | v6 (reviewer) | v7 spec 0.6 (三审) | v7 新方案 (两审) |
+|------|--------------|-------------------|-----------------|
+| 事实验证 | 5 维度 | 设定校对 | **事实审查**（5 维度 + v7 特有项） |
+| 结构/商业 | 无 | 编辑审 | **编辑审**（细化 + 主角动机） |
+| 主观评价 | 无（明确禁止） | 读者审（爽不爽） | **去掉**（留给作者） |
+
+**新的两审定义**：
+
+**1. 事实审查**（AI，新鲜上下文）
+- v6 的 5 个维度：
+  - 设定一致性：能力/地点/物品是否符合世界观
+  - 时间线：时间衔接、倒计时、角色位置
+  - 叙事连贯：钩子回应、场景转换、情绪弧
+  - 角色一致性：对话风格、行为动机、知识边界
+  - 逻辑：因果关系、角色决策、力量对比
+- v7 特有的三项：
+  - "要写到的事"逐条核对正文
+  - 机检泄密候选的语义判断
+  - 条目履历引用的章内证据验证
+- 输出：结构化问题清单（severity + category + blocking）
+
+**2. 编辑审**（AI，新鲜上下文）
+- 结构：开头/转折/高潮/收尾是否到位
+- 节奏：信息密度、情绪起伏
+- 商业性：钩子强度、追读力（用知识库标准提示，不终审）
+- **主角动机**（RFC 反馈新增）：
+  - 主角每个主要行动是否有即时驱动、可见压力、预期收益、情绪原因
+  - 或明确标注为非理性行为
+- 输出：结构化问题清单
+
+**关键原则**（继承 v6）：
+- ✅ 只报可验证的问题（必须有 evidence）
+- ✅ severity + blocking 机制（critical 自动阻断）
+- ❌ 不评价文笔质量（除非是可计数的句式问题，归机检）
+- ❌ 不评价"爽不爽"（AI 无法代替真实读者，作者自己读草稿就是最好的读者审）
+
+**理由**：
+1. v6 实践证明：5 维度事实审查是有效的，可验证的
+2. "爽不爽"是高度主观的，v6 明确禁止主观评价
+3. 作者在第 7 步审稿时通读草稿，本身就是最好的读者视角
+4. 两个新鲜上下文比三个更经济，且覆盖了所有可验证维度
+
+**多宿主适配**：
+- 完整模式：事实审查 + 编辑审各用独立上下文
+- 兼容模式：单 agent 顺序执行两审，诚实声明隔离度下降
+
+### D2: 审稿终止机制（来自 RFC 遗漏分析）
+
+**问题**：Discussion #118 用户 shuimushanjia 反馈："每次让AI审查修改后，再次审查又会出现新的问题，似乎无穷无尽"
+
+**决策**：明确审稿终止条件，避免无限循环
+
+**方案**：
+1. **两审输出结构化问题清单**，每个问题包含：
+   - `severity`: critical / high / medium / low
+   - `category`: 问题分类
+   - `blocking`: 是否阻断定稿（critical 默认 true）
+   - `description` + `evidence` + `fix_hint`
+
+2. **阻断规则**：
+   - 只有 `blocking=true` 的问题阻断定稿
+   - `severity=critical` 自动 `blocking=true`
+   - 其他 severity 由 AI 判断是否 blocking
+
+3. **作者审稿时的选择**：
+   - 接受当前版本（即使有非阻断问题）
+   - 改完接受（修改后不重新审稿，直接定稿）
+   - 打回重写
+
+4. **系统不强制完美**：
+   - 非阻断问题作为"优化建议"，不强制修改
+   - 作者可以在审稿单上标注"已知问题，接受现状"
+
+**理由**：
+1. v6 实际使用中存在审稿循环问题，v7 必须有明确解法
+2. v6 的 reviewer 已有 severity + blocking 机制（参考 `webnovel-writer/references/review-schema.md`）
+3. 两审调整减少了主观评价，但仍需要明确的终止机制
+4. 作者应该有权决定"够好了"，系统不应追求不可达的完美
+
+**实施要点**：
+- spec 0.7 §8（写章流程）明确审稿终止条件
+- multi-agent-spec v3.3 更新两审的输出格式（参考 v6 review schema）
+- 审稿报告模板明确区分"阻断性问题"和"优化建议"
+
+### D3: 未登记伏笔检测（来自 Discussion #118 深度核验）
+
+**问题**：v7 伏笔系统是纯声明制，只跟踪细纲声明、front matter 登记过的条目。AI 在写稿步（§8 第 4 步，干净上下文）即兴埋的钩子，无对应条目 → 不进"悬了太久"、卷复盘扫不到 → 烂尾。正是 shuimushanjia（06-22）反馈的"埋了一个伏笔之后就没了下文，似乎没将这判定为伏笔"。
+
+**决策**：给声明制加"补漏网"——在事实审查中检测正文里的疑似未登记伏笔，作为**非阻断候选**提示作者。
+
+**方案**：
+- **落点**：事实审查（§8 第 6 步），搭已有的整章通读。现检查是单向"声明推进了，正文真有吗"；新增反方向"正文出现疑似伏笔，反查有无条目"——同一次读取，边际成本≈0。
+- **形态**：结构化问题清单新增 `category=unregistered_thread`，`severity` low/medium，**`blocking` 永远 false**；走信息差泄密扫描同款"候选制，不拦截"（§4.3 模式）。
+- **作者裁决**（审稿单第 7 步三选）：登记成条目（触发"开新条目必须写收尾计划"，自动防悬空）/ 忽略（普通描写）/ 删掉。
+- **误报控制**：判定门槛保守，仅捞"刻意强调 + 明显悬置 + 本章无即时解释 + 结构像 setup"者。非阻断，误报代价低，但宁紧勿松。
+
+**理由**：
+1. shuimushanjia 抱怨的不是"系统忘了已登记的坑"（v7 防得很死），而是声明制天生看不见 AI 即兴挖的坑。
+2. 搭已有整章通读，成本几乎为零；非阻断，风险小。
+3. 对口最高频反馈，适合纳入 v7.0。
+
+**实施要点**：
+- spec 0.7 §8 第 6 步事实审查职责增列 `unregistered_thread` 候选检测。
+- multi-agent-spec v3.3 事实审查 category 取值表加 `unregistered_thread`。
+
+### D4: 设定↔大纲单向依赖（来自 freezero2020 反馈，2026-06-26）
+
+**问题**：freezero2020 反馈"设定集与大纲互相交叉，改一处牵连多文件、频繁不同步"，希望单向关联。v7 目录层已三分（`定稿/设定` 只进不改 / `大纲` 随时改 / `文风` 独立），主体诉求已满足，但依赖方向只是**隐含**单向，未显式成约束。
+
+**决策**：在 spec §1 设计不变量补一条显式约束。
+
+**方案**：
+- 不变量文字：**"设定层只记已发生的客观事实，不写排程/章节安排；依赖单向：大纲 → 设定，设定不反向引用大纲条目编号或卷号排程。"**
+- 纯文档约束，零代码成本。
+
+**理由**：v7 结构本已是这个方向，写死不变量可防止后续实现把排程内容混入角色卡/世界观，直接回应 freezero2020。
+
+**实施要点**：spec 0.7 §1 不变量列表增补一条；§4.2 角色卡说明可补一句"不写章节排程"。
+
+### R3: RFC 公开跟进（❌ 取消）
+
+~~在 Discussion #118 发布跟进评论~~
+
+**决定**：暂不发布 RFC 跟进评论，只完成文档更新和 git 提交。
+
+理由：文档更新完成后可以根据实际情况再决定是否发布评论。
+
+### R4: master README 更新（待执行）
+
+在 master 分支 README 添加 v7 状态板块：
+
+**内容要点**：
+- v6.x 当前稳定版状态（维护模式，仅修 bug）
+- v7 设计已定稿，实施进行中
+- 链接到 v7 分支的 PRD、spec、实施计划
+- 里程碑进度（后续定期更新）
+
+### R5: v7 分支清理（待执行）
+
+处理 v7 分支当前的 git 状态：
+- 14 个 `.trellis/` 修改文件需要评估：是否与 v7 任务相关？是否应提交？
+- 确保所有 v7 文档更新都提交到 v7 分支
+
+## Acceptance Criteria
+
+- [ ] A1/A2/A3 三个决策问题都有明确方案并记录在案
+- [ ] 相关文档已根据决策更新，无遗留"待定"或冲突描述
+- [ ] Discussion #118 已发布跟进评论，说明反馈采纳情况
+- [ ] v7 → master PR 已准备好或已提交
+- [ ] 所有更新已提交到 v7 分支，git 状态干净
+
+## Out of Scope
+
+- v7.0 的实际实施工作（编写代码）— 这只是设计收尾和文档准备
+- 7.x backlog 功能的设计细节（文风对齐、语义召回等）
+- 已在报告中标记为"需要澄清"但不阻塞 v7.0 的 spec 边界问题（B1-B4）— 可以作为文档微调处理
+
+## Confirmed Facts from Codebase
+
+- RFC 征集期已在 2026-06-12 开始（Discussion #118），原计划 ~06-19 收口（已过期）
+- v7 实施计划（`v7-implementation-plan.md`）已存在，状态为草案 0.1（2026-06-13）
+- 实施计划定义了 7 个里程碑（M0-M7），RFC 收口是硬节点，收口后才能开始 M1 格式层代码
+- 当前 v7 代码量为 0 行（`webnovel-writer/` 是冻结的 v6 遗产）
+- 现有文档状态：
+  - PRD 1.0 已定稿（2026-06-12）
+  - story-repo-spec 0.6（按 PRD 1.0 修订）
+  - multi-agent-adaptation-spec v3.2
+  - 后端开发规范基线 1.0（`.trellis/spec/backend/`）
+- 当前 git 状态：v7 分支有 14 个未提交文件（全部是 `.trellis/` 工作流系统更新）
+
+## Technical Context
+
+**A1 背景**：
+- story-repo-spec 0.6 §8.1 描述自动模式"定稿+待定稿批次"叠加视图
+- 当前 spec 未定义：批次内第 K 章打回后，K+1 到 N 章已依赖 K 的预登记事实时如何处理
+
+**A2 背景**：
+- spec 0.6 §2.2 要求 Node >= 22，使用内置 `node:sqlite` 实现零第三方依赖
+- 反馈报告指出 `node:sqlite` 在早期 Node 22 需要 `--experimental-sqlite` flag
+- Node v22.13.0+ 才不需要 flag，但模块仍为 release candidate 状态
+
+**A3 背景**：
+- spec 0.6 §5 定义三类线索条目（伏笔/悬念/感情线），每条有履历字段记录证据
+- spec 要求 cache rebuilder 作为格式参考实现，三审负责校验证据真实性
+- 当前 spec 未定义履历证据的结构化格式（如"见本章结尾对峙段"无法脚本验证）
+
+## Decisions Summary
+
+所有核心决策已完成，无阻塞性开放问题。
+
+1. **A1 决策结果**：采用方案 2（版本链叠加）✓
+   - 理由：符合实际写作情况，批次内章节需要连续性（新角色、伏笔在前章出现，后章继续发展）
+   - 实现要点：
+     - 支持批次内依赖，第 K+1 章可以使用第 K 章的预登记事实
+     - 当第 K 章被打回时，标记 K+1 到 N 章为"受影响"，需重新审核或重写
+     - 需要设计污染传播机制和作者确认流程（整批重写 vs 逐章确认）
+   
+2. **A2 决策结果**：Node >= 22.13.0 + 提示升级（无降级方案）✓
+   - 版本要求：Node >= 22.13.0（`node:sqlite` 无需 flag 的最低版本）
+   - 降级方案：不实现文件缓存降级，版本不足时给出清晰的升级指引
+   - 理由：
+     - Node 22.13.0 发布已 1.5 年，LTS 用户自然更新已覆盖
+     - v7 是全新重写，可以设定更高的技术门槛
+     - 保持"零第三方依赖"和单一缓存实现的简洁性
+     - 本地测试确认 Node 24.15.0 中 `node:sqlite` 可用
+   - 实现要点：安装器检测 Node 版本，< 22.13.0 时给出人话升级指引
+
+3. **A3 决策结果**：章节级别锚点 + 自然语言描述 ✓
+   - 格式：`第152章：主角在北境对峙时首次察觉真相`（保持现状）
+   - 验证范围：
+     - 重建器：只验证章节文件存在（脚本能做的）
+     - 三审：读取整章验证语义（AI 能做的）
+   - 理由：
+     - 网文章节长度 2000-3000 字，全文读取压力可接受
+     - 避免段落编号维护的复杂性和易错性
+     - 符合 PRD 原则"脚本能做的归脚本，做不到的归 AI 语义判断"
+     - 作者手改正文后不会破坏锚点引用
+   - 实现要点：spec 需明确"履历证据的章节引用由重建器验证存在性，语义正确性由三审负责"
+
+4. **合并时机决策**：暂不合并，master 保持 v6 稳定 ✓
+   - 做法：
+     - master 分支继续维护 v6（bug 修复）
+     - master README 更新 v7 重要进度说明（设计状态、里程碑进展）
+     - v7 分支独立开发，直到确认 v7 可以替代 v6
+     - 最终合并时机：v7.0 beta 测试通过，确认可替代 v6 后一次性合并
+   - 理由：
+     - 避免 master 长期处于"设计已公开但不可用"状态
+     - v6 用户不受 v7 开发影响，保持稳定性
+     - v7 有独立分支可以自由迭代，不受 master 约束
+   - 实现要点：
+     - 在 master README 添加 v7 状态板块（链接到 v7 分支的 PRD/实施计划）
+     - 定期（每个里程碑完成时）更新 master README 的 v7 进度说明

.trellis/tasks/06-26-rfc-followup/research/discussion-118-gap-analysis.md

@@ -0,0 +1,349 @@
+# Discussion #118 评论遗漏分析
+
+## 分析范围
+
+- **原始数据**：Discussion #118 的 7 条评论（2026-06-12 至 2026-06-22）
+- **对照基准**：`docs/architecture/v7-rfc-feedback-report-2026-06-16.md`
+- **分析目标**：识别反馈报告未覆盖或处理不充分的关键反馈
+
+---
+
+## 一、已在反馈报告中覆盖的要点
+
+### 1.1 Token 成本与弱模型现实
+- ✅ **yedonglai8-lab (06-12)**："claude opus4.8 大纲还没读完，先破产了。token烧的有点厉害，其他都是棒棒的。用deepseek v4 pro不能看"
+- 报告覆盖：§1 "Token 成本与弱模型现实"，明确提到 Claude 预算消耗和 DeepSeek v4 Pro 指令遵循能力差
+
+### 1.2 规划流程缺少确认点
+- ✅ **Chained1001 (06-12)**："V6 版本的 /webnovel-plan 环节会同步生成卷纲与章纲，二者生成流程相互绑定。用户无法先调整优化卷纲，再单独生成章纲。"
+- 报告覆盖：§2 "规划流程需要作者确认点"，完整引用该反馈并提出明确停顿点方案
+
+### 1.3 主角动机/目标检查
+- ✅ **Chained1001 (06-13)**："能否单独新增主角动机 / 目标这一项？目前 AI 生成剧情时常出现主角行为逻辑薄弱的问题，比如无故辗转地点、贸然冒险，行动缺乏合理支撑。"
+- 报告覆盖：§3 "主角动机 / 目标检查"，建议纳入三审清单
+
+### 1.4 文风对齐方法
+- ✅ **wangwwno1 (06-13)**：完整的文风分析方法（风格指纹、原子模式、复合语群、逐段约束、从修改中学习）
+- 报告覆盖：§4 "文风对齐 / 作者声音"，认可方向并建议放入 7.x 设计空间
+
+### 1.5 Codex 多宿主编排
+- ✅ **Fahaoxi (06-14)**："很喜欢这个项目，也试着将其迁移到codex上运行。个人感觉最优的方式还是让一个主控ai来调控负责阶段推进、ready payload、验收和阻断"
+- 报告覆盖：§5 "Codex / 多宿主编排"，建议定义两种模式（兼容模式 vs 质量模式）
+
+---
+
+## 二、遗漏的关键反馈
+
+### 2.1 术语自然度反馈 — 完全遗漏
+
+**来源**：Chained1001 (06-13 03:59)
+
+**原文**：
+> "大佬，还有个问题想请教。你之前列出的评判维度：伏笔、悬念、感情线、细纲、审稿、吃书、全书近况，麻烦帮忙看看其中有没有表述生硬、不合适的地方。"
+
+**性质**：直接回应 RFC 主文"征集意见"第 1 条（术语是否自然）
+
+**遗漏原因**：
+- 该评论同时提出了两个问题：术语反馈 + 主角动机建议
+- 反馈报告只提取了主角动机部分（§3），完全忽略了术语自然度反馈
+- 这是用户对 RFC 正式提问的直接回应，属于最应该处理的反馈类型
+
+**实际影响**：
+- 用户明确请求对术语表进行评审（"麻烦帮忙看看"）
+- 维护者未在 Discussion 中回复该问题
+- 反馈报告也未记录该反馈或说明"无术语反馈"
+
+### 2.2 审稿无限循环问题 — 覆盖不足
+
+**来源**：shuimushanjia (06-22 06:16)
+
+**原文**：
+> "个人在用AI写小说遇到的一点问题：每次让AI审查修改后，再次审查又会出现新的问题，似乎无穷无尽。AI似乎很难站在一个正真的作者角度统筹把握整本书，经常在前文故作高深埋了一个伏笔之后就没了下文，似乎没将这判定为伏笔。AI对一些设定的理解不够深刻，在正文中表现不出设定的亮点。"
+
+**问题拆解**：
+1. **审稿循环问题**："每次让AI审查修改后，再次审查又会出现新的问题，似乎无穷无尽"
+2. **伏笔追踪失效**："经常在前文故作高深埋了一个伏笔之后就没了下文，似乎没将这判定为伏笔"
+3. **设定理解浅薄**："AI对一些设定的理解不够深刻，在正文中表现不出设定的亮点"
+
+**报告覆盖情况**：
+- ❌ 审稿循环问题：**完全未提及**
+- ⚠️ 伏笔追踪问题：隐含在 §3（三审负责"伏笔、悬念、感情线"检查），但没有明确说明如何防止"埋了没用"
+- ⚠️ 设定理解问题：隐含在 §1（弱模型指令遵循问题），但没有具体到"设定表现不出亮点"
+
+**为何重要**：
+- 审稿循环是 v6 实际使用中的严重体验问题，直接影响工作流可用性
+- 该问题在 2026-06-22 提出（RFC 反馈报告 06-16 之后），但报告未更新
+- v7 的三审机制（读者审、编辑审、设定校对）是否能解决审稿循环？报告未说明
+
+### 2.3 文风标注的 Token 成本权衡 — 覆盖浅薄
+
+**来源**：wangwwno1 (06-13 06:37)
+
+**原文**：
+> "是的，而且我为了便宜用dsv4，它文风不稳定，比其他模型更需要显式约束进行引导。考虑到文风只能在草稿层面落实，最合适的做法应该是在草稿上一层，也就是规划每一个场景的节奏时确定。我不太熟悉网文写作，但这看起来对应网文中的章纲？在这一阶段需要确定核心冲突，冲突的解决过程，制定故事节拍。目前我是在节拍引入风格标记，告诉模型应该采用哪些手法来落实这部分内容。这样模型可以结合当前的故事节奏、涉及的意象和伏笔等一系列信息，来分析什么写法最合适，并写到细纲里。"
+
+**核心洞察**：
+1. **弱模型需要显式文风约束**："dsv4 文风不稳定，更需要显式约束"
+2. **文风应在章纲层引入**："最合适的做法应该是在草稿上一层，也就是规划每一个场景的节奏时确定"
+3. **节拍级别的文风标记**："在节拍引入风格标记，告诉模型应该采用哪些手法"
+
+**报告覆盖情况**：
+- ⚠️ 报告 §4 提到"在场景/章纲层就放入文风指导"，但没有明确：
+  - 弱模型可能**必须**有文风约束才能稳定输出（不是可选优化）
+  - 节拍级标记是解决 token 成本的关键（不是全局模板）
+- ⚠️ 报告提到"携带文风指导会增加 token 成本"，但没有提到用户已经给出解法：**节拍级别标记 + 章纲时确定**，而不是草稿时全文携带
+
+**为何重要**：
+- 这直接关系到 v7 对弱模型的承诺范围（§1 建议的"兼容模式"应该包含什么？）
+- 用户已经验证的实施路径（节拍标记）应该进入 v7.0 设计考量，而不是笼统地"放入 7.x"
+
+### 2.4 AI 的"中庸不出错"倾向 — 未处理
+
+**来源**：shuimushanjia (06-22 06:16)
+
+**原文**：
+> "有一点我很认可：AI训练了大量语料知识，有好的有差的，特别是质量中等的内容很多。那么AI在思考问题时更偏向于输出中庸不出错的回答。AI写的小说总感觉差口气，哪怕把大纲与细纲都写好，只让AI填充正文，还是感觉差点意思。这样如何让AI给出高质量回答是个难题。"
+
+**核心问题**：
+- AI 输出"中庸不出错"，即使有完整大纲和细纲，正文质量仍然"差口气"
+- 这是对 AI 辅助写作**根本可行性**的质疑
+
+**报告覆盖情况**：
+- ❌ 完全未提及
+- 该问题在 2026-06-22 提出（反馈报告 06-16 之后）
+
+**为何重要**：
+- 这是对 v7 核心价值主张的挑战："把流程和检查做得再好，AI 写的东西还是平庸怎么办？"
+- 如果维护者认可这个现实，应该在 v7 承诺中明确：系统的目标是"可用的初稿"而不是"发表级正文"
+- 如果维护者有解法（如文风对齐、审稿机制），应该说明为什么 v7 能改善这个问题
+
+---
+
+## 三、时间线问题
+
+### 3.1 反馈报告日期 vs 实际评论时间
+
+- **反馈报告日期**：2026-06-16
+- **报告覆盖的评论**：截至 2026-06-14 的 6 条评论（最后一条是 Fahaoxi 的 Codex 迁移）
+- **遗漏评论**：shuimushanjia 的评论（2026-06-22），共 1 条
+
+**问题**：
+- 反馈报告标题是"v7 RFC 反馈合并报告"，但实际只覆盖到 06-14
+- 06-22 的评论包含两个重要问题（审稿循环、AI 平庸倾向），完全未纳入
+- RFC 征集期原计划 ~06-19 收口，但 06-22 仍有新评论，说明征集期实际延长或未明确关闭
+
+---
+
+## 四、建议处理方式
+
+### 4.1 术语自然度反馈 — v7.0 前处理
+
+**建议**：
+1. 在 Discussion #118 回复 Chained1001，说明术语评审结果：
+   - 伏笔、悬念、感情线、细纲、审稿、吃书、全书近况 — 这些术语经内部审查和用户反馈，认为自然、无需修改
+   - 或指出具体调整（如有）
+2. 在 RFC 跟进评论中补充："术语自然度已收到反馈确认，无需调整"
+
+**理由**：
+- 这是 RFC 正式提问，用户明确请求反馈，不回复会显得忽略用户
+- 术语是格式层的一部分，RFC 阶段应该收口
+
+### 4.2 审稿无限循环 — 纳入 v7.0 设计
+
+**建议**：
+1. 在反馈报告补充 §2.6 "审稿循环终止机制"：
+   - **问题**：AI 审稿后修改，再审查又出现新问题，无限循环
+   - **v7 的解法**：
+     - 三审输出结构化问题清单，每个问题有 severity + blocking
+     - 只有 critical + blocking 问题阻断定稿，其他问题作为建议
+     - 作者审稿时可以选择"接受当前版本"（即使有非阻断问题），系统不强制完美
+   - **实施要点**：审稿报告模板应明确区分"阻断性问题"和"优化建议"
+2. 在 `story-repo-spec` 补充审稿流程的终止条件
+
+**理由**：
+- 审稿循环是工作流可用性的核心问题，v7 必须有明确解法
+- v6 的 reviewer 已经有 severity 机制（可参考），但可能执行不严格
+
+### 4.3 伏笔追踪失效 — 澄清 v7 改进点
+
+**建议**：
+1. 在 RFC 跟进评论中说明 v7 如何改善"伏笔埋了没用"：
+   - 每条伏笔有独立档案，记录"何时埋下、推进到哪、计划何时收尾"
+   - 三审的"设定校对"环节会核对"本章应推进的伏笔是否真的写到正文"
+   - 搁置过久时系统提示"悬了太久"（提醒，不阻断）
+2. 明确 v7 **不承诺**的部分：
+   - 系统不负责"伏笔是否精彩"，只负责"是否遗漏"
+   - "故作高深埋伏笔但后续平庸"是创作质量问题，不是系统能解决的
+
+**理由**：
+- v7 的伏笔跟踪机制是核心卖点，应该明确对标 v6 的该问题
+- 但要诚实划定边界，避免过度承诺
+
+### 4.4 文风标注 Token 成本 — 纳入 7.x 具体方案
+
+**建议**：
+1. 在反馈报告 §4 补充用户已验证的路径：
+   - **节拍级文风标记**（在章纲确定，不是草稿时全文携带）
+   - 适合弱模型场景（DeepSeek v4 等）
+2. 在 7.x backlog 中明确：
+   - v7.0：不做文风标注
+   - v7.x：探索节拍级文风标记（参考 wangwwno1 方案）
+
+**理由**：
+- 用户已经给出具体实施路径，不应该笼统地"放入 7.x"
+- 节拍级标记与 v7 的"章纲 → 细纲 → 草稿"流程天然契合
+
+### 4.5 AI 平庸倾向 — 文档澄清
+
+**建议**：
+1. 在 PRD 或 README 明确 v7 的质量承诺范围：
+   - v7 的目标是"可用的初稿"，不是"免修改的发表稿"
+   - 系统负责流程、一致性、机械检查，不负责"文笔是否出彩"
+   - 作者的人类判断和修改仍然是必需的
+2. 在 RFC 跟进评论中回应该用户：
+   - 承认 AI 的"中庸不出错"是现实
+   - 说明 v7 通过文风铁律、禁词、审稿机制改善但不消除该问题
+   - 7.x 的文风对齐功能会进一步优化
+
+**理由**：
+- 这是对核心价值主张的质疑，必须正面回应
+- 诚实的边界承诺比回避问题更能建立信任
+
+### 4.6 反馈报告更新 — 补充 06-22 评论
+
+**建议**：
+1. 更新反馈报告标题或说明：
+   - "v7 RFC 反馈合并报告（截至 2026-06-14）"
+   - 或补充 §6 "后续反馈"覆盖 06-22 评论
+2. 在 RFC 跟进评论中说明：
+   - RFC 征集期实际截止日期
+   - 后续反馈的处理方式
+
+---
+
+## 五、优先级评估
+
+| 反馈项 | 优先级 | 建议动作 | 阻塞 v7.0 实施？ |
+|--------|--------|----------|-----------------|
+| 术语自然度反馈 | 高 | 回复用户 + RFC 跟进评论 | 否 |
+| 审稿无限循环 | **关键** | 补充 spec §审稿终止机制 | **是** |
+| 伏笔追踪失效 | 中 | RFC 跟进评论说明改进点 | 否 |
+| 文风标注成本 | 中 | 更新 7.x backlog 具体方案 | 否 |
+| AI 平庸倾向 | 高 | 文档澄清质量承诺边界 | 否 |
+| 反馈报告更新 | 低 | 补充日期范围说明 | 否 |
+
+**关键发现**：
+- **审稿无限循环**是唯一可能阻塞 v7.0 实施的遗漏问题
+- v7 必须有明确的审稿终止机制，否则会重现 v6 的该问题
+
+---
+
+## 六、与现有决策的交叉验证
+
+### 6.1 两审调整 vs 审稿循环
+
+PRD (06-26) 已经决策：从"三审"调整为"两审"（事实审查 + 编辑审），去掉主观的"读者审"。
+
+**关联**：
+- 去掉"读者审"（爽不爽）可以减少主观评价带来的审稿循环
+- 但 shuimushanjia 的问题是"事实问题无穷无尽"，不是主观评价问题
+- **两审调整未必能解决审稿循环，仍需要明确的终止机制**
+
+### 6.2 主角动机检查 vs 行为逻辑问题
+
+PRD 已纳入"主角动机检查"到编辑审（RFC 反馈 Chained1001）。
+
+**关联**：
+- shuimushanjia 的"伏笔埋了没用"和"设定表现不出亮点"是更深层的问题
+- 主角动机检查只覆盖"行动逻辑"，不覆盖"伏笔追踪"和"设定理解"
+- **需要在事实审查中明确"伏笔履历验证"的职责**
+
+---
+
+## 七、总结
+
+### 7.1 反馈报告完整性评估
+
+- **覆盖率**：5/7 条评论，71%
+- **遗漏**：1 条完全遗漏（06-22），1 条部分遗漏（术语反馈）
+- **深度**：对已覆盖评论的提取较完整，但缺少"为什么 v7 能解决该问题"的说明
+
+### 7.2 关键遗漏优先级
+
+1. **审稿无限循环** — 必须在 v7.0 前设计终止机制
+2. **术语自然度** — 用户正式提问，必须回复
+3. **AI 平庸倾向** — 需要澄清质量承诺边界
+4. **文风成本权衡** — 用户已给出解法，应纳入 7.x 具体方案
+
+### 7.3 建议后续动作
+
+1. 更新 `story-repo-spec` 补充审稿终止机制（§8.6）
+2. 在 Discussion #118 回复 Chained1001 的术语反馈
+3. 发布 RFC 跟进评论，补充遗漏反馈的处理情况
+4. 更新反馈报告或标注日期范围
+
+---
+
+**分析完成时间**：2026-06-26  
+**分析依据**：Discussion #118 完整评论（7 条）+ RFC 反馈报告 2026-06-16
+
+---
+
+## 八、补充分析（2026-06-27）：新评论 + v7 逐条核验
+
+> 本节是对 2026-06-26 分析的补订。两个动因：①出现第 8 条评论（freezero2020，06-26），原分析未收录；②原分析对照的是「反馈报告」，本节改为**直接对照 v7 spec 0.7**，给出"v7 是否已解决"的实判。
+
+### 8.1 新评论：freezero2020（2026-06-26）— 设定集与大纲解耦
+
+**原文**：
+> 设定集可否不关联大纲的内容，设定集里只保留设定的原意，其他与大纲有关的（类似章节安排）放在单独的文件里。我在设定完成后，尝试安排不同的文风、进度，结果发现每次改动都会涉及相当多的文件，经常发生大纲与设定集不同步……感觉将大纲与设定集最好单向关联，且在不同阶段给予不同的优先级似乎要好一些。
+
+**诉求拆解**：①设定只存"设定原意"，章节排程类内容挪出；②大纲↔设定双向交叉导致改一处牵连多文件、频繁不同步；③希望**单向关联** + 分阶段优先级。
+
+**v7 现状核验**：v7 在**目录层已三分**，比 freezero2020 设想的更彻底——
+- `定稿/设定/`（只进不改，已发生的客观事实记账）
+- `大纲/`（作者意图，随时可改）
+- `文风/`（品味库，独立顶层）
+
+文风、进度（卷纲）已各自独立可改，角色卡只记客观事实（境界/位置/持有/状态），不含排程。**主体诉求 v7 已满足**。
+
+**残留 gap**：v7 是**隐含**单向（大纲引用设定正名，设定只做事实记账），但 §1 不变量未**显式写死**"设定层不得写排程/章节安排、依赖方向单向"。→ 处置见 §8.3 决策 D4。
+
+### 8.2 新发现的真缺口：未登记伏笔检测（呼应 shuimushanjia 06-22）
+
+shuimushanjia 的伏笔抱怨在原分析 §2.2/§4.3 已部分处理，但**定性不准**。重新核验 v7 流程后定性如下：
+
+- v7 伏笔系统是**纯声明制**：只跟踪细纲「本章要写到的事」声明过、front matter 登记过的条目（§7→§8→§4.1→§5）。对"规划阶段就想好的伏笔"闭环完备（收尾计划必填、悬了太久、卷复盘清账）。
+- **盲区**：§8 第 4 步写稿是「AI 干净上下文」，AI 可能在正文里**即兴埋钩子**。但只有声明过的才会在第 8 步入账。即兴埋的坑无条目 → 不进"悬了太久"、卷复盘扫不到 → 烂尾。这**正是** shuimushanjia 说的"埋了一个伏笔之后就没了下文，似乎没将这判定为伏笔"。
+- 结论：shuimushanjia 抱怨的**不是**"系统忘了已登记的坑"（那部分 v7 防得很死），而是**声明制天生看不见 AI 即兴挖的坑**。→ 处置见 §8.3 决策 D3。
+
+### 8.3 两条确定的设计处置（收敛为 D3 / D4，详见 prd.md / design.md）
+
+**D3：未登记伏笔检测（给声明制加补漏网）**
+- 落点：**事实审查**（§8 第 6 步），搭已有的整章通读——现检查是"声明推进了，正文真有吗"，新增反方向"正文出现疑似伏笔，反查有无条目"，同一次读取，边际成本≈0。
+- 形态：结构化问题清单新增 `category=unregistered_thread`，`severity` low/medium，**`blocking` 永远 false**；走信息差泄密扫描同款"候选制，不拦截"。
+- 作者裁决（审稿单第 7 步）：登记成条目（触发收尾计划必填，自动防悬空）/ 忽略（普通描写）/ 删掉。
+- 风险：误报。判定门槛**保守**——仅捞"刻意强调 + 明显悬置 + 本章无即时解释 + 结构像 setup"者；非阻断，误报代价低，但宁紧勿松。
+- 版本：可进 **v7.0**（成本低、对口最高频反馈、非阻断风险小）。
+
+**D4：设定↔大纲单向依赖（不变量）**
+- 落点：spec §1 设计不变量补一条——"**设定层只记已发生的客观事实，不写排程/章节安排；依赖单向：大纲 → 设定，设定不反向引用大纲条目编号或卷号排程**"。
+- 性质：纯文档约束，零代码成本，直接回应 freezero2020。
+- 版本：v7.0（spec 0.7 文字增补）。
+
+### 8.4 其余反馈的 v7 核验结论（速查）
+
+| 反馈 | v7 判定 | 依据 |
+|---|---|---|
+| 审稿无限循环（shuimushanjia） | ✅ 已解决 | §8 审稿终止机制（D2）；"改完接受不重审"=循环终止保证 |
+| 多视角审核（onenuo28） | ✅ 已解决 | 两审各自新鲜上下文 |
+| 主控编排/ready payload（Fahaoxi） | ✅ 已解决 | 状态机单入口 §10 + 备料 §8.3 |
+| 设定/大纲解耦（freezero2020） | 🟡 主体已解决，补 D4 | 目录三分；缺单向依赖不变量 |
+| 伏笔即兴埋坑（shuimushanjia） | 🟡 补 D3 | 声明制盲区 |
+| 文风对齐/节拍标记（wangwwno1 等） | ⛔ v7.0 不做，7.x | 建议细纲节拍预留"手法标签"字段位，低成本铺路 |
+| AI 中庸/设定不出彩（shuimushanjia） | ⚠️ 边界 | 文风铁律+best-of-N+编辑审缓解，不消除；PRD 明确"可用初稿"承诺 |
+
+---
+
+**补充分析完成时间**：2026-06-27  
+**补充依据**：Discussion #118 第 8 条评论（freezero2020 2026-06-26）+ story-repo-spec 0.7 全文核验

.trellis/tasks/06-26-rfc-followup/task.json

@@ -0,0 +1,26 @@
+{
+  "id": "rfc-followup",
+  "name": "rfc-followup",
+  "title": "v7 RFC 后续推进",
+  "description": "RFC 反馈收口与文档更新：A1/A2/A3 决策、D1 两审、D2 审稿终止机制、D3 未登记伏笔检测、D4 设定↔大纲单向依赖；落地 spec 0.7 / multi-agent-spec v3.3",
+  "status": "planning",
+  "dev_type": null,
+  "scope": null,
+  "package": null,
+  "priority": "P1",
+  "creator": "codex",
+  "assignee": "claude",
+  "createdAt": "2026-06-26",
+  "completedAt": null,
+  "branch": null,
+  "base_branch": "v7",
+  "worktree_path": null,
+  "commit": null,
+  "pr_url": null,
+  "subtasks": [],
+  "children": [],
+  "parent": null,
+  "relatedFiles": [],
+  "notes": "",
+  "meta": {}
+}