muse-agent-example/.agent/docs/architecture/domains/01-作品领域.md

作品领域 SoT

数据权威：本领域的正式内容（Canonical）以 PostgreSQL muse-example 库为唯一事实源；Git 只管代码、Skill、文档与 DDL，不再是正式内容权威。横切合同（一切输入产出必须落库才能被看见）见领域设计索引 §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 等）加上对应库表共同定义。作品身份、状态、规划、正文、用户决策、运行回执都在库里。一切输入产出必须落库才能被看见，这条横切合同见领域设计索引 §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-实体领域）
• pattern_bindings：绑定的范式范围或明确 ID

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

4. 正文与候选边界

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

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

5. 规划与状态

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

6. 生命周期

draft -> writing -> paused -> writing -> completed

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

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

7. 可恢复性

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

8. 验收条件

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

9. 关联 SoT

• 领域总览与横切合同：领域设计索引
• 实体事实：02-实体领域
• 正向创作与决策语义：05-创作流程领域
• 数据权威、raw 进库、运行回执字段合同与可恢复性：08-数据权威与可视化领域
• Shadow/Canonical 上级合同：架构-02