zizi cfa46e6e7a 框架: 前期创作流程SSOT——五阶段流程+设定闭环/卷数/范式绑定三决策
把"前期准备"立成正式流程 SSOT,并填三个架构空白(独立子代理形而上四维审查通过后提交):
- 05-创作流程领域 §1A 前期创作阶段:定盘→大纲/卷纲→设定拆条→范式文风→细纲五阶段,
  每阶段进入/退出/门禁,区分代码硬门禁与文档纪律;归属收编卷纲/设定拆条/装配assembly/
  范式绑定四个既成事实;现状与待建已对齐代码(取数端+生产接线已建、结构化文风画像等待建)。
- 02-实体领域 §8 决策:设定全书闭环校验+全书设定台账(演变历程从只追加日志升级为闭环义务,
  设定×章消费矩阵从库表机械重算,与 canon_compliance 一致性正交)。
- 01-作品领域 §6 决策:分卷数合同(novel_work.篇幅目标 增分卷数,outline 分卷粗纲卷数须一致机械校验)。
- 03-范式领域 §6 决策:规划期绑定(pattern_bindings 合同;实验仓以已确认 assembly 行承载,
  作品行承载列为主仓方向;消费侧取数端+生产接线已建)。
- _index.md 协作关系登记同步。
2026-08-02 02:17:30 +08:00

127 lines
11 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# 作品领域 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)