Procházet zdrojové kódy

docs(v7): M6 spec 回填——spec 0.12(决策 36-37)/multi-agent v3.7/计划出口达成 + 任务工件

- story-repo-spec 0.12:§3 连写无条目变动上限键;§8.1 批次三件套/三态/污染传播收口(0.7 留白)/stage 前置审稿单/质检判据;整批不要更正为丢弃批次;§8 第 8 步定稿含条目创建(threadCreates 缺口,决策 37)
- multi-agent v3.7:SKILL 自动模式段同步;§5.1 批次暂存不开第二条写入路径
- v7-implementation-plan §M6 出口达成标注(含两处实现偏离记录)
- backend database-guidelines §7:工作区暂存数据四条约定
- M6 任务工件(prd/design/implement/jsonl),AC1-AC7 复核打勾
lingfengQAQ před 11 hodinami
rodič
revize
f514a31ee8

+ 10 - 0
.trellis/spec/backend/database-guidelines.md

@@ -54,3 +54,13 @@
 
 - [ ] 各表的列定义与索引(实现 O4 精准读取接口时定稿)
 - [ ] 重建器的增量更新策略(全量重建 vs 按 commit 增量)
+
+## 7. 工作区暂存数据(自动模式批次,M6 起)
+
+7.1 `工作区/待定稿/` 是机器域暂存区:`批次.json`/`定稿包.json` 是机器域 JSON,不受防呆方言约束;`草稿.md` 的 front matter 仍必须用防呆序列化器写出(作者可能打开看)。批次数据必须只经 `src/staging/index.js` 读写,消费点禁止绕过该模块直读批次文件。
+
+7.2 staged 数据**禁止进入任何缓存表与 meta 统计**(`fingerprints` 与 `imagery_top` 只算定稿):staged 章可能被打回,入表即破坏 §2.5 的确定性重算与 §2.2 的"删缓存重建一致"。叠加视图必须从工作区文件现读。
+
+7.3 叠加消费点(备料/审稿输入/机检)必须以"批次存在"为总开关:无批次时零额外 IO、零行为变化(既有全量测试是该不变量的回归面)。
+
+7.4 `批次.json` 损坏必须从章目录扫描重建元数据,恢复的章状态一律保守置"受影响"——宁可多一轮重审,禁止臆断为"待审收"。

+ 1 - 0
.trellis/tasks/07-04-m6-auto-mode/check.jsonl

@@ -0,0 +1 @@
+{"_example": "Fill with {\"file\": \"<path>\", \"reason\": \"<why>\"}. Put spec/research files only — no code paths. Run `python .trellis/scripts/get_context.py --mode packages` to list available specs. Delete this line once real entries are added."}

+ 131 - 0
.trellis/tasks/07-04-m6-auto-mode/design.md

