muse-agent-example/.agent/docs/architecture/domains/05-创作流程领域.md

创作流程领域 SoT

1. 唯一职责

创作流程领域拥有单用户正向创作链的步骤、状态和失败收敛。它回答"用户的创作意图怎样变成待审候选（Shadow）、候选怎样经过检查、用户决策怎样把候选写为库内正式正文（Canonical）"。

本领域不拥有作品正文内容、实体字段、范式内容、Agent Prompt、评分量表或存储表结构（存储归 01-作品领域 和 08-数据权威与可视化领域）。

一切输入产出必须落库可见——横切合同见索引 §3。

1A. 前期创作阶段（正向创作链的前段）

本节拥有正文生成之前的五阶段串行流程：定盘 → 大纲/卷纲 → 设定拆条 → 范式与文风选定 → 细纲。它回答"一部书在动笔写正文之前，要依次产出哪些规划事实、每步卡在什么门禁上、满足什么条件才允许进入下一步"。§2 的正向流程从本节阶段 4 产出的细纲往后接续。

本领域拥有这五阶段的顺序、进入/退出条件和门禁，不拥有各阶段产物的字段合同与存储表结构——字段权威在 meta/schemas/，存储与确认链分别在 01-作品领域、02-实体领域、03-范式领域，本节只引用、不重复定义。

两条贯穿五阶段的硬合同（均为既有合同，本节只引用）：

• 横切总闸：一切规划候选先落 Shadow，经用户确认翻 Confirmed 后才进入生成上下文（Shadow/Canonical 双轨，见 架构-02）。
• 上层约束下层：大纲派生卷纲、卷纲派生细纲；下层规划不得与已确认的上层规划相悖，冲突时以下层退回为准。

阶段定义

除特别注明外，各阶段规划产出都经 persist_planning 落 example_planning_section（默认 state='shadow'），用户确认后翻 confirmed。

阶段 0 · 定盘

• 进入条件：作品已创建（作品行存在，见 01-作品领域）。
• 产出：work_core（题材定位 / 核心卖点 / 主题立意 / 基调 / 禁区 / 核心悬念 / 谜底与真相 / 结局方向 / 目标读者，字段权威见 meta/schemas/work_core.yaml）+ novel_work 的篇幅目标（目标章数 × 单章字数区间 × 分卷数，见 meta/schemas/novel_work.yaml）。落 section_type='setting'。
• 机械门禁：篇幅目标三要素齐全——当前为文档纪律，待升级为落库校验。
• 退出条件：work_core 九字段与篇幅目标三要素齐备且用户确认（confirmed）。

阶段 1 · 大纲 / 卷纲

• 进入条件：阶段 0 已确认。
• 产出：outline（scope=work，字段权威见 meta/schemas/outline.yaml）——主线一句话、分卷粗纲（每卷：卷名 · 卷目标 · 核心冲突 · 情绪终点）、当前卷细纲、未来卷粗纲（防续写提前收线）、弃案记录（防 AI 复活旧方向）。落 section_type='outline'。
• 机械门禁：主线一句话 ≤ 50 字、每卷四要素齐、卷粗纲 ≈ 卷正文 0.3–0.5%、卷数 = 篇幅目标.分卷数——当前均为文档纪律，待升级为落库机械校验（卷数合同是本次新增的架构空白之一，见本节"现状与待建"）。
• 退出条件：大纲 confirmed，且卷数与篇幅目标.分卷数一致。

阶段 2 · 设定拆条

• 进入条件：阶段 1 已确认。
• 产出：把设定拆成结构本体 23 型条目（world / power_system / faction / character / item / location / event / character_relation 等，型与字段权威见 meta/schemas/）。主落点是实体入库链：muse_knowledge_draft → 用户确认 → muse_knowledge_entity（关系另落 muse_knowledge_relation），确认链由 02-实体领域 拥有。每条实体带「演变历程」（已发生的 {章, 台阶, 周期}，周期取 登场/成长/高光/退场/结局）与「成长弧线」（未来计划）。
• 机械门禁：
  1. payload ↔ schema 字段覆盖（落库机械校验，带「字段存疑：原因」逃生口）——已建：persist_planning 落库按 meta/schemas/<型>.yaml 校验必填字段，缺必填失败关闭；fine_outline 型已标「字段覆盖门禁：强制」，其余型字段（中文键）与 payload 对齐后逐步纳入；推荐字段缺失只报告不拦，确无依据的字段可显式标「字段存疑：原因」放行。
  2. 设定全书闭环：每条设定须有 登场 → … → 结局 的计划弧线，有始有终——目标合同，待建（本次新增架构空白之一）。
  3. 全书设定台账：设定 × 章消费矩阵，标记未被碰 / 未收口——目标合同，待建（本次新增架构空白之一）。
