# 作品领域 SoT

> 数据权威：本领域的正式内容（Canonical）以 PostgreSQL `muse-example` 库为唯一事实源；Git 只管代码、Skill、文档与 DDL，不再是正式内容权威。横切合同（一切输入产出必须落库才能被看见）见[领域设计索引](_index.md) §3，本领域只引用、不重复定义。

## 1. 唯一职责

作品领域拥有一部小说作为创作项目的身份、规划、正式正文、作品级状态、用户决策记录，以及其他领域产物在作品内的归档关系。它回答“正在写哪部作品、正式内容是什么、下一步写什么、哪些决策已经由用户确认”。决策本身意味着什么（接受、合并、丢弃各改变什么）由创作流程领域定义，本领域拥有决策记录的存储与可追溯。

作品领域不拥有实体详细事实、跨作品范式、审核/实验结果语义、Agent 定义、Skill 实现、运行回执字段合同或库内检索加速。`reviews`、`experiments`、`runs` 在库内挂在作品名下只是为了完整归档：审核与实验的 schema 与终态由质量与复利领域拥有，运行回执（`runs`）的字段合同由数据权威与可视化领域拥有，本领域只声明它们与作品的归档关系。

## 2. 数据合同

作品的正式内容权威是 PostgreSQL（`muse-example` 库）里的三张表：

| 库表 | 承载 |
|---|---|
| `muse_content_work` | 作品行：身份、状态、规划引用、绑定 |
| `muse_content_chapter` | 章行：章序、标题、章级状态 |
| `muse_content_block` | 正文块：正文整章存 `content_text` 列 |

字段权威由 `meta/schemas/`（`work_core`、`novel_work`、`outline`、`chapter`、`style` 等）加上对应库表共同定义。作品身份、状态、规划、正文、用户决策、运行回执都在库里。一切输入产出必须落库才能被看见，这条横切合同见[领域设计索引](_index.md) §3。

正式内容以库行为准，不再要求 `work.yaml`、`settings/*.md` 这类文件形态。

## 3. 作品行字段合同

`muse_content_work` 一行只保存静态身份和必须由人判断的字段：

- `schema_version`：字段合同标识，当前为 `work-file-v1`
- `work_id`
- `slug`
- `title`
- `category`
- `status`：`draft | writing | paused | completed`
- `created_at`
- `next_action`
- `entity_root`：指向库内该作品的实体集合，由实体领域拥有（见 [02-实体领域](02-实体领域.md)）
- `pattern_bindings`：绑定的范式范围或明确 ID

章节数、字数、最后章号、审核前沿、库内检索加速版本等派生量不写进作品行，必须从库内正文、审核结果或状态机械计算，不做手工镜像。

## 4. 正文与候选边界

- 正式正文 = 库内正文块（`muse_content_block`）：只保存用户手写保存、原样接受或修改后合并后的内容。
- AI 产出默认不可信，先落库为待审候选（Shadow），不触碰正式正文。
- 完整候选正文属于 raw，按 raw 边界进库（单独表 + 访问控制），只读看板可看全文；raw 的存储与访问控制合同见 [08-数据权威与可视化领域](08-数据权威与可视化领域.md)。
- 接受或合并时必须校验候选版本、正文哈希、当前正式正文 revision 和来源状态，全部通过后才写库；任一失败不得写正式正文。
- 丢弃候选不修改正式正文、实体或范式。
- 每次接受/合并/丢弃对应的运行回执随候选归档到作品名下；回执的字段合同见 [08-数据权威与可视化领域](08-数据权威与可视化领域.md)，本领域只声明归档关系。

实现边界：作品、章、正文经 import 已落库，接受的前置校验为纯函数、已可用。目标合同还差三处落库写入——写正式正文、决策记录、运行回执；在正式正文落库写入层建成前，正式正文的写回暂由人工提交兜底，属临时通道，不是合同形态。

## 5. 规划与状态

- 规划（总纲、卷纲、章级细纲）候选先落库为待审候选，用户确认后才入库成为正式规划。
- 分卷数合同：`novel_work.篇幅目标.分卷数` 是规划承诺，大纲分卷粗纲的卷数须与之一致并经机械校验，见 §6。
- 进度状态在库内记录下一步、伏笔承接和阶段目标，不复制正文可推导的统计。
- 叙事状态在库内只保存作品级状态或对实体状态的引用；人物、地点、事件等详细事实由实体领域拥有。
- 章数、字数、前沿等派生量机械计算，不入库做手工镜像。
- 用户接受正文不自动确认知识或实体变化。正文保存后可以异步生成实体草稿，仍需确认。

## 6. 设计决策：分卷数合同

### 背景

`novel_work.篇幅目标` 当前只有目标章数与单章字数区间，没有分卷数。`outline`（scope=work）的分卷粗纲按卷承载骨架，其卷数就是「本作计划分几卷」的结构计数，却没有上层承诺可对齐：规划期可以静默增减卷，续写可以提前收线或无限膨胀，机械门也没有依据拦截。卷数本应在定盘阶段拍定、由大纲/卷纲阶段遵守，需要把它挂进篇幅目标，使上层约束下层（篇幅目标 → 大纲分卷派生）。

### 选项

