zizi-al/muse-agent-example
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
muse-agent-example/muse/sot/domains/05-创作流程领域.md

30 KiB
Raw Blame History

创作流程领域 SoT

1. 唯一职责

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

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

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

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

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

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

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

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

阶段定义

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

阶段 0 · 定盘

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

阶段 1 · 大纲 / 卷纲

  • 进入条件：阶段 0 已确认。
  • 产出：outline（scope=work，字段权威见 muse/content/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 等，型与字段权威见 muse/content/meta/schemas/）。主落点是实体入库链：muse_knowledge_draft → 用户确认 → muse_knowledge_entity（关系另落 muse_knowledge_relation），确认链由 02-实体领域 拥有。每条实体带「演变历程」（已发生的 {章, 台阶, 周期}，周期取 登场/成长/高光/退场/结局）与「成长弧线」（未来计划）。
  • 机械门禁：
    1. payload ↔ schema 字段覆盖（落库机械校验，带「字段存疑：原因」逃生口）——已建：persist_planning 落库按 muse/content/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 味黑名单 / 对话风格 / 章末钩子风格 / 达标样张，字段权威见 muse/content/meta/schemas/style.yaml）。
  • 机械门禁：assembly 经用户确认（confirmed）才进正文上下文、assemble 只消费已绑定范式（对齐 专题-07：公共范式只走规划期决策、写作期引用，不作写作期临场海选）、style 真注入 writer——取数端与生产接线已建：assemble-context 三个一等取数端（load_confirmed_fine_outline / load_confirmed_pattern_bindings / load_confirmed_style）已建并由生产编排（muse/content/work/skills/generate/write-next-chapter/scripts/produce_next_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。细纲字段合同见 muse/content/meta/schemas/ 与 细纲合同（plan-chapter）。
  • 机械门禁：
    • 硬门禁（既有，代码失败关闭）：section_type='fine_outline' 必带 target_chapter、payload 为非空 JSON、细纲须为结构化对象且数组/字符串字段类型稳定（落库即拒）。
    • 内容门禁（文档纪律，待升级）：硬事件 / 伏笔动作（埋 · 推 · 收）/ 必须出场实体 / 章末钩子齐备；细纲硬约束覆盖率 100%（回放评测维度，见 专题-04）；细纲产出形与 writer 装配消费形统一——已建：唯一字段权威 muse/content/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；以及本轮落地的——细纲唯一字段合同（muse/content/meta/schemas/fine_outline.yaml，产出形与装配消费形统一）、落库字段覆盖门禁（fine_outline 型已强制失败关闭）、assemble-context 三个一等取数端（load_confirmed_fine_outline / load_confirmed_pattern_bindings / load_confirmed_style）并由生产编排 produce_next_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. 正向流程

人机分界（硬口径 · 以「创作内容有没有变」为准）

人关注的是内容变化过程：作品正文、规划/正文候选草稿、知识卡、AI 味规则（及同类创作权威）何时被写出、改写、升格或落正式库。

闸口（你确认的）：产出节点生成候选之后，必须经你确认，才能入库为正式内容。accept 授权下游草稿自动生成（章后抽卡、案例/规则候选等，一律 shadow / proposed）；草稿转正式仍须你确认。未确认不得把候选当作 Canonical；不得在未 accept 时自动写下游草稿。

可不自动 / 须人看见并决策 可自动跑
改库内正式创作权威：muse 正式正文、规划 confirmed、知识卡转正、声音账定版、AI 味规则/样例激活等 不改正式权威：只读检查、装载方法合同、机械/语义门、评分与诊断报告、经验 proposed；以及 accept 授权后的下游草稿（抽卡/案例/规则候选 → shadow）
决定「改哪一版内容」「要不要把草稿/卡/规则变成正式」 检索、冻结清单校验、额度/探针；人说「写第 N 章 / 改：…」即授权本轮产/改 Shadow 候选

因此两个产出节点仍是「先自动检查，再谈改内容」；自动阶段不得偷偷改正文/草稿/卡/规则：

【节点 P · 生成设定/规划】
  自动：装载方法 Skill；对已有草稿做只读检查 → 报告
  人决策才发生内容变化：要不要生成/改一版规划草稿 → 要不要 confirmed

【节点 W · 生成正文】
  自动：prevent 合同装配（约束投影，不改正文）；机械门；语义门；diagnose 报告；
        方法只读检查报告
  人决策才发生内容变化：要不要让写手产/改候选草稿 → 要不要 revise → 要不要 accept 进正式正文