• 退出条件：设定条目经用户确认入正式实体表，且字段覆盖、闭环、台账三项校验通过（三项建成前，以用户确认为退出准绳）。

阶段 3 · 范式与文风选定

• 进入条件：阶段 2 已确认。
• 产出：
  • 规划期 select_patterns 从公共范式卡（work_id=0）选定本作范式，绑定 pattern_bindings；范式内容与消费尺寸合同见 03-范式领域。
  • 装配 assembly：把已选范式与本作事实组织为待装配集合，落 section_type='assembly'（装配此前无领域 owner，本节收编，见下"归属收编"）。
  • style 文风画像八字段（叙事人称视角 / 句式 / 叙述配比 / 用词质感 / AI 味黑名单 / 对话风格 / 章末钩子风格 / 达标样张，字段权威见 meta/schemas/style.yaml）。
• 机械门禁：assembly 经用户确认（confirmed）才进正文上下文、assemble 只消费已绑定范式（对齐 专题-07：公共范式只走规划期决策、写作期引用，不作写作期临场海选）、style 真注入 writer——取数端与生产接线已建：assemble-context 三个一等取数端（load_confirmed_fine_outline / load_confirmed_pattern_bindings / load_confirmed_style）已建并由生产编排（docs/write-chapter/step2_write_chapter.py）接线；范式只读已确认 assembly 绑定注入（实验仓承载，见 03-范式领域 §6），确认文风投影为 styleConstraints 随冻结上下文注入 writer（不再写死为空）。待建：当前注入的是设定行的一句话文风（书12 现状），结构化 style 八字段画像的书级抽取尚未建；写作期范式须可回指 confirmed 绑定的门禁尚未机械强制。评测 A/B/C 臂走独立冻结注入，不读生产绑定。
• 退出条件：assembly 已 confirmed 并完成 pattern_bindings 绑定，style 八字段齐备。

阶段 4 · 细纲

• 进入条件：阶段 3 已确认，且当前卷大纲已确认。
• 产出：逐章 fine_outline（章细纲 ≈ 章正文 3–5%，是结构骨架不是缩写，超比例退回），落 section_type='fine_outline' 且必须带 target_chapter。细纲字段合同见 meta/schemas/ 与 细纲合同（plan-chapter）。
• 机械门禁：
  • 硬门禁（既有，代码失败关闭）：section_type='fine_outline' 必带 target_chapter、payload 为非空 JSON、细纲须为结构化对象且数组/字符串字段类型稳定（落库即拒）。
  • 内容门禁（文档纪律，待升级）：硬事件 / 伏笔动作（埋 · 推 · 收）/ 必须出场实体 / 章末钩子齐备；细纲硬约束覆盖率 100%（回放评测维度，见 专题-04）；细纲产出形与 writer 装配消费形统一——已建：唯一字段权威 meta/schemas/fine_outline.yaml（必填集满足装配与机械门、推荐集保留规划表达力），plan-chapter 与 writer 装配同指它，结束此前两套字段不相交的漂移。
• 退出条件：该章细纲 confirmed，硬约束覆盖率达标，产出形可被 writer 装配直接消费。

五阶段共用的落库机械门禁（既有，代码失败关闭）

这四条由 persist_planning / decide-candidate 在库侧强制，不靠调用方自觉：

1. section_type 只接受 setting / outline / state / assembly / fine_outline，非法值拒落。
2. fine_outline 缺 target_chapter 拒落。
3. payload 必须是非空 JSON 对象。
4. 规划确认只走 shadow → confirmed 单通道，非 shadow 不可确认；未 confirmed 的规划不进生成上下文。

归属收编登记

以下四个既成事实此前散落在别处或无 owner，本节在流程里给它们一个明确阶段位置；字段与存储 owner 不变，本领域只拥有它们所处的阶段、进入/退出与门禁。

既成事实	本流程位置	字段 / 存储 owner（只引用）
卷纲	阶段 1 产出的一部分	outline schema + 01-作品领域 §5（规划存储与确认）；此前仅 01 一笔带过
设定拆条	阶段 2	23 型 schema + 02-实体领域（入库与确认链）；此前仅为纪律
装配 assembly	阶段 3	example_planning_section.section_type='assembly'；此前无领域 owner，由本节收编
范式规划期绑定	阶段 3	03-范式领域 §5/§6（消费合同；规划期绑定消费侧已建、作品行承载列待建）+ pattern_bindings（01-作品领域 §3 已声明字段）

现状与待建

