muse-agent-example/.agent/docs/architecture/domains/03-范式领域.md

范式领域 SoT

1. 唯一职责

范式领域拥有可复用的写作方法、适用条件、禁用条件、来源证据和验证状态。它回答“什么写法在什么场景下值得参考、证据是什么、是否已经达到可复用标准”。

范式不是作品事实。范式可以指导规划和写作，但不能证明某人物、事件或世界规则成立。

范式的正式内容（Canonical）权威在 PostgreSQL，不在 Git 文件。Git 只管代码、Skill、meta/schemas 和文档；范式卡作为正式内容存在库里，由只读看板查库渲染给人看。一切输入产出必须落库可见，这条硬纪律见 领域索引 §3，本文件不重复定义。

2. 数据合同

范式不再用“目标文件目录”定义，改用数据合同定义：字段权威 = meta/schemas 六个范式型 + 库表。

• 六个范式型（由 meta/schemas 驱动）：scene_pattern（通用桥段）、trope（套路）、craft（技法）、pacing（节奏）、emotion（情感）、combat（打斗）。每型的字段、边界判据和 aiContext 控制项由对应 schema 拥有，本文件不复制字段定义，见 meta/schemas/。
• 库表：范式卡是 muse_knowledge_draft 表里的行。公共范式 work_id = 0，作品级范式 work_id = 8（当前实验作品）。型别、名称、摘要、写法要点、适用条件、例证出处等放在 draft_payload（JSONB）里，结构对齐 meta/schemas 对应型。
• scope（适用范围）用库内字段区分，不再用目录层级：公共 / 作品两层靠 work_id + 目标库区分。work_id = 0 是公共范式，非零 work_id 是某部作品的作品级范式。
• 范式卡的演进历史靠库内 revision 和数据库自身的版本/备份承载，不在卡里另写一份不可校验的历史叙述。

3. 最小范式合同

一张范式卡至少由这些库内字段说清楚：

• work_id：0 为公共，非 0 为作品级，决定这张卡的适用范围。
• draft_type：范式型，取六个范式型之一。现状：库内活卡 draft_type 恒为 entity、无区分力；型在 draft_payload 中文键「型」（公共卡）/ 英文键 type（作品卡），见可视化合同 §7；目标合同待对齐。
• draft_payload（JSONB）：至少含 名称、一句话摘要、标签、来源（手工 / 抽取@第N章 / 拆书@书名），以及该型在 meta/schemas 定义的特有字段（如通用桥段的场景类型、目标结构、推进机制、例证出处）。
• status：库内状态字段。现状取值是“待确认 → 确认 / 丢弃”，见第 4 节。
• confidence：可信度，供召回排序参考，不单独决定卡是否成立。
• source_type / source_id：来源回指，能追到拆书原文、抽取章节或作品证据。

draft_payload 的人可读部分必须至少说明：要解决的问题、适用条件、不适用或容易误用的条件、可操作写法、预期效果和可观察信号、来源与验证证据。例证出处只记书名 + 回目 + 一句话定位，严禁抄录原文；原书全文按 raw 规则进库，见 领域索引 §8。

4. 生命周期

设计目标合同是五态：

observation -> draft -> evaluating -> active -> retired

• observation：只留在作品审核、实验或经验记录中，不进入正式范式。
• draft：已形成可操作写法，但证据不足。
• evaluating：已进入预注册实验或跨样本复核。
• active：有可追溯证据，允许被正式上下文选择。
• retired：被证伪、被更高版本替代或适用边界已失效。

现状标注：库里现在只有“草稿 / 待确认 → 确认 / 丢弃”这一档，五态生命周期尚未建成。evaluating、active、retired 的机械判据待建。

单章、单作品或一次高分不能直接产生公共 active。升格必须说明样本范围、场景选择偏差和替代解释。

现有实现锚点：公共范式卡由 deconstruct-book 窗级聚类出卡，经 review-knowledge-cards 三角色审核（番茄作家 / 起点作家 / 主编）判 pass / revise / reject 后写回卡里，再由用户确认落为正式内容。

5. 消费合同

• 范式按意图、场景、适用范围选择，不能临场把整个范式库倾倒给 writer。
• 注入 writer 的是有尺寸上限的写法摘要（名称、一句话摘要、写法要点），不是库行全文。来源指针另留在冻结上下文里供审计回读。
• 尺寸上限（现有实现，合同侧失败关闭）：name ≤ 40 字、summary ≤ 120 字、writingPoints ≤ 6 条且每条 ≤ 200 字；召回每型取 top-2、单次总量 ≤ 12 张。超量内容在合同侧直接拒收，无论检索端将来怎么换，超量都进不了 writer 输入。
• 范式冲突时按作品明确绑定、适用范围、证据等级和版本顺序处理；无法确定时省略，不随机拼接。
• 范式只影响“怎么写”，不能覆盖作品和实体的正式事实。

