927aafedaa
- 新增 docs/2026-08-01-评测harness改造设计.md：意图(三层目的,放弃证据独立性)、边界(物理vs逻辑隔离是种类差)、六条原则、三条独立评审收敛依据、实现项清单 - 领域索引§3：单一基底、分层权威、分区治理(评测独立性不由物料位置承载) - 05§7：访问分离非隔离+引擎单点强制+run_type钉死、oracle读侧红线、从预防迁到发现 - 06§7：COMPLETED轮次封存、代价明账、常设不变量 - 08§5：代价明账(外部可审计性换全文可走查)、访问分离非隔离
7.3 KiB
创作流程领域 SoT
1. 唯一职责
创作流程领域拥有单用户正向创作链的步骤、状态和失败收敛。它回答"用户的创作意图怎样变成待审候选（Shadow）、候选怎样经过检查、用户决策怎样把候选写为库内正式正文（Canonical）"。
本领域不拥有作品正文内容、实体字段、范式内容、Agent Prompt、评分量表或存储表结构（存储归 01-作品领域 和 08-数据权威与可视化领域）。
一切输入产出必须落库可见——横切合同见索引 §3。
2. 正向流程
用户意图
-> 从库内读取作品目标、已确认规划和当前正式正文
-> 组装并冻结角色上下文
-> Planner/Fine-outline 产生规划候选（按需）
-> 用户确认规划
-> Writer 产生正文待审候选（Shadow）
-> 确定性检查（机械门）
-> 语义检测（Semantic Detector）
-> 质量策略与有限修订（补证≤3 次 / 重写≤2 次）
-> 展示候选、风险、来源和质量摘要
-> 用户：原样接受 / 修改后合并 / 丢弃
-> accept preflight 与 revision 校验
-> 写库内正式正文（= 写库内正文块，不写任何本地文件）
-> 生成实体/范式观察草稿
-> 继续创作
写正式正文 = 写库内正文块。候选在用户接受之前已落库（候选表），只读看板随时可见。
用户也可以直接在库内编辑并保存正式正文，不要求先运行 Agent 或配置范式。
3. 状态合同
待审候选状态采用有限状态机（设计合同）：
DRAFT -> CHECKING -> PASSED -> ACCEPTED
| |
| -> ARCHIVED
-> REJECTED
DRAFT/CHECKING/PASSED -> DISCARDED（用户明确决策）
- 状态应持久化到库（候选表），使只读看板能渲染每个候选的当前命运。
- 状态迁移必须绑定
run_id+attempt+candidate_version+candidate_sha256。 - 迟到检测结果、旧版本候选和 revision 冲突不能覆盖新状态。
PASSED只表示候选可展示、可进入接受前置校验，不表示已成为正式正文。- 诊断和评测候选固定不可接受（四层机械强制：资格由 run 类型机械派生、合同硬校验拒绝、接受入口硬拒、产出钉死评测区）。
现状标注：当前实现只有内存四态（DRAFT / CHECKING / PASSED / REJECTED）；ACCEPTED、DISCARDED、ARCHIVED 三态与持久化到候选表为目标合同，待建。
4. 用户决策
只有三类改变候选命运的用户决策：
- 原样接受：当前候选正文写为库内正式正文。
- 修改后合并：用户修改产生新
candidate_version，必须重新检测和接受前置校验。 - 丢弃：正式正文不变，候选标记为丢弃并留在库内可查。
决策记录落库（存储结构归 01-作品领域）。
重新生成、查看来源、展开评分和取消运行是辅助操作，不等于接受、合并或丢弃。
5. ReAct 编排
主 Agent 负责观察库内当前状态、选择下一项 Skill、读取结果并决定是否继续。它不能绕过以下保护步骤：
- schema 与来源校验。
- 上下文冻结。
- 确定性检查（机械门）。
- 语义检测。
- 用户接受前置校验（accept preflight）。
- 正式正文 revision 比较与库内原子写（CAS 乐观锁，冲突则收敛到明确终态）。
正文、规划、提取、检测和评审分别由单一职责角色执行。主 Agent 不把多个角色合成一次模型调用。
已落地的编排合同（run_writer_pipeline）：机械门 → 语义检测 → 补证≤3 / 重写≤2、CAS 乐观锁 + 失败收敛终态、动态篇幅合同、评测候选四层强制。
6. 运行与落库
- 正式内容和候选都在 PostgreSQL 内；Git 只管代码与文档，不承载正式内容。
- 模型调用失败时保留库内已有正式内容不受损；重试产生新
attempt。 - 任一步失败必须进入明确终态，不留下无法判断是否可接受的处理中候选。
- 一切输入产出落库（见索引 §3）：用户意图、冻结上下文、候选正文、检测与评分、决策、运行回执、补证与重写记录。
待建（目标合同）：
- 写库写入层：当前管线只读不写，正式内容变更仍靠人工 commit；目标是管线直接原子写库。
- 状态机持久化与三态（ACCEPTED / DISCARDED / ARCHIVED）落候选表。
- 生产链上的质量评分环节：当前盲评只接离线评测，生产链尚无评分落库。
- 生成实体/范式草稿的触发接线：当前未接通。
7. 开发评测边界
Gate A/B、A/B/C 三臂、参考书标准答案和盲评只属于开发期离线验收，不进入普通创作链。离线评测可以复用 Writer、Detector、Judge 和上下文合同，但：
- 所有评测候选固定不可接受（四层机械强制，见 §3）。
- 评测产出不反写作品、实体或范式正式事实。
- 评测产出钉死评测区，只读看板可按区查看但不混入正式内容视图。
- 访问分离，不是隔离（harness 改造原则，见 docs/2026-08-01-评测harness改造设计）：评测与生产同库，靠逻辑隔离（
run_type+ 状态机 + 访问控制），不是物理隔离。强制须收拢到引擎单点：评测行对生产读默认不可见、run_type插入后不可变（使(eval, accepted)永不可达），不靠每条查询自觉过滤。 - oracle 读侧红线：oracle / 标准答案 / 全文不进任何模型输入上下文，只供人走查——可机械验证的硬红线，与冻结合同同级（写侧已有硬强制，读侧不能只靠查询纪律）。
- 从预防迁到发现：逻辑隔离不能全靠预防，配常设不变量持续抓越界——没有评测派生卡绑定到生产、没有评测质量结果出现在任何生产视图、没有正式正文块的来源能追溯到评测候选，违反即报警。
8. 验收条件
- 单用户可以完成新建作品、规划、生成、审核和接受正文，全流程在库内闭环。
- 每个待审候选在库内有明确状态、版本、来源和用户决策记录。
- 修改后合并一定产生新版本并重跑检测。
- 任何评测候选都不能成为库内正式正文（四层强制可机械验证：查询候选表
run_type为评测类型的行，status不得为 ACCEPTED）。 - 中途失败不损坏库内已有的作品、实体或范式正式事实。
- 只读看板能渲染每个候选的当前状态——看板看不到 = 没落库 = 不合规。
9. 关联 SoT
- 作品与决策存储：01-作品领域——正式正文、决策记录的表结构归它。
- 上下文输入：04-上下文领域——冻结上下文的选择与裁剪。
- 质量步骤：06-质量与复利领域——机械门、语义检测、评分的合同。
- 数据权威与落库：08-数据权威与可视化领域——库权威层级、落库机制、只读看板。
- 接受上级合同：专题-01——accept preflight 的产品级规范。