• 已建成（引用即可）：五阶段顺序与产出落点、example_planning_section 的 section_type 白名单与 fine_outline 必带章号、shadow → confirmed 单通道、公共范式卡与 select_patterns；以及本轮落地的——细纲唯一字段合同（meta/schemas/fine_outline.yaml，产出形与装配消费形统一）、落库字段覆盖门禁（fine_outline 型已强制失败关闭）、assemble-context 三个一等取数端（load_confirmed_fine_outline / load_confirmed_pattern_bindings / load_confirmed_style）并由生产编排 step2_write_chapter.py 接线（细纲统一消费、范式只读已确认 assembly 绑定、文风投影为 styleConstraints 注入 writer）。
• 决策已定、机械落地待建（三个架构空白）：合同见 02/01/03 三域决策记录——
  1. 设定全书闭环校验 + 全书设定台账（把「演变历程」从只追加日志升级为闭环义务，新增设定 × 章消费矩阵视图；见 02-实体领域 §8）。
  2. 卷数合同：novel_work 篇幅目标增「分卷数」，outline 分卷粗纲卷数须与之一致并机械校验（见 01-作品领域 §6）。
  3. 范式规划期绑定：消费侧已通；作品行 pattern_bindings 承载列为主仓生产方向（实验仓暂以已确认 assembly 行承载，见 03-范式领域 §6）。
• 待建（其余门禁升级与取数补全）：阶段 0–1 的字数 / 比例 / 四要素校验、阶段 2 字段覆盖门禁扩到其余型（中文键 schema 与英文 payload 对齐后纳入）、阶段 4 细纲硬约束覆盖率门禁、结构化 style 八字段画像的书级抽取（当前注入设定行一句话文风）、写作期范式须可回指 confirmed 绑定的机械门禁。字段层面的回填（novel_work 分卷数、pattern_bindings 库列）属各 owner 文档与 meta/schemas，不在本节。

本节验收条件

1. 五阶段可机械读出先后：任一早阶段的规划未 confirmed 时，其直接后续阶段的规划不允许进入生成上下文（查询 example_planning_section 的 state 与依赖关系可验证）。
2. 每条规划产出都在库内有 section_type、state、target_chapter（细纲）记录，只读看板可据此渲染前期全流程。
3. 任一 fine_outline 行必带非空 target_chapter 与非空 payload（查询可验证，缺者在落库时即被拒）。
4. 未 confirmed 的 assembly 不出现在正文生成上下文里；正文上下文引用的范式均可回读到 pattern_bindings 绑定记录（绑定库列建成后可机械验证）。
5. 阶段门禁失败（字数超限、卷数与分卷数不一致、字段覆盖不足、闭环缺弧线、覆盖率不达标）会阻断进入下一阶段，而不是静默放行（各门禁升级落库后逐项可机械验证）。

2. 正向流程

用户意图
  -> 从库内读取作品目标、已确认规划和当前正式正文
  -> 组装并冻结角色上下文
  -> Planner/Fine-outline 产生规划候选（按需）
  -> 用户确认规划
  -> Writer 产生正文待审候选（Shadow）
  -> 确定性检查（机械门）
  -> 语义检测（Semantic Detector）
  -> 质量策略与有限修订（补证≤3 次 / 重写≤2 次）
  -> 展示候选、风险、来源和质量摘要
  -> 用户：原样接受 / 修改后合并 / 丢弃
  -> accept preflight 与 revision 校验
  -> 写库内正式正文（= 写库内正文块，不写任何本地文件）
  -> 生成实体/范式观察草稿
  -> 继续创作

写正式正文 = 写库内正文块。候选在用户接受之前已落库（候选表），只读看板随时可见。

用户也可以直接在库内编辑并保存正式正文，不要求先运行 Agent 或配置范式。

3. 状态合同

待审候选状态采用有限状态机（设计合同）：

DRAFT -> CHECKING -> PASSED -> ACCEPTED
                    |          |
                    |          -> ARCHIVED
                    -> REJECTED
DRAFT/CHECKING/PASSED -> DISCARDED（用户明确决策）

• 状态应持久化到库（候选表），使只读看板能渲染每个候选的当前命运。
• 状态迁移必须绑定 run_id + attempt + candidate_version + candidate_sha256。
• 迟到检测结果、旧版本候选和 revision 冲突不能覆盖新状态。
• PASSED 只表示候选可展示、可进入接受前置校验，不表示已成为正式正文。
• 诊断和评测候选固定不可接受（四层机械强制：资格由 run 类型机械派生、合同硬校验拒绝、接受入口硬拒、产出钉死评测区）。

现状标注：候选状态已持久化。生产运行级 CAS 链落 example_candidate_cas（PostgresCasStateStore，一次运行一条链：DRAFT / CHECKING / PASSED / REJECTED，revision 单调 +1，DB 触发器锁方向闭集与身份不可变），生产编排 step2_write_chapter.py 已接它。候选表 example_candidate 承载业务态（含 accepted / discarded），接受/丢弃经 write_canonical 单通道翻态。ARCHIVED 态仍未启用。