消费方式（已决策，见 §6）：合同态是“规划期选定并绑定范式，写作期只消费已绑定范式”，决策与落库合同见 §6；现状“写作期按本章意图实时有界召回”在绑定合同生效后即为违规路径。范式注入 writer 的尺寸上限与冲突规则仍以本节为准，§6 只补“选哪几张、何时生效、谁来消费”的绑定语义。

实验臂现状：Gate A 用 A/B/C 三臂，A 臂恒空（纯历史原文对照），B/C 臂拿候选范式卡；分臂规则收敛在 writer 合同一处，保证“有无范式卡”这个单变量不被破坏。

6. 设计决策：规划期绑定

背景：范式的正路是“规划期决策、写作期引用”——规划产出显式挂所引范式的引用，写作期只按引用注入、不重新检索范式，上级合同见 专题-07 §2。本领域 §5 消费合同的目标态与此一致，但现状是写作期按本章意图实时有界召回，两者未对齐；同时 01-作品领域 §3 已在作品行字段合同声明 pattern_bindings（绑定的范式范围或明确 ID），真实库表 muse_content_work 却无承载列。这两处缺口由本决策一并收口为明确合同。

选项：

选项	做法	取舍
A 写作期实时召回（现状）	每章按意图对公共范式库有界召回	选择不可追溯、不可复现，无法形成“规划决策→写作引用”链；与专题-07 验收 3 直接冲突
B 规划期绑定 + 写作期只读引用	select_patterns 规划期选定 → Shadow → 用户确认 → 写 pattern_bindings → 写作期只消费已绑定	选择由用户决策、落库可追溯、注入可复现；代价是绑定须有库表承载位与确认门禁
C 写作期海选 + 事后登记	写作期向量海选，选中后再补登记	登记滞后于消费，单变量与可复现性同样被破坏，只是 B 的劣化版

结论：采用 B。合同如下。

1. 绑定对象与形态：pattern_bindings 承载本作已确认绑定的范式引用集合，每条绑定 = 范式卡库内 sourceId + 选定时的版本 / 内容哈希快照。绑定可指公共范式卡（work_id = 0，已确认 / active 态），也可指作品级范式（非零 work_id）。哈希快照冻结绑定语义：范式卡后续被修订不静默改变已绑定内容，是否换绑由用户重新决策。

2. SoT↔库不一致与补齐方向：pattern_bindings 已是作品行 SoT 合同字段（01-作品领域 §3），但 muse_content_work 尚无承载列——这是 SoT 先于库的债。本领域只定范式侧语义；库表承载位与落库机制归 01-作品领域 与 08-数据权威与可视化领域，不在此写 DDL。补齐方向：在作品行增结构化承载位，存已确认绑定的范式引用集合；承载位建成前，绑定事实必须有临时落库位，不得只活在内存或文件，否则违反“一切落库”横切合同（领域索引 §3）。

   • 实验仓落地承载（遵循 db/ddl 「主仓表原样不改列、实验扩展进 example_*」口径）：承载位 = 最新一条已确认 assembly 规划行（example_planning_section，section_type=assembly，state=confirmed）的 patternReferences；确认 assembly 即激活绑定，不另改 muse_content_work。消费侧由 assemble-context load_confirmed_pattern_bindings 只读该已确认绑定（写作期不临场召回）。作品行 pattern_bindings 列仍是主仓生产承载方向（归 01/08），届时实验仓承载收敛回作品行。

3. 生效时机（Shadow→confirmed）：规划期 select_patterns 从公共范式卡选定本作范式，选择先落 Shadow（规划候选）；经用户确认翻 confirmed 后才写入 pattern_bindings、才可进生成上下文（横切总闸见 架构-02）。未经确认的 Shadow 选择不是绑定，不得被写作期消费。

4. assembly 落点与 knowledgeBindings 填充：assembly 装配本次写作上下文时，其范式绑定项（knowledgeBindings 的范式部分）只从该作品 confirmed 的 pattern_bindings 派生——按引用回读冻结范式卡、回读验哈希，再按 §5 尺寸上限裁成注入视图；不从全库临场召回。选择、冻结、裁剪、投影的机制归 04-上下文领域，本领域只约束“范式这一路只认已绑定引用”。

5. 消费合同（写作期只读引用）：assemble / writer 只消费 pattern_bindings 里 confirmed 绑定的范式；写作期对公共范式库做相似度临场海选的链路判违规（对齐 专题-07 §7 验收 3）。范式冲突仍按 §5 既有规则（作品明确绑定优先、无法确定则省略，不随机拼接）。

6. 与评测 A/B/C 臂的关系：生产绑定走作品行 pattern_bindings；评测 A/B/C 臂的分臂规则仍收敛在 writer 合同一处（开发评测边界见 05-创作流程领域 §7），A 臂恒空、B/C 臂注入评测侧独立冻结的同一组范式卡。两条注入路径分立：评测臂不读作品行 pattern_bindings，生产绑定也不改写评测臂的冻结卡集——保证“有无范式卡 / 哪组范式卡”这个单变量不被生产绑定污染。