@@ -0,0 +1,131 @@
+# M6 自动模式 design
+
+## 1. 总体结构:批次是工作区数据,脚本判定、宿主执行
+
+```
+工作区/待定稿/
+  批次.json                    批次元数据(真源,机器域 JSON)
+  0006-夜探藏经阁/
+    草稿.md                    front matter + 正文(终稿形态)
+    定稿包.json                完整 finalize payload(预登记的机器形态)
+    审稿单.md                  该章两审产物(批量审稿呈报用)
+  0007-.../
+
+src/staging/index.js(新模块,批次真源的唯一读写点)
+  ├─ readBatch(repoPath)                → {exists, 起章, 章列表:[{章号,标题,状态,目录}], 连续无条目变动}
+  ├─ stagedFacts(repoPath)              → 叠加视图用事实包(见 §2.2)
+  ├─ stageChapter(ctx, {chapterNum, payload}) → 校验+落盘+清工作区+停止判定
+  ├─ judgeStop(ctx, batch)              → {stop: bool, reasons: string[]}(四件套,纯脚本)
+  ├─ judgeBatchQuality(staged, baselineFp, config) → 质检判据(纯函数,零 IO)
+  ├─ rejectFrom(repoPath, chapterNum)   → K=打回,K+1..N=受影响
+  ├─ finalizeBatch(ctx)                 → 逐章 finalizeChapter,按章原子
+  └─ discardBatch(repoPath)             → 删批次
+
+commands/:stage-chapter / batch-status / finalize-batch / batch-reject / batch-discard(薄壳)
+消费点小改:prep/index.js、review/index.js、mechanical-check/index.js、state-machine/{index,dto}.js
+```
+
+写章八阶段与状态机零改动(spec §8.1);自动模式只是"第 7-8 步的确认与入档推迟到批末"。
+
+## 2. 模块契约
+
+### 2.1 批次.json(机器域,staging 模块独占读写)
+
+```json
+{
+  "起章": 6,
+  "章列表": [
+    { "章号": 6, "标题": "夜探藏经阁", "状态": "待审收", "目录": "0006-夜探藏经阁" },
+    { "章号": 7, "标题": "…", "状态": "受影响", "目录": "0007-…" }
+  ],
+  "连续无条目变动": 0
+}
+```
+
+- 状态 ∈ `待审收` | `打回` | `受影响`。stage-chapter 写入/覆盖时置`待审收`并重算计数;rejectFrom 置`打回`/`受影响`。
+- 目录名 = `NNNN-净化标题`(复用 ChapterWriter 的 sanitize 规则,抽公共 util 或复制口径并测一致)。
+- 损坏/缺失容错:批次.json 读不了但目录存在 → 从章目录扫描重建元数据(状态全部回`受影响`并人话说明——宁保守勿臆断);空目录=无批次。
+
+### 2.2 stagedFacts(叠加视图的数据面,全部来自批次文件,不碰缓存)
+
+```js
+{
+  chapters: [{ 章号, 标题, frontMatter, body }],        // 升序;来自各章 草稿.md
+  threads:  Map<id, {status, lastAdvanced}>,            // 由各定稿包 threadUpdates + 草稿声明推导
+  newEntities: Set<string>, newAliases: Set<string>,    // rosterUpserts 的 正名/别名
+  characterUpdates: Map<name, updates合并>,             // 后章覆盖前章同字段
+  timelineRows: [{volumeNum, row}],
+  secretWrites: [{id, frontMatter, content}],
+  总字数, 弱钩尾计数                                      // 近况叠加用的派生值
+}
+```
+
+- threads 推导口径:`threadUpdates[].updates.状态` 直接采信;开启类声明(草稿 front matter「埋下/设下/萌芽」)产生新条目 `进行` 态。与机检/审稿共用 `parseThreadDeclarations`,不双写。
+- 全部同步纯读文件;任何单章文件损坏 → 该章事实跳过并在返回 `warnings` 里如实说明(消费点原样透传给报告/材料,不静默)。
+
+### 2.3 stage-chapter(A3)
+
+前置校验(不过则零写入):
+- 章号 = 定稿 maxChapter + 已 staged 数 + 1(批内连续,不跳章不重章)
+- payload 完整性同 finalizeChapter 前置(章号整数、frontMatter.标题在)
+- `工作区/审稿.md` 存在(先审后暂存——与手动模式"作者过目审稿单"对应的自动模式不变量:**审稿单必须已生成**,作者批末统一看)
+
+落盘(writeAtomicBatch 原子批):草稿.md(payload.frontMatter+body 组回)、定稿包.json、审稿单.md(搬 `工作区/审稿.md` 内容)、批次.json 更新;随后清工作区单章文件(细纲/本章写作材料/草稿-A/审稿/评审报告——payload.workspaceFiles 并集)。
+返回:`{ok, staged: N, 停止: judgeStop 结果, output 人话}`。
+
+### 2.4 judgeStop 四件套(C1-C4,全零 token)
+
+1. 写满:`staged ≥ config.连写批次大小`
+2. 收卷/卷纲耗尽:末 staged 章 `收卷: 是` → 停(转卷复盘);下一章卷号(末 staged 章卷号,或其 +1 若收卷)无 `大纲/卷纲/第NN卷.md` → 停
+3. 连续无条目变动:批次.json 计数 ≥ `config.连写无条目变动上限`(默认 3;BookConfigReader defaults 加键)
+4. 质检不过线 judgeBatchQuality(staged 章、基线指纹行、config):
+   - 弱钩尾:staged 末尾连续弱钩数(口径同 book-status:`包含'弱钩'或以'-弱'结尾`)≥ `连续弱钩上限`
+   - 缺锚点:任一 staged 章 front matter 无「书内时间」
+   - 句式偏离:staged 全部正文合并 styleMetrics vs fingerprints 基线行,平均句长偏 ≥30% 或句长方差偏 ≥50%(复用 mechanical-check 容差常量,抽到 style-stats 或公共常量避免双写);无基线行 → 该判据静默跳过
+   返回 `{过线: bool, 原因: string[]}`,原因人话("批内连续 3 章弱钩,建议人工过一眼节奏")。
+
+### 2.5 叠加消费点(B2-B4,每处小改)
+
+- **prep**:`stagedFacts` 有章时——近章结尾取 staged 末两章 body 尾 150 字(不足再回定稿章补);时间线片段追加 staged rows(标注「批内预登记」);信息差边界并入 staged secretWrites(listUnrevealed 结果 + staged 未揭晓);全书近况行加「批内已暂存 X 章(第 A-B 章)」且总章数/字数/连续弱钩计入 staged。
+- **review-input**:相关条目并入 staged threads(新开条目以 `{id, type, 简述: 声明原文, 状态, 开启章}` 形态出现);名册/相关角色并入 newEntities/characterUpdates;时间线/信息差/近况同 prep 口径。
+- **mechanical-check**:`checkThreadDeclarations` 的 known Map 并入 staged threads;`checkNewProperNouns` 的 known 并入 newEntities/newAliases;`checkSecretKeywords` 增 staged 未揭晓秘密。签名不动——staging 事实在 mechanicalCheck 入口读一次传下去。
+- 三处都以 `readBatch().exists` 为开关:无批次零行为变化(AC5 全关矩阵)。
+
+### 2.6 finalize-batch(D3)
+
+1. readBatch;空 → 人话拒绝。任一章状态 ≠ 待审收 → 拒绝并列出("第 7 章打回未重写、第 8 章受影响未重审")。
+2. 升序逐章:读定稿包.json → `finalizeChapter(ctx, payload)`(每章自身原子 commit + 缓存刷新)→ 成功删该章批次目录并更新批次.json。失败 → 立即停,返回已入档/未入档清单与人话原因(已入档的保留——按章原子;工作区剩余批次原样,续跑=修复后再跑 finalize-batch)。
+3. 全部成功:删 批次.json 与 待定稿/ 空壳 → 跑 `runHealthCheck`(例行,只算定稿)→ 输出附体检一句话状态。
+4. `--until=<章号>`:只转正到第 K 章(作者"前几章先发"),其余留批次。
+
+### 2.7 batch-reject / batch-discard / batch-status
+
+- `batch-reject <章号>`:章号必须在批次内;置 K=打回(清该章目录内容,保留目录与元数据行——重写后 stage-chapter 覆盖)、K+1..N=受影响(工件保留)。受影响章重审通道:宿主重跑 review-input(叠加视图已反映 K 重写后事实)→ save-review → `stage-chapter <章号> --payload=…` 覆盖式重暂存(章号连续性校验对"批内已存在的章号"放行为覆盖)。
+- `batch-discard`:`fs.rm 待定稿/` 整树;输出确认人话。**破坏性:宿主必须先向作者确认**(SKILL.md 写明),脚本本身不再二次确认(CLI 无交互约定)。
+- `batch-status [--json]`:readBatch + judgeStop + judgeBatchQuality + 各章审稿单阻断数摘要;`--json` 给宿主,无参出人话表。
+
+### 2.8 状态机与宿主(E1-E3)
+
+- 序 3:`unfinishedWorkDetail` 的待定稿分支充实——dto 加 `批次: {起章, 章数, 各章状态摘要, 建议}`;「从哪继续」细分:有打回/受影响 → "重写打回章/重审受影响章";全待审收且停止命中 → "呈报作者批量审稿";未满 → "继续批内下一章"。
+- 序 6 dto:`自动确认细纲: config.自动确认细纲` 布尔直出 + 期望产物文案条件化;连写指引一句话("作者要连写时走 stage-chapter 批次流,见 SKILL 自动模式段")。
+- SKILL.md 新段「自动模式(连写)」:进入条件(作者说连写/挂机)→ 批内循环(next→细纲[自动确认开则直接 persist-outline]→prepare→写→mechanical-check→review-input→两审→save-review→**stage-chapter**→看返回停止判定)→ 停止后 batch-status 呈报作者 → 三形态裁决(finalize-batch / 改后重审再 finalize / batch-reject→重写重审)→ batch-discard 需作者明确说整批不要。渲染三平台壳 + drift。
+
+## 3. 数据与兼容
+
+- 无缓存 schema 变更(SCHEMA_VERSION 不动);staged 数据不进任何缓存表/meta(AC7)。
+- 批次文件是工作区文件:不入 git、不受防呆方言约束(YAML 方言只管作者可见源文件;批次.json/定稿包.json 是机器域)。草稿.md 的 front matter 用防呆序列化器组回(作者可能打开看)。
+- 既有命令零签名变更;mechanicalCheck/prep/review 内部叠加,消费方(CLI/测试)无感。
+- `连写无条目变动上限` 进 BookConfigReader defaults(值 3)+ spec §3 回填。
+- Windows 中文路径:批次目录名含中文标题——沿用 ChapterWriter 净化规则,e2e 在 CI windows job 覆盖。
+
+## 4. 权衡记录
+
+- **stage 前置"审稿单必须存在"**(而非允许无审直暂存):自动模式砍掉的是"逐章问作者",不是"逐章审"——两审是质量闸门也是批量审稿的呈报材料,无审稿单的批次作者没法批。
+- **finalize-batch 中途失败不整批回滚**:spec 明文"原子性按章保留";已 commit 的章是作者敲定过的合法定稿,回滚反而制造"已批准内容消失"。
+- **批次质检在 stage 时逐次判、不在批末补算**:早停少浪费(漂移第 3 章就停,不写满 8 章);判据纯函数批末 batch-status 重算同口径。
+- **受影响章不强制重写只强制重审**:spec"需重新审核或重写"二选一,作者裁量;入口硬校验只认"待审收",重审通道即 stage 覆盖。
+
+## 5. 回滚
+
+- P1-P4 每期独立 commit,`git revert` 单期可退;批次数据全在工作区(gitignore),代码回退不留残留状态。
+- 最坏情况(批次数据结构有 bug):`batch-discard` 清工作区即回到手动模式,定稿零污染——宪法级路径(作者敲定才入 git)保证爆炸半径限于工作区。