4. 用户决策

只有三类改变候选命运的用户决策：

• 原样接受：当前候选正文写为库内正式正文。
• 修改后合并：用户修改产生新 candidate_version，必须重新检测和接受前置校验。
• 丢弃：正式正文不变，候选标记为丢弃并留在库内可查。

决策记录落库（存储结构归 01-作品领域）。

重新生成、查看来源、展开评分和取消运行是辅助操作，不等于接受、合并或丢弃。

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）：用户意图、冻结上下文、候选正文、检测与评分、决策、运行回执、补证与重写记录。

现状与待建：

• 写库写入层：已建——write_canonical.accept 单事务写正文块（revision CAS）+ 来源归因 + 命令幂等 + 决策归档 + 候选翻态，任一失败整体回滚；DB 级兜底复检 run_type=production、state=passed、semantic_status=passed（先审后入，语义未过不得接受）。
• 状态机持久化：已建——运行级 CAS 链 example_candidate_cas，业务态落 example_candidate；ARCHIVED 态未启用。
• 结构化事实增量：已建——example_fact_delta（提案）+ example_fact_ledger（正典账本）；模型只提六型闭集增量且必须带正文证据引文，只有用户批准的增量随正文同事务入账本，抽取结果不自动升格。
• 待建：生产链上的质量评分环节（盲评仍只接离线评测）；补证重组装在语义缺口下的自动接线（当前缺口失败关闭）；章后抽取的异步执行（接受时只登记 pending 投影）。

7. 开发评测边界

Gate A/B、A/B/C 三臂、参考书标准答案和盲评只属于开发期离线验收，不进入普通创作链。离线评测可以复用 Writer、Detector、Judge 和上下文合同，但：

• 所有评测候选固定不可接受（四层机械强制，见 §3）。
• 评测产出不反写作品、实体或范式正式事实。
• 评测产出钉死评测区，只读看板可按区查看但不混入正式内容视图。
• 访问分离，不是隔离（harness 改造原则，见 docs/2026-08-01-评测harness改造设计）：评测与生产同库，靠逻辑隔离（run_type + 状态机 + 访问控制），不是物理隔离。强制须收拢到引擎单点：评测行对生产读默认不可见、run_type 插入后不可变（使 (eval, accepted) 永不可达），不靠每条查询自觉过滤。
• oracle 读侧红线：oracle / 标准答案 / 全文不进任何模型输入上下文，只供人走查——可机械验证的硬红线，与冻结合同同级（写侧已有硬强制，读侧不能只靠查询纪律）。
• 从预防迁到发现：逻辑隔离不能全靠预防，配常设不变量持续抓越界——没有评测派生卡绑定到生产、没有评测质量结果出现在任何生产视图、没有正式正文块的来源能追溯到评测候选，违反即报警。

8. 验收条件

1. 单用户可以完成新建作品、规划、生成、审核和接受正文，全流程在库内闭环。
2. 每个待审候选在库内有明确状态、版本、来源和用户决策记录。
3. 修改后合并一定产生新版本并重跑检测。
4. 任何评测候选都不能成为库内正式正文（四层强制可机械验证：查询候选表 run_type 为评测类型的行，status 不得为 ACCEPTED）。
5. 中途失败不损坏库内已有的作品、实体或范式正式事实。
6. 只读看板能渲染每个候选的当前状态——看板看不到 = 没落库 = 不合规。

9. 关联 SoT

• 作品与决策存储：01-作品领域——正式正文、规划存储、决策记录、pattern_bindings 字段声明的表结构归它。
• 设定拆条与实体入库：02-实体领域——阶段 2 设定条目的 draft → entity 确认链与演变历程归它。
• 范式规划期绑定：03-范式领域——阶段 3 范式消费尺寸合同与规划期绑定（消费侧已建、作品行承载列待建）归它。
• 上下文输入：04-上下文领域——冻结上下文的选择与裁剪。
• 质量步骤：06-质量与复利领域——机械门、语义检测、评分的合同。
• 数据权威与落库：08-数据权威与可视化领域——库权威层级、落库机制、只读看板。
• 结构本体字段权威：meta/schemas/——前期五阶段各产出（work_core / novel_work / outline / style / 23 型）的字段合同。
• 接受上级合同：专题-01——accept preflight 的产品级规范。
• 细纲硬约束覆盖率：专题-04——阶段 4 覆盖率门禁的回放评测维度。
• 范式规划期决策：专题-07——公共范式只走规划期决策、写作期引用的上级合同。