4adc85cafd
- 八个领域 SoT + 索引：正式内容权威从 Git 文件改为 PostgreSQL；Git 退回代码/文档/DDL 权威，可对作品信息与文本留痕但非权威。 - 立横切合同：一切输入产出必须落库可见；raw 进库可看全文（访问控制）。 - 08 更名为数据权威与可视化领域；新增独立 可视化模块合同（只读查库渲染，绝不写）。 - AGENTS.md / README.md 同步翻面。
8.5 KiB
质量与复利领域 SoT
数据权威已改订为 PostgreSQL：正式内容（Canonical）都在库里，待审候选（Shadow）也在库里，raw 进库可看全文，只读看板只查库渲染绝不写。本文档不再描述任何“作品内文件目录”作为质量证据的家。落库的横切合同见索引 §3，本文只引用、不重复定义。
1. 唯一职责
质量与复利领域拥有候选检查、语义审核、评分策略、失败终态合同和经验升格规则。它回答“候选有什么问题、是否可以交给用户裁决、某种写法是否稳定有效、哪些经验值得进入范式、Agent、Skill 或工具”。
本领域产出检查、审核、实验和升格结论，并把结论落库；它不拥有正文、实体事实、范式正文、模型运行底座，也不拥有用户的接受动作。一切检查输入与质量产出都必须落库可见，没落库的等于系统视角里不存在。
2. 四层质量链
机械正确性
-> 语义正确性
-> 创作质量
-> 长期效果与复利
- 机械检查：schema、字数合同、hash、引用、状态机、预算账本、确定性规则。
- 语义检测：实体、关系、细纲硬约束、知情范围、时间线和来源支持。
- 创作评审：通用底层指标 + 场景类型评分；指出具体可修问题。
- 长期验证：跨章、跨场景或跨作品复核，结合用户决策和合法外部反馈判断方法是否有效。
机械失败不可被 Agent 主观覆判：机械层不过就是不过，语义和创作评审再高也不能把它盖过去。语义和创作评审也不能替代机械检查。
3. 评分结构
评分采用两层结构：
- 通用底层指标（四个通用维度）：设定与实体保真、规划忠实、文风一致、可读性。这些跨章节可比较。
- 场景类型策略（五类场景）：战斗、人物对话、转折、信息揭示、老角色回归，各有自己的重点、权重和锚点。
每章不能自创完全不同的量表，否则失去跨章比较；也不能用一套固定权重覆盖所有场景。量表、场景策略和阈值必须版本化——改了评分口径，要能读出“这次用的是哪一版量表”。
现有实现承认（各一句，不展开）：六类混淆项报告与新角色比例分层裁决由 eval 质量收敛环承载；卡三角色审核与金标准校准由 review-cards 承载。
4. 失败分类
安全报告至少区分五类（这是合同）：
execution_invalid：调用、schema、hash、raw、预算、运行状态或适配器失败，无法形成质量结论。quality_failed：执行有效，但候选存在明确质量问题或硬约束残留。insufficient_evidence：样本或场景不足，不能形成方向结论。no_gain：执行有效且质量合格，但新策略没有证明增益。passed：满足对应质量或实验合同。
实现现状标注（诚实保留，不强改）：当前以四类终态承载——
passed/failed/insufficient_evidence/no_gain，失败原因靠原因码表达。合同里的execution_invalid与quality_failed在实现中合并落failed，靠原因码区分；这两类从合同五类到实现四类的精确映射待对齐。
运行器失败可以使 Gate 失败关闭，但报告必须保留失败类别与原因码，不能让用户把基础设施故障误解为正文不合格。
5. 库内证据
审核、实验、运行证据一律落库，并绑定它所评价的正文或候选哈希：
- 审核记录（reviews）：候选与章节的质量摘要、问题、修复与复验结论，落库并绑候选哈希。
- 实验记录（experiments）：baseline、假设、干预、预期、到期与结论，落库并绑被验证的正文或候选哈希。
- 运行回执（runs）：安全执行回执、预算账本与 raw 指针，落库；完整 Prompt/Response、供应商原始响应等 raw 进单独表、可看全文（访问控制见索引 §8）。
- 用户决策与正式状态：接受、合并、丢弃及其依据，落库。
正文发生变化后，旧审核不能继续作为接受依据——哈希一变，挂在旧哈希上的审核自动失效。
实现现状标注（诚实保留）：当前审核证据散在
docs/的带日期报告里、不绑哈希，正文一变旧报告照常躺着、无法判定是否过期。审核/实验/运行证据落库并绑候选哈希，待建。
6. 经验升格
经验升格的规则由本领域独家拥有。范式领域和 Agent 与 Skill 领域只描述各自在这条链上的那一段，并链接回这里。
单次观察
-> 作品 review/experiment（落库证据）
-> 重复出现的 lesson/win
-> 范式 draft/evaluating
-> active 范式
-> 稳定 Skill / Tool / Agent 规则
这是本领域的设计目标合同；现状是这条链基本未实现——证据还散在文件、升格靠人手记，承接物（把 lesson/win 接进范式与 Skill 的结构与状态机）还没建起来。
与 02 的同名区分：本节“升格”指经验沿上面这条链从一次观察长成可复用的范式/Skill/Tool。02-实体领域 里的“作品面实体入库（也叫升格）”指拆书抽出的实体进入某部作品的正式事实库。两者只是都叫“升格”，对象、链路与 owner 都不同，引用时注意区分。
升格原则：
- 同类问题第 3 次复发，停止逐次修补，评估是否固化为检查项或 Skill。
- 单作品证据默认只能产生作品级范式。
- 跨作品规则变更必须做影响复核。
- 每项优化必须写明可证伪假设、观察窗口和替代解释。
- 可机械判断的经验优先固化为工具，不长期堆进 Prompt。
- 已被 Skill/Tool 完整拥有的执行步骤，范式和 lessons 只保留原理、证据与链接。
7. Gate A/B 边界
- Gate A 只验证离线评测链可运行，不能宣布正文层通过。
- Gate B 才对跨作品样本做正文能力和策略增益裁决。
- Gate A/B 是开发验收，不是正常用户写一章的线上质量流程。
- 离线 raw、标准答案和候选进库（单独表 + 访问控制），不要求留仓外。
现有实现承认（各一句，不展开）：预算账本合同与运行探针锁定由 db 与运行回执承载，Gate B 通过回执的哈希链由 confirm 承载。
实现现状标注（诚实保留）：当前只有一个作品且评测样本已预注册，Gate B 因此恒判
insufficient_evidence（跨作品样本不足）——这是目标态下的正确行为，不是 bug。
8. 可恢复性
可恢复性不在本领域定义，见 08-数据权威与可视化领域：质量证据与运行回执既然全部落库，可恢复性就跟随数据库备份、快照或可重建脚本，加上 Git 里的代码与 DDL 从零重建库结构。本领域不再单独主张“本地完备”。
9. 待建
- 经验升格链承接物：把 lesson/win 接进范式与 Skill/Tool 的结构、状态机与落库字段。
- 审核证据落库绑哈希：审核/实验/运行记录从
docs/日期报告迁入库表并绑正文或候选哈希。 - eval 收敛环脚本：把评分、失败分类与升格触发串成可机械复跑的闭环。
10. 验收条件
- 机械失败、运行失败和内容质量失败可以由原因码明确区分，脚本能从报告里读出类别。
- 修改后的候选一定重新检查并绑定新 hash；旧 hash 上的审核对当前正文不再有效。
- 每个 active 范式或稳定规则都有可追溯到库内记录（含哈希）的证据。
- 同一章用两套不同场景策略打分时，通用底层指标的分差能被脚本读出并比较；场景策略只改场景权重，不改四个通用维度的定义。
- 任一审核、实验或运行回执，都能用库内一条记录定位到它所评价的正文或候选哈希。
11. 关联 SoT
- 数据权威、落库合同、raw 边界与可恢复性：索引 §2/§3/§4/§8，细则见 08-数据权威与可视化领域
- 范式生命周期：03-范式领域
- 实体入库“升格”（与本文经验升格不同义）：02-实体领域
- Agent/Skill 升格：07-Agent与Skill领域
- 离线 Gate 上级合同：专题-04