【节点 A · 章通过后】
  自动（在 accept 的授权范围内）：只读汇总、建议清单、运行证据/lesson proposed；
        下游草稿生成——章后抽卡、AI 味案例与规则候选，一律落 shadow / proposed
  人决策才发生内容变化：草稿转正式——卡是否确认入实体、案例是否落卡、规则是否激活、声音账是否定版

章级串起来：

用户意图
  -> 读库事实
  -> 自动检查（不改创作内容）→ 展示报告
  -> 【人】授权内容变化：生成或修改草稿/正文/卡/规则，或确认落正式库
  -> 再自动检查新内容（仍不越权改正式态）→ 人再决策
  -> 继续

写正式正文 = 写库内正文块。检查报告与运行证据可在人决策前可见；创作内容的每一次写入都应能在过程里被看见。

用户也可以直接在库内编辑正式正文；一旦走 Agent，仍须遵守：自动层不改创作内容，内容变化经人。

2.1 自动层 vs 内容变化层

层 允许 禁止（自动层）
自动 读库；方法合同装载；门与诊断/方法检查报告；运行回执；example_lesson 的 proposed；人已授权本轮时的 Shadow 产/改；accept 后下游 shadow 草稿 写/改正式正文；规划翻 confirmed；知识卡/规则/声音账转正
内容变化（人在场） 说「写/改/采纳/丢弃」；confirm 卡；activate 规则；定版声音账 把自动检查或 shadow 草稿假装成已落正式库

与实现的对齐说明：人说「写第 N 章」「改：…」即本轮产/改 Shadow 的授权。诊断/prevent 若只写质量与证据表，可自动。accept 后下游草稿自动生成的执行接线仍待建（投影已可 pending）；未接线前不得声称已自动抽卡。

2.2 创作方法 Skill 与去 AI 味

  • 方法 Skill：在 P/W 自动装载 + 自动只读检查（出报告）；不因检查而改草稿/正文。真正按报告改内容、或确认规划，等人。
  • prevent / diagnose：目标为自动检查/约束投影；revise、规则激活、案例转正属内容/规则变化，等人。
  • 方法出卡进 select_patterns 会改卡与装配，属内容变化链，须人确认（复利批次 3）。

现状 vs 目标：门与 diagnose 报告侧已较完整；方法自动检查仍待建。

2.3 交互回合合同（节点 W）

每一轮输入拼装顺序固定；第 2 轮及以后只在第 7 项写入你的上一轮原话，1–6 与第 1 轮同序。

序 输入项 说明
1 库事实 作品 / 目标章 / as_of
2 已确认细纲 fine_outline confirmed；硬约束只写事件/结果，禁止修辞描写句
3 前章正式正文基线 连续 as_of 起若干章
4 文风 + 已绑定范式 有则注入
5 prevent 约束投影 不改正文
6 方法合同（只读） 装载 + 检查报告；待建
7 本轮人指令 第 1 轮可为空（「写第 N 章」）；之后为「改：…」原文
输出块 说明
候选正文 Shadow，可预览，≠ Canonical
门与诊断报告 机械 / 语义 / diagnose（及方法检查，待建）
本轮输入摘要 喂了什么，可在看板回看
决策菜单 改 / 丢弃 / 采纳 三选一；agent 不得自选
你说 系统 正式正文
改：… 不入库；开下一轮，第 7 项=你的原话 不变
丢弃 候选 discarded 不变
采纳 / 正文可以了 accept → Canonical；自动启动下游 shadow 草稿（抽卡等）；转正仍等人 变

2.4 节点 × Skill 挂载

_index.md 只做分类；本表才是编排菜单。必用=编排必须调用；可选=报告或增强；人授权=你说了才跑内容变化。

节点 必用 可选（自动报告） 人授权才用
P 规划 assemble-context、plan-story / plan-chapter 方法只读检查；check-content-consistency 规划草稿生成与 confirmed
W 正文 prevent-ai-flavor→assemble-context→write-next-chapter→机械门→语义→diagnose-ai-flavor→Shadow 方法只读检查；score-content-quality（生产待建） 「写/改」产候选；revise-ai-flavor / polish-prose / rewrite-selection；decide-candidate
A 章后 （accept 触发）下游草稿：extract-chapter-knowledge、案例/规则候选登记 lesson proposed；只读汇总 confirm-knowledge-draft；规则激活；声音账定版；下一章开写

参照方法 Skill（prose-craft 等）不进 meta/chains；挂在 P/W「可选装载」，出卡升公共范式仍走复利批次 3 人闸。

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 触发器锁方向闭集与身份不可变），生产编排 produce_next_chapter.py 已接它。候选表 example_candidate 承载业务态（含 accepted / discarded），接受/丢弃经 write_canonical 单通道翻态。ARCHIVED 态仍未启用。

