docs(设计): 新增专题-08自动化测试方案SoT，蒸馏G1/G4需求缺口

- 新增 专题-08-自动化测试方案：四层测试金字塔、确定性/语义分界判据、语义评测方法论(双盲评委/对照实验Gate B/回放)、测试可判定性合同
- 登记归属：00-文档大纲 + 内容映射表
- 蒸馏G1(收紧自动确认)：产品-02 §6.4/§9.1 纳入达标自动确认四条件，消除唯一入口矛盾
- 蒸馏G4(运行时叙事门)：专题-04 §4.2.1 补三维量表与通过线(设定≥7.0/角色·场景≥6.0)及四步裁决
- 新增 docs/plans 缺口跟踪：登记10项需求缺口与蒸馏状态

.agents/workflows/ai-development-protocol.md

@@ -2,6 +2,7 @@
 
 > **类型**:元流程(workflows) · **简版规约**:[`../../AGENTS.md`](../../AGENTS.md) §5 工作协议(本文件是其操作化展开)。
 > **何时用**:承接**任何** oh-my-muse 任务时先走本流程分流。核心立场:**机械门禁优先、完成=验证、反假绿**。
+> **版本**:v1 · **更新日期**:2026-07-20 · **变更记录**:从未编号版本升级为 v1，新增创作智能体反序验证门禁与正文卡索引/原文回读双线。
 
 ---
 
@@ -32,6 +33,14 @@
 - 全简体中文注释;外部交互/核心实现/错误路径留可追溯日志。
 - 契约先行(见 [`../rules/contract-first.md`](../rules/contract-first.md));守 BC 边界(见 [`../rules/bc-boundaries.md`](../rules/bc-boundaries.md))。
 
+### 创作智能体反序验证门禁
+
+- **能力验证顺序固定**:清洗/抽卡/范式 → 正文 Gate B → 细纲 → 大纲+设定。正文 Gate B 未由唯一判定器输出 `passed` 前,不得启动细纲智能体真实能力验收;单章、单作品、Gate A 或人工观感都不能替代 Gate B。
+- **正式创作数据流不倒置**:产品运行仍是大纲+设定 → 细纲 → 正文。反序只用于能力隔离与归因,不能让实验评测产物反写正式设定、Canonical 状态、细纲或正文。
+- **正文双线固定**:抽取卡只作索引,命中后必须按来源引用回读冻结线内原文。卡线负责定位事实与历史场景,原文线负责人物声音、动作习惯、能力表现和叙事质感;无来源卡不得单独支撑正文硬事实。
+- **独立权威事实**:作者确认的正式设定、冻结点可见的 Canonical 状态、已确认细纲声明的新事实直接引用各自不可变版本,不要求伪造抽取卡或历史原文来源。
+- **阶段边界**:正文实验阶段不改产品 API、Flyway、业务数据库或 Canonical 主链。只有正文 Gate B=`passed` 后,才另立产品化计划和后续细纲验收计划。
+
 ## 五、验证(证据门 —— 不可跳过)
 - **完成 = 机械验证**;无自动化绿证据**不得**声称“完成/修复/通过”(见 [`../rules/verification-and-anti-false-green.md`](../rules/verification-and-anti-false-green.md))。
 - 用户可见功能按 [`../skills/golden-journey-vertical-slice.md`](../skills/golden-journey-vertical-slice.md) 的**三指标**报告(代码 / 自动化验证 / 端到端可用),不给单一百分比。

design-docs/00-文档大纲.md

@@ -1,7 +1,7 @@
 # New-Design（新设计）V2 文档大纲（入口）
 
-- 版本：v9
-- 更新日期：2026-06-29
+- 版本：v10
+- 更新日期：2026-07-17
 - 目标读者：产品 / 架构 / 前端 / 后端 / 文档维护者
 - 阅读时间：10–20 分钟
 - 边界说明：本文件只负责导航、边界和归属，不重复解释概念；概念解释必须落在对应主文档中。
@@ -99,8 +99,11 @@
 - [专题-01-正文建议接受(Accept Suggestion)实现规范](专题-01-正文建议接受(Accept%20Suggestion)实现规范.md)
 - [专题-02-Sudowrite对标与Muse产品取舍](专题-02-Sudowrite对标与Muse产品取舍.md)
 - [专题-03-AI编排上下文与质量评测实现规范](专题-03-AI编排上下文与质量评测实现规范.md)
+- [专题-04-生成质量门控与创作健康度设计方案](专题-04-生成质量门控与创作健康度设计方案.md)
 - [专题-05-AI统一交互协议与外部AgentAdapter设计](专题-05-AI统一交互协议与外部AgentAdapter设计.md)
 - [专题-06-元数据驱动的智能体架构](专题-06-元数据驱动的智能体架构.md)——收束「agent = f(作品 + 元数据 + 知识库)」横切架构：元引擎与功能链双枢、三体关系、target type 23 型结构本体、统一创作数据读取器、base 内置机制与拆书通用抽取。
+- [专题-07-知识消费契约与质量闭环](专题-07-知识消费契约与质量闭环.md)——收束「知识效用」横切主线：消费选择契约（按用途默认合同与注入视图）、知识质量三性（可命中/可行动/可持续）、回放评测（参考书=标准答案）、长线进度消费语义（演变历程三期消费）。
+- [专题-08-自动化测试方案](专题-08-自动化测试方案.md)——收束「测试可判定性」横切主线：四层测试金字塔、确定性/语义分界判据、语义评测方法论（双盲评委/对照实验 Gate B 范式/回放评测）、测试可判定性合同、已拍决策的测试合同。不重定义状态机/Schema/API/质量维度，只引用各 owner。
 
 说明：专题文档只负责跨文档收束，不抢走 Schema、状态机和统一 API 的单一归属。
 
@@ -148,6 +151,8 @@
 - 产品旅程与长期闭环：`产品-03-用户旅程与操作流程.md`
 - 系统处理流程：`流程-02A-管理员系统处理流程(系统视角).md` / `流程-02B-普通用户系统处理流程(系统视角).md`
 - AI 编排、检索上下文和质量评测跨文档合同：`专题-03-AI编排上下文与质量评测实现规范.md`
+- 知识消费选择契约、知识质量三性、回放评测、长线进度消费语义：`专题-07-知识消费契约与质量闭环.md`
+- 测试金字塔分层、确定性/语义分界判据、语义评测方法论、测试可判定性合同：`专题-08-自动化测试方案.md`
 - AI 外部运行时统一协议与 Adapter：`专题-05-AI统一交互协议与外部AgentAdapter设计.md`
 - 统一数据库表结构：`后端-04-统一数据库Schema-v1.md`
 - 统一接口契约：`后端-05-统一API契约-v1.md`

design-docs/prototypes/专题-07-知识消费契约与质量闭环-总览.html

