# 创作流程领域 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）。
- 评测产出不反写作品、实体或范式正式事实。
- 评测产出钉死评测区，只读看板可按区查看但不混入正式内容视图。

## 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 的产品级规范。