+ 1 - 0
.trellis/tasks/07-04-m6-auto-mode/implement.jsonl

@@ -0,0 +1 @@
+{"_example": "Fill with {\"file\": \"<path>\", \"reason\": \"<why>\"}. Put spec/research files only — no code paths. Run `python .trellis/scripts/get_context.py --mode packages` to list available specs. Delete this line once real entries are added."}

+ 63 - 0
.trellis/tasks/07-04-m6-auto-mode/implement.md

@@ -0,0 +1,63 @@
+# M6 实施清单
+
+执行方式:inline(M1-M5.5 先例),四期每期一 commit,期末验证绿才进下期。上下文顺序:prd → design → 本清单;Phase 2 起步走 trellis-before-dev。
+
+## P1 staging 模块 + stage/status 命令
+
+- [x] P1.0 前置缺口修复(prd 决策 D7):`ThreadLedgerWriter.createThread({id, frontMatter, body, 短题})`(拒绝已存在编号/非法类型)+ `finalizeChapter` payload 增 `threadCreates`(进同一 stage/rollback 集合);`v7/test/finalize/` 补"埋下→定稿→条目文件在→缓存含新条目→下一章推进机检零误报"接力用例
+- [x] P1.1 `v7/src/staging/index.js`:readBatch / stagedFacts / stageChapter / judgeStop / judgeBatchQuality / rejectFrom / discardBatch(契约 design §2.1-2.4、§2.7);目录名净化与 ChapterWriter 同源(抽 `src/util/filename.js` 或等价,两处共用)
+- [x] P1.2 BookConfigReader defaults 加 `连写无条目变动上限: 3`
+- [x] P1.3 `v7/src/commands/stage-chapter.js` + `batch-status.js`(薄壳,`--payload` 走 readJsonInput 先例);bin 注册
+- [x] P1.4 `v7/test/staging/index.test.js` + `v7/test/commands/stage-chapter.test.js`:
+  - 章号连续性(跳章/重章拒绝;批内已存在章号=覆盖重暂存)
+  - 前置校验零写入;审稿单缺失拒绝
+  - 落盘三件套 + 批次.json 状态/计数;工作区单章文件清干净
+  - judgeStop 四件套逐一(写满/收卷/卷纲耗尽/连续无条目变动);judgeBatchQuality 三判据(弱钩尾/缺书内时间/句式 vs 基线 29% 不停 31% 停)
+  - 批次.json 损坏 → 扫描重建、状态保守回「受影响」
+
+验证:`node --test v7/test/staging/ v7/test/commands/stage-chapter.test.js`(注意目录参数怪癖,必要时列文件)
+提交:`feat(v7): M6 P1——staging 批次模块与 stage-chapter/batch-status`
+
+## P2 叠加视图三消费点
+
+- [x] P2.1 `prep/index.js`:近章结尾/时间线/信息差/全书近况叠加(design §2.5);无批次零变化
+- [x] P2.2 `review/index.js assembleReviewInput`:相关条目/名册/相关角色/时间线/信息差/近况叠加
+- [x] P2.3 `mechanical-check/index.js`:三个 known 集合并入 staged 事实
+- [x] P2.4 测试:`v7/test/prep/`、`v7/test/review/`、`v7/test/mechanical-check/` 各补批次两态用例——AC2 批内依赖主用例(K 章埋伏笔+新角色+时间线行 → K+1 备料/审稿输入/机检三面验证);AC7 前半(批次进行中删缓存重建 → 叠加输出深等不变)(集中在 `test/staging/overlay.test.js`,另含重审不倒灌用例——stagedFacts 增 before 过滤)
+- [x] P2.5 既有测试零改动仍绿(AC5 全关矩阵的回归面)——全量 398 绿
+
+验证:`node --test v7/test/prep/ v7/test/review/ v7/test/mechanical-check/`(列文件跑)
+提交:`feat(v7): M6 P2——备料/审稿输入/机检叠加视图(批内依赖)`
+
+## P3 批量定稿与污染传播
+
+- [x] P3.1 `staging.finalizeBatch`(design §2.6:入口硬校验全待审收、升序逐章原子、失败停在该章、`--until`、尾部例行体检提示)+ `v7/src/commands/finalize-batch.js`
+- [x] P3.2 `batch-reject` / `batch-restage` / `batch-discard` 命令 + rejectFrom 污染标记(K 打回清工件、K+1..N 受影响)
+- [x] P3.3 测试 `v7/test/staging/finalize-batch.test.js`(gitBookCtx 先例):
+  - AC1 端到端:stage×3 → finalize-batch → 三 commit 按序、入档内容与手动 finalizeChapter 逐字段一致、批次清空、next 报下一章
+  - AC3 注入错误恢复演练:打回第 2 章 → 3..N 受影响 → finalize-batch 拒绝(人话列障碍)→ 重写重审回待审收 → 成功;grep 全部 commit 确认打回章旧内容零泄漏
+  - 中途失败按章保留(坏定稿包注入第 4 章,等价 faultAfterWrite):第 3 章已入档保留、失败章留批次、报告如实
+  - AC6 batch-discard:定稿零变化、工作区净、next 回序 6
+  - AC7 后半:全程 fingerprints/meta imagery_top 无 staged 数据断言
+  - 追加:--until 截断转正 + next 报批次续跑
+
+验证:`node --test v7/test/staging/`(列文件)
+提交:`feat(v7): M6 P3——finalize-batch 逐章原子转正与打回污染传播`
+
+## P4 状态机/宿主接线 + 收口
+
+- [x] P4.1 序 3 dto 批次明细 + 序 6 dto `自动确认细纲` 标志(design §2.8);`v7/test/state-machine/` 补用例,router.test.js 既有断言不改
+- [x] P4.2 SKILL.md「自动模式(连写)」段 + 三平台壳重渲染(`node scripts/build-host-shells.mjs`)+ drift check 绿;批次五命令入 SKILL 写章流程/例外流程表
+- [x] P4.3 开关矩阵测试(AC5):四组合行为断言(全关=现状包含在既有回归;单开各一用例;全开=AC1 引用)——`test/state-machine/auto-mode.test.js`
+- [x] P4.4 全量 `node --test`(Windows 本机)407 绿 + AC1-AC8 复核、prd.md 打勾(AC8 CI 部分待 push)
+- [x] P4.5 spec 回填(Phase 3.3):story-repo-spec 0.12(§3 `连写无条目变动上限` 键;§8.1 实现口径——批次三件套/三态/污染传播/stage 前置审稿单/质检判据;§8 第 8 步条目创建;决策 36-37);multi-agent spec v3.7(SKILL 自动模式段 + §5.1 批次不开第二条写入路径);v7-implementation-plan §M6 出口标注(含两处实现偏离记录);backend database-guidelines 增 §7 工作区暂存数据四条
+- [ ] P4.6 commit + push,CI 双平台绿;prd.md AC8 回填 run 号
+
+提交:`feat(v7): M6 P4——状态机批次感知、SKILL 自动模式段与开关矩阵` + `docs(v7): M6 spec 回填`
+
+## 风险与回滚点
+
+- 机检/备料/审稿是主循环热路径——叠加必须以 `readBatch().exists` 为总开关,无批次分支零额外 IO(AC5 全关矩阵 + 既有全量测试把关)
+- `finalizeChapter` 复用时 workspaceFiles 语义:批次章的工作区文件已在 stage 时清过,payload 转正时 workspaceFiles 应为空/仅剩批次目录——finalize-batch 负责置空并自管批次目录删除,防误删他章工件
+- 批次.json 是单点:损坏走扫描重建(保守回受影响),测试覆盖
+- 每期独立 commit 可 revert;批次数据在工作区,代码回退无残留