后果：

• 范式选择从“写作期黑盒召回”变为“规划期用户决策 + 落库可追溯”，规划产出携带引用链，写作任务可回指该绑定。
• 新增两条机械门禁：①写作期任一注入 writer 的范式必须能回指 pattern_bindings 一条 confirmed 绑定，无绑定来源失败关闭；②select_patterns 的 Shadow 选择在用户确认前不出现在 pattern_bindings、不进生成上下文。
• 产生一项对作品领域的依赖：muse_content_work 需补 pattern_bindings 承载位（见结论 2）；承载位建成前绑定只能走临时落库位，属过渡通道，不是合同形态。
• 现状写作期实时有界召回在绑定合同生效后即为违规路径，须收敛为“只读已绑定”。

7. 范式在经验升格中的位置

范式是经验升格的中转站：作品里反复出现的稳定观察，先进入范式验证，达到可复用标准后，再升格为 Skill、确定性工具或 Agent 规则。完整升格规则和判据由质量与复利领域独家拥有，见 06-质量与复利领域 §6。本节只说范式这一段：

• 升格一旦发生，范式卡只保留原理、适用边界和证据，具体执行步骤链接到接手它的 Skill 或 Tool，不再自己留一份。
• 只适用于单书的经验留在作品级（非零 work_id），不得污染公共层（work_id = 0）。

两个“升格”不同义：本节的“经验升格”指写法经验从范式提炼为 Skill / Tool / Agent 规则，对象是方法。02 实体领域里的“升格”指参考书或正文产生的实体草稿经用户确认成为作品正式事实，对象是作品面实体入库，见 02-实体领域。两者对象不同，不要混用。

8. 检索与召回

范式的选择靠库内检索：按型别、适用范围、场景和意图从库里过滤候选；库内检索加速（pgvector 向量索引）只负责提高召回速度，不是独立权威，可从库重建。任何命中都必须回读库行并校验内容哈希后才能采用。

• 检索加速失败只影响速度，不改变范式状态语义、不跳过审核。
• 只读看板查库渲染范式，绝不写库；接受、丢弃等写操作仍由 decide-candidate Skill 和主会话走。
• 可恢复性（库备份、快照、可重建脚本）见 08-数据权威与可视化领域。

9. 验收条件

1. 每张 active（或现状下已确认）范式卡都能从 draft_payload 回到来源（拆书书名 + 回目，或作品证据）。
2. 公共范式行的 work_id = 0，作品级范式行的 work_id 非 0；单作品观察不会被写成 work_id = 0。
3. 任一注入 writer 的范式摘要可机械校验：name ≤ 40 字、summary ≤ 120 字、writingPoints ≤ 6 条且每条 ≤ 200 字；超量在合同侧失败关闭。
4. 单次召回每型 ≤ 2 张、总量 ≤ 12 张，可机械读出。
5. 检索加速命中后必回读库行并验哈希；哈希不符的命中不被采用。
6. 范式卡只影响“怎么写”，上下文里的作品事实和实体事实不被范式覆盖。
7. 范式升格为 Skill/Tool 后，卡里不存在第二份执行步骤，只有链接。
8. 只读看板对范式只查不写。
9. 规划期绑定（§6）可机械校验：写作期任一注入 writer 的范式都能回指作品行 pattern_bindings 一条 confirmed 绑定，无绑定来源失败关闭；select_patterns 的 Shadow 选择在用户确认前不出现在 pattern_bindings、不进生成上下文。

10. 待建

• 五态生命周期（evaluating / active / retired）的机械判据。
• scope 的 category（品类）层：现状只有公共 / 作品两层，品类层为目标。
• 规划期绑定的合同已定（见 §6）；消费侧取数端（assemble-context load_confirmed_pattern_bindings）与生产编排接线已建（实验仓以已确认 assembly 行承载）。剩余待建只是落地：muse_content_work 的 pattern_bindings 承载列（库表承载归 01-作品领域，届时实验仓承载收敛回作品行）、绑定确认门禁、写作期范式须可回指 confirmed 绑定的机械门禁（尚未强制）。

11. 关联 SoT

• 数据权威与落库硬纪律：领域索引
• 质量与经验升格规则：06-质量与复利领域
• 实体入库（另一种“升格”）：02-实体领域
• Skill 边界：07-Agent与Skill领域
• 数据权威与可恢复性：08-数据权威与可视化领域
• 类型结构：meta/schemas/
• 作品行 pattern_bindings 字段合同与库表承载：01-作品领域
• 装配的选择 / 冻结 / 裁剪 / 投影机制：04-上下文领域
• 开发评测边界与 A/B/C 臂：05-创作流程领域
• 知识消费上级合同（规划期决策、写作期引用）：专题-07