927aafedaa
- 新增 docs/2026-08-01-评测harness改造设计.md：意图(三层目的,放弃证据独立性)、边界(物理vs逻辑隔离是种类差)、六条原则、三条独立评审收敛依据、实现项清单 - 领域索引§3：单一基底、分层权威、分区治理(评测独立性不由物料位置承载) - 05§7：访问分离非隔离+引擎单点强制+run_type钉死、oracle读侧红线、从预防迁到发现 - 06§7：COMPLETED轮次封存、代价明账、常设不变量 - 08§5：代价明账(外部可审计性换全文可走查)、访问分离非隔离
122 lines
7.3 KiB
Markdown
122 lines
7.3 KiB
Markdown
# 创作流程领域 SoT
|
||
|
||
## 1. 唯一职责
|
||
|
||
创作流程领域拥有单用户正向创作链的步骤、状态和失败收敛。它回答"用户的创作意图怎样变成待审候选（Shadow）、候选怎样经过检查、用户决策怎样把候选写为库内正式正文（Canonical）"。
|
||
|
||
本领域不拥有作品正文内容、实体字段、范式内容、Agent Prompt、评分量表或存储表结构（存储归 [01-作品领域](01-作品领域.md) 和 [08-数据权威与可视化领域](08-数据权威与可视化领域.md)）。
|
||
|
||
一切输入产出必须落库可见——横切合同见索引 §3。
|
||
|
||
## 2. 正向流程
|
||
|
||
```text
|
||
用户意图
|
||
-> 从库内读取作品目标、已确认规划和当前正式正文
|
||
-> 组装并冻结角色上下文
|
||
-> Planner/Fine-outline 产生规划候选（按需）
|
||
-> 用户确认规划
|
||
-> Writer 产生正文待审候选（Shadow）
|
||
-> 确定性检查（机械门）
|
||
-> 语义检测（Semantic Detector）
|
||
-> 质量策略与有限修订（补证≤3 次 / 重写≤2 次）
|
||
-> 展示候选、风险、来源和质量摘要
|
||
-> 用户：原样接受 / 修改后合并 / 丢弃
|
||
-> accept preflight 与 revision 校验
|
||
-> 写库内正式正文（= 写库内正文块，不写任何本地文件）
|
||
-> 生成实体/范式观察草稿
|
||
-> 继续创作
|
||
```
|
||
|
||
写正式正文 = 写库内正文块。候选在用户接受之前已落库（候选表），只读看板随时可见。
|
||
|
||
用户也可以直接在库内编辑并保存正式正文，不要求先运行 Agent 或配置范式。
|
||
|
||
## 3. 状态合同
|
||
|
||
待审候选状态采用有限状态机（设计合同）：
|
||
|
||
```text
|
||
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-作品领域](01-作品领域.md)）。
|
||
|
||
重新生成、查看来源、展开评分和取消运行是辅助操作，不等于接受、合并或丢弃。
|
||
|
||
## 5. ReAct 编排
|
||
|
||
主 Agent 负责观察库内当前状态、选择下一项 Skill、读取结果并决定是否继续。它不能绕过以下保护步骤：
|
||
|
||
1. schema 与来源校验。
|
||
2. 上下文冻结。
|
||
3. 确定性检查（机械门）。
|
||
4. 语义检测。
|
||
5. 用户接受前置校验（accept preflight）。
|
||
6. 正式正文 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改造设计](../../../../docs/2026-08-01-评测harness改造设计.md)）：评测与生产同库，靠逻辑隔离（`run_type` + 状态机 + 访问控制），不是物理隔离。强制须收拢到引擎单点：评测行对生产读默认不可见、`run_type` 插入后不可变（使 `(eval, accepted)` 永不可达），不靠每条查询自觉过滤。
|
||
- **oracle 读侧红线**：oracle / 标准答案 / 全文**不进任何模型输入上下文**，只供人走查——可机械验证的硬红线，与冻结合同同级（写侧已有硬强制，读侧不能只靠查询纪律）。
|
||
- **从预防迁到发现**：逻辑隔离不能全靠预防，配常设不变量持续抓越界——没有评测派生卡绑定到生产、没有评测质量结果出现在任何生产视图、没有正式正文块的来源能追溯到评测候选，违反即报警。
|
||
|
||
## 8. 验收条件
|
||
|
||
1. 单用户可以完成新建作品、规划、生成、审核和接受正文，全流程在库内闭环。
|
||
2. 每个待审候选在库内有明确状态、版本、来源和用户决策记录。
|
||
3. 修改后合并一定产生新版本并重跑检测。
|
||
4. 任何评测候选都不能成为库内正式正文（四层强制可机械验证：查询候选表 `run_type` 为评测类型的行，`status` 不得为 ACCEPTED）。
|
||
5. 中途失败不损坏库内已有的作品、实体或范式正式事实。
|
||
6. 只读看板能渲染每个候选的当前状态——看板看不到 = 没落库 = 不合规。
|
||
|
||
## 9. 关联 SoT
|
||
|
||
- 作品与决策存储：[01-作品领域](01-作品领域.md)——正式正文、决策记录的表结构归它。
|
||
- 上下文输入：[04-上下文领域](04-上下文领域.md)——冻结上下文的选择与裁剪。
|
||
- 质量步骤：[06-质量与复利领域](06-质量与复利领域.md)——机械门、语义检测、评分的合同。
|
||
- 数据权威与落库：[08-数据权威与可视化领域](08-数据权威与可视化领域.md)——库权威层级、落库机制、只读看板。
|
||
- 接受上级合同：[专题-01](../../../../../design-docs/专题-01-正文建议接受%28Accept%20Suggestion%29实现规范.md)——accept preflight 的产品级规范。
|