| 选项 | 做法 | 取舍 |
|---|---|---|
| A. 分卷数入篇幅目标 + 卷数一致性机械校验 | 篇幅目标增「分卷数」作为规划承诺；分卷粗纲卷数必须等于篇幅目标.分卷数，规划确认前机械校验 | 卷数成为硬合同，规划期即拦截不一致；代价是改卷须先改篇幅目标 |
| B. 卷数只由大纲自带，篇幅目标不记承诺 | 分卷粗纲卷数即事实，不向篇幅目标回写 | 省一个字段；但卷数无上层承诺，改卷无门禁，续写可静默增减卷 |
| C. 卷数做派生量，从大纲回算进篇幅目标 | 篇幅目标.分卷数 = count(分卷粗纲)，机械镜像 | 违反「派生量不手工镜像」原则（§3）；承诺与回算混淆，规划期无法先于大纲定卷数 |

### 结论

选 A。

**① 篇幅目标.分卷数 字段合同。** 含义：本作计划划分的卷数，定盘阶段由用户拍定的规划承诺。与目标章数、单章字数区间三者共同构成篇幅目标——目标章数定总量、单章字数区间定每章尺度、分卷数定分册骨架；三者须自洽，分卷数不得大于目标章数。aiContext 用途：随篇幅目标走 `aiContext: [planning]`，只在规划期（大纲/卷纲）进生成上下文约束 planner 分卷，写作期不注入。性质：规划承诺，不是回算量。

**② 分卷粗纲卷数一致性机械校验。** 规则：`outline`（scope=work）的分卷粗纲条目数必须等于 `novel_work.篇幅目标.分卷数`。校验时机：规划候选落库为待审（Shadow）之后、用户确认翻 confirmed 之前的机械门，即大纲/卷纲阶段的出门门禁。失败关闭：不一致时该规划候选不得翻 confirmed、不得进生成上下文，明确失败关闭——不静默放行、不自动改数，由用户回到篇幅目标或分卷粗纲修正后重跑；改卷必须先改篇幅目标.分卷数，再让分卷粗纲对齐。归属：校验是确定性机械门、不调模型，门禁编排归 [05-创作流程领域](05-创作流程领域.md)，合同本身（比什么、何时比、失败关什么）归本领域。

**③ 承诺量与回算量边界。** 规划承诺（人定、稳定合同、写进篇幅目标）：目标章数、单章字数区间、分卷数，三者都在规划期拍定，不随正文增长自动变。回算量（机械重算、绝不手工镜像、不进篇幅目标）：已确认章数、总字数，从库内正式正文机械计算（§3）。分卷粗纲卷数既不是独立承诺也不是回算量，而是结构计数，是 ② 校验的对象，本身不由正文派生。一句话：卷数与目标章数是「计划要多少」的承诺，已确认章数与总字数是「实际写了多少」的回算，两类不互相镜像。

### 后果

- 篇幅目标成为三要素合同，定盘阶段「篇幅目标三要素齐全」门禁有了字段支撑。
- 卷数变更受控：任何加减卷都必须先动篇幅目标.分卷数并让分卷粗纲对齐，机械门在规划期拦截，续写不再能静默提前收线或无限加卷。
- 上层约束下层成立：篇幅目标（定盘）派生约束大纲分卷（卷纲），与既有规划派生关系一致。
- 横切总闸不变：分卷粗纲作为规划候选仍先落 Shadow，校验通过且用户确认后才翻 confirmed 进生成上下文。

> 现状标注：`novel_work.篇幅目标` 说明当前为「目标章数与单章字数区间」，分卷数字段及对应库列、outline 卷数一致性机械门为目标合同，schema 与机械门实施由主会话承接，本领域只定合同。

## 7. 生命周期

```text
draft -> writing -> paused -> writing -> completed
```

状态只描述作品生命周期，不表达章节审核或发布状态。章节的正式性由其是否为库内正式正文块以及 revision 记录决定。

> 注：本生命周期用 `draft/writing/paused/completed`，而部分 schema 用“筹备/连载/完结”，两套状态词待对齐。

## 8. 可恢复性

作品的可恢复性（数据库备份、快照、可重建脚本，配合 Git 里的代码与 DDL 从零重建库结构）见 [08-数据权威与可视化领域](08-数据权威与可视化领域.md)。

## 9. 验收条件

1. 一部作品的身份、规划、正式正文、用户决策都能从 `muse-example` 库查出，不依赖任何文件。
2. 库内正式正文与待审候选隔离：候选不被当作正式正文返回；丢弃候选后，正式正文逐字节不变。
3. 章节数、字数、前沿等派生量不在库内手工镜像；从正文机械重算，两次结果一致。
4. 用户决策、正文 revision、审核结果在库内可追溯。
5. 接受/合并校验（候选版本、正文哈希、正式正文 revision、来源状态）任一失败时，库内正式正文不发生写入。
6. 作品的每个输入产出都已落库，只读看板能据此渲染出作品全貌，不读取任何库外数据。
7. `reviews`、`experiments`、`runs` 不在作品领域重复定义结果 schema 或终态。
8. `outline`（scope=work）的分卷粗纲卷数与 `novel_work.篇幅目标.分卷数` 一致；不一致的规划候选不能翻 confirmed、不进生成上下文。

## 10. 关联 SoT

- 领域总览与横切合同：[领域设计索引](_index.md)
- 实体事实：[02-实体领域](02-实体领域.md)
- 正向创作与决策语义：[05-创作流程领域](05-创作流程领域.md)
- 数据权威、raw 进库、运行回执字段合同与可恢复性：[08-数据权威与可视化领域](08-数据权威与可视化领域.md)
- Shadow/Canonical 上级合同：[架构-02](../../../../design-docs/架构-02-核心数据结构与双轨模型.md)