+ 96 - 0
.trellis/tasks/07-04-m6-auto-mode/prd.md

@@ -0,0 +1,96 @@
+# M6 自动模式(按批次定稿):待定稿批次、叠加视图、停止条件、批量定稿
+
+## Goal
+
+自动模式落地为"控制上移到大纲层"的连写流程:批内每章走完写章八阶段的 1-6 步后**不定稿**,草稿/审稿单/预登记数据攒进 `工作区/待定稿/`;写后续章的材料从"定稿 + 待定稿批次"叠加组装(支持批次内依赖);停止条件命中即停转人工;作者批量过审稿单后**逐章按序原子定稿**。**定稿永远需要作者敲定——没有任何不经作者确认写入定稿区的路径**(PRD §2.3 宪法级)。
+
+对应实施计划 §M6(`docs/architecture/v7-implementation-plan.md:168`),上游依据:`v7-prd.md` §2.3(旅程三)/§4 #14(控制点滑杆)/#15(连写质量漂移)、`story-repo-spec` 0.11 §8.1(自动模式整节)/§7(工作区)/§10 序 3(含待定稿批次)、M5.5 交付的 `runHealthCheck` 结构化 data 与 style-stats("体检不过线"数据面)。
+
+**里程碑定位**:M5 F1 后主循环全程 CLI 已通,M5.5 体检数据面已备——M6 是最后一块核心功能拼图(其后 M7 导出/migrate → beta)。
+
+## Background(已确认事实)
+
+- **序 3 已探测待定稿**:`detectors.js:129` 待定稿目录非空 → resume「待定稿批次续跑」;但批次结构、明细 dto、续跑指引都是空的。
+- **【实施期发现 07-04】新开条目无入档通道(M2 起潜伏缺口)**:`thread-declarations.js:7` 注释称"条目文件由定稿创建",但 `finalizeChapter` 的 `threadUpdates` 只能 update/appendHistory 既有文件——手动模式「埋下 伏笔-X」定稿后条目文件不存在,下一章「推进 伏笔-X」被机检阻断。既有测试从未串"埋下→定稿→推进"接力所以没炸。M6 批内依赖(AC2)踩在此缝上,作为 P1.0 先修:payload 增 `threadCreates:[{id, frontMatter, body, 短题?}]`(文件格式沿卷复盘伏笔条目先例),手动/批次两模式共用。
+- **finalize payload 即预登记形态**:`finalizeChapter(ctx, payload)`(`v7/src/finalize/index.js`)吃 `{frontMatter, body, summary, threadUpdates, characterUpdates, rosterUpserts, timelineRows, secretWrites, commitLines, workspaceFiles}`,原子 commit + 缓存刷新。spec §8.1"预登记数据……定稿时原样转正"可字面实现:暂存的就是 payload。
+- **叠加视图的三个消费点**:备料 `prep/index.js`(八组件)、审稿输入 `review/index.js assembleReviewInput`(相关条目/名册/时间线/信息差/近况)、机检 `mechanical-check/index.js`(threads 表查条目声明——staged 新开条目会被误判"不存在"阻断,必须叠加)。三者的数据源=缓存(定稿派生)+源文件。
+- **缓存不变量**:`.cache` 只派生自定稿源文件,任何时刻可删重建(backend/database 规范 §2/§2.5)。staged 数据**不得**进缓存表(会破坏"删缓存重建一致")。
+- **体检语义(M5.5)**:`runHealthCheck` 只算定稿正文;fingerprints/meta `imagery_top` 是确定性派生物。批次判定不得把 staged 草稿写进这两处。
+- **book.yaml 既有键**:`自动确认细纲: false`、`连写批次大小: 8`(BookConfigReader 有默认值);`连续弱钩上限: 3`。spec §8.1"连续 3 章(可配)无条目变动"的"可配"尚无键。
+- **卷纲**:`大纲/卷纲/第NN卷.md`(OutlineReader.readVolumeOutline);建书产第一卷卷纲,卷复盘产下卷卷纲。"绝不让模型裸奔编纲"。
+- **宿主驱动模型(M4/M5 定式)**:宿主 AI 调 CLI 循环,脚本判定下一步(`next --json` 单入口 + F1 缝命令,JSON 走 `--file`);SKILL.md 单源渲染三平台壳,drift check 进 CI。
+- **章文件命名**:`NNNN-标题.md`(ChapterWriter,标题净化 Windows 非法字符)。待定稿目录名沿用同规则。
+- **"整批不要"**:批次是工作区文件(`.gitignore` 含 `工作区/`),未入 git——丢弃=删工作区批次目录;`goto-chapter`(M3)管的是已定稿回退,两者不混。
+
+## Requirements
+
+### A. 待定稿批次结构(spec §8.1/§7)
+
+- A1 `工作区/待定稿/NNNN-标题/` 每章一目录:`草稿.md`(front matter+正文终稿)、`定稿包.json`(完整 finalize payload)、`审稿单.md`(该章两审产物,批量审稿时给作者看)
+- A2 `工作区/待定稿/批次.json` 批次元数据:起章、各章 `{章号, 标题, 状态}`(状态 ∈ 待审收/打回/受影响)、连续无条目变动计数;机器域 JSON
+- A3 `stage-chapter <章号> --payload=<json>` 暂存一章:校验(章号连续、payload 完整性同 finalize 前置校验)→ 落批次目录(草稿/定稿包从 payload 生成,审稿单从 `工作区/审稿.md` 搬入)→ 清本章工作区单章文件(细纲/材料/草稿/审稿)→ 返回停止条件判定
+- A4 断点续跑:批次进行中任何时刻中断,`next` 序 3 能报批次明细(几章已暂存、各章状态、从哪继续)
+
+### B. 叠加视图(支持批次内依赖,RFC 决策 A1)
+
+- B1 staging 读取模块:从批次目录读 staged 事实(新开/推进条目、名册/角色变更、时间线行、信息差写入、staged 章 front matter 与正文),**只读工作区文件,不依赖也不写缓存**
+- B2 备料叠加:全书近况(总章数/字数/写到/连续弱钩/悬了太久计入 staged)、时间线片段(+staged 行)、信息差边界(+staged 写入)、近章结尾(staged 末两章草稿尾部优先)
+- B3 审稿输入叠加:相关条目(含 staged 新开/推进后的状态)、名册(+staged upsert)、相关角色(角色卡合并 staged 变更)、时间线片段、信息差候选、全书近况——批内第 K+1 章审稿能看到第 K 章预登记事实
+- B4 机检叠加:条目声明检查把 staged 条目并入已知集合(K 章「埋下 伏笔-003」后 K+1 章「推进 伏笔-003」不得误判阻断);新专名/信息差候选并入 staged 名册与秘密
+- B5 缓存不变量保持:批次进行中删缓存全量重建,叠加视图输出不变;fingerprints 表与 meta `imagery_top` 永不含 staged 数据
+
+### C. 停止条件四件套(PRD #15,命中即停转人工)
+
+- C1 批次写满:staged 章数 ≥ `连写批次大小`
+- C2 卷纲耗尽:下一章所属卷无卷纲文件(绝不裸奔编纲);staged 章声明 `收卷: 是` 同样终止批次(后续归序 4 卷复盘)
+- C3 连续 N 章无条目变动:staged 章 front matter 三数组声明连续为空 ≥ N(`连写无条目变动上限`,book.yaml 新键,默认 3)
+- C4 批次质检不过线("体检不过线"的批次落点):对 staged 章跑零 token 判据——连续弱钩 ≥ `连续弱钩上限`、缺「书内时间」、句式 vs 基线指纹超容差(复用机检 30%/50% 口径);判据纯函数化供批内批末复用
+- C5 判定内聚:`stage-chapter` 返回与 `batch-status` 都输出「继续 / 停(原因)」;判定零 token 纯脚本
+
+### D. 批量审稿、污染传播与批量定稿(spec §8.1 版本链)
+
+- D1 `batch-status [--json]`:批次明细(各章状态、审稿单要点、停止判定、批次质检结论)——作者批量过稿的呈报数据面
+- D2 `batch-reject <章号>`:打回第 K 章 → K 状态=打回,K+1..N 全部标记=受影响(工件保留);重写 K(重走写章 1-6 步 + `stage-chapter` 覆盖)、受影响章重审(重跑两审 + `save-review` 后经 stage 通道更新回待审收)
+- D3 `finalize-batch`:全部章状态=待审收才可执行;按章号升序逐章 `finalizeChapter`(每章独立原子 commit,中途失败停在该章、已入档的保留——"原子性按章保留");全部成功后清批次目录;打回章的旧预登记数据不得出现在任何 commit(批内污染不出批次)
+- D4 `batch-discard`:整批丢弃——删待定稿目录与批次元数据,定稿零变化,`next` 回到序 6
+- D5 作者裁决三形态可走通:整批接受(D3)/ 改某几章(宿主改批次内文件 → 重审 → D3)/ 从某章起打回(D2)
+
+### E. 状态机与宿主接线(PRD #14 开关矩阵)
+
+- E1 序 6 dto 增自动模式提示:`自动确认细纲` 开 → 期望产物注明"提案直接生效不问作者";连写由作者一句话开启,宿主按批次流走 stage-chapter。两开关全关 = 现行为零变化
+- E2 序 3 dto 充实:待定稿存在时带批次明细(A4)
+- E3 SKILL.md 增「自动模式(连写)」流程段(批次循环:细纲→写→机检→两审→stage→按返回判停;批末呈报→作者裁决→finalize-batch);三平台壳重渲染、drift check 绿
+- E4 例行体检衔接:批末(finalize-batch 成功尾部)如实提示体检状态;序 5 既有触发不变
+
+## Acceptance Criteria
+
+- [x] AC1 批次端到端:批次大小 3 的书,stage×3(每章草稿/定稿包/审稿单落位、工作区单章文件清干净)→ 停止=写满 → `finalize-batch` → 三个 `ch(N)` commit 按序、条目/时间线/摘要入档与手动模式逐字段一致、批次目录清空 → `next` 报下一章(`test/staging/finalize-batch.test.js` AC1)
+- [x] AC2 批次内依赖:第 K 章预登记「埋下 伏笔-X + 名册新角色 + 时间线行」→ 第 K+1 章备料材料含全部三者且近章结尾=K 章草稿尾部;审稿输入相关条目含伏笔-X;机检对「推进 伏笔-X」零误报(`test/staging/overlay.test.js` 三面用例)
+- [x] AC3 注入错误恢复演练(PRD #15 验收):打回第 2 章 → 第 3..N 章自动标记受影响 → `finalize-batch` 拒绝执行并人话说明 → 重写第 2 章重 stage、受影响章重审回待审收 → `finalize-batch` 成功;打回章的旧预登记内容不出现在任何 commit(`test/staging/finalize-batch.test.js` AC3,grep 全部 commit)
+- [x] AC4 停止条件四件套各有测试:写满 / 卷纲耗尽(含收卷声明)/ 连续 3 章无条目变动 / 批次质检不过线(弱钩连发、缺书内时间、句式偏离三判据各验)(`test/staging/index.test.js` 停止条件 4 例 + 质检 3 例)
+- [x] AC5 开关矩阵(PRD #14 验收):`自动确认细纲`×连写四组合——全关时既有全量测试零改动仍绿(407 绿,router.test.js 未动);单开细纲自动确认序 6 dto 有标志;连写走批次通道(序 3 批次明细);全开端到端即 AC1(`test/state-machine/auto-mode.test.js`)
+- [x] AC6 整批丢弃:`batch-discard` 后定稿零变化、工作区干净、`next` 回序 6(`test/staging/finalize-batch.test.js` AC6)
+- [x] AC7 缓存不变量:批次进行中删 `.cache` 全量重建,备料/审稿输入/机检叠加输出不变(`test/staging/overlay.test.js`);`fingerprints` 与 meta `imagery_top` 全程无 staged 数据(finalize-batch.test.js AC1 内断言)
+- [ ] AC8 全量测试绿 + CI 双平台绿(drift check 含 SKILL 壳重渲染)——本机 407 绿 + drift check 绿;CI run 号待 push 回填
+
+## Out of Scope
+
+- ❌ 真模型连写 smoke(beta 手测门,同 M4/M5 先例)
+- ❌ 已发布错误的顺势圆(M3 impact 已有影响分析;顺势圆方案生成是 AI 语义,走既有吃书流程)
+- ❌ 批次质检阈值 book.yaml 参数化(复用既有 `连续弱钩上限` 与机检容差常量;新键仅 `连写无条目变动上限`——spec 原文明说"可配")
+- ❌ 批内并行写章(批内依赖决定顺序写;并行是 7.x 优化)
+- ❌ 停止条件"体检不过线"之外的例行体检改动(M5.5 语义不动)
+
+## 决策记录(规划期,依据法律文本推导;实施中发现冲突回改本节)
+
+- **D1 宿主驱动、脚本判定**:不新增状态机状态——自动模式=序 6/序 3 的批次感知 + 批次 CLI 五件套(stage-chapter/batch-status/finalize-batch/batch-reject/batch-discard)。依据:PRD §2.3"自动与手动的差异只是确认粒度"、spec §8.1"状态机与八阶段零改动"。
+- **D2 定稿包.json 即预登记**:暂存的就是完整 finalize payload,批量定稿逐章原样喂 `finalizeChapter`——"原样转正"字面实现,无第二套入档路径(宪法级"定稿永远经作者敲定"由 finalize-batch 的作者触发保证)。
+- **D3 叠加视图=staging 只读模块+三消费点合并,不碰缓存**:缓存永远只派生自定稿(不变量 2/"删缓存重建一致"CI 项);staged 事实从工作区文件现读,批内章数 ≤ 批次大小,全量读代价可忽略。
+- **D4 "体检不过线"落为批次质检纯函数**(含 staged 章),例行体检仍只算定稿:fingerprints/meta 是确定性派生物,staged 草稿可能被打回,入表会破坏重算一致性。批次质检判据=连续弱钩/缺书内时间/句式 vs 基线(全部零 token 可数项,数据面来自 M5.5)。
+- **D5 污染传播=批次元数据状态机**:待审收/打回/受影响三态;finalize-batch 只转正"待审收",存在其他状态即整批拒绝——"批内污染不出批次"由入口硬校验保证,不靠宿主自觉。
+- **D6 "整批不要"=删工作区批次**:批次未入 git,丢弃即删文件;`goto-chapter` 保留给已定稿回退,职责不混。
+- **D7(实施期 07-04)finalize payload 增 `threadCreates`**:新开条目的入档通道缺失是 M2 起的真缺口(见 Background),修在 `finalizeChapter`(手动/批次共用、同一原子边界与回滚集合),不在 staging 层单修——"事实变更只经定稿流程入 git"不开第二条路。spec §8 第 8 步与 SKILL 定稿包字段随 3.3 回填。
+
+## Open Questions
+
+(无——若实施中发现 spec §8.1 与代码既有约定冲突,先回本节记录再动代码)

+ 26 - 0
.trellis/tasks/07-04-m6-auto-mode/task.json

@@ -0,0 +1,26 @@
+{
+  "id": "m6-auto-mode",
+  "name": "m6-auto-mode",
+  "title": "M6 自动模式(按批次定稿)",
+  "description": "",
+  "status": "in_progress",
+  "dev_type": null,
+  "scope": null,
+  "package": null,
+  "priority": "P2",
+  "creator": "codex",
+  "assignee": "codex",
+  "createdAt": "2026-07-04",
+  "completedAt": null,
+  "branch": null,
+  "base_branch": "v7",
+  "worktree_path": null,
+  "commit": null,
+  "pr_url": null,
+  "subtasks": [],
+  "children": [],
+  "parent": null,
+  "relatedFiles": [],
+  "notes": "",
+  "meta": {}
+}

+ 4 - 4
docs/architecture/multi-agent-adaptation-spec-2026-06-05.md

@@ -1,8 +1,8 @@
 # Webnovel Writer 多宿主与多智能体适配 Spec
 
-> 日期:2026-06-05(v3 修订:2026-06-11;v3.1:同日,hook 语义 deny → ask,依据 #113;v3.2:2026-06-12,按 PRD 1.0 §10.2 修订——安装器重写为工作目录布局、AGENTS.md 公约数层、SessionStart 注入、模板条件块、放弃插件市场;v3.3:2026-06-26,RFC 后续决策——两审模式、审稿清单定义;v3.4:2026-06-27,RFC 深度核验——事实审查增 D3 未登记伏笔检测 category;v3.5:2026-07-02,设计边界回顾——§6.1 目录图角色清单同步两审实态;v3.6:2026-07-03,M1-M5 review S-2——§7.1 registry 示例补 M5 实态字段 detect_bin/install_dir 等,照抄示例不再被 validator 打回)
-> 状态:草案 v3.6
-> 基线:**v7 story repo**(`story-repo-spec-2026-06-10.md` 0.10)+ **PRD**(`v7-prd.md` 1.1,产品法律文本,冲突时以 PRD 为准)。v2 的基线是 v6.1.0 Python runtime,该架构已被 v7 推翻;本版继承 v2 的元层纪律,重写全部基座层。
+> 日期:2026-06-05(v3 修订:2026-06-11;v3.1:同日,hook 语义 deny → ask,依据 #113;v3.2:2026-06-12,按 PRD 1.0 §10.2 修订——安装器重写为工作目录布局、AGENTS.md 公约数层、SessionStart 注入、模板条件块、放弃插件市场;v3.3:2026-06-26,RFC 后续决策——两审模式、审稿清单定义;v3.4:2026-06-27,RFC 深度核验——事实审查增 D3 未登记伏笔检测 category;v3.5:2026-07-02,设计边界回顾——§6.1 目录图角色清单同步两审实态;v3.6:2026-07-03,M1-M5 review S-2——§7.1 registry 示例补 M5 实态字段 detect_bin/install_dir 等,照抄示例不再被 validator 打回;v3.7:2026-07-04,M6 自动模式——SKILL.md 单源增「自动模式(连写)」段并重渲染各宿主壳,§5.1 补批次暂存不开第二条写入路径
+> 状态:草案 v3.7
+> 基线:**v7 story repo**(`story-repo-spec-2026-06-10.md` 0.12)+ **PRD**(`v7-prd.md` 1.2,产品法律文本,冲突时以 PRD 为准)。v2 的基线是 v6.1.0 Python runtime,该架构已被 v7 推翻;本版继承 v2 的元层纪律,重写全部基座层。
 > 来源:v2(基于 PR #110 review 重写)+ 2026-06 多平台调研核验 + Trellis 多宿主机制调研(2026-06-11)+ PRD 1.0 + RFC 后续决策(2026-06-26)+ RFC 深度核验(2026-06-27)
 > 定位:把 v7 的格式层(story repo)原封不动地暴露给多个 agent 宿主——格式平台无关,本 spec 只管入口怎么落、角色怎么生成、安装怎么零门槛、支持等级怎么诚实。
 
@@ -96,7 +96,7 @@ Skill、agent、hook、安装器全部只是入口或调度层。真正修改项
 定稿 / 吃书 / 补登 原子 commit → story repo
 ```
 
-**跨宿主唯一硬要求**:事实变更必须经流程 commit 入 git,任何宿主不得绕过定稿流程直写 `定稿/` 与 `大纲/伏笔|悬念|感情线/`。v2 §8.3 的 write-gate/chapter-commit/projection 硬要求随 v6 架构作废,不替换、不变形保留。
+**跨宿主唯一硬要求**:事实变更必须经流程 commit 入 git,任何宿主不得绕过定稿流程直写 `定稿/` 与 `大纲/伏笔|悬念|感情线/`。v2 §8.3 的 write-gate/chapter-commit/projection 硬要求随 v6 架构作废,不替换、不变形保留。自动模式(story repo spec §8.1)不开第二条写入路径:批次暂存是工作区数据,入档仍逐章走定稿 commit,宿主只负责按 SKILL「自动模式(连写)」段调度批次命令。
 
 ### 5.2 Claude Code 是第一宿主,但分发只走 npx
 

+ 22 - 8
docs/architecture/story-repo-spec-2026-06-10.md

@@ -1,6 +1,11 @@
-# Story Repo 格式规格(v7 草案 0.11
+# Story Repo 格式规格(v7 草案 0.12
 
-> 状态:0.11。相对 0.10 的变更(2026-07-04 M5.5 体检落地,决策 35 见 §14):
+> 状态:0.12。相对 0.11 的变更(2026-07-04 M6 自动模式落地,决策 36-37 见 §14):
+> - §3 book.yaml 增「连写无条目变动上限」键(0.6 决策 20 的"连续 3 章(可配)"至此有键,默认 3)
+> - §8.1 实现口径回填:批次目录三件套与批次.json 三态、污染传播机制(0.7 版留白"由 M6 实施时设计"至此收口)、暂存前置"审稿单必须已生成"、批次质检判据("体检不过线"的批次落点)
+> - §8 第 8 步:定稿 commit 明确含条目文件**创建**(新开条目入档通道,M2 起潜伏缺口)
+>
+> 0.11 相对 0.10 的变更(2026-07-04 M5.5 体检落地,决策 35 见 §14):
 > - §9 体检定义术语替换:「时间线孤儿」→「缺时间锚点」(front matter 无「书内时间」或时间线漏行,两种缺法都查;PRD §4 #2 验收用词同步)
 > - §9 体检定义与实现对齐:报告含跨章高频意象与句式体检两节;高频意象清单供备料「反复读清单」与机检候选(§8 第 5 步)消费——体检产出、机检消费
 >
@@ -161,6 +166,7 @@ spec_version: "7.0"
 关键章稿数: 3              # 卷首/转折/高潮章 best-of-N
 自动确认细纲: false        # true 时细纲默认采纳提案,跳过停顿点 2(§8.1)
 连写批次大小: 8            # 自动模式一个批次的章数,也是连写体检周期(§8.1)
+连写无条目变动上限: 3      # 连写停止条件:连续 N 章 front matter 三数组声明全空即停(§8.1)
 ```
 
 ## 4. 定稿/
@@ -422,7 +428,7 @@ v7 的伏笔/悬念/感情线是**声明制**——系统只跟踪细纲「本
 - **作者裁决**(第 7 步审稿单):登记成条目(触发"开新条目必须写收尾计划",自动防悬空)/ 忽略(普通描写)/ 删掉。
 - 边界:系统只负责"像伏笔但没登记"的提醒,不判断"这个伏笔好不好"。
 
-**定稿的一次 commit 包含**:草稿 → `定稿/正文/`(front matter 写入章档案与条目变动);`设定/` 变更(位置/状态/境界/持有/信息差/名册/时间线追加);涉及的三类条目文件更新(front matter + 履历追加);`摘要/章摘要/`(审稿单定稿版);工作区清空。
+**定稿的一次 commit 包含**:草稿 → `定稿/正文/`(front matter 写入章档案与条目变动);`设定/` 变更(位置/状态/境界/持有/信息差/名册/时间线追加);涉及的三类条目文件**创建与更新**本章「埋下/设下/开启」的新条目在此建档——条目文件由定稿创建,声明不建档下一章就会被机检误报"条目不存在";既有条目 front matter + 履历追加);`摘要/章摘要/`(审稿单定稿版);工作区清空。
 
 **commit message 约定**(前缀 ASCII 是机器协议,便于 `git log --grep`):
 
@@ -438,11 +444,12 @@ ch(152): 北境的雪
 **全自动 ≠ 无控制,是控制上移到大纲层**:作者逐卷确认卷纲,一次确认管几十章。**自动模式与手动模式的差异只是确认粒度:逐章 vs 按批次**——状态机与八阶段零改动,没有"自动定稿"。
 
 - `自动确认细纲: true` → 第 2 步默认采纳细纲提案(提案必须含定位声明)。
-- **批次运行**:连写 `连写批次大小`(默认 8)章。每章走完 1-6 步后**不定稿**,草稿、审稿单、预登记数据存入 `工作区/待定稿/NNNN-标题/`。
-- **叠加视图与版本链**(规范性要求,RFC 决策 A1):写批内后续章时,备料脚本组装"`定稿/` + 待定稿批次预登记"的叠加视图——批内前章的设定变更、条目推进、时间线行在工作区就位,定稿时原样转正。**支持批次内依赖**:第 K+1 章可以使用第 K 章的预登记事实。当第 K 章被作者打回时,标记 K+1 到 N 章为"受影响",需重新审核或重写(具体污染传播机制由 M6 实施时设计)。
-- **停止条件**(命中即停转人工):批次写满 / 体检不过线 / 卷纲耗尽(**绝不让模型裸奔编纲**)/ 连续 3 章(可配)无条目变动。
-- **批量审稿与定稿**:批次结束 → 体检 → 作者过一遍攒下的审稿单(整批接受 / 改某几章 / 从某章起打回重写)→ 作者敲定后**逐章按序定稿**(原子性按章保留)→ 下一批次。批内错误未定稿,直接改,影响最多波及一个批次。
-- 整批不要 → "回到第 N 章"(§9);已发布后才发现的错误 → 影响分析 + 顺势圆(§9)。
+- **批次运行**:连写 `连写批次大小`(默认 8)章。每章走完 1-6 步后**不定稿**,暂存进 `工作区/待定稿/NNNN-标题/` 三件套:`草稿.md`(front matter+正文终稿,防呆方言序列化)、`定稿包.json`(完整定稿 payload,预登记的机器形态——**暂存的就是定稿时原样转正的数据,无第二套入档路径**)、`审稿单.md`(该章两审产物)。批次元数据 `待定稿/批次.json`(机器域 JSON):起章、各章 `{章号, 标题, 状态}`、连续无条目变动计数。**暂存前置:该章审稿单必须已生成**——自动模式砍掉的是"逐章问作者",不是"逐章审";两审既是质量闸门也是批量审稿的呈报材料。
+- **叠加视图与版本链**(规范性要求,RFC 决策 A1):写批内后续章时,备料/审稿输入/机检组装"`定稿/` + 待定稿批次预登记"的叠加视图——批内前章的设定变更、条目推进、时间线行在工作区就位,定稿时原样转正。**支持批次内依赖**:第 K+1 章可以使用第 K 章的预登记事实。staged 数据只存工作区文件,**不进缓存表、不进指纹与意象派生物**(缓存永远只派生自定稿,删缓存重建叠加输出不变)。
+- **污染传播**(批次状态机,三态 `待审收`/`打回`/`受影响`):第 K 章被作者打回 → K 置"打回"并清工件(重写后重新暂存覆盖),K+1..N 置"受影响"(工件保留,作者裁量**重审或重写**:重审=重跑两审后收回待审收,重写=重走写章流程后覆盖暂存)。**批量定稿入口硬校验:任一章状态非"待审收"即整批拒绝并人话列障碍**——"批内污染不出批次"由入口保证,不靠宿主自觉。
+- **停止条件**(命中即停转人工,全部零 token 脚本判定,逐章暂存时判、早停少浪费):批次写满 / 批次质检不过线 / 卷纲耗尽或收卷声明(**绝不让模型裸奔编纲**;收卷后归卷复盘)/ 连续 `连写无条目变动上限`(默认 3)章无条目变动。**批次质检**即"体检不过线"的批次落点,判据:批尾连续弱钩 ≥ `连续弱钩上限`、任一 staged 章缺「书内时间」、staged 正文句式 vs 基线指纹超容差(口径同机检:平均句长 30%/句长方差 50%);例行体检(§9)仍只算定稿,在批量定稿成功后例行跑。
+- **批量审稿与定稿**:批次停止 → 呈报作者(各章状态、审稿单要点、停止原因、质检结论)→ 作者裁决(整批接受 / 改某几章重审 / 从某章起打回重写)→ 作者敲定后**逐章按序原子定稿**(每章独立 commit;中途失败停在该章,已入档保留——原子性按章保留;支持只转正前段"前几章先发")→ 下一批次。批内错误未定稿,直接改,影响最多波及一个批次。
+- **整批不要 → 丢弃批次**:批次是工作区文件(未入 git),丢弃=删除待定稿目录,定稿零变化,需作者明确确认;"回到第 N 章"(§9)管**已定稿**回退,两者职责不混。已发布后才发现的错误 → 影响分析 + 顺势圆(§9)。
 
 两个开关全关 = 逐章交互流程,行为完全不变。
 
@@ -547,6 +554,13 @@ v6 的 8 个命令全部内化为以上状态。作者只需要一个入口和"
 
 ## 14. 决策记录
 
+### 0.11 → 0.12(依据:2026-07-04 M6 自动模式落地)
+
+| # | 变更 | 落点 | 来源 |
+|---|------|------|------|
+| 36 | 自动模式实现口径回填:批次目录三件套(草稿/定稿包/审稿单)+ 批次.json 三态(待审收/打回/受影响);污染传播=批次状态机,批量定稿入口硬校验"全待审收"(0.7 版留白至此收口);暂存前置"审稿单必须已生成"(砍的是逐章问作者,不是逐章审);批次质检判据钉死(批尾连续弱钩/缺书内时间/句式 vs 基线 30%·50% 容差),例行体检仍只算定稿、移到批量定稿成功后跑;"整批不要"从「回到第 N 章」更正为**丢弃批次**(批次未入 git,删工作区即回手动模式;goto 只管已定稿回退);§3 增 `连写无条目变动上限` 键 | §8.1、§3 | M6 任务(`.trellis/tasks/07-04-m6-auto-mode/`)决策 D2/D4/D5/D6/权衡记录;PRD §4 #14/#15 |
+| 37 | 新开条目入档通道补缺:定稿 commit 明确含条目文件**创建**(M2 起 `threadUpdates` 只能更新既有文件,「埋下→定稿→下一章推进」会被机检误报不存在;修在定稿流程、手动/批次共用,不在暂存层单修——"事实变更只经定稿流程入 git"不开第二条路) | §8 第 8 步 | M6 任务决策 D7(实施期 07-04 发现,M2 起潜伏缺口) |
+
 ### 0.10 → 0.11(依据:2026-07-04 M5.5 体检里程碑)
 
 | # | 变更 | 落点 | 来源 |

+ 1 - 0
docs/architecture/v7-implementation-plan.md

@@ -174,6 +174,7 @@ M1 defer 的指纹提取与 M2 D2 决策推迟的统计项在此收口——此
 - 批量审稿、作者敲定后逐章按序定稿、整批回滚("回到第 N 章"复用 M3)
 - **架构实施**(§1.5 原则):叠加视图通过 Storage Adapter 组装,状态机只管编排
 - **出口**:PRD §4 #15 验收——自动模式端到端 + 注入错误的恢复演练(批内污染不出批次)
+  (出口达成 2026-07-05:staging 批次模块(真源唯一读写点)+ 批次六命令 stage-chapter/batch-status/finalize-batch/batch-reject/batch-restage/batch-discard;备料/审稿输入/机检三消费点叠加,批内依赖可用、删缓存重建输出不变;停止四件套逐章判早停 + 批次质检三判据;污染传播三态 + finalize-batch 入口硬校验"全待审收";序 3/序 6 dto 批次感知;SKILL「自动模式(连写)」段 + 壳重渲染 drift 绿。实现口径两处偏离原计划并已回填法律文本:"整批不要"= batch-discard 删工作区(非"回到第 N 章",goto 只管已定稿回退);叠加视图=staging 只读模块直读工作区文件(不经 Storage Adapter、不碰缓存)。任务:`.trellis/tasks/07-04-m6-auto-mode/`,spec 0.12 决策 36-37)
 
 ### M7 导出 + /migrate + beta 入口