@@ -0,0 +1,179 @@
+<!DOCTYPE html>
+<html lang="zh-CN">
+<head>
+<meta charset="UTF-8">
+<title>专题-07 · 知识消费契约与质量闭环 · 方案总览</title>
+<style>
+  body{font-family:"PingFang SC","Microsoft YaHei",sans-serif;margin:0;background:#f5f6f8;color:#1c2733;line-height:1.65}
+  .wrap{max-width:1120px;margin:0 auto;padding:22px 20px 40px}
+  h1{font-size:24px;margin:6px 0 2px}
+  .sub{color:#5b6b7b;font-size:13px;margin-bottom:14px}
+  .claim{background:#fff8e6;border-left:6px solid #e6a817;padding:12px 16px;border-radius:8px;font-size:15.5px;margin:10px 0 16px}
+  .claim b{color:#8a5a00}
+  .tabs{display:flex;gap:6px;border-bottom:2px solid #d8dfe8;margin-bottom:16px;flex-wrap:wrap}
+  .tab{padding:9px 18px;border-radius:8px 8px 0 0;cursor:pointer;font-size:14.5px;background:#e9edf2;color:#44536a;border:1px solid #d8dfe8;border-bottom:none;user-select:none}
+  .tab.on{background:#fff;color:#0b57d0;font-weight:600;position:relative;top:2px;border-bottom:2px solid #fff}
+  .panel{display:none}
+  .panel.on{display:block}
+  h2{font-size:17px;color:#0b57d0;margin:18px 0 8px}
+  h3{font-size:14.5px;margin:14px 0 6px}
+  p,li{font-size:13.5px;margin:5px 0}
+  table{border-collapse:collapse;width:100%;font-size:13px;margin:8px 0}
+  th,td{border:1px solid #dde3ea;padding:6px 10px;text-align:left;vertical-align:top}
+  th{background:#eef2f7}
+  .card{background:#fff;border-radius:10px;padding:14px 18px;box-shadow:0 1px 3px rgba(0,0,0,.06);margin:10px 0}
+  .lane{display:flex;align-items:stretch;gap:8px;flex-wrap:wrap;margin:8px 0}
+  .step{flex:1;min-width:118px;border-radius:8px;padding:9px 10px;font-size:12.5px;text-align:center}
+  .done{background:#e8f2ec;border:1.5px solid #2e7d51}
+  .new{background:#e8f0fd;border:1.5px solid #0b57d0}
+  .step b{display:block;font-size:13px;margin-bottom:2px}
+  .arrow{align-self:center;color:#7a8794;font-size:16px}
+  .legend{font-size:12px;color:#5b6b7b;margin-top:6px}
+  .legend span{display:inline-block;width:11px;height:11px;border-radius:3px;vertical-align:-1px;margin:0 4px 0 10px}
+  .warn{font-size:13px;color:#a33;background:#fdf3f3;border-radius:6px;padding:9px 12px;margin:8px 0}
+  .pin{background:#f0f6f1;border-left:4px solid #2e7d51;padding:8px 12px;border-radius:6px;font-size:13.5px;margin:8px 0}
+  code{background:#eef1f5;border-radius:4px;padding:0 4px;font-size:12.5px}
+  .src{color:#8291a0;font-size:12px;margin-top:16px}
+</style>
+</head>
+<body><div class="wrap">
+
+<h1>知识消费契约与质量闭环 · 方案总览</h1>
+<div class="sub">SoT 正文：design-docs/专题-07-知识消费契约与质量闭环.md（v1）· 配套修订：专题-03 v3 / 专题-04 v2 / 专题-06 v4 / 架构-02 v11 / 后端-05 v11 / 前端-03 v7 / 大纲 v10 / 映射表 v8 · 2026-07-17 · 经 codex 与 opus 双独立评审</div>
+
+<div class="claim"><b>核心主张：</b>知识的价值只在被选中并改善产出（写作、检测、规划三个效用时刻）的那一刻兑现。此前 SoT 钉死了「治理」（谁能读什么：授权/来源/双轨/裁剪/预算），本次补上「效用」（该读哪几条、注入什么、有没有用、知识本身好不好）——<b>以用定卡：消费端定义质量，参考书当标准答案。</b></div>
+
+<div class="tabs">
+  <div class="tab on" data-p="p1">① 总览与缺环</div>
+  <div class="tab" data-p="p2">② 消费选择契约</div>
+  <div class="tab" data-p="p3">③ 质量三性与回放评测</div>
+  <div class="tab" data-p="p4">④ 长线进度与本体拍板</div>
+</div>
+
+<div class="panel on" id="p1">
+<div class="card">
+<h2>知识的一生：左三格原有，右三格本次立约</h2>
+<div class="lane">
+  <div class="step done"><b>拆书抽取</b>23 型结构模具</div>
+  <div class="arrow">→</div>
+  <div class="step done"><b>双轨确认</b>草稿→正式，先审后入</div>
+  <div class="arrow">→</div>
+  <div class="step done"><b>授权治理</b>版权/来源/字段裁剪</div>
+  <div class="arrow">→</div>
+  <div class="step new"><b>选择契约</b>按用途定"该读哪几条"</div>
+  <div class="arrow">→</div>
+  <div class="step new"><b>注入视图</b>摘要/全文两档，有尺寸上限</div>
+  <div class="arrow">→</div>
+  <div class="step new"><b>回放评测</b>对照原书评分，反哺卡去留</div>
+</div>
+<div class="legend"><span style="background:#e8f2ec;border:1.5px solid #2e7d51"></span>既有（治理侧）<span style="background:#e8f0fd;border:1.5px solid #0b57d0"></span>本次立约（效用侧，owner=专题-07）</div>
+<div class="warn"><b>为什么必须补：</b>一致性门控（canon_compliance）拿本作知识库当标准拦候选——知识错了，门控会把写对的候选拦下来。输入端质量是输出端门控成立的前提，不是锦上添花。</div>
+</div>
+
+<div class="card">
+<h2>术语桥（「卡」在系统里的权威身份）</h2>
+<table>
+<tr><th>口语</th><th>SoT 权威载体</th></tr>
+<tr><td>待确认的卡</td><td>Knowledge Draft（待审层，默认不可信）</td></tr>
+<tr><td>本作正式事实卡</td><td>Local Knowledge Entity / Relation（局域知识库）</td></tr>
+<tr><td>公共参考卡（范式卡）</td><td>Global KB 范式 Canonical（技法五型：craft / combat / emotion / scene_pattern / trope）</td></tr>
+<tr><td>卡的结构模具</td><td>MetaSchema target_type（23 型）</td></tr>
+</table>
+<p>三个效用时刻：<b>写作时注入</b>（当前态 + 已决策范式）· <b>检测时对照</b>（本作知识当标准）· <b>规划时排线</b>（演变历程 + 参照成长曲线）。</p>
+</div>
+</div>
+
+<div class="panel" id="p2">
+<div class="card">
+<h2>按用途的默认合同（purpose 四值逐一钉死）</h2>
+<table>
+<tr><th>用途</th><th>默认注入</th><th>明确不注入</th></tr>
+<tr><td><b>generation</b> 续写/场景写作</td><td>在场实体（当前章出场+一跳关系）的当前态<b>摘要视图</b>；规划期已决策引用的公共范式（上限 3 条，全文视图）；文风/节奏画像</td><td>范式临场海选；演变历程全线</td></tr>
+<tr><td><b>planning</b> 规划/排线</td><td>目标线程实体的演变历程全线；大纲与作品核心；Global 成长曲线范式（型×品类结构键召回，相似度只作兜底）</td><td>—</td></tr>
+<tr><td><b>detection</b> 一致性检测</td><td>在场实体当前态全量 + 关系闭包 + 事件时间线</td><td>公共范式（检测不需要「怎么写」）</td></tr>
+<tr><td><b>extraction</b> 抽取/维护</td><td>该型模具全字段视图</td><td>—</td></tr>
+</table>
+<div class="pin">范式进入生成上下文的唯一正路：<b>规划期决策、写作期引用</b>。规划产出必须携带范式引用链，写作按引用注入、不重新检索。写作期对范式做临场相似度海选 = 违规（实测依据：同型范式向量相似 74% 多为词汇假近，语义真并率仅约 10%——相似度选不出对的范式）。</div>
+</div>
+
+<div class="card">
+<h2>注入视图与排序（视图 ≠ 存储）</h2>
+<ul>
+<li><b>两档视图</b>：摘要视图（名称+一句话+当前态要点）为默认档；焦点实体升全文视图（按 aiContext 用途裁剪后的字段全量）。各型尺寸上限随字段合同登记，超限不注入。</li>
+<li><b>为什么必须独立成合同</b>：库内实测两端病并存——一半卡不足 400 字符（无肉可注），最大单卡 104KB（一张即撑爆预算）。</li>
+<li><b>排序信号</b> = 结构匹配度（在场＞关系一跳＞相似兜底；范式取型×场景意图×品类精确匹配优先）＋ 效用统计（被命中率/被接受率/跨书频次）。预算内截断落 omittedSources（截断规则归专题-03）。</li>
+<li><b>来源优先级全链</b>：本作事实（Local）＞ 用户绑定知识（User/已安装）＞ 全局与市场参考（Global/市场）。范式只提供「怎么写」，不得覆盖「是什么」。</li>
+</ul>
+</div>
+</div>
+
+<div class="panel" id="p3">
+<div class="card">
+<h2>知识质量三性（输入侧检尺，与输出侧维度分立、单向咬合）</h2>
+<table>
+<tr><th>性</th><th>定义</th><th>可测指标（口径）</th></tr>
+<tr><td><b>可命中</b></td><td>该被想起时能被检索到：命名鲁棒（别名表）+ 向量覆盖 + 结构键齐全</td><td>别名覆盖率 · 向量覆盖率 · 同实体分裂率（抽样审计同一实体被建成多条卡的比例）</td></tr>
+<tr><td><b>可行动</b></td><td>注入后能直接改善产出，不是分析散文</td><td>注入视图尺寸达标率 · 字段充实度（对照字段合同非空率）</td></tr>
+<tr><td><b>可持续</b></td><td>增量维护不腐坏：同名异质不并、真同才并；演变归并有序；溯源完备</td><td>重复率 · 演变断线率 · 溯源完整率</td></tr>
+</table>
+<p><b>裁决权在消费端</b>：p50 实例数=1 的「范式」只是观察不是范式，跨书频次与消费端命中/接受统计才是去留的最终裁决。阈值由回放评测首轮基线确定，随后按质量策略生命周期（draft→evaluating→active）治理。</p>
+</div>
+
+<div class="card">
+<h2>回放评测（参考书 = 标准答案）</h2>
+<p>冻结第 N 章时点的知识状态 → 按契约组装上下文 → 跑规划/续写/检测 → 与原书第 N+1 章对照评分。</p>
+<table>
+<tr><th>评测线</th><th>怎么跑</th><th>评什么</th></tr>
+<tr><td>规划线</td><td>预测下一台阶/伏笔回收，对照原书走向</td><td>台阶预测命中、伏笔回收命中</td></tr>
+<tr><td>生成线</td><td>有卡 vs 无卡 vs 打乱卡 对照生成</td><td>设定一致性、要素覆盖</td></tr>
+<tr><td>检测线</td><td>人工向候选注入错误</td><td>错误检出率</td></tr>
+</table>
+<div class="pin"><b>门禁</b>：知识策略（选择契约参数、注入视图定义、判重规则）是与 Quality Policy 同栖 AI 编排策略面的正式策略对象，版本化管理；<b>变更未经回放对照评测不得上线、不得声称改善质量</b>（evaluating→active，评测未过就没有 active）。</div>
+<div class="warn"><b>合规两道闸</b>：授权状态闸（reference_work 四值，unauthorized 失败关闭）+ 评测用途闸（授权快照 allowedPurpose 须含离线评测；research_only 只限内部、禁外发）。评测产物只存评分/摘要/定位，不留存原书全文。</div>
+</div>
+</div>
+
+<div class="panel" id="p4">
+<div class="card">
+<h2>长线进度消费语义（演变历程三期消费）</h2>
+<p>长篇（尤其升级流）的骨架是实体演变。世界域实体六型共享<b>演变历程</b>元素：{章, 台阶, 周期} 结构化里程碑。</p>
+<table>
+<tr><th>消费期</th><th>用什么</th><th>干什么</th></tr>
+<tr><td>规划期</td><td>本作历程全线 + 参照曲线（跨书台阶间距/周期分布）</td><td>排下一台阶的时机与幅度</td></tr>
+<tr><td>检测期</td><td>当前态对照</td><td>新候选不得与当前台阶矛盾</td></tr>
+<tr><td>写作期</td><td>只给当前态摘要</td><td>全历程默认不进上下文（防上万字明细撑爆预算）</td></tr>
+</table>
+</div>
+
+<div class="card">
+<h2>本体侧两项拍板（落在专题-06 v4）</h2>
+<div class="pin"><b>参照作品面</b>：参考书的实体演变卡不进 Global KB、不可被作品绑定、不是第四类知识库——它是挂在 reference_work 档案下的系统侧证据资产，用途只有两个：回放评测的标准答案底座、叙事域范式的蒸馏源。进 Global KB 的只能是蒸馏后的「成长曲线范式」（trope/pacing 形态，只存定位摘要不存原文）。<b>世界域形态是证据，叙事域形态才是范式。</b></div>
+<div class="pin"><b>双层型判定闭合</b>：判据不变（三样本实测无损则不拆）；craft 已以 1326 条公共范式实测通过，拍板不拆；character/style/pacing 依同一判据在各自公共面首批落库时判定。</div>
+</div>
+
+<div class="card">
+<h2>本次 SoT 修订清单</h2>
+<table>
+<tr><th>文档</th><th>版本</th><th>改了什么</th></tr>
+<tr><td>专题-07（新增）</td><td>v1</td><td>知识效用主线唯一 owner：术语桥 / 消费选择契约 / 质量三性 / 回放评测 / 长线消费语义 / 实验台实证附录 / 验收清单</td></tr>
+<tr><td>专题-06</td><td>v3→v4</td><td>拍板双层型判定（craft 不拆）；新增 §6.4 参照作品面；世界域六型登记演变历程元素；读取器 purpose 枚举 parse→extraction；挂专题-07</td></tr>
+<tr><td>专题-03</td><td>v2→v3</td><td>§4.2 登记「该选哪几条」的选择契约归属专题-07</td></tr>
+<tr><td>专题-04</td><td>v1→v2</td><td>§10 离线评估输入补「知识策略版本」；物理文件名补 .md（并修四册断链）</td></tr>
+<tr><td>架构-02</td><td>v10→v11</td><td>aiContext 值域升级：布尔或用途集（true=全用途 / false=不入 / 用途子集；布尔为退化情形）——实验台字段级用途裁剪实证反哺术语权威</td></tr>
+<tr><td>后端-05 / 前端-03</td><td>v11 / v7</td><td>aiContext 值域表述随术语权威对齐</td></tr>
+<tr><td>00-大纲 / 内容映射表</td><td>v10 / v8</td><td>登记专题-07 与其 owns 概念；补齐专题-04/05/06 漏登</td></tr>
+</table>
+</div>
+</div>
+
+<div class="src">依据：专题-03/04/06 与架构-02 全文核读 + design-docs 全库横切取证 + 实验台数据库只读实测（8 本参考书 ≈1.18 万章、活卡 8587 张、范式卡向量覆盖 100%、升格卡 0%、p50 实例数 1、卡体 p50 395 字符 / 最大 104KB）。全部数字可回溯。</div>
+</div>
+<script>
+document.querySelectorAll('.tab').forEach(t=>t.addEventListener('click',()=>{
+  document.querySelectorAll('.tab').forEach(x=>x.classList.remove('on'));
+  document.querySelectorAll('.panel').forEach(x=>x.classList.remove('on'));
+  t.classList.add('on');document.getElementById(t.dataset.p).classList.add('on');
+}));
+</script>
+</body>
+</html>

design-docs/专题-01-正文建议接受(Accept Suggestion)实现规范.md

@@ -1,10 +1,11 @@
 # 专题-01：正文建议接受（Accept Suggestion）实现规范
 
-- 版本：v5
-- 更新日期：2026-05-23
+- 版本：v6
+- 更新日期：2026-07-20
 - 目标读者：产品 / 架构 / 前端 / 后端 / 测试
 - 阅读时间：20–35 分钟
 - 边界说明：本文档只收束“接受建议”这条跨文档主链路：用户怎么把 AI 候选写入正文、关联知识草稿怎么保留或失效、正文来源归因怎么落点、事务边界怎么切、前端怎么反馈。精确 Schema、状态机和统一错误模型由后续后端阶段承接；当前阶段以 `架构-02` 和 `架构-04` 为准。
+- 变更记录：v6（2026-07-20）补齐编辑后新 candidateVersion、重新 detector、`accept_preflight` 与 CAS 接受边界；实验阶段不改 API/DB。v5（2026-05-23）收束接受建议、知识草稿、来源归因和事务边界。
 
 ## 1. 目标与范围
 
@@ -42,14 +43,14 @@ Accept Suggestion 是 AI 候选从待审层(Shadow)进入正文规范数据(Cano
 | 路径 | 正文结果 | 知识草稿结果 | 历史结果 |
 |---|---|---|---|
 | 原样接受 | Suggestion 内容进入目标 Block | 与当前 Suggestion 绑定的草稿保持待确认；不得自动入 Local KB | Suggestion 归档为 accepted |
-| 修改后合并 | `contentOverride` 进入目标 Block | 旧草稿立即失效；AFTER_COMMIT 重新提取新的草稿 | Suggestion 归档为 accepted，并保留 `final_content` 快照（如需要） |
+| 修改后合并 | 用户编辑先生成递增的 candidateVersion，重新通过 detector 和 `accept_preflight` 后，该版本正文进入目标 Block | 旧版本草稿在新版本被接受时失效；AFTER_COMMIT 重新提取新的草稿 | 最终 candidateVersion 归档为 accepted，旧版本保留审计链且不可接受 |
 | 拒绝 | 正文不变 | 关联草稿一起丢弃 | Suggestion 归档为 rejected |
 
 ### 2.2 为什么“修改后合并”不是新状态
 
 - 用户决策仍然是“接受这条建议，只是我改了最终入正文的文本”。
 - 它不应该发明新的 Active 状态，也不应该生成第二套历史状态机。
-- 归档层统一记为 `accepted`，但必须保留“这是 modified merge”的审计语义。
+- 编辑动作只生成新的待审 candidateVersion，不直接写正文；归档层最终统一记为 `accepted`，但必须保留“这是 modified merge”的版本链与审计语义。
 
 ### 2.3 Stale Draft 规则
 
@@ -90,7 +91,7 @@ Accept Suggestion 是 AI 候选从待审层(Shadow)进入正文规范数据(Cano
 
 - Accept 主事务内不得发起外部 AI / 提取 / 校验调用。
 - 原样接受时，正文写入、候选归档、正文来源归因、关联草稿状态保留、change log、outbox 写入必须放在同一事务里完成。
-- 修改后合并时，正文写入、Suggestion 归档、旧草稿失效与审计仍在主事务；重新提取只能走 AFTER_COMMIT 异步链路。
+- 修改后合并时，只有新 candidateVersion 重新通过 detector 和 `accept_preflight` 后，正文写入、Suggestion 归档、旧草稿失效与审计才进入主事务；重新提取只能走 AFTER_COMMIT 异步链路。
 
 ### 4.4 历史与投影
 
@@ -112,8 +113,8 @@ Accept 命令必须携带以下语义：
 | actor / work / targetBlock | 当前用户、作品和目标 Block |
 | suggestion | 仍处于 Active / Shadow 的候选 |
 | expectedRevision | 用户决策基于的目标 Block revision，必填 |
-| acceptMode | `accept_as_is` 或 `merge_after_edit` |
-| finalContent | 仅 `merge_after_edit` 需要，表示用户确认写入正文的最终内容 |
+| acceptMode | `accept_as_is` 或 `merge_after_edit`；后者只能引用已经重新检测通过的编辑版本 |
+| candidateVersion / candidateSha256 | 本次实际接受的不可变候选版本及正文哈希；编辑后必须递增版本并重新计算哈希 |
 | decisionContext | UI 决策来源、候选版本、质量结果版本和必要审计摘要 |
 | acceptPreconditionContext | 接受前置校验上下文，必须覆盖输出合规、静态检查、质量结果版本、来源状态、来源事件影响、Action Policy、授权快照、作品资产 feature gate、`expectedRevision` 和幂等结果；系统在接受时实时校验，不封装为独立对象 |
 
@@ -121,8 +122,8 @@ Accept 命令必须携带以下语义：
 
 | 语义 | 原样接受 | 修改后合并 |
 |---|---|---|
-| blockOutcome | 目标 Block 写入成功，revision 递增 | 目标 Block 写入用户最终内容，revision 递增 |
-| suggestionOutcome | Suggestion 离开 Active，进入 Archive，disposition=accepted | Suggestion 离开 Active，进入 Archive，disposition=accepted，并记录 modified merge 摘要 |
+| blockOutcome | 目标 Block 写入成功，revision 递增 | 目标 Block 写入已重新检测通过的编辑版本正文，revision 递增 |
+| suggestionOutcome | Suggestion 离开 Active，进入 Archive，disposition=accepted | 最终 candidateVersion 离开 Active，进入 Archive，disposition=accepted；旧版本保留 modified merge 版本链且不可接受 |
 | knowledgeDraftOutcome | 关联草稿保持待确认，仍需单独进入知识确认入口 | 基于旧候选文本的草稿失效，不允许继续确认 |
 | followupTask | 可触发投影刷新，不要求即时返回草稿数量 | AFTER_COMMIT 启动重新提取或投影刷新任务 |
 
@@ -152,11 +153,25 @@ Accept 在任何写正文动作前必须完成前置校验。前置校验失败
 
 服务端必须在接受时实时校验候选来源版本和授权状态；如果校验缺失、过期、质量结果版本不匹配、`expectedRevision` 不匹配、授权快照变化、来源状态变化、作品资产 feature gate 变化或幂等结果不可复用，必须在写正文前重算。重算结果不是提示文案，而是写 Canonical 的硬闸门。
 
+### 6.1 candidateVersion、detector 与 `accept_preflight`
+
+用户编辑候选时不得把 `contentOverride` 直接送进 Accept 主事务。编辑动作必须：
+
+1. 基于当前候选生成严格递增的新 candidateVersion 和 candidateSha256，旧版本立即失去接受资格但保留审计。
+2. 重新运行 detector；报告必须绑定新 candidateVersion、candidateSha256、contextSnapshotSha256 和 qualityPolicyVersion，旧报告不得复用。
+3. detector 绿证据成立后才进入 `accept_preflight`；编辑内容未重新检测、检测超时、报告版本不符或仍有高严重度问题时失败关闭。
+4. `accept_preflight` 实时校验 `mode=production`、`acceptanceEligible=true`、候选未过期、上下文快照和来源未失效、授权仍有效、detector 报告精确绑定当前候选、`expectedRevision` 一致及幂等结果可复用。
+5. 诊断、评测和回放候选固定 `acceptanceEligible=false`，即使正文相同或 detector 通过也不能进入 Canonical。
+
+接受写入采用 compare-and-set（CAS）：只有服务端当前记录仍匹配 `runId + attempt + candidateVersion + candidateSha256 + currentState + expectedRevision` 时，才允许原子完成正文 revision 递增和候选终态迁移。旧 attempt、旧 candidateVersion、迟到 detector 结果、重复状态事件或 revision 已变化时返回冲突或既有幂等结果，不能覆盖新版本或 Canonical。具体生命周期只在 [架构-04 §5](架构-04-状态机与约束清单.md) 定义，本节拥有接受命令的前置与原子写边界。
+
 | 校验 | 失败结果 |
 |---|---|
 | actor 对作品、Block、Suggestion 有操作权限 | `PERMISSION_DENIED`，不写正文 |
 | Suggestion 仍处于 Active / Shadow，未过期、未失效 | `SUGGESTION_NOT_ACCEPTABLE`，不写正文 |
 | expectedRevision 匹配目标 Block 当前 revision | `REVISION_CONFLICT`，进入显式冲突处理 |
+| mode=production 且 acceptanceEligible=true | `CANDIDATE_NOT_ACCEPTANCE_ELIGIBLE`，不写正文 |
+| detector 绿报告精确绑定 candidateVersion、candidateSha256、contextSnapshotSha256 和策略版本 | `QUALITY_EVIDENCE_STALE` 或 `DETECTOR_NOT_PASSED`，不写正文 |
 | 接受前置校验通过（实时校验来源版本和授权状态），且覆盖输出合规、静态检查、质量结果版本、来源状态、授权快照、作品资产 feature gate、expectedRevision 和幂等结果 | 按校验结果阻断、需重验或要求显式确认 |
 | 输出合规、语义安全围栏和静态检查通过 | `OUTPUT_COMPLIANCE_BLOCKED` 或 `STATIC_CHECK_FAILED`，不写正文 |
 | 候选正文 lineage 中所有来源有有效 Authorization Snapshot | `SOURCE_AUTH_INVALID`，候选 invalidated / blocked |
@@ -173,8 +188,8 @@ Accept 在任何写正文动作前必须完成前置校验。前置校验失败
 
 1. 加载 Active Suggestion 并校验归属、状态与过期时间。
 2. 加载目标 Block，并用 `expectedRevision` 做并发保护。
-3. 实时校验候选来源版本和授权状态（校验清单：候选来源、授权快照、市场作品资产 feature gate、质量门控、输出合规、静态检查、质量结果版本、幂等结果和当前 Block revision）。
-4. 更新 Block 内容与 revision。
+3. 执行 `accept_preflight`，实时校验接受资格、candidateVersion/hash、detector 绿报告、上下文快照、候选来源版本和授权状态（校验清单：候选来源、授权快照、市场作品资产 feature gate、质量门控、输出合规、静态检查、质量结果版本、幂等结果和当前 Block revision）。
+4. 以 candidateVersion、candidateSha256、当前候选状态和 `expectedRevision` 做 CAS，更新 Block 内容与 revision。
 5. 如果候选包含 AI、市场、外部知识或授权知识来源，写 Block Source Attribution。
 6. 将 Suggestion 迁入候选归档(disposition=accepted)。
 7. 保持关联知识草稿为待确认；仅当问题来源没有参与正文 lineage 时，才允许把草稿标记为不可确认或需重验。
@@ -185,14 +200,14 @@ Accept 在任何写正文动作前必须完成前置校验。前置校验失败
 
 ### 7.2 修改后合并事务
 
-单个事务内完成：
+编辑动作先在事务外形成新的待审 candidateVersion 并重新运行 detector；只有 detector 绿且 `accept_preflight` 通过后，单个接受事务才完成：
 
-1. 加载 Active Suggestion 并校验归属、状态与过期时间。
+1. 加载最终 Active candidateVersion，并校验归属、状态、候选哈希、版本链与过期时间。
 2. 加载目标 Block，并用 `expectedRevision` 做并发保护。
-3. 实时校验候选来源版本和授权状态（校验清单：候选来源、授权快照、市场作品资产 feature gate、质量门控、输出合规、静态检查、质量结果版本、幂等结果和最终正文内容）。
-4. 用 `contentOverride` 更新 Block 内容与 revision。
+3. 执行 `accept_preflight`，确认 detector 绿报告精确绑定最终 candidateVersion/candidateSha256/contextSnapshotSha256，并实时校验来源版本和授权状态。
+4. 以 candidateVersion、candidateSha256、当前候选状态和 `expectedRevision` 做 CAS，把该候选正文写入 Block 并递增 revision；不得接受临时 `contentOverride`。
 5. 默认继承上游候选的 lineage、授权快照、许可限制、召回状态和风险标记，并写 Block Source Attribution。
-6. 将 Suggestion 迁入候选归档(disposition=accepted)，必要时记录 `final_content`。
+6. 将最终 candidateVersion 迁入候选归档(disposition=accepted)，保留完整编辑版本链与最终正文哈希。
 7. 将旧知识草稿标记为失效，不允许继续确认。
 8. 写 change log / audit log，标记这是 modified merge。
 9. AFTER_COMMIT 发布重新提取事件或创建异步任务记录。
@@ -277,10 +292,11 @@ Reject 不得更新 Block，不得创建重新提取链路。
 
 1. 用户点击“修改”。
 2. 调整最终入正文的结构化内容。
-3. 点击“修改后合并”。
-4. 服务端完成正文主事务，并让旧草稿失效。
-5. UI 显示“已合并，旧知识草稿已失效，正在重新提取”。
-6. 前端进入等待新草稿状态。
+3. 系统创建递增的 candidateVersion 并重新运行 detector；检测中不能点击接受。
+4. detector 绿后，用户点击“修改后合并”，服务端执行 `accept_preflight` 与 CAS。
+5. 服务端完成正文主事务，并让旧版本知识草稿失效。
+6. UI 显示“已合并，旧知识草稿已失效，正在重新提取”。
+7. 前端进入等待新草稿状态。
 
 ### 9.3 Reject
 
@@ -306,6 +322,9 @@ Reject 不得更新 Block，不得创建重新提取链路。
 11. 候选使用市场作品资产时，必须经过作品资产使用预检和 feature gate；否则不能接受。
 12. 修改后合并默认继承上游 lineage 和许可限制，不能用 `contentOverride` 洗白来源。
 13. Accept / Merge 写 Canonical 前必须实时校验来源版本和授权状态，校验清单必须覆盖输出合规、静态检查、质量结果版本、来源状态、授权快照、作品资产 feature gate、expectedRevision 和幂等结果。
+14. 用户编辑必须生成递增 candidateVersion 并重新运行 detector；未重新检测或 detector 非绿不得进入 `accept_preflight`。
+15. 只有 `mode=production`、`acceptanceEligible=true` 且候选/上下文/检测/策略版本一致时才能接受；诊断和评测候选永不可接受。
+16. Accept / Merge 必须以 candidateVersion、candidateSha256、当前状态和 `expectedRevision` 做 CAS，旧版本和迟到结果不得覆盖 Canonical。
 
 ### Should-Have（P1）
 
@@ -339,6 +358,9 @@ Reject 不得更新 Block，不得创建重新提取链路。
 - 市场作品资产缺 feature gate / owner 预检 / `workAssetUsePrecheckId` 时阻断接受
 - 修改后合并触发旧草稿失效
 - 修改后合并不能清空上游 lineage、授权快照和许可限制
+- 编辑后 candidateVersion 递增并重新 detector；旧检测报告和旧候选不可接受
+- `acceptanceEligible=false`、detector 非绿、上下文哈希漂移或策略版本漂移时 `accept_preflight` 失败
+- CAS 冲突、迟到 detector 和重复命令不能覆盖新 candidateVersion 或正文 revision
 - Reject 零正文副作用
 - 409 冲突返回必要信息
 - 投影失败不阻塞主事务

design-docs/专题-03-AI编排上下文与质量评测实现规范.md

@@ -1,9 +1,10 @@
 # 专题-03：AI 编排、上下文与质量评测实现规范
 
-- 版本：v2
-- 更新日期：2026-06-29
+- 版本：v4
+- 更新日期：2026-07-20
 - 目标读者：产品 / 架构 / 后端 / 前端 / 测试
 - 阅读时间：30-45 分钟
+- 变更记录：v4（2026-07-20）§4.5 固化正文实验的 `WriterContext v1`、`WriterOutput v1`、`RetrievalManifest`、双证据与冻结语义；明确实验阶段不改产品 API/DB。v3（2026-07-17）§4.2 登记「分区内该选哪几条知识」的选择契约归属 [专题-07-知识消费契约与质量闭环](专题-07-知识消费契约与质量闭环.md)；关联阅读补专题-07。
 - 边界说明：本文件承接阶段 1~5，定义 AI 编排、上下文组装、检索、运行权限、来源追踪、风险路由和质量评测的产品架构合同。它不定义精确数据库表、后端 endpoint、前端组件和运维门禁；这些由后续前端/后端阶段承接。
 
 ## 1. 归属范围
@@ -175,6 +176,8 @@ Token 预算顺序：
 4. 超限时先摘要化低优先级资料，再截断。
 5. 被省略资料进入 omittedSources，原因只能是 `token_budget`、`not_authorized`、`stale_source`、`low_confidence`、`not_relevant` 或 `blocked`。
 
+分层与预算回答「装多少、先装谁」；分区内「该选哪几条知识、以什么视图注入、按什么排序」的选择契约归 [专题-07-知识消费契约与质量闭环](专题-07-知识消费契约与质量闭环.md)，本册不重复定义。
+
 ### 4.3 来源和授权
 
 每个进入上下文的外部或授权来源必须携带 Authorization Snapshot 或等价不可变指纹，最小语义包括：
@@ -213,6 +216,51 @@ AI 结果必须能解释：
 - 是否触发质量门控、重写、风险标记或输出阻断。
 - 下一步用户可以接受、修改、丢弃、重生成或进入知识确认。
 
+### 4.5 正文 WriterContext、输出与冻结合同
+
+本节是正文生成上下文和输出结构的唯一 owner。知识侧为什么必须“卡是索引、按来源回读原文”由 [专题-07 §2.1](专题-07-知识消费契约与质量闭环.md) 定义；本节只定义检索结果如何冻结、组装和交给写手。
+
+#### 4.5.1 `WriterContext v1`
+
+`WriterContext v1` 是写手唯一可见输入，采用严格 schema：缺字段、未知字段、错误版本、无效引用或哈希不一致均失败关闭。最小合同如下。
+
+| 字段组 | 必须包含 | 约束 |
+|---|---|---|
+| 身份与用途 | `schemaVersion=writer-context-v1`、runId、attempt、mode、qualityPolicyVersion | mode 仅为 `production` / `diagnostic_only`；运行标识不参与内容身份哈希 |
+| 作品与冻结点 | workId、targetChapter、asOf、sourceVersion、authorizationSnapshot、sourceStatus | 回放必须 `asOf < targetChapter`；来源非允许状态即失败关闭 |
+| 快照与检索 | contextSnapshot、retrievalPlan、`RetrievalManifest` | 引用、版本、过滤、排序、哈希和裁剪原因必须完整且互相一致 |
+| 创作骨架 | 已确认大纲定位、fineOutline、narrativeState | 细纲明确区分硬事件、结果方向、伏笔动作、章末钩子、必须出场实体和可调整节拍 |
+| 双证据 | `factEvidence[]`、`proseEvidence[]`、evidenceCoverage[] | 事实与写法证据不得混装；每项都必须回到不可变来源引用 |
+| 输出控制 | outputContract、tokenBudget、omittedSources | 包含动态篇幅、结构要求、新设定申报规则和所有省略原因 |
+| 接受隔离 | `acceptanceEligible` | `diagnostic_only`、evaluation 或回放上下文固定为 false；不得被写手输出覆盖 |
+
+`factEvidence[]` 负责“写得对”，每项保存 factId、sourceType、不可变 sourceRef、内容哈希和 coverageState；来源准入、抽取卡回读要求及正式设定/Canonical 状态/细纲新事实的独立权威分类只以 [专题-07 §2.1](专题-07-知识消费契约与质量闭环.md) 为准。无可靠来源的提示不得进入该字段。
+
+`proseEvidence[]` 负责“写得像”，只包含可回读的历史原文，记录 sourceVersion、章号、Block、Unicode code point 左闭右开区间、内容哈希和用途。连续前四章全文是正文实验 v1 的基础文风证据；抽取卡命中的来源原文只作补充，并按不可变来源去重、稳定排序。事实来源与原文证据不能互相冒充。
+
+#### 4.5.2 `RetrievalManifest`
+
+`RetrievalManifest` 是一次确定性检索结果的冻结清单，至少记录 `planId`、查询、授权和作品过滤、排序规则、卡索引版本、原文读取版本、sourceVersion/sourceRefs、stateAsOf、章号、Block 与字符区间、内容哈希、排除项和裁剪原因。抽取卡排序固定为 `score DESC, sourceVersion ASC, sourceId ASC, sourceOffset ASC`；同一检索计划、授权快照、冻结点和索引版本必须得到同一来源集合与 manifest identity。
+
+manifest identity 对规范化后的来源集合计算，使用 UTF-8、Unicode NFC、LF、对象键排序和稳定数组合同；runId、时间戳、执行节点不参与身份。检索与原文读取必须在同一只读冻结快照内完成；任一来源越过冻结点、缺版本、缺授权、缺哈希或无法重现时，整次上下文组装失败关闭。
+
+冻结边界按用途统一解释：
+
+1. 回放只读取 `chapter <= asOf` 的 Canonical 正文、状态里程碑和抽取卡来源；目标章、未来章、全书终态摘要和无法证明绝对章号的演变事实一律拒绝。
+2. 正向创作以当前最新 Canonical 章为 `asOf`；正式设定、Canonical 状态和已确认细纲分别读取各自不可变版本。
+3. A/B/C 诊断臂可以改变证据策略，但共享作品、冻结点、大纲、细纲、篇幅算法、模型和检测规则，且全部 `acceptanceEligible=false`。
+4. 评测产物只用于诊断和 Gate 裁决，不能反写 Canonical、知识卡、正式设定、Narrative State 或细纲。
+
+#### 4.5.3 `WriterOutput v1`
+
+`WriterOutput v1` 采用严格 schema，至少包含 `schemaVersion=writer-output-v1`、runId、attempt、mode、qualityPolicyVersion、contextSnapshotId/contextSnapshotSha256、candidateVersion、candidateBody/candidateSha256、`acceptanceEligible`、claimLedger[]、evidenceRequests[]、newSettingDeclarations[] 和 selfCheck。
+
+候选正文先统一为 UTF-8、Unicode NFC 和 LF，再计算 SHA-256 与 Unicode code point 区间。claimLedger 每项必须绑定候选哈希、事实类型、正文区间和对应 factEvidence；证据请求和新设定申报不得静默改写上下文。`acceptanceEligible` 由可信组装层派生，写手无权把 false 改为 true；接受链的 candidateVersion、detector 与 CAS 前置条件只由 [专题-01 §6](专题-01-正文建议接受(Accept%20Suggestion)实现规范.md) 定义。
+
+#### 4.5.4 实验落地边界
+
+当前只在正文实验台验证以上合同，不修改产品 API 契约、Flyway、正式业务数据库或 Canonical 主链。只有正文 Gate B 由 [专题-04 §10.1](专题-04-生成质量门控与创作健康度设计方案.md) 的唯一判定顺序裁决为 `passed` 后，才另立产品化计划更新 `docs/api-contracts/*`、数据库迁移和正式实现；Gate B 通过前不得启动细纲智能体真实能力验收。
+
 ## 5. 检索和图查询
 
 ### 5.1 RAG 定位
@@ -512,4 +560,5 @@ Source Status Event 必须幂等处理，传播失败时要可重试；在传播
 - `架构-01-系统全貌与边界上下文.md`
 - `架构-02-核心数据结构与双轨模型.md`
 - `架构-04-状态机与约束清单.md`
-- `专题-04-生成质量门控与创作健康度设计方案`
+- `专题-04-生成质量门控与创作健康度设计方案.md`
+- `专题-07-知识消费契约与质量闭环.md`

design-docs/专题-04-生成质量门控与创作健康度设计方案.md

@@ -1,8 +1,6 @@
 # 专题-04：生成质量门控与创作健康度设计方案
 
-- 版本：v1
-- 更新日期：2026-05-23
-- 目标读者：产品 / 架构 / 前端 / 后端 / 测试
+- 目标读者：创作者 / 产品 / Agent 实现者 / 架构 / 前端 / 后端 / 测试
 - 阅读时间：25-40 分钟
 - 边界说明：本文件承接阶段 1~5，定义质量门控(Quality Gate)、创作健康度(Writing Health)、质量策略、有限重写、质量结果展示和质量观测的产品架构合同。AI 编排、上下文组装和运行时权限见 `专题-03`；精确 Schema、API 和前端组件由后续阶段承接。
 
@@ -68,6 +66,27 @@
 | 角色声音一致性 | `character_voice` | 角色对白、行为、语气是否符合角色档案和近期章节表现 | 触发重写；失败可允许用户修改后合并 |
 | 场景结构 | `scene_structure` | 场景目标、动作链、因果、视角和段落推进是否完整 | 触发重写；严重断裂时建议重生成 |
 
+#### 4.2.1 运行时叙事门量表与通过线
+
+叙事关键维度在运行时按下列量表打分并裁决，不再是模糊词。盲评机制（双盲双评、候选随机化、任一维两次评分差 `>0.5` 只加一次第三评、稳定配对取中位数、无稳定配对则不得强行给出输赢）只引用 §10.1，本节不重复定义；运行时与离线实验的差异在于：运行时对**单个候选**裁决，离线实验对**种群 A/B 臂**裁决。
+
+每维按 0-10 分、0.5 分步长评分，并逐项标注证据来自已确认正文、Local KB、正式规划、Narrative State 还是评委自行推断。运行时通过线如下（由质量策略登记、可调，但必须显式登记；未登记视为门控未闭合，候选不得进 `shadow_ready`）：
+
+| 维度 | 通过线 | 理由 |
+|---|---|---|
+| 设定一致性 `canon_compliance` | `>=7.0` | 硬事实层，门槛最高 |
+| 角色声音一致性 `character_voice` | `>=6.0` | 可修改后合并，门槛次之 |
+| 场景结构 `scene_structure` | `>=6.0` | 可重写补救，门槛次之 |
+
+运行时裁决顺序（命中前项即停止，后项不得覆盖前项）：
+
+1. 设定一致性出现**硬事实冲突 verdict**（与已确认正文、Local KB 或正式规划直接矛盾，类比 §10.1 Gate A 的"硬约束覆盖率 `<100%`"）：不论分数，直接 `high_risk`，禁止接受。
+2. 任一维评分不稳定（无稳定配对）或评测异常：`unavailable`/`needs_recheck`，fail-closed，不放行。
+3. 任一维 `<` 通过线：触发 Shadow 内有限重写（上限见 §5，默认 ≤2 次）；重写后仍 `<` 通过线：`high_risk`，需修改后合并或重生成。
+4. 三维全 `>=` 通过线且无硬事实冲突：`pass`/`rewritten_pass`，可进 `shadow_ready`。
+
+`qualityState` 的转移与风险路由优先级只引用 §6，本节不重复定义。本节通过线数值是运行时默认值，其合理性由 §10 离线实验与回放评测校准；校准责任人与时点登记于质量策略。
+
 ### 4.3 非关键维度
 
 非关键维度只展示评分和建议，交给用户判断。
@@ -256,12 +275,13 @@ active -> superseded / rolled_back
 
 离线评估用于比较智能体、Prompt、上下文策略和质量策略，不直接影响用户当前候选。
 
-默认允许进入离线评估的样本只有四类：
+默认允许进入离线评估的样本只有五类：
 
 1. 合成样本。
 2. 公开授权样本。
 3. 用户或发布者显式授权用于评估的样本。
 4. 已按合规规则脱敏、去标识化且不可还原到用户私有正文的样本。
+5. 经 [专题-07 §4](专题-07-知识消费契约与质量闭环.md) 两道闸校验的参考作品回放样本（`reference_work` 授权四值 + 评测用途授权快照；评测产物不留存原书全文）。
 
 默认禁止进入离线评估：
 
@@ -269,7 +289,7 @@ active -> superseded / rolled_back
 - 私人 AI 候选全文。
 - 完整上下文快照。
 - 完整 Prompt / Response。
-- 外部知识或市场资产全文。
+- 外部知识或市场资产全文（经上文第 5 类两道闸校验的参考作品回放样本除外）。
 
 如果未来需要使用真实私有内容做评估，必须先有单独的合规访问设计、授权记录、最小化样本、脱敏策略、审计记录和退出机制；不能由质量策略配置直接打开。
 
@@ -279,6 +299,7 @@ active -> superseded / rolled_back
 - Agent Version。
 - Prompt Version。
 - Context Assembly Strategy。
+- 知识策略版本（选择契约参数、注入视图定义、判重规则；其回放评测机制见 [专题-07-知识消费契约与质量闭环](专题-07-知识消费契约与质量闭环.md)）。
 - Quality Policy Version。
 - Authorization Snapshot 和来源摘要。
 - New-API Binding 摘要。
@@ -296,6 +317,58 @@ active -> superseded / rolled_back
 
 评估结果只能用于管理员判断策略、智能体或 Prompt 是否上线，不直接修改用户作品。
 
+### 10.1 正文实验五维量表、盲评与 Gate A/B
+
+正文回放把创作、语义检测和盲评拆成独立模型职责：
+
+| 角色 | 每次调用的唯一职责 | 不负责 |
+|---|---|---|
+| writer | 根据最小创作输入生成一章正文 | claim、证据缺口、新设定申报、哈希、版本、自检或评分 |
+| semantic detector | 对一个已绑定候选核对事实、细纲硬约束、证据与新设定 | 创作、润色、改写、文学评分或运行哈希 |
+| blind judge | 对盲化候选按预注册维度评分并给出事实/硬约束 verdict | 修改正文、替代 detector、读取臂专属上下文或计算运行哈希 |
+
+“一个职责”不等于“一个字段一次调用”。detector 可以在一份报告中列出同一候选的多条语义 verdict，judge 可以在一份报告中完成同一次盲评的多维评分；创作、检测和评审仍必须是不同调用。
+
+同一样本的 A/B/C 由三个互不共享会话的 fresh writer 调用产生；每个候选各运行一次 fresh detector；两个 reviewer 分别运行 fresh blind judge，只有评分不稳定时增加一次第三 reviewer。模型、effort、输出 schema、单次预算和公共上下文控制必须在可比调用间一致。
+
+正文回放使用独立的 `writer` 评测 profile，不覆盖细纲、知识或其他评测量表。每个维度按 0-10 分、0.5 分步长评分，并逐项标注证据来自已确认细纲、冻结历史原文、卡索引还是评委自行推断。
+
+| 维度 | 评判问题 |
+|---|---|
+| 设定与实体保真 | 人物、关系、物品、地点、力量规则、知情范围和即时状态是否与冻结事实一致 |
+| 细纲与情节忠实 | 细纲硬事件、结果方向、伏笔动作、必须出场实体和章末钩子是否全部兑现，且未被反转或提前回收 |
+| 文风一致性 | 叙述声音、角色语言、动作习惯、段落节奏是否与冻结原文证据一致 |
+| 叙事张力 | 场景推进、因果、冲突升级、情绪连续和章末牵引是否成立 |
+| 文笔与可读性 | 文字是否准确、流畅、具体，是否存在空泛解释、机械重复或明显阅读阻力 |
+
+每个样本先由两个独立、无会话的评委双盲评分；候选臂名随机化，第二评委反转展示顺序。任一维两次评分差异 `>0.5` 时，只增加一次第三评委。第三评委后，若三份评分中至少一对差值 `<=0.5`，该维最终分取三者中位数；若不存在稳定配对，整个样本失败，不得强行给出输赢或方向结论。去盲、稳定性判断和聚合必须机械执行，人工只能复核证据归因，不能手改终态。
+
+blind judge 只能看到盲化 candidate ID、候选正文、所有臂相同的细纲评测字段和 evaluator-only oracleTruthPack；不得看到真实 A/B/C 映射、各臂 WriterContext、卡检索轨迹、臂专属原文或 raw 路径。judge 模型只返回五维评分、逐项理由、事实 verdict 和硬约束 verdict；candidate/input/oracle/report/model-receipt hash 由 judge adapter 注入或计算。
+
+预算分为两层：`plannedCalls` 是单个 Gate 执行的不可变调用计划，`maxCalls` 是独立安全上限。启动预留只按各角色 `plannedCalls × maxBudgetUsdPerCall` 计算，不得把安全上限当作调用计划；每次调用前还要校验累计实际成本、剩余计划预留和角色调用数。补证、返修或重跑必须创建新的显式计划与预算预留。
+
+正文实验只允许下列 Gate 顺序，命中前项即停止，后项不得覆盖前项：
+
+**Gate A（链路可运行）**
+
+1. 任一预期调用、schema、hash、冻结、授权、未来泄漏审计、模型回执或 judge 稳定性异常：`failed`。
+2. 预注册评测集自身不足 5 个有效样本或五类场景不全：`insufficient_evidence`。
+3. C 臂存在 detector 高严重度残留或细纲硬约束覆盖率 `<100%`：`failed`。
+4. 其余：`passed`。
+
+Gate A 只证明链路可运行，不代表正文层通过。
+
+**Gate B（正文层正式裁决）**
+
+1. Gate B 运行中任一预期调用、schema、hash、冻结、授权、泄漏审计或 judge 稳定性异常：`failed`。
+2. Gate A=`failed`：`failed`；Gate A=`insufficient_evidence`：`insufficient_evidence`。
+3. 预注册评测集作品 `<2`、任一作品有效样本 `<5`、总有效样本 `<10` 或五类场景未覆盖：`insufficient_evidence`。
+4. C 臂硬约束覆盖率 `<100%`、存在 detector 高严重度残留，或 C-A 的文风一致性/叙事张力在整体或任一非空新角色分层退化：`failed`。
+5. C-A 的设定与实体保真平均增量 `>=0.25` 且至少 `60%` 样本增量 `>0`：`passed`。
+6. 其余：`no_gain`。
+
+报告必须列出假阴、假阳、未来泄漏、评委不稳定、新角色无卡和场景选择偏差等混淆项。单章、单作品或只选卡友好场景不得得出普适结论。只有 Gate B=`passed` 才能声称正文层通过并启动细纲智能体真实能力验收；其他终态继续修正文层或补充预注册的合法样本。A/B/C 的冻结与接受隔离合同只引用 [专题-03 §4.5](专题-03-AI编排上下文与质量评测实现规范.md)，本节不重复定义。
+
 ## 11. 线上质量观测
 
 线上质量观测用于发现策略、智能体、上下文组装和质量门控的真实效果，不用于监控单个作者的创作水平。
@@ -351,3 +424,4 @@ active -> superseded / rolled_back
 - `架构-02-核心数据结构与双轨模型.md`
 - `架构-04-状态机与约束清单.md`
 - `专题-03-AI编排上下文与质量评测实现规范.md`
+- `专题-07-知识消费契约与质量闭环.md`

design-docs/专题-05-AI统一交互协议与外部AgentAdapter设计.md

@@ -1,9 +1,10 @@
 # 专题-05：AI 统一交互协议与外部 Agent Adapter 设计
 
-- 版本：v0.1
-- 更新日期：2026-06-29
+- 版本：v0.2
+- 更新日期：2026-07-20
 - 目标读者：架构 / 后端 / 前端 / 运维 / 测试
 - 边界说明：本文定义 Muse 后端到外部 Agent 运行时的统一交互协议与 adapter 层。它承接 `专题-03-AI编排上下文与质量评测实现规范.md`，不改变 Shadow -> Canonical、Runtime Permission Envelope、RAGFlow 检索和用户确认边界。
+- 变更记录：v0.2（2026-07-20）§5.4 固化正文写手 adapter 的无工具、无会话持久化和超时失败关闭边界；v0.1（2026-06-29）建立外部 Agent 统一协议与 provider adapter 设计。
 
 ## 1. 背景与结论
 
@@ -215,6 +216,19 @@ AgentScope adapter 以后按同一协议接入：
 - 请求和响应仍走 `MuseAgentRuntimeRequest/Response`
 - AgentScope 内部工具和知识权限即使受限，Muse 仍按外部 runtime 处理，不授予直接写入权。
 
+### 5.4 正文写手 adapter 隔离边界
+
+正文写手 adapter 是开放能力节点，但采用比通用 provider 更窄的执行边界：
+
+1. **无工具**：写手进程的工具集合必须为空，不得读取文件、搜索、访问数据库、调用网络工具或自行扩大检索范围。检索、授权、冻结与组装全部在可信的 Muse 层完成。
+2. **无会话持久化**：每次 attempt 使用独立无状态进程，禁止恢复、续接或保存 provider 会话；旧 attempt 的隐式记忆不得进入新候选。
+3. **单一输入**：adapter 只接收 [专题-03 §4.5](专题-03-AI编排上下文与质量评测实现规范.md) 定义的冻结 `WriterContext v1`，不得旁路追加未登记正文、卡片、Prompt 记忆或未来信息。
+4. **严格输出**：只接受 `WriterOutput v1`；非 JSON、未知字段、缺字段、候选哈希或上下文哈希不匹配均视为协议失败，不生成可接受候选。
+5. **超时失败关闭**：adapter 必须设置单次 deadline。超时、取消、非零退出、provider bad response 或进程失联时，当前 attempt 进入失败终态，取消下游 detector/judge，丢弃迟到结果，且不得回退到有工具写手、旧会话或其他 provider 伪装成功。
+6. **接受资格不可伪造**：`acceptanceEligible` 由可信上下文层派生；诊断/评测运行及任何 adapter 失败结果固定不可接受。provider 返回 true 不能覆盖可信层的 false。
+
+该边界先在实验台验证，不新增或修改产品 API、数据库字段和正式 runtime 状态；产品化必须等待正文 Gate B 通过后另立计划。本节只拥有 adapter 隔离语义，Writer 合同和接受链分别由专题-03、专题-01 定义。
+
 ## 6. 系统 Agent 配置体验
 
 管理端系统 Agent 配置页新增“外部运行时”区域：

design-docs/专题-06-元数据驱动的智能体架构.md

@@ -1,10 +1,10 @@
 # 专题-06：元数据驱动的智能体架构
 
-- 版本：v3
-- 更新日期：2026-07-09
+- 版本：v5
+- 更新日期：2026-07-20
 - 目标读者：架构 / 后端 / 前端 / 产品
 - 边界说明：本册是「元数据驱动的智能体架构」这条横切主线的单一 owner，收束四件此前散落无主的事——元引擎与功能链如何共同驱动智能体、拆书作为通用抽取智能体的两处用场、target type 结构本体的全清单与分层判据、统一创作数据读取器与 base 内置机制。术语与双轨不变式的权威在 [架构-02-核心数据结构与双轨模型](架构-02-核心数据结构与双轨模型.md)（MetaSchema、Canonical/Shadow、domain/scope）；AI 链路合同与 Context Assembly 在 [专题-03-AI编排上下文与质量评测实现规范](专题-03-AI编排上下文与质量评测实现规范.md)；外部 Agent 协议在 [专题-05-AI统一交互协议与外部AgentAdapter设计](专题-05-AI统一交互协议与外部AgentAdapter设计.md)；表结构与字段合同在 [后端-04-统一数据库Schema-v1](后端-04-统一数据库Schema-v1.md)。上述对象本册只链接、不重复定义。
-- 变更记录：v3（2026-07-09）结构本体补全 scope 轴空格位——新增 `chapter`（章节容器）、`scene`（场景卡）、`narrative_state`（叙事状态模具）三型，清单 20→23、scope 七值全挂靠，种子四档同步 23 项；钉死读取器只依赖 owner api 模块具名端口（服务即 API）与 storage_binding 的权力边界（映射非数据通道）。v2（2026-07-09）新增 §2.1 检索基座的替换合同与演进方向（引擎缝 + 引擎中立合同，预期纯 Java 自研：PG 向量插件 + New-API 嵌入/重排，切块收回保护节点）。v1（2026-07-09）定稿自 2026-07-08 架构评审，将「agent = f(作品 + 元数据 + 知识库)」主线、三体关系、20 型结构本体、统一读取器与 base 机制蒸馏为 canonical。
+- 变更记录：v5（2026-07-20）§7.1 登记 `generation_context` 的 generation purpose 严格 schema 投影、卡索引视图和事实/原文双证据字段，具体合同仍由专题-03/07 owner 定义。v4（2026-07-17）拆书实验台证据回填——§4.5 拍板双层型开放问题（`craft` 公共面实测无损写入同一字段合同，单模具双库成立，不拆）并登记世界域实体型共享「演变历程」元素；§6 新增 6.4 参照作品面（参考书实体演变卡 = 系统侧证据资产，蒸馏为叙事域成长曲线范式后才入 Global KB）；知识消费选择契约与质量闭环整体归新册 [专题-07-知识消费契约与质量闭环](专题-07-知识消费契约与质量闭环.md)，本册补链接；§7 读取器 purpose 枚举 `parse` 统一为 `extraction`、字段级裁剪随 `aiContext` 值域升级（布尔或用途集，权威在 [架构-02 §9](架构-02-核心数据结构与双轨模型.md)）对齐表述。v3（2026-07-09）结构本体补全 scope 轴空格位——新增 `chapter`（章节容器）、`scene`（场景卡）、`narrative_state`（叙事状态模具）三型，清单 20→23、scope 七值全挂靠，种子四档同步 23 项；钉死读取器只依赖 owner api 模块具名端口（服务即 API）与 storage_binding 的权力边界（映射非数据通道）。v2（2026-07-09）新增 §2.1 检索基座的替换合同与演进方向（引擎缝 + 引擎中立合同，预期纯 Java 自研：PG 向量插件 + New-API 嵌入/重排，切块收回保护节点）。v1（2026-07-09）定稿自 2026-07-08 架构评审，将「agent = f(作品 + 元数据 + 知识库)」主线、三体关系、20 型结构本体、统一读取器与 base 机制蒸馏为 canonical。
 
 ---
 
@@ -113,7 +113,7 @@ sequenceDiagram
 | 元数据用途类 | 管什么 | 载体与 owner |
 |---|---|---|
 | **① 结构本体** | 实体有哪些属性（拆书抽、生成写、检测查的结构模具） | MetaSchema target types（本册 §4.2 起） |
-| **② 质量维度** | 怎么评判好坏 | Quality Policy（[专题-04](专题-04-生成质量门控与创作健康度设计方案.md)） |
+| **② 质量维度** | 怎么评判好坏 | Quality Policy（[专题-04](专题-04-生成质量门控与创作健康度设计方案.md)；输入侧知识质量维度与回放评测见 [专题-07](专题-07-知识消费契约与质量闭环.md)） |
 | **③ 编排** | 智能体怎么串 | FunctionChain（本册 §1，落地见 [后端-04 §7.2](后端-04-统一数据库Schema-v1.md)） |
 | **④ 智能体配置** | 每个能力怎么配（prompt/模型绑定/工具授权/输出合同） | Agent Version（[专题-05](专题-05-AI统一交互协议与外部AgentAdapter设计.md)） |
 | **⑤ 可见与策略** | 每字段的权限行为与灰度 | MetaVisibilityPolicy（[架构-02 §9](架构-02-核心数据结构与双轨模型.md)） |
@@ -204,9 +204,9 @@ scope 落座有两处最易被误判，须点明。`outline` 取 `work` 而非 c
 
 ### 4.5 三层浇铸与双层型
 
-结构本体按浇铸去向分三层：**结构骨架**只浇作品事实实例，入 Local KB 或规划；**公共参考**只浇跨作品范式，由系统级拆书入 Global KB，只存抽象范式与脱敏例证、不留原文；**双层**两处都浇。所有型共享名称/别名/摘要/标签等基础字段，各型只在此之上标注特有字段。
+结构本体按浇铸去向分三层：**结构骨架**只浇作品事实实例，入 Local KB 或规划；**公共参考**只浇跨作品范式，由系统级拆书入 Global KB，只存抽象范式与脱敏例证、不留原文；**双层**两处都浇（参考书的世界域实体演变另有落位，见 §6.4 参照作品面）。所有型共享名称/别名/摘要/标签等基础字段，各型只在此之上标注特有字段；世界域实体型（`location`/`faction`/`power_system`/`item`/`event`/`character`）在此之上共享**演变历程**元素（{章, 台阶, 周期} 结构化里程碑，实验台已在六型实证；长线消费语义见 [专题-07 §5](专题-07-知识消费契约与质量闭环.md)，字段合同落 [后端-04](后端-04-统一数据库Schema-v1.md)）。
 
-`character`、`style`、`pacing`、`craft` 四型是双层型。主案取**单模具双库**——一型一 schema，作品面实例与公共范式共用同一字段合同，公共面实例落 Global KB。是否为公共面另立独立的 `*_paradigm` 型，留待三样本实测（拆书产出的公共范式能否无损写进同一字段合同）再定：能无损写入则不拆，字段合同不同构才拆。在此之前 W1 先落作品面种子，不被这个开放问题阻塞。
+`character`、`style`、`pacing`、`craft` 四型是双层型。主案取**单模具双库**——一型一 schema，作品面实例与公共范式共用同一字段合同，公共面实例落 Global KB。是否为公共面另立独立的 `*_paradigm` 型，判据本身不变——三样本实测无损写入则不拆、字段合同不同构才拆。`craft` 已由拆书实验台以远超三样本的量级实测通过（1326 条公共范式无损写入同一字段合同），**拍板不拆**；`character`/`style`/`pacing` 依同一三样本判据在各自公共面首批落库时判定，无损即沿用单模具。判定机制至此闭合，不再是开放问题。
 
 ---
 
@@ -266,6 +266,14 @@ scope 落座有两处最易被误判，须点明。`outline` 取 `work` 而非 c
 
 系统级范式的入库走一条专门入口——「管理员确认系统级知识草稿 → Global KB 范式 Canonical」，确认人是管理员，产出走 Draft→确认→Canonical 同构链。该入口是双轨 Canonical 封闭枚举的一项，权威登记见 [架构-02 §1.2 进入 Canonical 的入口](架构-02-核心数据结构与双轨模型.md)。
 
+### 6.4 参照作品面：参考书实体演变的浇铸位
+
+系统级拆书除产出抽象范式外，还会按章推进沉淀参考书自身的实体演变卡——力量体系、物品、角色等世界域形态，带真实章号的 {章, 台阶, 周期} 里程碑。这类产物**不进 Global KB、不可被用户作品绑定**，浇铸位是**参照作品面**：挂在 `reference_work` 档案之下的系统侧中间资产（knowledge 域），生命周期随参考作品档案的「采购→拆解→归档」走。它的正式用途只有两个：**回放评测的标准答案底座**与**叙事域范式的蒸馏源**（两个用途的定义见 [专题-07](专题-07-知识消费契约与质量闭环.md)）。
+
+进入 Global KB 的只能是蒸馏后的叙事域「成长曲线范式」（`trope`/`pacing` 形态：台阶间距分布、周期结构、爆发节奏），溯源与版权传播沿用 §6.3——只存定位摘要，不存原文。一句话钉死边界：**世界域形态是证据，叙事域形态才是范式；参照作品面存证据，Global KB 只收范式。**
+
+承载与治理三条钉死：参照作品面**不是第四类知识库**，不进 [架构-02 §4.1](架构-02-核心数据结构与双轨模型.md) 的三类库清单，用户不可见、不可检索；物理承载复用 §6.2 已定的 Global KB document 特化与资料处理任务链，父对象是 `reference_work` 档案，随档案「采购→拆解→归档」同生命周期；参考作品版权状态收紧时沿 §6.3 的来源传播语义处理——阻断其派生证据用于新的评测与蒸馏（均属新使用），不回滚已确认的范式 Canonical。
+
 ---
 
 ## 7. 统一创作数据读取器
@@ -278,10 +286,24 @@ scope 落座有两处最易被误判，须点明。`outline` 取 `work` 而非 c
 
 **最小读合同**：
 
-- **输入**六项：actor；workId；分区请求集（作品容器 / 规划 / 按 target_type 与 scope 过滤的 Local KB 实体 / 仅限已绑定的 Global KB 公共范式，对齐「显式绑定不自动注入」）；运行权限包引用（其分区许可上限只能收紧不能放宽）；purpose（generation/detection/planning/parse，授权按用途裁，对齐 [专题-03 §4.3 来源和授权](专题-03-AI编排上下文与质量评测实现规范.md) 的「允许阅读不等于允许进 AI 上下文」）；期望 schemaVersion（可选，防任务中途版本漂移）。
+- **输入**六项：actor；workId；分区请求集（作品容器 / 规划 / 按 target_type 与 scope 过滤的 Local KB 实体 / 仅限已绑定的 Global KB 公共范式，对齐「显式绑定不自动注入」）；运行权限包引用（其分区许可上限只能收紧不能放宽）；purpose（generation/detection/planning/extraction，授权按用途裁，对齐 [专题-03 §4.3 来源和授权](专题-03-AI编排上下文与质量评测实现规范.md) 的「允许阅读不等于允许进 AI 上下文」）；期望 schemaVersion（可选，防任务中途版本漂移）。
 - **输出**：分区化的结构块列表，每块含 `targetType`、`schemaKey`、`schemaVersion`、已按 `aiContext` 裁剪的结构化字段值、`dataRevision`、来源标注（对齐 [专题-03 §5.3 检索结果合同](专题-03-AI编排上下文与质量评测实现规范.md)），以及 `omittedFields` 及原因。
 
-裁剪分三级、同时生效：**字段级**（`aiContext=false` 的字段剔除）、**来源级**（状态受限的来源整块不进）、**用途级**（`allowedPurpose` 不含本次 purpose 的剔除）。任一级判定剔除，数据即不进上下文。受限来源整块进 `omittedSources`，失败关闭并留痕可审计。
+裁剪分三级、同时生效：**字段级**（`aiContext` 不含本次 purpose 的字段剔除——`false` 即任何用途不入、`true` 即全用途可入，值域权威见 [架构-02 §9](架构-02-核心数据结构与双轨模型.md)）、**来源级**（状态受限的来源整块不进）、**用途级**（来源授权 `allowedPurpose` 不含本次 purpose 的剔除）。任一级判定剔除，数据即不进上下文。受限来源整块进 `omittedSources`，失败关闭并留痕可审计。
+
+### 7.1 `generation_context` 的正文生成登记
+
+`generation_context`（domain=`ai_context`、scope=`agent`）在正文实验中启用 generation purpose 的严格 schema 投影。这里仅登记 MetaSchema 结构入口，不复制邻册合同：
+
+| 登记项 | MetaSchema 约束 | 唯一 owner |
+|---|---|---|
+| purpose | 固定枚举值 `generation`；不接受别名、空值或未知值 | purpose 值域与字段级 `aiContext` 语义仍见 [架构-02 §9](架构-02-核心数据结构与双轨模型.md) |
+| schema / output 版本 | 必填、精确匹配；缺字段与未知字段失败关闭 | `WriterContext v1` / `WriterOutput v1` 见 [专题-03 §4.5](专题-03-AI编排上下文与质量评测实现规范.md) |
+| cardIndexView | 只登记抽取卡的索引视图与来源引用，不承载原文正文 | “卡是索引、根据来源回读原文”见 [专题-07 §2.1](专题-07-知识消费契约与质量闭环.md) |
+| factEvidence / proseEvidence | 两个独立字段组，禁止互相冒充或合并成通用 evidence | 双证据字段、哈希和冻结规则见 [专题-03 §4.5](专题-03-AI编排上下文与质量评测实现规范.md) |
+| 正式事实来源 | 正式设定、Canonical 状态和细纲新事实保留各自不可变版本引用，不强造抽取卡或历史原文来源 | 权威来源分类见 [专题-07 §2.1](专题-07-知识消费契约与质量闭环.md) |
+
+该登记先约束实验台 schema 和上下文投影，不代表产品 API、数据库结构或正式 MetaSchema 种子已经变更；产品化必须等正文 Gate B 通过后另立契约与迁移计划。
 
 ---
 
@@ -293,6 +315,7 @@ scope 落座有两处最易被误判，须点明。`outline` 取 `work` 而非 c
 | BC 边界与协作规则、override 只增不改的边界推论 | [架构-01-系统全貌与边界上下文](架构-01-系统全貌与边界上下文.md) |
 | AI 编排、Context Assembly、检索合同、质量评测 | [专题-03-AI编排上下文与质量评测实现规范](专题-03-AI编排上下文与质量评测实现规范.md) |
 | 质量维度定义与创作健康度 | [专题-04-生成质量门控与创作健康度设计方案](专题-04-生成质量门控与创作健康度设计方案.md) |
+| 知识消费选择契约、知识质量三性、回放评测、长线进度消费语义 | [专题-07-知识消费契约与质量闭环](专题-07-知识消费契约与质量闭环.md) |
 | 外部 Agent 统一协议与 adapter | [专题-05-AI统一交互协议与外部AgentAdapter设计](专题-05-AI统一交互协议与外部AgentAdapter设计.md) |
 | MetaSchema 表、功能链表、reference_work 表、storage_binding 落点 | [后端-04-统一数据库Schema-v1](后端-04-统一数据库Schema-v1.md) |
 | 作品与动态字段接口契约 | [后端-05-统一API契约-v1](后端-05-统一API契约-v1.md) |

design-docs/专题-07-知识消费契约与质量闭环.md

@@ -0,0 +1,225 @@
+# 专题-07：知识消费契约与质量闭环
+
+- 版本：v2
+- 更新日期：2026-07-20
+- 目标读者：产品 / 架构 / 后端 / 测试
+- 边界说明：本册是「知识效用」这条横切主线的单一 owner——回答「该读什么知识、注入后有没有用、知识本身好不好」，收束四件此前无主的事：知识消费选择契约（含按用途默认合同与注入视图）、知识质量三性、回放评测、长线进度消费语义；文末附实验台实证附录。以下邻册对象本册只链接、不重复定义：Context Assembly 分层与 Token 预算见 [专题-03 §4](专题-03-AI编排上下文与质量评测实现规范.md)、检索结果合同见 [专题-03 §5.3](专题-03-AI编排上下文与质量评测实现规范.md)、统一创作数据读取器读合同见 [专题-06 §7](专题-06-元数据驱动的智能体架构.md)、输出侧质量维度见 [专题-04](专题-04-生成质量门控与创作健康度设计方案.md)、结构本体与字段合同见 [专题-06 §4](专题-06-元数据驱动的智能体架构.md) 与 [后端-04](后端-04-统一数据库Schema-v1.md)、Narrative State 与双轨见 [架构-02](架构-02-核心数据结构与双轨模型.md)。核心主张一句话：**知识的价值只在被选中并改善产出——写作、检测、规划三个效用时刻——的那一刻兑现；质量标准必须由消费端定义、由回放评测测量——以用定卡。**
+- 变更记录：v2（2026-07-20）在 §2.1 固化正文消费的「卡是索引、按来源回读冻结原文」契约，并区分抽取卡证据与正式设定、Canonical 状态、细纲新事实三类独立权威来源。v1（2026-07-17）建立知识消费选择、质量三性、回放评测和长线进度消费语义。
+
+---
+
+## 0. 术语桥
+
+理解本册的钥匙：**SoT 里没有「卡」这个一级概念**。产品与实验台口语里的「知识卡片 / 卡」是一组权威载体的统称，本册全部论述落到这组载体上，不新造模型。
+
+| 口语说法 | SoT 权威载体 | owner |
+|---|---|---|
+| 待确认的卡 | Knowledge Draft（待审、默认不可信） | [架构-02 §4.2](架构-02-核心数据结构与双轨模型.md) |
+| 本作正式事实卡 | Local Knowledge Entity · Relation（本作正式实体/关系） | [架构-02 §4.2](架构-02-核心数据结构与双轨模型.md) |
+| 公共参考卡 | Global KB 范式 Canonical（跨作品公共参考） | [架构-02 §1.2 / §4.1](架构-02-核心数据结构与双轨模型.md) |
+| 卡的结构模具 | MetaSchema target_type（23 型） | [专题-06 §4.3](专题-06-元数据驱动的智能体架构.md) |
+
+两个实验台口语也一次性登记，下文实证引用沿用：**范式卡** = 技法五型的公共参考卡（进 Global KB）；**升格卡** = 世界域型的实体演变卡——产品内是本作事实卡（进 Local KB），实验台以参考书彩排时其产物落参照作品面（见 §5）。
+
+登记：**拆书实验台（agent-example，仓内实验目录）是本册与专题-06 的排练场**——设计不等于进度，实验台证据只作本册论断的实证输入，不代表产品已实现。
+
+---
+
+## 1. 第一性原理：知识是外置记忆，缺的是效用闭环
+
+一句话钥匙：**长篇创作的一切质量问题，本质都是记忆问题；知识库就是这套系统的外置记忆。**
+
+模型上下文有限且没有持久状态，百万字长篇里吃设定、前后矛盾、角色失声、升级线错乱，根子都是「该记住的没被带回来」。抽卡的唯一目的，是让知识在未来某次生成里被选中、被注入、改善产出。记忆兑现价值的时刻只有三个，与智能体分工一一对应（[专题-06 §3](专题-06-元数据驱动的智能体架构.md)）。
+
+| 效用时刻 | 谁在用 | 用什么 |
+|---|---|---|
+| 写作时注入 | 写作智能体 | 实体当前态 + 技法范式参考 |
+| 检测时对照 | 检测智能体 | Local KB 当标准，查候选是否吃设定（对应 `canon_compliance`） |
+| 规划时排线 | 规划智能体 | 演变历程 + 参照书成长曲线，排下一个台阶 |
+
+产品承诺就锚在这三个时刻上。[产品-01](产品-01-产品定位与核心价值.md) 的核心卖点原话是「已确认知识在下一次生成时真正回到上下文」，叙事质量承诺是「角色弧光、情节推进、悬念维护和章节张力」不退化——兑现这两句承诺的机器正是本册。
+
+缺环在哪：**治理侧全线完备，效用侧全线空缺。**
+
+| 侧面 | 问的问题 | 现状 |
+|---|---|---|
+| 治理（能不能读） | 授权 / 来源 / 双轨 / 裁剪 / 预算 | 钉死（专题-03、专题-06 §7、架构-02） |
+| 效用（该不该读、好不好） | 这一幕该选哪些知识、什么算一条好知识、注入后有没有用 | 无 owner、无定义、无测量 |
+
+最锋利的一条必须写死——**记忆腐坏时，输出端门控不但补偿不了，还会放大伤害**。检测维度 `canon_compliance` 拿 Local KB 当对照标准来拦候选（[专题-04 §4.2](专题-04-生成质量门控与创作健康度设计方案.md)）：知识错了，门控会把写对的候选当成「吃设定」拦下来。所以输入端质量不是锦上添花，是输出端门控成立的前提。
+
+---
+
+## 2. 知识消费选择契约
+
+一句话钥匙：**读取器（[专题-06 §7](专题-06-元数据驱动的智能体架构.md)）解决「能不能读 + 怎么裁字段」，本节补「该读哪几条」——按知识形态分两类合同，选择键不同、注入形态不同。**
+
+| 知识形态 | 选择键（该读哪几条） | 注入什么 | 不做什么 |
+|---|---|---|---|
+| 本作事实（Local KB 实体/关系/事件） | 在场召回（当前场景出场实体 + 其关系闭包）+ 相似召回兜底 | 实体**当前态**摘要 | 不注入全演变历程——历程按 `aiContext` 用途裁剪，续写不给（实验台实证：演变历程标 [detection, extraction]，防上万字明细撑爆上下文） |
+| 公共范式（Global KB 技法五型 `craft`/`combat`/`emotion`/`scene_pattern`/`trope`） | 结构化匹配：型 × 场景意图（打斗/情感/通用桥段）× 线程弧位（`trope` 管「这条线接下来几章怎么走」）× 品类 | 规划期选定的范式引用 | **不靠相似度临场海选**——范式描述与正文语域不同，实验台实证同型范式向量相似 74% 多为词汇假近，语义真并率仅约 10% |
+
+口径说明：上表「公共范式」行指写作期的技法范式；`style`/`pacing` 的跨作品公共面（含参照作品面蒸馏出的成长曲线范式，见 §5）按 planning 行的结构键召回，不走写作期注入。
+
+范式进入生成上下文的正路是「**规划期决策、写作期引用**」，不是写作时临场向量海选。规划产出必须显式挂所引范式的引用，形成「规划决策 → 写作引用」链；写作期只按引用注入，不重新检索范式。
+
+**按用途的默认合同**——统一读取器 purpose 四值（[专题-06 §7](专题-06-元数据驱动的智能体架构.md)）逐一钉死默认选择；分层次序与 Token 预算的上位规则见 [专题-03 §4.2](专题-03-AI编排上下文与质量评测实现规范.md)，本表只定「该选哪几条」：
+
+| purpose | 默认注入 | 明确不注入 |
+|---|---|---|
+| generation（续写/场景写作） | 在场实体（当前章出场 + 一跳关系）的当前态**摘要视图**；规划期已决策引用的公共范式（上限 3 条，全文视图）；文风/节奏画像 | 范式临场海选；演变历程全线 |
+| planning（规划/排线） | 目标线程实体的演变历程全线；大纲与作品核心；Global 成长曲线范式（型 × 品类结构键召回，相似度只作兜底） | — |
+| detection（一致性检测） | 在场实体当前态全量 + 关系闭包 + 事件时间线 | 公共范式（检测不需要「怎么写」） |
+| extraction（抽取/维护知识） | 该型模具全字段视图 | — |
+
+```mermaid
+flowchart LR
+    subgraph P["消费用途 purpose"]
+        direction TB
+        G["写作 generation"]
+        D["检测 detection"]
+        PL["规划 planning"]
+        X["抽取 extraction"]
+    end
+    subgraph F["知识形态 → 选择键"]
+        direction TB
+        L["本作事实（Local KB）<br/>在场召回 ＋ 相似兜底"]
+        C["公共范式（Global KB 技法五型）<br/>型 × 场景意图 × 线程弧位 × 品类"]
+    end
+    subgraph V["注入视图（≠ 存储形态）"]
+        direction TB
+        VS["摘要 / 全文两档"]
+        VR["排序：结构匹配度 ＋ 效用统计"]
+    end
+    P -->|按 aiContext 用途裁深浅| F
+    L --> V
+    C -->|规划期决策·写作期引用| V
+```
+
+**联合与冲突**：来源优先级全链对齐 [产品-01](产品-01-产品定位与核心价值.md)——本作事实（Local KB）＞ 用户绑定知识（User KB 与已安装知识库）＞ 全局与市场参考（Global KB 范式、市场资产摘要），冲突时低优先级来源不得替代高优先级事实；范式只提供「怎么写」，不得覆盖「是什么」。
+
+**卡粒度预算**：进入上下文的是**注入视图，不是整条存储记录**。注入视图分两档——摘要视图（名称 + 一句话摘要 + 当前态要点）是默认档，焦点实体升全文视图（按 `aiContext` 裁剪后的字段全量）。排序信号 = 结构匹配度（在场 > 关系一跳 > 相似兜底；范式取型 × 场景意图 × 品类的精确匹配优先）+ 效用统计（被命中率 / 被接受率 / 跨书频次）；预算内截断落 omittedSources（截断规则归 [专题-03 §4.2](专题-03-AI编排上下文与质量评测实现规范.md)）。实验台实证两端病并存——p50 卡体仅 395 字符（薄到无肉可注）与单卡 104KB（角色卡流水累积，一张即撑爆预算）——这证明注入视图必须是一份独立合同，不能等于存储形态。
+
+### 2.1 正文消费的卡索引与原文回读契约
+
+正文生成再加一条不可绕过的消费规则：**卡是索引，根据抽取卡记录的来源回读原文；卡不能替代原文。** 卡负责缩小检索范围、指出相关实体与历史状态，冻结线内的历史原文负责证明人物声音、动作习惯、能力表现和叙事质感。读取器不得把卡片正文直接倾倒给写手，或把抽取摘要伪装成历史原文证据。
+
+| 来源类型 | 进入正文上下文的条件 | 证据落点 |
+|---|---|---|
+| 由历史正文抽取的卡 | 必须携带 `sourceVersion`、`sourceRefs` 和按冻结点重建的 `stateAsOf`；系统沿 `sourceRefs` 回读 `chapter <= asOf` 的原文，并记录章节、Block、字符区间与内容哈希 | 卡只保留索引视图；事实约束与写法参考分别进入 [专题-03 §4.5](专题-03-AI编排上下文与质量评测实现规范.md) 的双证据字段 |
+| 无可追踪原文来源的抽取卡 | 只能作为 `unverifiedIndexHint` 暴露缺口，不得单独支撑正文硬事实 | 进入省略/缺口清单，不进入可采信事实证据 |
+| 作者确认的正式设定 | 直接引用其不可变正式版本，不要求伪造历史原文来源 | 独立权威事实证据 |
+| Canonical 状态 | 直接引用当前冻结点可见的正式状态版本，不要求抽取卡二次背书 | 独立权威事实证据 |
+| 细纲声明的本章新事实 | 以已确认细纲版本为权威，标记 `declared_new`；它不是历史事实，不得强造原文来源 | 独立权威事实证据与新设定申报 |
+
+卡片与其来源是否落在冻结线内，只按 [专题-03 §4.5](专题-03-AI编排上下文与质量评测实现规范.md) 的 `RetrievalManifest` 和冻结规则判断；本册只拥有“选卡后必须回读什么”以及哪些正式事实不依赖抽取卡的消费规则。
+
+---
+
+## 3. 知识质量三性（输入侧质量维度）
+
+一句话钥匙：**三性是输入侧检尺，与专题-04 的输出侧维度同构——模具与检尺分立、单向咬合（[专题-04 §4](专题-04-生成质量门控与创作健康度设计方案.md)）；输出维度检「写出来的字好不好」，三性检「拿去写的知识好不好」。**
+
+| 质量性 | 定义 | 失败实证（实验台） | 可测指标建议 |
+|---|---|---|---|
+| **可命中** | 该被想起时能被检索到：命名鲁棒（别名表）+ 向量覆盖 + 结构键齐全 | 升格卡命名脆，同一实体断成两条成长线（「生物机甲」与「铁头」分家）；升格卡向量覆盖为 0，尚未接入检索 | 别名覆盖率（有别名表的实体卡占比）、向量覆盖率（有活向量的活卡占比）、同实体分裂率（抽样审计中同一真实实体被建成多条卡的比例） |
+| **可行动** | 注入后能直接改善产出，而非一段分析散文 | 升格台阶粒度过长、单位事件串进体系卡；实体卡缺「当前态摘要」 | 注入视图尺寸达标率（落在该型登记上限内的占比）、字段充实度（对照该型字段合同的非空率） |
+| **可持续** | 增量维护下不腐坏：判重「同名异质不并、真同才并」、演变归并有序、溯源完备 | 向量相似 74% 多为同型词汇假近、真并率仅约 10%——「同名异质不并」是对的（宁缺勿滥） | 重复率（消费端召回中判为同一知识的比例）、演变断线率（抽样审计中同实体演变断成多线的比例）、溯源完整率（可回溯到来源与归并审计的卡占比） |
+
+范式卡字段形态已较好（公式 / 启动条件 / 失效风险 / 张力来源），实体卡的短板是缺当前态摘要；可持续还要求演变按真实章号排序、溯源可回溯可撤销。
+
+**单实例长尾**必须点明：实验台实证范式卡 p50 实例数 = 1——「只被观察到一次的范式」只是观察不是范式。跨书频次是范式可信度的核心信号，消费端效用统计（命中 / 接受）是最终裁决。**质量三性的裁决权在消费端，不在抽取端。**
+
+三性指标的阈值不拍脑袋：由回放评测（§4）首轮基线确定，此后进入质量策略生命周期管理（draft → evaluating → active，见 [专题-04 §9.2](专题-04-生成质量门控与创作健康度设计方案.md)），与输出侧维度同一套治理节奏。
+
+---
+
+## 4. 回放评测：质量的测量闭环
+
+一句话钥匙：**参考书本身就是标准答案。** 冻结第 N 章时点的知识状态 → 按 §2 契约组装上下文 → 跑规划/续写/检测 → 与原书第 N+1 章（或后续台阶）对照评分，把知识质量从口味变成数字。
+
+| 评测线 | 怎么跑 | 评什么 |
+|---|---|---|
+| 规划线 | 用第 N 章知识预测下一台阶 / 伏笔回收，对照原书实际走向 | 台阶预测命中、伏笔回收命中 |
+| 生成线 | 有卡 vs 无卡 vs 打乱卡 的对照生成 | 设定一致性、要素覆盖 |
+| 检测线 | 人工向候选注入错误 | 错误检出率 |
+
+评的是整体：**知识质量 × 选择策略 × 提示词共同决定回放得分，必须变量控制对照才能归因**。落位上，回放评测是 [专题-04 §10](专题-04-生成质量门控与创作健康度设计方案.md) 离线评估框架内的一类评估——该框架的评估输入已含 Context Assembly Strategy，本册补「知识策略」这一评估对象维度。样本合规两道闸：**授权状态闸**对齐 [专题-06 §6.2](专题-06-元数据驱动的智能体架构.md) 的 `reference_work` 授权四值，`unauthorized` 失败关闭、不进评测；**评测用途闸**——版权状态不等于评测许可，样本进入评测必须绑定不可变授权快照且 `allowedPurpose` 包含离线评测（对齐 [专题-03 §4.3](专题-03-AI编排上下文与质量评测实现规范.md) 「授权按用途执行」与 [专题-04 §10](专题-04-生成质量门控与创作健康度设计方案.md) 的允许样本四类），`research_only` 只限内部评测、禁外发。评测产物只存评分、摘要与章节定位，不留存原书全文。
+
+由此立一条门禁：**知识策略（选择契约参数、注入视图定义、判重规则）的变更，未经回放对照评测不得上线、不得声称改善质量**——对齐 [专题-04 §9.2](专题-04-生成质量门控与创作健康度设计方案.md) 策略生命周期的 evaluating → active，评测未过就没有 active。
+
+**知识策略（Knowledge Strategy）是一个正式策略对象**，与 Quality Policy 同栖 AI 编排的策略面、同一套治理节奏：内容 = 选择契约参数（§2 默认合同的可调参数）+ 注入视图定义（各型两档视图与尺寸上限）+ 判重规则（§3 可持续判据）；生命周期 = draft → evaluating → active（[专题-04 §9.2](专题-04-生成质量门控与创作健康度设计方案.md)）；每次评测与生成任务记录其版本引用（评测输入登记见 [专题-04 §10](专题-04-生成质量门控与创作健康度设计方案.md)），回滚只影响后续任务、不改写历史结果。
+
+拆书实验台是回放评测的第一个排练场：书（8 本约 1.18 万章）+ 卡（范式 6327 / 升格 2260）+ 章级锚点（实例 / 里程碑带真实章号）三要素已齐，是唯一能把卡质量落成数字的地方。
+
+```mermaid
+flowchart LR
+    Prod["生产<br/>拆书抽取 · 23 型模具"] --> Gov["治理<br/>双轨确认 · 授权/来源"]
+    Gov --> Sel["选择<br/>§2 消费契约<br/>冻结第 N 章知识状态"]
+    Sel --> Inj["注入<br/>§2 注入视图组装上下文"]
+    Inj --> Gen["生成 / 检测 / 规划"]
+    Gen --> Cmp["对照原书<br/>第 N+1 章 / 后续台阶"]
+    Cmp --> Score["评分<br/>规划线 / 生成线 / 检测线"]
+    Score -. 反哺卡质量三性 .-> Prod
+    Score -. 反哺选择策略 .-> Sel
+```
+
+---
+
+## 5. 长线进度消费语义（演变历程如何被用）
+
+一句话钥匙：**长篇（尤其升级流品类）的骨架是实体演变——力量体系、装备、角色的台阶推进；载体已在，缺的是消费语义。**
+
+载体 = Narrative State（[架构-02 §3](架构-02-核心数据结构与双轨模型.md)，作品/章节/实体三维叙事运行态）+ 演变历程字段。实验台已在六个世界域型上实证 {章, 台阶, 周期} 的结构化里程碑。演变历程分三期消费。
+
+| 消费期 | 用谁 | 怎么用 |
+|---|---|---|
+| 规划期 | 本作历程 + 参照曲线（拆书沉淀的跨书台阶间距/周期分布） | 排下一台阶的时机与幅度 |
+| 检测期 | 当前态对照 | 新候选不得与当前台阶矛盾 |
+| 写作期 | 只给当前态摘要 | 全历程默认不进（`aiContext` 用途不含 generation） |
+
+**参照作品面**：参考书的实体演变卡落参照作品面——系统侧证据资产，不进 Global KB、不可被作品绑定，定义、承载与版权治理见 [专题-06 §6.4](专题-06-元数据驱动的智能体架构.md)。本册只消费它的两个用途：①回放评测的标准答案底座（§4）；②蒸馏源——进入 Global KB 的只能是蒸馏后的叙事域「成长曲线范式」（`trope`/`pacing` 形态），供规划期作参照曲线。
+
+---
+
+## 6. 实验台实证附录
+
+一句话钥匙：**实验台是排练场；下表只陈述已被 9 批实拆检验的事实，及各事实结论的唯一 owner 分册。**
+
+| 实验台已实证 | 结论归属分册 |
+|---|---|
+| 23 型结构本体实战可用 | [专题-06](专题-06-元数据驱动的智能体架构.md) |
+| `aiContext` 按 4 用途（planning/generation/detection/extraction）字段级裁剪可落地 | [架构-02 §9](架构-02-核心数据结构与双轨模型.md)（值域已升级为布尔或用途集）/ [专题-06 §7](专题-06-元数据驱动的智能体架构.md) |
+| 演变历程结构化里程碑 {章,台阶,周期} | [专题-06 §4.5](专题-06-元数据驱动的智能体架构.md) / [后端-04](后端-04-统一数据库Schema-v1.md) 字段合同 |
+| 判重判据「同名异质不并」 | 本册 §3 |
+| 单实例长尾与跨书频次信号 | 本册 §2 / §3 |
+| 升格卡注入视图两端病（395 字符 / 104KB） | 本册 §2 |
+| 参考书实体演变卡可产、可逆、带真实章号锚点（参照作品面的可行性底座） | [专题-06 §6](专题-06-元数据驱动的智能体架构.md) / 本册 §5 |
+
+---
+
+## 7. 验收清单
+
+本册闭合后必须满足以下可判定条款：
+
+1. 任何新增知识型进入 Global KB 检索集前，必须同时给出 §2 的选择键（怎么被选中）与注入视图定义（注入什么形态），二者随该型字段合同登记，缺一不得入检索集。
+2. 进入生成上下文的必须是注入视图，不得是整条存储记录；各型注入视图的尺寸上限随字段合同登记，超限判不合格、不注入。
+3. 公共范式进入生成上下文的路径只有「规划期决策、写作期引用」——规划产出必须携带所引范式的引用链，写作任务记录必须能回指该引用；写作期对范式做临场相似度海选的链路判违规。
+4. 回放评测在某作品/品类跑通前，涉及该范围的知识策略变更不得对外声称「提升质量」；质量声明必须附回放运行标识（评估集版本 + 知识策略版本 + 三线得分）与变量控制说明。
+5. 判重遵循「同名异质不并、真同才并」；每次归并必须留存可判定的并类判据与被并卡快照（归并审计），缺审计的归并判违规（宁缺勿滥）。
+6. 演变历程默认不进写作期上下文（`aiContext` 用途不含 generation），违反即记为撑爆预算风险项。
+7. 参考书样本进入回放评测前必须同时通过授权状态闸（`reference_work` 四值，`unauthorized` 失败关闭）与评测用途闸（授权快照 `allowedPurpose` 含离线评测）；评测产物不得留存原书全文。
+8. 卡的每个结构部件（检索键 / 注入体 / 演变链 / 溯源）的消费者以字段级 `aiContext` 用途标注为准；无任何用途标注且不承担溯源/审计治理职能的部件按赘肉裁撤，不随卡进上下文。
+
+---
+
+## 8. 关联阅读
+
+| 主题 | 权威文档 |
+|---|---|
+| Context Assembly 四层与 Token 预算、检索结果合同、质量评测输入合同 | [专题-03-AI编排上下文与质量评测实现规范](专题-03-AI编排上下文与质量评测实现规范.md) |
+| 输出侧质量维度、离线评估框架 | [专题-04-生成质量门控与创作健康度设计方案](专题-04-生成质量门控与创作健康度设计方案.md) |
+| 统一读取器读合同、结构本体 23 型与三层浇铸、拆书两处浇铸、`reference_work` 授权四值 | [专题-06-元数据驱动的智能体架构](专题-06-元数据驱动的智能体架构.md) |
+| 双轨模型、Narrative State、三类知识库、MetaSchema `aiContext` 控制项 | [架构-02-核心数据结构与双轨模型](架构-02-核心数据结构与双轨模型.md) |
+| 知识来源优先级（本作事实高于公共参考）、核心价值承诺 | [产品-01-产品定位与核心价值](产品-01-产品定位与核心价值.md) |
+| 逐型字段合同 | [后端-04-统一数据库Schema-v1](后端-04-统一数据库Schema-v1.md) |

design-docs/专题-08-自动化测试方案.md

@@ -0,0 +1,156 @@
+# 专题-08：自动化测试方案
+
+- 目标读者：创作者 / 产品 / 架构 / 前端 / 后端 / 测试 / Agent 实现者
+- 阅读时间：25-40 分钟
+- 边界说明：本文件是贯穿四仓（muse-cloud / muse-admin / muse-studio / muse-design-docs）的**测试可判定性**横切 SoT，owns 三个概念——测试金字塔分层、确定性/语义分界判据、语义评测方法论。它**不重定义**任何状态机、Schema、API 或质量维度：那些的单一归属仍在各自分册（见各节引用），本册只规定"它们必须满足什么条件才算可测、以及用什么手段验证"。
+
+## 1. 定位与非目标
+
+### 1.1 定位
+
+Muse 的可测性呈两极：
+
+- **约 95% 的系统是确定性机器**——状态机、双轨写路径、事务、幂等、鉴权、协议外壳、不丢稿。其对错**不看正文含义、只比对结构与数值**即可判定，用经典自动化测试钉死，是自动化率 > 90% 的主体。
+- **决定"这段 AI 写得能不能用"的语义内核**——正文质量、一致性判定、知识效用——本质上必须靠多模态大模型评判，不能用"通过/失败"硬断言，只能用对照实验与盲评量表。
+
+本册给出：四层测试金字塔、一条确定性/语义分界判据、三套语义评测机制，以及每个功能"要可测必须提供什么"的可判定性合同。
+
+### 1.2 非目标
+
+- 不定义具体业务状态机、表结构、端点、错误码、质量维度——归属见各节引用的 owner 分册。
+- 不替代 `docs/mvp/` 的进度总账与覆盖 JSON；本册定义"测什么、怎么验"，覆盖 JSON 是"哪些已登记可机械核对"的执行台账。
+- 不记录调试经过、某次测试结果或开发状态。
+
+## 2. 测试金字塔（四层）
+
+越往下越贵、越往上越该多。每一层的用例都从现有 SoT 合同反推。
+
+| 层 | 验证对象 | 规模/成本 | 手段 | 合同 owner（本册只引用） |
+|---|---|---|---|---|
+| **L1 数据不变式 / 状态机** | 双轨写路径、状态迁移合法性、唯一约束、快照不可变 | 多而密、最廉价 | 后端单测 + 真 PG 集成测试 + ArchUnit | [架构-02](架构-02-核心数据结构与双轨模型.md)（双轨不变式）、[架构-04](架构-04-状态机与约束清单.md)（状态机）、[后端-04](后端-04-统一数据库Schema-v1.md)（约束） |
+| **L2 接口契约 / 事务 / 幂等** | 错误码、乐观锁、鉴权边界、事务回滚、SSE 框架、版本头 | 多、廉价 | 契约测试 + 集成测试 + 故障注入 | [后端-05](后端-05-统一API契约-v1.md)（API 契约）、[后端-03](后端-03-关键流程实现与接口契约.md)（事务/事件） |
+| **L3 前端交互 / 不丢稿** | 编辑器保存、影子层冲突、建议接受、动态表单、SSE 重连 | 中 | Playwright E2E + 前端单测 | [前端-02](前端-02-编辑器与影子层交互.md)、[前端-03](前端-03-元引擎与动态表单.md)、[专题-01](专题-01-正文建议接受(Accept%20Suggestion)实现规范.md) |
+| **L4 AI 语义质量** | 正文质量、一致性判定、知识效用 | 少而精、最贵 | LLM 评委 + 对照实验 + 回放评测 | [专题-04](专题-04-生成质量门控与创作健康度设计方案.md)（质量维度/量表）、[专题-07](专题-07-知识消费契约与质量闭环.md)（知识效用/回放） |
+
+**分层纪律**：L1–L3 必须占自动化用例的绝大多数；L4 数量少、慢、贵，但测的是产品命根子，绝不用 L1–L3 的"通过/失败"思路去做（见 §5）。
+
+## 3. 确定性 / 语义分界判据
+
+唯一判据：
+
+> **这件事的对错，能不能不看正文含义、只比对结构和数值就知道？能 → 确定性（机械断言）；不能 → 语义（大模型评判）。**
+
+### 3.1 分界总表
+
+| 测什么 | 类别 | 验证手段 |
+|---|---|---|
+| 状态迁移、枚举值域 | 确定性 | 状态图遍历 + 断言 |
+| 双轨写路径隔离（AI 不直写正文事实层） | 确定性 | 写路径审计测试 |
+| 事务原子 / 乐观锁 / 幂等 | 确定性 | 集成测试 + 故障注入 |
+| 鉴权 / admin·app 入口隔离 | 确定性 | 矩阵化权限测试 |
+| 协议外壳 / 哈希绑定 / fail-closed | 确定性 | 契约测试 |
+| 不丢稿 / 冲突不静默覆盖 | 确定性 | Playwright 杀进程重载 |
+| 一致性"两段设不设定冲突" | 混合 | 定位/绑定部分断言 + 判定部分 LLM 评委 |
+| 正文质量五维打分 | 混合 | 确定性流程 + 盲评大模型打分 |
+| 知识回放对照 | 混合 | 确定性框架 + 对照评分 |
+| 风格 / 节奏 / 可行动性 | 纯语义 | LLM 评委 / 对照实验，不下硬结论 |
+
+### 3.2 混合体的处理纪律
+
+混合体（外壳确定 + 打分语义）是最易做错的一类：**外壳必须单测，内核必须大模型**，二者不可互相替代。
+
+- **一致性检测**（owner [专题-03](专题-03-AI编排上下文与质量评测实现规范.md)）：引用能否唯一定位、哈希是否绑定、`unknown` 是否带 gapReason——确定性断言；"claims/事实冲突 verdict"——LLM 判定。
+- **正文离线实验**（owner [专题-04 §10](专题-04-生成质量门控与创作健康度设计方案.md)）：双盲双评流程、"单维差 >0.5 加第三评""取稳定配对中位数""样本 <5 判证据不足"——确定性规则；五维打分——盲评大模型。
+- **知识回放**（owner [专题-07 §4](专题-07-知识消费契约与质量闭环.md)）：冻结第 N 章、按契约组装、对照第 N+1 章——确定性框架；"台阶命中/设定一致/错误检出"——对照评分。
+
+## 4. 确定性合同主干（高 ROI，优先铺）
+
+以下六类全部可从现有 SoT 直接生成用例，是回归主干，最先落地：
+
+1. **错误码枚举稳定**：业务错误码取自 [后端-05 §5](后端-05-统一API契约-v1.md) 枚举；特定失败不得压缩为泛化码（如来源阻断必须返 `SOURCE_BLOCKED` 而非 `STATE_CONFLICT`）。
+2. **乐观锁**：Block 写入必带 `expectedRevision`，冲突必拒且 revision 单调递增（owner [架构-04 §4.6](架构-04-状态机与约束清单.md)）。
+3. **Accept 事务原子**：候选接受 8 步（校验→写 revision→归因→归档→审计/outbox）任一步失败整体无副作用；outbox/投影异步失败不回滚已提交正文（owner [后端-03 §4](后端-03-关键流程实现与接口契约.md)）。
+4. **幂等**：同 `commandId` 重提返回首次结果、不重复写/确认/绑定/导出；同键不同语义必报 `IDEMPOTENCY_CONFLICT`（owner [后端-05 §2.5](后端-05-统一API契约-v1.md)）。
+5. **鉴权矩阵 / 入口隔离**：`/admin-api/**` 改不了用户正文，`/app-api/**` 碰不到系统配置；系统内部调用不得复用用户 token；越权 `FORBIDDEN`、无身份 `UNAUTHENTICATED`（owner [后端-02 §4.3](后端-02-工程结构与模块职责.md)，ArchUnit 包级隔离）。
+6. **双轨写路径审计**：AI 任务/候选/智能体绝不能直写正文事实层；来源传播只能限制/标记/作废，不得改写已确认正文（owner [架构-02 §1.1](架构-02-核心数据结构与双轨模型.md)、[架构-04 §11](架构-04-状态机与约束清单.md)）。
+
+补充确定性主干（同优先级）：状态机迁移图遍历（通用版本/任务/候选/来源）、唯一约束与快照不可变、SSE 框架合同与重连续传、`X-API-Version` 废弃期/410 行为、不丢稿不变式（崩溃后 `max(本地缓存, 服务端)` 可恢复、零丢失）。
+
+## 5. 语义评测方法论
+
+语义部分最大的坑是"测了个寂寞"（跑一次、看着行、就过）。三套机制，铁律先行：**n=1 不下结论；两臂必须对等、控住混淆变量。**
+
+### 5.1 LLM 评委（双盲双评）——给单条产出打分
+
+- 两个评委独立打分、互不知结果；分差超阈值（[专题-04 §10.1](专题-04-生成质量门控与创作健康度设计方案.md) 用 0.5）自动引入第三评。
+- 评委 fresh 进程隔离、匿名样本，不告知"AI 写还是人写"。
+
+### 5.2 对照实验（A/B 两臂对等）——回答"新策略是否真的更好"
+
+- 两臂对等：同一批章节、同一模型、同一预算，只改变被测变量。
+- 样本不足不下结论：[专题-04 §10.1](专题-04-生成质量门控与创作健康度设计方案.md) Gate A——样本 <5 或五场景不全 → `insufficient_evidence`（判"证据不足"，**不是**"通过"）。
+- **通过线必须是硬数字**。全仓范本 = [专题-04 §10.1](专题-04-生成质量门控与创作健康度设计方案.md) Gate B：试验臂相对对照臂，文风或张力**不退化**，且设定保真均值 **≥0.25**、且 **≥60%** 样本为正 → `passed`。这是"语义质量落成确定性判定"的唯一现成范本，所有新语义门补标准时照此范式。
+
+### 5.3 回放评测——回答"知识/上下文策略有没有用"
+
+拿参考书当标准答案：冻结到第 N 章，按消费契约组装上下文去生成第 N+1 章，对照真实第 N+1 章（owner [专题-07 §4](专题-07-知识消费契约与质量闭环.md)）。铁律：**没跑过回放，不许声称有改善。**
+
+## 6. 测试可判定性合同（倒逼 owner 分册）
+
+**每个功能要进入自动化验收，必须向测试提供下列之一；提供不出来的，视为需求未闭合，不得声称"已完成"。**
+
+| 功能类型 | 必须提供 | 提供不出来的后果 |
+|---|---|---|
+| 状态机 / 流程 | 完整合法+非法迁移图、终态 | 无法写迁移断言 |
+| 端点 / 命令 | 稳定错误码、前置条件、幂等键来源 | 无法写契约/并发测试 |
+| 数值门槛（TTL/置信度/配额） | **具体数值**，或明确的"基线产生时点+校准责任人" | 过期/拒绝/超限路径不可断言 |
+| 语义质量门 | 量表 + 通过线 + 评委规则（照 §5.2 Gate B 范式），或书面承认"只展示不阻断" | 既想阻断又无判据 = 黑洞，测试拒绝背书 |
+| 失败路径 | 四问：为什么 / 哪些事实没变 / 下一步 / 返回哪里 | 失败恢复不可验收 |
+
+本条是测试对需求的硬约束：凡声称"质量达标""风险可控""自动入库"而无上表对应判据者，测试侧记为**不可判定**，回退 owner 分册补标准。当前已知的不可判定点，集中登记在 `docs/plans/2026-07-30-测试倒逼需求缺口跟踪.md`，拍死后蒸馏回各分册即删。
+
+## 7. 已拍决策的测试合同
+
+以下三项已由人类拍死（2026-07-30），本册登记其**测试合同**；对应 owner 分册的措辞修订见缺口跟踪文档的蒸馏清单。
+
+### 7.1 收紧自动确认（G1）
+
+**决策**：知识草稿仅在四条件**全满足**时自动入库——① 自有正文产生 ② 无外部来源 lineage ③ 无冲突 ④ 置信度达标；任一不满足 → 进待确认队列，用户确认才入正文事实层。
+
+**测试合同（确定性）**：
+- 四条件逐一置假，断言草稿进入待确认队列、**不**写正文事实层；
+- 四条件全真且置信度达标，断言 `confirm_mode=auto` 且可撤回；
+- 带外部 lineage 的草稿即便改写，断言**不**洗白来源、**不**走自动确认。
+
+**已蒸馏**：`产品-02 §6.4` 入口清单已纳入"知识草稿达标自动确认（四条件）"，`§9.1` "唯一入口"措辞已对齐，与 `流程-02B §7` 矛盾消除。
+
+### 7.2 叙事质量门补硬标准并阻断（G4）
+
+**决策**：运行时叙事三维（设定一致 / 角色声音 / 场景结构）照 §5.2 Gate B 范式补硬标准——每维一个量表 + 双盲评委 + 通过线，不达标阻断或触发有限重写（重写上限默认 ≤2，owner [专题-04 §5](专题-04-生成质量门控与创作健康度设计方案.md)）。
+
+**测试合同（混合）**：
+- 确定性外壳：量表步长、双盲流程、"分差 >0.5 加第三评"、重写上限、`qualityState` 转移——机械断言；
+- 语义内核：三维打分由盲评大模型给；
+- 阻断断言：构造低于通过线的样本，断言候选**不**进 `shadow_ready`、**不**可接受。
+
+**已蒸馏**：`专题-04 §4.2.1` 已补运行时叙事门量表（0-10/0.5 步长）、三维通过线（设定 ≥7.0、角色/场景 ≥6.0）与四步裁决顺序，盲评机制引用 §10.1。
+
+### 7.3 阈值分类处理
+
+**决策**：
+
+- **安全类阈值现在拍死**——凭证有效期（handoff token / 下载凭证）、风险与冲突分级。一旦数值确定，其过期/拒绝/禁静默确认路径即为确定性断言。
+- **语义类阈值留回放首轮基线**——知识质量三性门槛、回放通过线、自动确认置信度。必须同时写明"基线产生时点 + 校准责任人"，否则视同悬置。
+
+**测试合同**：
+- 安全类：数值落 SoT 后，过期/重复使用/actor 不匹配/越级确认 → 断言拒绝 + 写审计；
+- 语义类：基线未定时，测试只断言"指标可计算、留痕、门禁要求附运行标识"，**不**断言 pass/fail；基线定后补硬断言。
+
+**待蒸馏**：具体安全数值（建议默认：handoff token 15 分钟、下载凭证 5 分钟、安全操作冷却 24 小时——**待人类确认**）落 `架构-04 §12` 与 `后端-05 §4.8/§4.9`；语义类"校准时点+责任人"落 `专题-07 §3/§4`。
+
+## 8. 验收与 CI 门禁
+
+- **覆盖登记**：每条确定性合同登记进覆盖 JSON（接口门机械源），可机械核对；未登记者不计入自动化率。
+- **防假绿**：遵循 [`.agents/rules/verification-and-anti-false-green.md`](../.agents/rules/verification-and-anti-false-green.md)——测试必须真驱动被测流程并观察行为，禁止只跑 typecheck/空断言冒充通过。
+- **阻断规则**：CI 中 L1–L3 测试失败阻断合入；L4 语义评测以"证据不足/退化"为失败信号，不以单次分数为失败信号。
+- **语义门上线门禁**：任何语义质量门，要么持有 §5.2 范式的硬通过线，要么书面标注"只展示不阻断"；二者皆无 → 测试侧拒绝背书，需求视为未闭合。

design-docs/产品-01-产品定位与核心价值.md

@@ -416,6 +416,6 @@ AI 生成的候选在交付用户之前，经过质量评分。关键维度（
 - 管理员系统处理流程：`流程-02A-管理员系统处理流程(系统视角).md`
 - 普通用户系统处理流程：`流程-02B-普通用户系统处理流程(系统视角).md`
 - 核心概念与双轨模型：`架构-02-核心数据结构与双轨模型.md`
-- 质量门控与创作健康度：`专题-04-生成质量门控与创作健康度设计方案`
+- 质量门控与创作健康度：`专题-04-生成质量门控与创作健康度设计方案.md`
 - AI 编排、上下文与质量评测：`专题-03-AI编排上下文与质量评测实现规范.md`
 - 系统全貌与边界上下文：`架构-01-系统全貌与边界上下文.md`

design-docs/产品-02-核心功能与交互边界.md

@@ -386,8 +386,9 @@ Muse 的 AI 能力通常不是单个智能体按钮，而是系统功能编排
 - 用户手动创建或修正作品知识。
 - 导入解析或全书解析结果先经过章节级确认；其产生的知识草稿仍必须再经过知识确认。
 - 规划候选经过用户确认，并按规则沉淀为作品知识或叙事状态。
+- 知识草稿达标自动确认：仅当下列四个条件**全部满足**时，系统才可自动把草稿写入局域知识库——① 草稿由用户自有正文产生；② 不含任何外部来源 lineage（市场资产、授权知识、参考作品等）；③ 与既有知识无冲突；④ 置信度达到质量策略登记的阈值。任一条件不满足，草稿一律进入待确认队列，由用户确认后才入库。自动确认结果对用户可见、可撤回。
 
-正文保存只表示用户文本落盘，进入正式正文和版本历史；它不自动表示相关内容可以沉淀为作品知识、设定、关系或事件事实。
+正文保存只表示用户文本落盘，进入正式正文和版本历史；它不自动表示相关内容可以沉淀为作品知识、设定、关系或事件事实。带外部来源 lineage 的草稿即使用户改写，也不得借此洗白来源、改走自动确认。
 
 知识草稿确认前必须校验来源快照。来源正文、规划项、候选文本或授权资产版本已变化时，草稿必须标记为已过期，不能确认入库。用户可以重新提取、手动修改后保存或忽略。
 
@@ -508,7 +509,7 @@ Muse 的 AI 能力通常不是单个智能体按钮，而是系统功能编排
 - 管理员配置 MetaSchema、系统级智能体、全局知识、权限、质量门控和市场治理规则。
 - 普通用户写作、规划、选择智能体、绑定知识来源、确认候选和知识。
 - AI 产出的候选文本、知识草稿、规划候选、风险标记都先进入 Shadow。
-- 进入 Canonical 的唯一入口是用户确认，或用户自己的正文保存动作；正文保存不等于知识入库。
+- 进入 Canonical 的入口是用户确认、用户自己的正文保存动作，以及 §6.4 定义的"知识草稿达标自动确认"（仅限自有正文、无外部来源、无冲突、置信度达标四条件全满足的窄口径）；除此之外 AI、外部知识和市场资产不得直接写正式事实。正文保存不等于知识入库。
 - Archive 记录已接受、已丢弃、已过期、失败、撤权和历史版本，不能和待确认内容混显示。
 
 ### 9.2 普通用户决策模型
@@ -738,4 +739,4 @@ AI 候选必须分层呈现，避免把写作决策变成审计决策。
 - 普通用户系统处理流程：`流程-02B-普通用户系统处理流程(系统视角).md`
 - Accept 收束专题：`专题-01-正文建议接受(Accept Suggestion)实现规范.md`
 - AI 编排、上下文与质量评测：`专题-03-AI编排上下文与质量评测实现规范.md`
-- 质量门控与创作健康度：`专题-04-生成质量门控与创作健康度设计方案`
+- 质量门控与创作健康度：`专题-04-生成质量门控与创作健康度设计方案.md`

design-docs/内容映射表.md

@@ -1,7 +1,7 @@
 # 内容映射表（New-Design(新设计) V2）
 
-- 版本：v7
-- 更新日期：2026-06-20
+- 版本：v8
+- 更新日期：2026-07-17
 - 目标读者：文档维护者/架构/前端/后端/产品
 - 阅读时间：10–15 分钟
 - 边界说明：本文件只做“内容归属与迁移策略”定义，不承载业务/架构细节；细节必须落到对应 V2 文档里，避免重复。
@@ -43,6 +43,11 @@
   - `专题-01-正文建议接受(Accept Suggestion)实现规范.md`
   - `专题-02-Sudowrite对标与Muse产品取舍.md`
   - `专题-03-AI编排上下文与质量评测实现规范.md`
+  - `专题-04-生成质量门控与创作健康度设计方案.md`
+  - `专题-05-AI统一交互协议与外部AgentAdapter设计.md`
+  - `专题-06-元数据驱动的智能体架构.md`
+  - `专题-07-知识消费契约与质量闭环.md`
+  - `专题-08-自动化测试方案.md`
 - dev 路线图（⚠️ `doc/dev/*` 规划未落地、从未创建；职责已由实际文档承担）：
   - 真实现状与目标差距 → [`docs/项目功能与进度总览.md`](../docs/项目功能与进度总览.md)
   - 总体路线图 / 阶段 → [`docs/mvp/进度总账.md`](../docs/mvp/进度总账.md)
@@ -190,7 +195,19 @@
   - target type 结构本体：23 型清单 + domain 逐值语义 + 拆分判据（术语权威仍在 `架构-02` §9）
   - 统一创作数据读取器：AI 上下文的服务端读合同（三级裁剪、fail-closed omittedSources）
   - base 内置种子清单：23 项四档全局 schema 的叠加与继承机制
-  - 拆书通用抽取与参考作品：`reference_work` 档案 + 范式 lineage（Global/Local KB 两处浇铸）
+  - 拆书通用抽取与参考作品：`reference_work` 档案 + 范式 lineage（Global/Local KB 两处浇铸；参照作品面 = 系统侧证据资产，非第四类知识库，见其 §6.4）
+- 知识效用闭环（横切）：主文档 `专题-07-知识消费契约与质量闭环.md`，owns 四个概念——
+  - 知识消费选择契约：按用途（generation/planning/detection/extraction）的默认合同、注入视图两档、排序信号（截断规则归 `专题-03` §4.2）
+  - 知识质量三性：可命中 / 可行动 / 可持续（输入侧检尺，与 `专题-04` 输出侧维度分立、单向咬合）
+  - 回放评测：参考书=标准答案的知识策略离线评估（机制归 `专题-04` §10 框架，定义在本册）
+  - 长线进度消费语义：演变历程 {章,台阶,周期} 的规划/检测/写作三期消费
+  - 边界备注：参照作品面的浇铸位归 `专题-06` §6.4；输出侧质量维度仍归 `专题-04`；术语权威仍在 `架构-02`
+- 测试可判定性（横切）：主文档 `专题-08-自动化测试方案.md`，owns 四个概念——
+  - 测试金字塔分层：L1 数据不变式/状态机、L2 接口契约/事务/幂等、L3 前端交互/不丢稿、L4 AI 语义质量
+  - 确定性/语义分界判据：「能否不看正文含义、只比对结构与数值判定对错」+ 混合体处理纪律
+  - 语义评测方法论：双盲评委、对照实验两臂对等（Gate B 范式）、回放评测；n=1 不下结论
+  - 测试可判定性合同：每个功能要可测必须提供的判据；未提供视为需求未闭合
+  - 边界备注：不重定义状态机/Schema/API/质量维度，只引用各 owner；具体质量维度仍归 `专题-04`，知识效用仍归 `专题-07`
 - 状态机与约束：主文档 `架构-04-状态机与约束清单.md`
 - 后端模块职责：主文档 `后端-02-工程结构与模块职责.md`
 - 统一数据库表结构：主文档 `后端-04-统一数据库Schema-v1.md`

design-docs/前端-02-编辑器与影子层交互.md

@@ -393,4 +393,4 @@ Block 粒度为场景/小节级。一个 Block 对应正文中一个相对独立
 - 普通用户操作流程：`流程-01B-普通用户操作流程(操作视角).md`
 - 普通用户系统流程：`流程-02B-普通用户系统处理流程(系统视角).md`
 - Accept 专题：`专题-01-正文建议接受(Accept Suggestion)实现规范.md`
-- 质量门控专题：`专题-04-生成质量门控与创作健康度设计方案`
+- 质量门控专题：`专题-04-生成质量门控与创作健康度设计方案.md`

design-docs/前端-03-元引擎与动态表单.md

@@ -1,7 +1,7 @@
 # 前端-03：元引擎与动态表单
 
-- 版本：v6
-- 更新日期：2026-05-24
+- 版本：v7
+- 更新日期：2026-07-17
 - 目标读者：前端 / 架构 / 产品 / 后端
 - 阅读时间：25-45 分钟
 - 边界说明：本文件定义 MetaSchema 在两个前端中的使用方式：Vben 管理后台配置元结构，`muse-studio` 用户端消费可见投影并渲染创作表单。元结构定义看 `架构-02`，Schema 看 `后端-04`，API 看 `后端-05`。
@@ -71,7 +71,7 @@
 | 控制项 | 管理后台含义 | 用户端含义 |
 |---|---|---|
 | `uiVisible` | 是否允许展示给普通用户 | false 时用户端默认不展示；也不生成可见空壳 |
-| `aiContext` | 是否允许进入 AI 上下文 | 不等于用户可见，也不等于可导出；前端只展示后端返回的上下文摘要 |
+| `aiContext` | 是否允许进入 AI 上下文（布尔或用途集，值域权威见 `架构-02` §9） | 不等于用户可见，也不等于可导出；前端只展示后端返回的上下文摘要 |
 | `userEditable` | 普通用户是否可编辑 | false 时只能只读展示或隐藏；不能在前端强开编辑 |
 | `userSearchable` | 是否允许普通用户检索 | false 时不进入用户搜索入口、筛选项或联想结果 |
 | `exportable` | 是否允许随作品导出 | false 时导出预检必须排除，并显示不可导出原因 |

design-docs/后端-03-关键流程实现与接口契约.md

@@ -358,4 +358,4 @@ Account/Member 只提供用户可见权益和汇总，不替代业务 owner。
 - 状态机：`架构-04-状态机与约束清单.md`
 - Accept 专题：`专题-01-正文建议接受(Accept Suggestion)实现规范.md`
 - AI 编排专题：`专题-03-AI编排上下文与质量评测实现规范.md`
-- 质量门控专题：`专题-04-生成质量门控与创作健康度设计方案`
+- 质量门控专题：`专题-04-生成质量门控与创作健康度设计方案.md`

design-docs/后端-05-统一API契约-v1.md

@@ -1,7 +1,7 @@
 # 后端-05：统一 API(接口) 契约-v1
 
-- 版本：v10
-- 更新日期：2026-06-19
+- 版本：v11
+- 更新日期：2026-07-17
 - 目标读者：前端 / 后端 / 架构 / 测试
 - 阅读时间：35-55 分钟
 - 边界说明：本文件只定义 Muse 在 Yudao Cloud fork 上的 API 分组、资源语义、关键命令、错误模型与异步交互。底层表结构看 `后端-04`，状态机看 `架构-04`，关键流程看 `后端-03`。
@@ -180,7 +180,7 @@ MetaSchema 管理命令必须带 `commandId`、操作者、权限点、变更理
 | 字段 | 语义 |
 |---|---|
 | `uiVisible` | 是否进入用户可见投影 |
-| `aiContext` | 是否允许进入 AI 上下文组装 |
+| `aiContext` | 是否允许进入 AI 上下文组装（布尔或用途集，值域权威见 `架构-02` §9） |
 | `userEditable` | 用户端是否允许保存该动态字段 |
 | `userSearchable` | 是否允许用户搜索或筛选 |
 | `exportable` | 是否可被导出预检纳入 |

design-docs/架构-02-核心数据结构与双轨模型.md

@@ -1,11 +1,11 @@
 # 架构-02：核心数据结构与双轨模型
 
-- 版本：v10
-- 更新日期：2026-07-09
+- 版本：v11
+- 更新日期：2026-07-17
 - 目标读者：架构 / 后端 / 前端 / 产品 / 测试
 - 阅读时间：35-50 分钟
 - 边界说明：本文件定义核心模型、模型归属、双轨边界和跨模型不变式；不定义数据库字段、索引、接口路径或完整状态机。BC 边界见 `架构-01-系统全貌与边界上下文.md`，生命周期见 `架构-04-状态机与约束清单.md`，精确表结构和 API 由后端阶段承接。
-- 变更记录：v10（2026-07-09）§1.2 Canonical 入口封闭枚举增补「管理员确认系统级知识草稿 → Global KB 范式」；§2 订正功能链归属（定义归元引擎 Meta BC、运行编排归 AI runtime、Governance 为逻辑治理面）；§9 补 domain 逐值语义、base 与叠加（override 只增不改）与 target_type 命名规则，本体全清单 owner 指向专题-06。
+- 变更记录：v11（2026-07-17）§9 `aiContext` 值域升级为布尔或用途集（`true` 全用途可入 / `false` 一律不入 / 用途子集仅列出用途可入；用途枚举 generation/planning/detection/extraction），布尔为其退化情形，既有 `aiContext=true/false` 表述语义不变；依据拆书实验台字段级用途裁剪实证，消费语义见 [专题-07-知识消费契约与质量闭环](专题-07-知识消费契约与质量闭环.md)。v10（2026-07-09）§1.2 Canonical 入口封闭枚举增补「管理员确认系统级知识草稿 → Global KB 范式」；§2 订正功能链归属（定义归元引擎 Meta BC、运行编排归 AI runtime、Governance 为逻辑治理面）；§9 补 domain 逐值语义、base 与叠加（override 只增不改）与 target_type 命名规则，本体全清单 owner 指向专题-06。
 
 ## 1. 双轨模型
 
@@ -248,7 +248,7 @@ MetaSchema 不负责：
 | 控制项 | 含义 |
 |---|---|
 | uiVisible | 是否在用户界面展示 |
-| aiContext | 是否允许进入 AI 上下文 |
+| aiContext | 是否允许进入 AI 上下文；值域为布尔或用途集——`true`（任何用途可入）/ `false`（一律不入）/ 用途子集（仅列出的用途可入；用途枚举 generation/planning/detection/extraction），布尔是用途集的退化情形 |
 | userEditable | 用户是否可编辑 |
 | userSearchable | 用户是否可检索 |
 | exportable | 是否允许随范围导出 |

design-docs/架构-04-状态机与约束清单.md

@@ -1,10 +1,11 @@
 # 架构-04：状态机与约束清单
 
-- 版本：v6
-- 更新日期：2026-05-24
+- 版本：v7
+- 更新日期：2026-07-20
 - 目标读者：架构 / 后端 / 前端 / 测试 / 产品
 - 阅读时间：45-60 分钟
 - 边界说明：本文件是 Muse 生命周期、状态流转和不可绕过约束的架构层单一来源；状态值是概念层合同，具体字段名、表结构和接口路径由后端阶段承接。系统边界见 `架构-01-系统全貌与边界上下文.md`，核心模型见 `架构-02-核心数据结构与双轨模型.md`。
+- 变更记录：v7（2026-07-20）§5.2.1 登记正文实验候选与生产候选隔离、编辑版本重检、detector 绿证据、`accept_preflight` 和 CAS 状态约束；实验阶段不改 API/DB。v6（2026-05-24）收束 Muse 生命周期、来源传播和不可绕过约束。
 
 ## 1. 状态机总原则
 
@@ -248,6 +249,20 @@ running -> failed / canceled
 - 修改后合并必须让旧知识草稿失效，并基于最终正文重新提取。
 - 候选来源撤权、下架、召回、owner 缺失、文本 revision 冲突或合规阻断时，接受和合并禁用。
 
+### 5.2.1 正文候选的实验隔离与接受子状态
+
+正文实验候选和生产候选共享检测规则，但不共享接受资格。
+
+| 对象 | 允许流转 | 不可绕过约束 |
+|---|---|---|
+| 诊断/评测正文候选 | `draft -> checking -> passed / rejected / failed / invalid_unstable` | `acceptanceEligible=false` 为不变量；passed 只表示本次检测或评测完成，候选永远不能进入 `accept_preflight` 或 Canonical |
+| 生产正文候选版本 | `draft -> checking -> shadow_ready -> accept_preflight -> accepted_as_is / merged_after_edit / revision_conflict / authorization_stale / source_stale / quality_stale` | 只有 detector 绿且报告绑定当前 candidateVersion、candidateSha256、contextSnapshotSha256 和 qualityPolicyVersion，才能进入 shadow_ready |
+| 用户编辑版本 | `shadow_ready -> edited_candidate -> checking` | 编辑必须创建严格递增的新 candidateVersion；旧版本和旧 detector 报告立即失去接受资格，不允许“改完直接合并” |
+
+`accept_preflight` 只允许 `mode=production`、`acceptanceEligible=true` 的当前版本进入，并实时校验候选未过期、detector 绿证据、上下文快照、授权、来源状态、策略版本和 `expectedRevision`。写入 Canonical 必须采用 compare-and-set（CAS）：服务端记录同时匹配 `runId + attempt + candidateVersion + candidateSha256 + currentState + expectedRevision` 才能原子递增 Block revision，并按用户决策迁入 `accepted_as_is` 或 `merged_after_edit` 后归档。旧 attempt、旧 candidateVersion、迟到结果和重复事件只能返回冲突或幂等旧结果，不能覆盖当前候选或正文。
+
+实验台只验证上述状态合同，不写正式正文库，不修改产品 API、Flyway 或业务数据库结构。产品化必须在正文 Gate B 通过后另立计划；Gate B 通过前不得启动细纲智能体真实能力验收。接受命令的具体前置与事务边界只引用 [专题-01 §6](专题-01-正文建议接受(Accept%20Suggestion)实现规范.md)，本文件不重复定义。
+
 ### 5.3 规划候选生命周期
 
 | 状态 | 含义 | 允许离开方式 |

docs/plans/2026-07-30-测试倒逼需求缺口跟踪.md

@@ -0,0 +1,44 @@
+# 测试倒逼需求缺口跟踪（2026-07-30）
+
+- 性质：短期任务文档。由"设计自动化测试方案"任务产生，用于跟踪测试倒逼出的需求缺口与蒸馏动作。**拍死并蒸馏回各 owner 分册后删除本文件**，结论性合同归 `design-docs/专题-08-自动化测试方案.md`。
+- 来源：通读 design-docs 全册提取可测合同时发现的不可判定/自相矛盾点。
+- 测试方案 SoT：[`design-docs/专题-08-自动化测试方案.md`](../../design-docs/专题-08-自动化测试方案.md)（§6 可判定性合同、§7 已拍决策）。
+
+## 一、已拍决策（2026-07-30，人类确认）
+
+| 决策 | 结论 | 测试合同归属 |
+|---|---|---|
+| G1 自动确认入口矛盾 | **收紧自动确认**：仅"自有正文+无外部来源+无冲突+置信度达标"四条件全满足才自动入库，其余进待确认队列；"唯一入口"措辞纳入"达标自动确认" | 专题-08 §7.1 |
+| G4 运行时叙事质量门 | **补硬标准并阻断**：照 Gate B 范式给叙事三维定量表+双盲评委+通过线，不达标阻断/重写 | 专题-08 §7.2 |
+| 阈值批处理 | **分类处理**：安全类（凭证 TTL/风险分级）现在拍死；语义类（知识质量/回放通过线/自动确认置信度）留回放首轮基线，须写明校准时点+责任人 | 专题-08 §7.3 |
+
+## 二、缺口清单与蒸馏动作
+
+状态：`已拍待蒸馏` = 决策已定、需改 owner 分册措辞；`待人类拍` = 仍需人类定具体数值/标准。
+
+### 第一档：自相矛盾 / 状态机悬置
+
+| # | 缺口 | 现状矛盾 | owner | 蒸馏动作 | 状态 |
+|---|---|---|---|---|---|
+| G1 | 自动确认 vs 唯一入口 | `产品-02 §6.4/§9.1` 言唯一入口=用户确认/保存（清单不含自动确认）；`流程-02B §7` 允许达标自动入库 | `产品-02` | 改 `产品-02 §6.4/§9.1`：入口清单纳入"达标自动确认（四条件）"，与 `流程-02B §7` 对齐 | **已蒸馏** |
+| G2 | 计费状态机悬置 | `产品-02 §10.8` 要求 待结算/已结算/已返还/已补偿 四态；`流程-02A §10` 称"由后续 owner 承接"，当前无状态可测 | `后端-04`/`后端-05` | 补计费 ledger 状态机与端点；未补前测试仅能断言 quota-adjustment 幂等+审计 | 待人类拍（是否本阶段做） |
+| G3 | 改写"洗白"外部来源判据缺失 | "独立来源证明/原创确认"反复作前置条件，从无成立判据 | `架构-04 §6`/`产品-02 §6.4` | 定义"原创确认成立"的可验证条件；未定前测试断言"外部 lineage 不可被改写移除" | 待人类拍 |
+
+### 第二档：阈值 / 标准缺失
+
+| # | 缺口 | 现状 | owner | 蒸馏动作 | 状态 |
+|---|---|---|---|---|---|
+| G4 | 运行时叙事门无判定标准 | `专题-04 §4.2` 仅模糊词，无分值/阈值 | `专题-04 §4.2` | 照 §10.1 Gate B 体例补三维量表+双盲+通过线 | **已蒸馏** |
+| G5 | 知识质量三性有指标无阈值 | 8 指标已命名，数值"留回放首轮基线" | `专题-07 §3` | 补"基线产生时点+校准责任人"；基线定后补数值 | 已拍（留基线，待补时点/责任人） |
+| G6 | 回放评测无通过线 | 三线只有"得分"，无"多少分算可上线" | `专题-07 §4` | 补切断分（照 Gate B 范式）+ 校准时点 | 已拍（留基线，待补时点/责任人） |
+| G7 | 自动确认置信度无定义 | 仅"超阈值"，数值/设定者/可调性全无 | `产品-02 §6.4`/`专题-04` | 定置信度数值或留基线+责任人（随 G1 蒸馏一并处理） | 已拍（留基线） |
+| G8 | 凭证/冷却 TTL 无数值 | handoff token、下载凭证"短期有效"、安全冷却期均无时长 | `架构-04 §12`/`后端-05 §4.8/§4.9` | 拍死数值（**建议默认待确认**：handoff 15min / 下载凭证 5min / 安全冷却 24h） | 已拍（安全类现在定，具体数值待人类确认） |
+| G9 | 风险/冲突分级无标准 | "高风险禁静默一键确认"，但等级/分级未定义 | `产品-02 §10.4`/`专题-04` | 定风险等级枚举与"可确认章节"判据 | 已拍（安全类现在定，具体分级待人类给） |
+| G10 | 灰度发布无通过准则 | 系统智能体"高风险进灰度"，成功/回退判定缺失 | `流程-02A §5`/`专题-04` | 定灰度通过/回退判据（可用对照实验范式） | 待人类拍 |
+
+## 三、下一步
+
+1. 人类确认 G8 三个 TTL 默认值、G9 风险分级枚举、G2/G3/G10 是否本阶段做。
+2. Agent 按上表"蒸馏动作"改 owner 分册（G1→产品-02、G4→专题-04、G8→架构-04/后端-05）。
+3. 每条蒸馏完成后在 `专题-08 §7` 对应"待蒸馏"标记去除，覆盖 JSON 登记对应确定性合同。
+4. 全部蒸馏完成 → 删除本文件。