4. 用户决策

正文候选命运的三类用户决策（菜单与 §2.3 一致）：

  • 原样接受（采纳）：当前候选写为库内正式正文；并授权下游 shadow 草稿自动生成。
  • 修改后重产（改：…）：人指令进入下一轮输入第 7 项；或用户编辑产生新 candidate_version——必须重新检测和接受前置校验。
  • 丢弃：正式正文不变，候选标记为丢弃并留在库内可查。

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

查看来源、展开评分和取消运行是辅助操作，不等于接受、改写授权或丢弃。

5. 目标工作链与编排合同

人的创作意图
  -> 主代理润色、确认歧义（不写作、不约束创作）
  -> 写作智能体自主探索生成候选
  -> 检查智能体自主取证检查
  -> 主代理向人请求授权（继续 / 补证 / 重写 / 换方向）
  -> 候选落库
  -> 人闸决策 -> 正式正文

主代理只传递人的意图；五个角色经授权只读工具自主探索，探索轨迹进依赖清单。补证与重写没有业务次数硬上限，由主代理向人请求授权，编排停在授权终态，人决定继续、换方向或停止；技术保护（单次超时、单次预算、用户取消、事务保护）保留。机械检查与语义检查的检查规则作为提示词传给检查智能体，系统保留报告防造假校验：引文必须真实存在于候选正文、哈希绑定、报告结构合法。

保护步骤主代理和智能体都不能绕过：

  1. schema 与来源校验。
  2. 上下文冻结与依赖清单留痕。
  3. 确定性检查（机械门）。
  4. 语义检查（检查智能体 + 防造假校验）。
  5. 用户接受前置校验（accept preflight）。
  6. 正式正文 revision 比较与库内原子写（CAS 乐观锁，冲突则收敛到明确终态）。

正文、规划、提取、检测和评审分别由单一职责角色执行，主代理不把多个角色合成一次模型调用。

当前生产编排实现（run_writer_pipeline）的事实：机械门 → 语义检测 → 单次收敛、证据缺口收敛为授权终态（AUTHORIZATION_REQUIRED，补证/重写经人授权后以新运行继续）、CAS 乐观锁 + 失败收敛终态、生成篇幅与机械接受底线分层合同、评测候选四层强制；业务继续/停止的授权归人，技术保护（超时、预算、取消）在执行策略层。生产写手收到 4000–7000 汉字（目标 7000），可信适配器只拒绝不满 3001 汉字或超过 10000 汉字的异常输出；两层区间由 WriterContext 机械校验保持嵌套。

写手执行的唯一生产形态是两阶段写手（produce_next_chapter.py <章> --provider P --model M）：探索阶段派发写作智能体（只读工具集）自主取材（细纲、前文、文风、范式、实体）、产出探索清单；确定性回放按清单重放只读工具（无模型参与），得到写手实际依赖的材料；生成阶段无工具派发、单次成稿，生成输入只含回放材料与篇幅/文风合同，不含全量预组装。探索与生成使用独立会话、各记独立派发运行，写手事实只来自它探索到的材料；探索清单与摘要落运行工件，探索轨迹与依赖清单进事件账本，是创作台链路透视的数据源。探索与生成分离的原因：单阶段同会话形态下，长篇生成会被多回合探索挤占输出空间导致正文碎片化（2026-08-23 烟测实证）。该形态已于 2026-08-23 生产烟测双门通过并经人采纳进正典；同源对照实验裁决直调链退出创作生成（见 07-Agent与Skill领域）。

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 投影）。
  • 补证重组装：已建——语义 needs_evidence 时 production_evidence_reassemble 检索本作品 as_of 内正文/实体摘录并追加 factEvidence；命中则停在授权终态（AUTHORIZATION_REQUIRED），重写经人授权后以新运行继续。零命中不禁止写手发明新设定、不重写，缺口升格为 newSettingCandidates，当前候选进人闸。新设定是否进入正典由人决定；与既有正典冲突仍失败关闭。

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-数据权威与可视化领域——库权威层级、落库机制、只读看板。
  • 结构本体字段权威：muse/content/meta/schemas/——前期五阶段各产出（work_core / novel_work / outline / style / 23 型）的字段合同。
  • 接受上级合同：专题-01——accept preflight 的产品级规范。
  • 细纲硬约束覆盖率：专题-04——阶段 4 覆盖率门禁的回放评测维度。
  • 范式规划期决策：专题-07——公共范式只走规划期决策、写作期引用的上级合同。