zizi-al/muse-agent-example
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

文档: 权威分层登记与合同收敛（含前会话治理文档工作）

Browse Source 
- 登记 SQLite 运行态账本：AGENTS/红线/08域/表映射 四处同口径
  （不产生 Canonical，冲突以 PG 为准）；表映射补 muse.db 八表清单
- web/app.py 按裁决登记为本地人审留痕通道（08域 §6.1，写面闭集）
- rubric 回写四项无条件阻断（_BLOCKING_ADVISORY_CODES 对齐）
- 红线措辞校准：额度窗口真实语义（跨窗续跑/降级/末窗 4h）、
  MUSE_LLM_ALLOW_UNGOVERNED 逃生口登记、抽取角色改治理链口径
- 角色合同登记 blind_judge/semantic_detector 别名与两阶段写手形态
- 文档失实修复：导读旧路径、细纲必填表补 3 字段、schemas/README
  改库内权威世界观、framework/README 登记 claude 适配器、
  harness README 对齐新布局、59 技能计数
- 迁移对账改关联计数（不再写死 reviews=6）
- 四维形而上审查报告（verdict PASS，含独立性局限声明）
- 含前一会话未提交的治理文档工作：AGENTS 重构、审查标准迁移、
  rubric 引用更新、.agent 目录索引更新
- .gitignore 补 muse.db 备份文件规则
This commit is contained in:
zizi 2026-08-30 23:06:39 +08:00
parent 76d38f2dc7
commit a7d2746d67
15 changed files with 247 additions and 242 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
.agent/_index.md
View File

@ -3,8 +3,13 @@
- [Muse SoT](../muse/sot/_index.md)
- [Skill 方法发现总索引](skills/_index.md)
- [Skill 编排索引](../muse/_skills_index.md)
- [角色身份提示](agents/)（writer / planner / extractor / detector / judge）
- [角色身份提示](agents/)（写手 / 规划 / 抽取 / 检测 / 裁判）
- [角色合同](../muse/sot/角色合同.md)（稳定角色边界、模型策略与派发合同唯一事实源）
- [边界合同](../muse/sot/边界合同.md)（组件职责边界与约束归属唯一事实源）
- [红线约束](约束/红线约束.md)（数据、探索、模型与提交硬性红线）
- [研发执行流程](rules/执行流程.md)（动态研发时序六阶段流程）
- [提示词与技能审查标准](规范/审查标准.md)（提示词 4 问、技能 7 问 + D8 复利审查规范）
- [去 AI 味道工程规范](规范/去AI味道工程规范.md)
- [指令集规范](规范/指令集规范.md) 与 [术语规范](规范/术语规范.md)
项目入口与协作规则仍由根目录 [`AGENTS.md`](../AGENTS.md) 拥有；本目录只保存跨任务稳定知识。

2
.agent/目录.md
View File

@ -2,7 +2,7 @@
|------|----------|----------|----------|----------|
| rules | rules/执行流程.md | 动态研发时序六阶段执行流程与判定条件 | 任务启动、阶段流转、门禁检查与经验沉淀前 | 必须严格按六阶段单向流转，不得跳步 |
| 约束 | 约束/红线约束.md | 数据、权限、模型与代码四大不可逾越红线 | 涉及数据读写、模型调用、探索边界与代码提交时 | 违反红线一票否决，直接阻断 |
| 规范 | 规范/ | 纯中文术语规范、指令集规范与去 AI 味道工程规范 | 编写指令、起名、设计提示词、写文档与代码审查时 | 全仓必须统一使用纯中文单名与中立指令语法 |
| 规范 | 规范/ | 提示词与技能审查标准、术语规范、指令集规范与去 AI 味道工程规范 | 编写指令、起名、设计提示词、技能审查、写文档与代码审查时 | 全仓必须统一使用纯中文单名与中立指令语法，审查按标准逐条核验 |
| skills | skills/ | 本仓长期复用的标准方法与能力（目录格式：skills/<分类>/<名>/SKILL.md） | 命中特定创作或工程方法场景时 | 统一使用反引号中文单名引用 |
| agents | agents/ | 智能体角色定义与四要素指令集（写手、规划、检测、裁判、抽取） | 派发角色任务与构建提示词时 | 严格落实三位一体中文单名与决策阶梯 |
| docs | docs/ | 团队设计与历史沉淀文档 | 查阅架构设计、技术演进时 | 运行期不加载，历史元数据隔离 |

6
.agent/约束/红线约束.md
View File

@ -4,7 +4,7 @@
## 1. 数据与状态红线
1. **唯一事实源**：PostgreSQL 是系统正式内容的唯一权威。严禁将库外临时文件或快照当作正式数据。
1. **唯一事实源**：PostgreSQL 是系统正式内容的唯一权威。严禁将库外临时文件或快照当作正式数据。本地 SQLite（`data/muse.db`）只是运行态留痕与单机工作账本，不构成正式内容权威。
2. **正典写入主权**：正文、规划与知识抽取必须先形成影子候选。严禁绕过审查或未经用户明确确认直接写入正典事实（Canonical）。
3. **禁止裸连操作**：严禁智能体或脚本绕过受控入口直连数据库执行一次性写入或 DDL。DDL 必须落入审计文件后受控执行。
@ -16,8 +16,8 @@
## 3. 模型治理与执行红线
1. **角色模型锁定**：写手、规划、裁判角色必须使用合同指定的顶级推理模型，抽取与清洗走内容模型。严禁静默更换模型、降级供应商或私自篡改提示词。
2. **额度窗口红线**：模型调用严格遵守额度窗口限制，达到预算或调用上限时强制熔断，严禁绕过治理层裸调接口。
1. **角色模型锁定**：写手、规划、裁判角色必须使用合同指定的顶级推理模型，抽取与检测按角色合同的 `governed-chain-or-fixed` 策略执行（固定 Opus 或全局统一降级链成员，完整 ID 等值）。严禁静默更换模型、降级供应商或私自篡改提示词；派发链前置校验与事后模型核对均为失败关闭。
2. **额度窗口红线**：模型调用严格遵守额度窗口限制（窗口起点 0/5/10/15/20 点，末窗为 4 小时）：调用次数达上限时休眠到下一窗口边界续跑，预算耗尽时本窗降级到非 MiniMax 链，严禁绕过治理层裸调接口。调试逃生口（`MUSE_LLM_ALLOW_UNGOVERNED=1` 或 `allow_ungoverned=True`）仅限本地诊断，不得用于生产调用。
3. **确定性不调模型**：规则校验、哈希计算、静态门禁与报告组装由确定性脚本执行，严禁调用模型执行机械任务。
## 4. 交付与代码红线

74
.agent/规范/审查标准.md Normal file
View File

@ -0,0 +1,74 @@
# 提示词与技能审查标准
> 状态：生效规范
> 适用范围：`.agent/agents/*.md`（角色提示词）与 `muse/lifecycle/quality/harness/manifests/skills.json` 登记的 Skill 包
> 门禁工具：`muse/lifecycle/quality/harness/skill_harness.py` 与 `test_skill_harness.py`
新增、修改或定期复核任何智能体提示词与技能时，按本规范逐条审查。
**核心原则**：一份提示词、一个技能只服务一个明确意图；与意图无关的词、约束、机制都是污染——它让执行者分心，也让合同两张皮。
---
## 1. 智能体提示词审查标准（`.agent/agents/*.md` 与角色系统提示词）
角色稳定合同以 [角色合同](../../muse/sot/角色合同.md) 为唯一事实源。角色文件可以包含面向智能体的身份、技能路由、推荐工具能力和工作方法；审查硬边界、模型策略、实际工具权限和结构化输出时以中心合同与适配器为准。
审查时逐条核验四个问题：
1. **面对谁**：这份提示词读给哪个模型/角色？它只该有这一个身份，不该同时背「执行器/评测器/审查器」之类第二身份。
2. **每个词都有意义吗**：逐词问——它对「这个角色干好本业」有用吗？框架名、schema 名、字段名、运行身份、哈希、评测状态这类机器词，对创作/规划/抽取/检测等本体任务毫无意义，是其它层的泄漏，应予剔除。
3. **约束是该有的限制吗**：每条约束问——它是角色意图本身需要的，还是支架（harness）本就能强制的？**输出格式**由结构化输出 Schema 强制、**实际工具可用性**由调用参数强制、**盲化**由「输入里压根没有该信息」保证；角色文件可以解释技能和工具的用途，但不能把提示文字当权限或结构门。
4. **正向与负向**：分清哪些部分**帮**角色达成意图（正向：本业纪律、领域边界、知情范围），哪些**妨碍**它（负向：与本业无关的机器约束、诱导照搬输入原文的措辞、让模型惦记评测的暗示）。负向部分删除或移到对应层。
> **反例与正解**：
> - **反例（已纠正）**：评测写手提示词曾塞入「你是 Gate A 离线回放的 writer…只输出 candidateBody…不输出哈希/身份…不访问 MCP」，把评测支架混进创作提示词——既没有写作指导，又诱导写手照抄细纲概述句。
> - **正解**：角色文件保留写作方法、技能路由和工具用途；输出格式、实际工具权限、盲化和证据绑定交给中心合同、Schema 与适配器。
---
## 2. 技能审查标准（Skill Review）
分类取值、八个评分维度、必备节清单和严重度定义的权威是 [`skill-quality-rubric.md`](../../muse/lifecycle/quality/harness/specs/skill-quality-rubric.md)。审查必须**先跑机械门，再人工审**，严禁用机械门跑绿代替人工判断：
```bash
# 静态审计门禁（阻断项与质量发现一并必须为零）
.venv/bin/python muse/lifecycle/quality/harness/skill_harness.py --strict
# 审计器回归测试
.venv/bin/python muse/lifecycle/quality/harness/test_skill_harness.py -q
```
人工逐条核验以下问题（括号内为对应质量维度）：
1. **给谁用**：消费者必须明确、单一——主会话编排、某个角色智能体，还是别的技能。只能由编排调用的必须声明 `orchestrated`；"不得由 Agent 自行触发"这类禁令写在散文里不算数。
2. **该用时会不会被用上**（D1，只对 `model_routed` 适用）：`description` 是模型唯一的路由依据，必须写清做什么、何时用、何时不用，并对易混的技能点名交接。
3. **目的单一**（D2）：一个技能只实现一个能力。功能并列、又当编排又当执行的，必须拆分。
4. **边界不重叠**（D3）：显式写出不做什么；集合内不得存在未声明的职责重叠。
5. **合同完整**（D4）：必备节按分类裁剪；`scripts/` 只放运行时确定性实现与机械门，测试归 `tests/skills/`，清单与模板归 `references/`。
6. **可靠性与失败关闭**（D5）：失败明确关闭，不静默降级、不返回假成功；错误带稳定码、不泄漏原文与密钥；确定性步骤真不调模型；走 `.venv`，不裸调数据库、接口或模型。
7. **机制优先与边界一致**（D6、D7）：能由 frontmatter、schema、adapter 或 `scripts/` 强制的约束不写成散文叮嘱；引用的路径、合同、字段与现行 SoT 一致，引用已失效合同的不得执行；`SKILL.md` 只留执行时必须常驻的内容。
8. **用过之后系统有没有更强**（D8，`lifecycle ≠ platform` 适用）：本次的方法与观察有没有沉淀成库内可被后续运行消费的资产（范式卡、规则、声音账、经验登记），还是用完即散。
### 命名与标识纪律
- 目录名必须等于 frontmatter `name`。
- 执行动作的系统能力技能命名采用小写 `动作-对象`，表达可调用能力，不复用 `scenario` 或含混阶段词。
- 创作方法技能采用小写领域名（如 `scene-craft`、`narration-pov`）。
- `scenario`、`source_type`、updater 和备份逻辑键是独立稳定标识，不随技能改名而随意变动。
---
## 3. 审查产出规范
每次审查对每个被审对象必须给出标准化产出：
1. **面对谁 / 目的**：明确调用方与核心功能定位。
2. **逐条问题清单**：按正向资产与负向污染分类，并逐条标注严重度（**阻断** / **严重** / **一般**）。
3. **具体修改建议**：给出明确的重构或裁剪方案。
> **严重度定义**：
> - **阻断（Blocker）**：存在维度 0 分项、违背红线、导致假绿或破坏数据一致性，必须立即修复才能合入。
> - **严重（Major）**：职责重叠、提示词泄漏、缺少机制约束等影响系统健壮性的问题。
> - **一般（Minor）**：措辞冗余、格式微调、非关键参考文档链接失效等。
审查过程只读、不直接改代码；修改需另行取得授权，框架改动与创作内容分开提交。

1
.gitignore vendored
View File

@ -28,3 +28,4 @@ docs/write-chapter/artifacts/
.opencode/
.cursor/
# END my-skills-cli
data/muse.db.bak-*

244
AGENTS.md
View File

@ -1,229 +1,81 @@
# AGENTS.md —— agent-example 项目工作入口
> 适用范围：本文件只约束 `agent-example/`。父仓 [`../AGENTS.md`](../AGENTS.md) 的通用工程、证据和协作规则继续生效；本文件只补充本地创作仓的规则，不重复父仓规范。
> **Skill 发现入口（必读）**：读完本文件后必须读 [`.agent/skills/_index.md`](.agent/skills/_index.md)（Skill 发现总索引）；需要某项能力时按索引中的 `skill_file` 读对应 `SKILL.md`。发现只靠 AGENTS.md → 总索引 → SKILL.md 的渐进披露，不依赖任何 coding agent 的 skill 自动发现。
> **技能发现入口（必读）**：读完本文件后必须读 [`.agent/skills/_index.md`](.agent/skills/_index.md)（方法技能总索引）与 [`muse/_skills_index.md`](muse/_skills_index.md)（编排技能总索引）；需要某项能力时按索引中的 `skill_file` 读对应 `SKILL.md`。发现只靠 AGENTS.md → 总索引 → SKILL.md 的渐进披露，不依赖任何 coding agent 的 skill 自动发现。
## 1. 项目定位
---
`agent-example` 的目标定位是物理位于 `oh-my-muse` 内、拥有独立 `.git/` 的单用户缩小版 Muse，以 PostgreSQL 为正式内容权威。目标系统由 ReAct Agent、角色 Agent、Skill 和确定性工具协作，在本地完成作品、实体、范式、规划、正文、审核、用户决策与经验复利；不实现管理员、多用户、租户、市场、计费或资产交易。
## 1. 项目定位与物理事实
- 完整 Muse 的产品、业务和总体架构 SoT 在 [`../design-docs/`](../design-docs)；本仓只定义单用户、数据库为权威的简化实现合同，发现通用设计问题后回填父仓 SoT。
- 本仓正式内容的权威是 PostgreSQL（`muse-example` 库）：作品、章、正文、实体、范式、用户决策、运行回执和 raw 都在库里。判断“系统里有没有这个东西”，以库里能不能查到为准；不得把库外的文件或临时快照说成正式内容。
- Git 是代码、Skill、Agent 提示词、`muse/content/meta/`、文档和 DDL 的权威，并可以对作品相关信息和作品文本留痕（版本历史与备份）；但 Git 留痕不是正式内容权威，正式内容以库为准，只读看板只读库，两者冲突时以库为准。库内向量索引是数据库一侧的检索加速，不是独立权威。可恢复性靠数据库备份加快库里代码与 DDL 重建，见 [数据权威与可视化领域 SoT](muse/sot/domains/08-数据权威与可视化领域.md)。
- 本仓继续承担真实创作、拆书、回放评测和候选审查；这些活动服务缩小版 Muse 的能力验证，不把开发期 Gate 当作产品主流程。
`agent-example` 的目标定位是物理位于 `oh-my-muse` 内、拥有独立 `.git/` 的单用户缩小版 Muse，以 PostgreSQL 为正式内容权威。
## 2. SoT 与职责边界
- **正式内容权威**：PostgreSQL（`muse-example` 库）是系统正式内容的唯一权威。作品、章、正文、实体、范式、用户决策、运行回执和 raw 都在库里。判断“系统里有没有这个东西”，以库里能不能查到为准；严禁把库外临时文件或快照当作正式内容。
- **运行态账本**：本地 SQLite（`data/muse.db`，gitignore）是默认派发与单机工作面的运行态账本（2026-08-28 存储裁决）：运行留痕（runs/events）、本地人审（reviews/revisions）、卡片与向量镜像、lesson 本地状态机和外部反馈数据落在其中；它不产生 Canonical，与 PG 冲突时以 PG 为准。表清单见 [`muse/authority/db/表映射.md`](muse/authority/db/表映射.md)。
- **代码与配置权威**：Git 是代码、技能、智能体提示词、`muse/content/meta/schemas/`、文档和 DDL 的权威，并对作品信息和文本留痕备份；但 Git 留痕不是正式内容权威，正式内容以数据库为准，只读看板只读库，两者冲突时以库为准。
- **能力边界**：由主会话派发角色智能体、技能和确定性工具协作完成创作与治理；不实现管理员、多用户、租户、市场、计费或资产交易。
SoT 按主题分域，不做跨主题的全局排序。可执行脚本与书面合同不一致时视为缺陷，不得自行拼接两套口径；本文件已经明确判定失效的旧路径，不因仍出现在历史文档或 skill 中而恢复有效。
---
| 载体 | 权威职责 |
|---|---|
| [`../AGENTS.md`](../AGENTS.md) + 本文件 | 父仓通用规则与本地创作仓工作边界。更具体的本地规则只做收窄，不取消父仓规则。 |
| [`CLAUDE.md`](CLAUDE.md) | Claude Code 兼容入口，只引用本文件，不定义独立规则或 SoT。 |
| [`../design-docs/`](../design-docs) | Muse 的概念、产品、业务和总体架构 SoT。 |
| [`muse/sot/domains/`](muse/sot/domains/_index.md) | 本仓领域边界、数据权威、落库合同和领域协作的 SoT。 |
| [`muse/sot/边界合同.md`](muse/sot/边界合同.md) | 组件职责边界与约束归属的唯一事实源：什么约束放提示词、工具、脚本、静态层；智能体/Skill/工具 server/主代理各自不做什么。 |
| [`muse/content/meta/schemas/`](muse/content/meta/schemas) | 23 型结构本体的字段合同；库内 payload 结构以该合同为准。 |
| [`muse/lifecycle/flow/chains/`](muse/lifecycle/flow/chains) | scenario、purpose、功能 skill、角色槽位和保护节点的链路登记。 |
| [`.agent/skills/`](.agent/skills/) | 只挂载 15 个 `model_routed` 方法 Skill；编排 Skill 的业务源位于 `muse/**/skills/`。所有位置由 `muse/lifecycle/quality/harness/manifests/skills.json` 的 `skill_path` 登记。 |
| [`tests/skills/`](tests/skills/) | Skill 的实现测试、集成测试和 fake pipeline 测试；它们提供回归证据，不拥有运行合同，也不等同于 Skill 行为评测。带确定性实现的 Skill 在此回归，纯模型判断的 Skill 靠行为评测。 |
| [`.agent/`](.agent/_index.md) | 运行期挂载面与方法 Skill 索引；领域设计位于 `muse/sot/`，新增、删除或重命名必须同步各级 `_index.md`。 |
| [`docs/`](docs) | 单次任务探索、计划、评测资料、样张和历史执行证据；任务完成后把稳定结论蒸馏到 `muse/sot/` 或 `.agent/`，不得长期拥有领域定义。 |
| [`README.md`](README.md) | 项目背景和历史路线概览。目录、阶段、技能数量和存储方式等描述可能陈旧，不得覆盖本文件、`muse/`、skill 或磁盘事实。 |
`muse/sot/domains/` 一个领域一份 SoT，索引只登记 owner 和协作关系，不复制字段与流程细节。`.agent/` 内挂载内容增删改名必须同步对应层级 `_index.md`。`docs/` 只记录单次任务过程、评测资料、样张和历史证据，不得覆盖领域 SoT。父仓 `design-docs/` 已拥有的完整产品概念，本仓只引用并定义单用户本地实现差异。
## 3. 真实目录与能力
## 2. 目录导航
```text
agent-example/
├── .git/ # 独立 Git 仓元数据
├── framework/ # FrameworkPort、Pi 适配器与通用执行对象
├── .agent/
│ ├── agents/ # 5 个 LLM 角色身份提示
│ └── skills/ # 15 个方法 Skill 的嵌套源与方法索引
├── muse/
│ ├── sot/ # 领域边界、角色合同与架构 SoT
│ ├── content/ # 作品、实体、范式、结构 schema
│ ├── lifecycle/ # 上下文、创作流程、质量、编排与 harness
│ ├── authority/ # DB、证据、只读看板与决策通道
│ └── platform/ # 连接、模型、嵌入等共享包
├── tests/ # Skill 实现测试与架构门禁
├── docs/ # 计划、评测资料、样张与历史执行记录
├── framework/ # FrameworkPort 通用协议与宿主适配器（Pi / DSH 对照）
├── runtime/ # 宿主无关执行底座（agent_executor / runs）
├── web/ # 本地人审工作台（只读 data/muse.db + 三个受控写端点）
├── .agent/ # 智能体能力中枢（角色提示词、方法技能、规则、约束与规范）
├── muse/ # Muse 业务核心（SoT、内容本体、创作生命周期、权威数据与平台共享库）
├── tests/ # 技能实现测试、架构门禁与回归验证
├── docs/ # 单次任务探索、计划、评测资料、样张与历史执行记录
├── .venv/ # 本地 Python 运行环境
├── requirements.txt # Python 依赖清单
├── CLAUDE.md # Claude Code 兼容入口，只引用 AGENTS.md
└── README.md # 历史概览，不是当前运行态 SoT
```
5 个角色：`writer`、`planner`、`extractor`、`detector`、`judge`。角色身份在 `.agent/agents/*.md`；稳定角色合同唯一事实源是 [角色合同](muse/sot/角色合同.md)，不把输入边界、模型策略、工具权限和输出合同散落进角色文件。Muse 先解析角色合同、冻结上下文、模型策略和输出 Schema，再通过 `FrameworkExecutionRequest` 调用 `framework/adapters/`；当前生产适配器是 Pi。本机 DSH 已更新为 `0.1.1-rc.2`，`web`/`headless` profile 配置检查已通过，但真实模型和 Muse 业务旅程尚未形成证据；DSH 只作为无工具 fresh 对照接缝，不把安装或配置痕迹当生产可用事实。角色是主会话派发的子代理：按 [07-Agent与Skill领域 §2](muse/sot/domains/07-Agent与Skill领域.md) 的派发合同起全新会话，注入身份提示、对应角色合同和冻结输入，输出由派发方校验并落证据；不依赖任何宿主的原生角色装载机制（如 Claude Code `--agent`），Claude CLI 不是角色运行底座。
---
### Skill 合同责任方索引
## 3. SoT 与事实源导航
实际清单与物理位置以 `muse/lifecycle/quality/harness/manifests/skills.json` 的 `skill_path` 为准。方法发现总索引见 [`.agent/skills/_index.md`](.agent/skills/_index.md)，编排发现索引见 [`muse/_skills_index.md`](muse/_skills_index.md)。索引由 `muse/lifecycle/quality/harness/skills_index.py --write` 生成；skill 增删改名后必须重新生成，一致性由架构测试机械校验。
SoT 按主题分域，不做跨主题的全局排序。可执行脚本与书面合同不一致时视为缺陷，不得自行拼接两套口径。
本表是另一条轴：登记每个 skill 的合同责任方、协作领域和领域 SoT，不复制各 Skill 的完整合同。每个 skill 必须登记一个合同责任方（业务领域或平台领域），但可以同时消费或影响多个协作领域；跨域调用、场景关系和保护节点在 `muse/lifecycle/flow/chains/` 登记。合同责任方表示谁维护该 Skill 的稳定能力合同，不表示 Skill 只能属于一个业务领域。
| 合同责任方 / 能力域 | 领域 SoT | Skill |
| 类别 | 载体 / 路径 | 权威职责 |
|---|---|---|
| 平台运行与证据 | 07-Agent 与 Skill、08-数据权威与可视化 | `access-database`、`call-content-model`、`execute-role-task`、`record-run-evidence`、`refresh-runtime-probe` |
| 上下文与知识检索 | 02-实体、04-上下文、08-数据权威与可视化 | `assemble-context`、`embed-knowledge`、`freeze-context`、`search-knowledge` |
| 导入、清洗与抽取 | 02-实体、05-创作流程 | `clean-book-text`、`deconstruct-book`、`inspect-parse-health`、`extract-chapter-knowledge`、`extract-work-knowledge`、`backup-work-extraction`、`reset-work-extraction`、`repair-work-extraction`、`import-book`、`review-knowledge-cards` |
| 规划与作品基础 | 05-创作流程 | `design-story-foundation`、`merge-story-candidates`、`plan-chapter`、`plan-story`、`concept-design`、`story-structure`、`story-planning`、`narrative-momentum`、`foreshadow-payoff`、`story-ending` |
| 写作与候选主权 | 01-作品、05-创作流程 | `decide-candidate`、`confirm-knowledge-draft`、`expand-scene`、`polish-prose`、`rewrite-selection`、`write-next-chapter`、`scene-craft`、`dialogue-craft`、`character-design`、`character-presentation`、`show-and-omission`、`narration-pov`、`prose-craft`、`theme-and-stance` |
| 质量与回放评测 | 06-质量与复利、05-创作流程 | `check-content-consistency`、`score-content-quality`、`adjudicate-quality-gate`、`optimize-content-quality`、`evaluate-frozen-replay`、`replay-writer-gate`、`load-replay-reference-work`、`novel-diagnosis` |
| 去 AI 味与人感 | 06-质量与复利、父仓专题-09 | `capture-ai-flavor-cases`、`promote-ai-flavor-rule`、`diagnose-ai-flavor`、`establish-voice-baseline`、`prevent-ai-flavor`、`revise-ai-flavor` |
| 总体设计 | [`../design-docs/`](../design-docs) | Muse 的概念、产品、业务和总体架构 SoT（设计 SSOT）。 |
| 领域 SoT | [`muse/sot/domains/`](muse/sot/domains/_index.md) | 本仓各业务领域边界、数据权威、落库合同与领域协作 SoT（01-08 域）。 |
| 边界合同 | [`muse/sot/边界合同.md`](muse/sot/边界合同.md) | 组件职责边界与约束归属唯一事实源：智能体/技能/工具 server/主代理职责划分。 |
| 角色合同 | [`muse/sot/角色合同.md`](muse/sot/角色合同.md) | 5 个角色（写手/规划/抽取/检测/裁判）的稳定输入边界、模型策略、工具权限与派发合同。 |
| 结构契约 | [`muse/content/meta/schemas/`](muse/content/meta/schemas) | 23 型结构本体与规划产物的字段合同；库内 payload 结构以此为准。 |
| 创作导读 | [`muse/sot/创作周期与Skill导读.md`](muse/sot/创作周期与Skill导读.md) | 创作生命周期各阶段流转、门禁、人机分界与技能责任方导读地图。 |
| 技能索引 | [`.agent/skills/_index.md`](.agent/skills/_index.md) / [`muse/_skills_index.md`](muse/_skills_index.md) | 59 个技能的方法发现总索引与编排索引（物理清单以 `skills.json` 为准）。 |
| 创作链条 | [`muse/lifecycle/flow/chains/`](muse/lifecycle/flow/chains) | scenario、purpose、功能 skill、角色槽位和保护节点的链路登记。 |
| 红线约束 | [`.agent/约束/红线约束.md`](.agent/约束/红线约束.md) | 数据权威、探索边界、模型治理与代码提交的不可逾越红线。 |
| 执行流程 | [`.agent/rules/执行流程.md`](.agent/rules/执行流程.md) | 动态研发时序六阶段执行流程与判定条件。 |
| 审查标准 | [`.agent/规范/审查标准.md`](.agent/规范/审查标准.md) | 智能体提示词 4 问、技能质量 7 问 + D8 复利审查规程与严重度定义。 |
| 工程规范 | [`.agent/规范/`](.agent/规范/) | [`去AI味道工程规范.md`](.agent/规范/去AI味道工程规范.md)、[`指令集规范.md`](.agent/规范/指令集规范.md)、[`术语规范.md`](.agent/规范/术语规范.md)。 |
| 任务与沉淀 | [`docs/`](docs) | 单次任务探索、计划、评测资料与历史执行证据；稳定结论回填 SoT。 |
58 个 skill 一律是本仓正式 skill，受同一套合同与门禁约束，不分等级：都须满足 [07-Agent与Skill领域 §3](muse/sot/domains/07-Agent与Skill领域.md) 的合同，都在 `skills.json` 登记，都进质量评分。全仓技能发现完全由 `AGENTS.md` 与渐进式目录契约驱动，彻底废除对宿主私有目录扫描的物理投影依赖。绑创作 scenario 的在 `muse/lifecycle/flow/chains/` 登记；平台与工具类由主会话或其它 Skill 直接调用。
---
**不按"是不是系统运行时"分等级。** 一个 Skill 当前有没有 `scripts/`、有没有数据库合同、有没有接入复利，是实现成熟度而非本质：`plan-chapter`、`expand-scene`、`polish-prose` 以模型判断为主、自身不带 Tool，落库由它们调用的 Skill 承担；`story-structure`、`scene-craft` 一类创作方法 Skill 目前只有 `SKILL.md` 与 `references/`，那是**未接入复利的欠账**，不是它们的天然形态（改造方向见下）。把成熟度写成类别，等于给未完成的 Skill 发永久豁免证。
## 4. 工作协议（硬约束）
`muse/lifecycle/quality/humanization/` 是“去 AI 味与人感”Skill 家族的能力域：`muse/lifecycle/quality/humanization/src/deai/` 是共享运行时库（包名 `muse-deai`，经 `requirements.txt` 的 `-e ./muse/lifecycle/quality/humanization` 安装）。被两个以上 Skill 或看板消费的确定性实现一律装成顶层可安装包，所属 Skill 只留 CLI：`muse-db`（连接）、`muse-llm`（模型调用、额度窗与 `muse_role` 角色执行）、`muse-embed`（嵌入），分别来自 `muse/platform/db`、`muse/platform/llm`、`muse/platform/embed`，由 `requirements.txt` 以 editable 方式安装。调用方 `import` 已安装的包，不得 `sys.path` 指向 `access-database/scripts`、`call-content-model/scripts`、`embed-knowledge/scripts`、`execute-role-task/scripts`、`establish-voice-baseline/scripts` 或 `muse/lifecycle/quality/humanization/src`；门禁见 [`tests/architecture/test_import_boundaries.py`](tests/architecture/test_import_boundaries.py)。规则与样例的运行时权威是 `example_ai_flavor_rule` / `example_ai_flavor_sample`（DDL-111，`muse/lifecycle/quality/humanization/tools/seed_rules_db.py` 种子同步，生产读取失败关闭，不静默回退 Git）；案例卡与声音账同样入库。仓内 YAML/JSON 是迁移种子、离线夹具和结构合同；规则生命周期变更经 YAML 评测/激活后同步入库。规则记录不各自注册为 Skill，Skill 负责动作和消费边界。`muse/lifecycle/quality/humanization/tests`、`tools`、`eval` 仍按包内惯例装载源码树。
1. **读后动手与渐进发现**：复杂任务开工前必须先读 SoT、角色合同与技能索引；技能发现遵循 `AGENTS.md → 索引 → SKILL.md` 渐进展开，不依赖宿主私有文件投影或猜测。
2. **机械验证优先与完成=验证**：遵循父仓反假绿规则，Python 统一使用仓内解释器 `.venv/bin/python`；必须通过相关单元测试、门禁与 `git diff --check`，无自动化证据严禁声称“完成/修复/通过”。
3. **数据权威与先审后入**：数据库为唯一正式权威，严禁裸连操作；正文、规划与知识抽取默认生成 Shadow 候选，经用户明确确认后方可写入 Canonical 正典事实。
4. **模型治理与受控探索**：模型调用严格遵守 5 小时额度窗口与受控治理链，角色严格锁定合同指定模型（写手/规划/裁判固定顶级推理模型）；确定性逻辑、门禁与报告组装由脚本完成，严禁调用模型；智能体探索仅限圈定只读工具并留痕。
5. **会话交互与汇报纪律**：全程使用简体中文白话，坚决去除 AI 味（直陈事实、动作与后果，禁止清嗓子套话与空转缓冲词）；需要用户决策时，必须交代清楚前因后果及各选项对下游的影响。
6. **提交授权与形而上审查**：严禁未经用户明确授权执行 `git add` 或 `git commit`；取得授权后、提交前，必须起独立子代理对真实 `git diff` 进行 4 维形而上审查（**逻辑完整性**、**一致性**、**合理性**、**可行性**），通过后方可提交；框架改动与创作内容分开审查、分开提交。
其中 15 个创作方法 Skill 由 7 本写作书的方法论单元按创作领域合并而来（`SKILL.md` 入口 + `references/` 全量内容），供 writer、planner、judge 在对应创作阶段取用。蒸馏与裁剪的历史留痕见 `docs/2026-08-19-craft-distillation-trace.md`（原料与旧 SoT 由 git 历史保留）。**`craft` 不再作为 Skill 的分类标签**：该词在本仓只有一个含义，即公共范式库的范式型之一（技法型，见 [03-范式领域 §2](muse/sot/domains/03-范式领域.md)）。
---
每个 Skill 的分类字段（`lifecycle` / `invocation` / `side_effects` / `compounding`）统一在 [`muse/lifecycle/quality/harness/manifests/skills.json`](muse/lifecycle/quality/harness/manifests/skills.json) 逐个登记，由 `muse/lifecycle/quality/harness/skill_harness.py` 机械校验；取值定义与质量评分口径见 [`muse/lifecycle/quality/harness/specs/skill-quality-rubric.md`](muse/lifecycle/quality/harness/specs/skill-quality-rubric.md)。
## 5. 知识与经验复利机制
**复利接入是所有创作 Skill 的共同要求，不是少数 Skill 的特权。** 一个创作 Skill 用过一次之后系统应当更强：它的方法要沉淀为库内可被后续运行消费、可被证据修正的资产（范式卡、AI 味规则、声音账、`example_lesson` 登记），走 [06-质量与复利领域 §6](muse/sot/domains/06-质量与复利领域.md) 既有的升格链，不新建平行基建。既有闭环范本是去 AI 味五技能。`compounding = none` 是欠账，由评分维度 D8 记账，现存缺口清单见 `docs/2026-08-20-skill-质量审查与复利改造清单.md`。
系统的核心价值在于复利：每一次创作与开发任务后，系统必须比上一次更强。
- **创作复利**：创作过程中提炼的技法沉淀为范式卡、AI 味规则、声音账与 `example_lesson` 登记入库，走 [06-质量与复利领域 §6](muse/sot/domains/06-质量与复利领域.md) 升格链。
- **工程复利**：开发交付后，将稳定设计与规则回写对应 SoT、`.agent/规范/`、`.agent/约束/` 或技能，过时内容及时清理，控制长期熵增。
Skill 领域列表的新增、删除、改名或主领域调整，必须同时检查 manifest 的 `skill_path`、`.agent/skills/` 方法挂载面、`muse/lifecycle/flow/chains/README.md` 和相关领域索引，并运行对应索引生成器；不得只改本表造成索引漂移。
上下文目标合同以 [上下文领域 SoT](muse/sot/domains/04-上下文领域.md) 为准：数据库读取器是核心实现，库内检索加速（向量）只做候选召回；任何命中都要回读库行并校验 hash。Skill 对自己读写哪些表负责，并把经手的输入和产出落库；没落库的输入产出在系统视角里等于不存在。
## 4. 反序验证顺序
本仓优化与验证采用反序推进：
```text
清洗 / 抽卡 / 范式
↓
正文智能体
↓
细纲智能体
↓
大纲 + 设定智能体
```
这是为了从底层证据与消费效果向上验证，不是正向生产调用顺序。不得把它改写成“大纲设定 → 细纲 → 正文”的实施进度，也不得因为某一层的单个样例可用，就宣称上层或整条创作链已经完成。
## 5. 创作与证据核心契约
1. **卡是索引，不是原文替代。** 卡用于定位实体、关系、来源和章号；生成或审查使用卡内历史事实前，必须沿 `sourceRefs/sourceVersion/stateAsOf` 回读冻结快照中的历史原文。
2. **严格冻结。** 所有历史原文、里程碑和窗口上界必须 `<= asOf`；目标章正文、目标章细纲答案、目标章出场清单及未来章、未来里程碑、终态摘要一律禁读。无法证明上界的来源按未知或省略处理。
3. **双证据而非卡片灌入。** 正文上下文以目标章前连续历史正文为基线，卡只触发补充原文回读；未经原文或正式设定、Canonical 状态、已确认细纲支持的卡内容不能单独成为事实证据。
4. **正文按细纲执行。** 细纲的硬事件、结果方向、伏笔动作、必须出场实体和章末钩子不可删除、反转或提前回收；缺细纲时停止，不由 writer 自编。
5. **先审后入。** 正文和规划先形成 Shadow 候选；机械门、语义检测或质量审查不通过时必须修订并以新候选版本重跑，不得绕过审查直接写入 Canonical。
## 6. 模型边界
- 清洗、抽卡、范式拆取及其模型调用统一走 `call-content-model` Skill，不裸调 New-API。治理政策固定为 5 小时额度窗：MiniMax 模型累计花费上限 `$24`，全模型成功调用上限 `6000`；运行适配器、正式配置和账本是额度合同的事实源，共享库 `muse_llm` 与 `muse_db.WINDOW_BUDGET_USD` / `WINDOW_CALL_CAP` 是实现，Skill CLI 只做入口，`test_quota.py` 只提供回归证据；模型链切换必须由该治理入口留下日志。
- 角色模型归属和派发字段以 [角色合同](muse/sot/角色合同.md) 为准：`planner`/`writer`/`judge` 固定 `opus`；`extractor`/`detector` 可在合同允许的治理策略内运行。每次框架调用必须显式传入 `provider`、`model` 和 `thinking`，不得从环境变量静默补全。拆书/导入侧抽取经 `call-content-model`/`deconstruct-book` Skill 走 MiniMax-M3，不走角色 model 派发；创作期章后抽取作为角色派发，可用 `opus`。
- 确定性脚本、合同校验、快照冻结、泄漏审计和报告生成不调用模型；除非对应 `SKILL.md` 明确声明模型步骤，不得把机械任务升级为模型任务。
- 固定 Opus 角色生成或评测只在对应任务 SoT、显式预算、冻结 profile 和原文用途授权全部满足后运行；自动化调用走 Anthropic 兼容 HTTP 适配器，不读取 Claude Code 配置，不启动模型 CLI。任一前置门失败都关闭执行。
- 角色的模型策略版本、模型别名、完整模型 ID、预算和回执必须与冻结配置一致。`planner`/`writer`/`judge` 不得因模型不可用而降级到内容模型链或更换供应商；需要变更时先取得明确授权并更新角色合同、profile 与探针。
## 7. 会话编排与汇报
- 主会话负责上下文组装、任务编排、机械校验和结果裁决；设定、大纲、细纲、正文和知识卡等创作内容由 `.agent/agents/` 中对应角色以子代理形式派发产生。该边界不限制主会话执行授权范围内的框架维护、只读核验和测试。
- 派发角色时必须显式指定模型，并遵守第 6 节的角色模型归属；不得由调用方静默换模型或绕过 skill 的模型治理。
- 每次创作生成结束后，向用户说明使用了哪些依据、候选或报告位于哪里，以及涉及哪些伏笔动作；不得把运行日志当作用户可观察的结果界面。
- 全程使用简体中文。任务正常执行期间只汇报关键里程碑；任务终止或需要用户决策时，第一句先说明用户现在需要做什么。
- 内部代号和英文术语要么不用，要么当场用白话解释；一句话只表达一件事，常规汇报以 30 秒内可读完为限。
- **汇报禁止 AI 味**：不堆抽象标签、不用空转缓冲词（其实/往往/某种程度上）、不假对照（不是 A 而是 B）、不凑数排比、不段末升华；具体压倒抽象，名词给实物、动词给动作。
- **需要用户决策时，每个决策点必须交代清楚**：前因后果（为什么需要这个决策、背景与约束是什么）、每个选项各自带来什么后果（选 A 影响什么、选 B 影响什么、对下游和全书走向各自意味着什么），用清晰的中文语义写；不许只列选项不交代后果，不许把后果写成抽象标签。
## 8. 数据与合规边界
- 主代理和业务 agent 不裸连 PostgreSQL 或 New-API。查询、写入和 DDL 走对应 skill 的 `scripts/`；专用导入、嵌入、检索也走各自 skill。
- 数据库写入、迁移、授权快照变更和批量运行必须先取得明确授权。DDL 先落 `muse/authority/db/ddl/` 的审计文件，再通过 `access-database` Skill 应用；不得用一次性直连命令绕过。
- 原书全文、完整问答、候选正文、标准答案和供应商响应按 raw 规则进库（单独表加访问控制，只读看板可看全文），授权、冻结边界遵守 `evaluate-frozen-replay` 合同。对外或跨任务引用的最终报告仍只保留评分、摘要、章节定位、失败类别和哈希，不直接复制全文。
- 未绑定、未授权、来源状态无效或超出用途范围的 `muse/content/entity/sources/` 与数据库来源不得进入上下文；失败时明确记录 `not_authorized`、`stale_source` 等原因，不静默降级。
## 9. 候选、改动与提交
- 创作候选默认不提交。用户明确选择接受或修改后合并，且实时审查通过后，才可经 `decide-candidate` 流程进入正式事实；丢弃也必须针对用户明确指定的候选。
- 框架改动与创作内容分开审查、分开提交。不得把 agents、skills、meta、脚本改动和正文、规划、知识卡候选混在同一提交。
- 任何 `git add` 或 `git commit` 都必须先取得用户明确授权；获得授权后，提交信息使用 `作品(书名): 动作 摘要` 或 `框架: 摘要`。
- **提交前必须形而上审查。** 取得授权后、执行 `git add` 前，必须起一个独立子代理，对即将提交的全部内容（先 `git diff` 出真实改动）从形而上层面审查四个维度：**逻辑完整性**（论点/合同/链路有无缺环、边界是否闭合）、**一致性**（与既有 SSOT、术语、字段合同、相邻文档有无矛盾）、**合理性**（设计取舍是否站得住、是否过度或不足）、**可行性**（是否真能落地运行、测试是否支撑结论）。审查只读、不改代码；四维给出明确结论（通过 / 带条件通过 / 不通过 + 具体问题），通过后才允许提交。框架改动与创作内容分别审查。
- 不覆盖、不还原、不暂存其他工作者或用户已有改动。执行前后都要核对真实 diff，只处理当前授权范围。
## 10. 评测结论与验证入口
- 明确区分**已验证事实**、**推断**和**假设**。报告必须给出证据来源；没有机械输出或运行证据时，不声称完成、修复或通过。
- 禁止从 `n=1` 样本推出普适结论。至少分析假阴、假阳、样本偏差和混淆因素；需要判断卡或模型效果时使用同任务、同模型、同预算、同公共上下文的对照，并把不稳定样本排除在方向结论之外。
- Python 一律使用仓内解释器 `.venv/bin/python`。先读目标 Skill 的 `SKILL.md`，再按 `muse/lifecycle/quality/harness/manifests/` 登记的类别和依赖选择相关验证；下面命令仅是现有局部验证入口示例：
```bash
.venv/bin/python tests/skills/plan-chapter/test_contract.py
.venv/bin/python tests/skills/call-content-model/test_quota.py
.venv/bin/python tests/skills/assemble-context/test_writer_contract.py
git diff --check
```
只运行与改动和风险相关的检查。测试涉及真实 PostgreSQL、New-API、Claude 或原文时，先核对授权、预算和副作用；不能把离线自测通过表述为真实链路通过。
## 11. Agent 提示词与 Skill 审查标准
新增、修改或定期复核任何 agent 提示词、skill 时，按本节逐条审。总原则：**一份提示词、一个 skill 只服务一个明确意图；与意图无关的词、约束、机制都是污染——它让执行者分心，也让合同两张皮。**
### 11.1 Agent 提示词（`.agent/agents/*.md` 与角色系统提示词）
角色稳定合同见 [角色合同](muse/sot/角色合同.md)。角色文件可以包含 Agent-facing 的身份、Skill 路由、推荐工具能力和工作方法；审查硬边界、模型策略、实际工具权限和结构化输出时以中心合同与适配器为准。
逐条问四个问题：
1. **面对谁**：这份提示词读给哪个模型/角色？它只该有这一个身份，不该同时背「执行器/评测器/审查器」之类第二身份。
2. **每个词都有意义吗**：逐词问——它对「这个角色干好本业」有用吗？框架名、schema 名、字段名、运行身份、哈希、评测状态这类机器词，对创作/规划/抽取/检测等本体任务毫无意义，是其它层的泄漏，应删。
3. **约束是该有的限制吗**：每条约束问——它是角色意图本身需要的，还是支架（harness）本就能强制的？**输出格式**由结构化输出 Schema 强制、**实际工具可用性**由调用参数强制、**盲化**由「输入里压根没有该信息」保证；角色文件可以解释 Skill 和工具的用途，但不能把提示文字当权限或结构门。
4. **正向与负向**：分清哪些部分**帮**角色达成意图（正向：本业纪律、领域边界、知情范围），哪些**妨碍**它（负向：与本业无关的机器约束、诱导照搬输入原文的措辞、让模型惦记评测的暗示）。负向部分删除或移到它该在的层。
> 反例（已纠正）：评测写手提示词曾塞入「你是 Gate A 离线回放的 writer…只输出 candidateBody…不输出哈希/身份…不访问 MCP」，把评测支架混进创作提示词——既没有写作指导，又诱导写手照抄细纲概述句。正解：角色文件保留写作方法、Skill 路由和工具用途；输出格式、实际工具权限、盲化和证据绑定交给中心合同、Schema 与适配器。
### 11.2 Skill（以 `muse/lifecycle/quality/harness/manifests/skills.json` 的 `skill_path` 为准）
分类取值、七个评分维度、必备节清单和严重度定义的 Owner 是 [`muse/lifecycle/quality/harness/specs/skill-quality-rubric.md`](muse/lifecycle/quality/harness/specs/skill-quality-rubric.md)；本节只规定审查怎么进行。**先跑机械门，再人工审**，不得用机械门跑绿代替人工判断：
```bash
.venv/bin/python muse/lifecycle/quality/harness/skill_harness.py --strict # 阻断项与质量发现一并必须为零
.venv/bin/python muse/lifecycle/quality/harness/test_skill_harness.py -q # 审计器回归
```
人工逐条问七个问题，括号内是对应维度：
1. **给谁用**：消费者必须明确、单一——主会话编排、某个角色 agent，还是别的 skill。只能由编排调用的必须声明 `orchestrated`；"不得由 Agent 自行触发"这类禁令写在散文里不算数。
2. **该用时会不会被用上**（D1，只对 `model_routed` 适用）：`description` 是模型唯一的路由依据，必须写清做什么、何时用、何时不用，并对易混的 skill 点名交接。
3. **目的单一**（D2）：一个 skill 只实现一个能力。功能并列、又当编排又当执行的，拆。
4. **边界不重叠**（D3）：显式写出不做什么；集合内不得存在未声明的职责重叠。
5. **合同完整**（D4）：必备节按分类裁剪；`scripts/` 只放运行时确定性实现与机械门，测试归 `tests/skills/`，清单与模板归 `references/`。
6. **可靠性与失败关闭**（D5）：失败明确关闭，不静默降级、不返回假成功；错误带稳定码、不泄漏原文与密钥；确定性步骤真不调模型；走 `.venv`，不裸调 PG/New-API/模型。
7. **机制优先与边界一致**（D6、D7）：能由 frontmatter、schema、adapter 或 `scripts/` 强制的约束不写成散文叮嘱；引用的路径、合同、字段与现行 SoT 一致，引用已失效合同的不得执行；`SKILL.md` 只留执行时必须常驻的内容。
还要问第八个问题——**用过之后系统有没有更强**（D8，`lifecycle ≠ platform` 适用）：本次的方法与观察有没有沉淀成库内可被后续运行消费的资产，还是用完即散。
维度按 `lifecycle`、`invocation`、`side_effects`、`compounding` 裁剪适用范围，具体见评分标准第 3 节，不在本文件重复。
目录名必须等于 frontmatter `name`。执行动作的 Skill 命名采用小写 `动作-对象`，名称表达可调用能力，不复用 `scenario`、内部模块名或含混阶段词；创作方法 Skill 用小写领域名（如 `scene-craft`、`narration-pov`）。`scenario`、`source_type`、updater 和备份逻辑键是独立稳定标识，不随 Skill 改名。
### 11.3 审查产出
每次审查对每个被审对象给出：**面对谁 / 目的**、**逐条问题**（正向资产 + 负向污染，各标严重度）、**具体修改建议**。严重度只取阻断 / 严重 / 一般三级，定义见评分标准第 5 节，不由审查者临场发挥。审查只读、不改代码；修改另起授权，框架改动与创作内容分开提交。
## 12. 框架无关指令体系与去 AI 规范
全仓执行框架无关通用指令集设计，彻底杜绝英文术语混杂与宿主框架绑定。
### 12.1 框架无关指令设计（跨宿主通用）
1. **中立语法**：工具与技能引用一律使用反引号包裹的标准中文单名（如 `` `深模块设计` ``、`` `章级细纲` ``、`` `一致性检测` ``），严禁绑定特定宿主的斜杠命令（`/cmd`）、私有 CLI 标志或绝对物理路径，确保在 Claude、OpenAI、Codex、Pi、DSH 等任意 Agent 环境下均可无缝解析。
2. **纯粹指令语义**：指令文本剔除模糊描述与套话，严格只承担四类要素：**判定条件**（前置断言与阻断）、**执行动词**（明确有序步骤）、**数据契约**（输入输出结构）、**硬性禁止**（绝对红线与终止边界）。详见 [`.agent/规范/指令集规范.md`](.agent/规范/指令集规范.md)。
3. **双轴解耦**：将静态部署（核心底座、交互编排、可选扩展三部分）与动态研发时序（意图 $\rightarrow$ 设计 $\rightarrow$ 编码 $\rightarrow$ 治理 $\rightarrow$ 门禁 $\rightarrow$ 沉淀六阶段，详见 [`.agent/rules/执行流程.md`](.agent/rules/执行流程.md)）彻底解耦，流程不随安装参数或部署环境变形。
### 12.2 全中文单名与上下文隔离
1. **三位一体单名制**：目录名、配置元数据 `name` 与正文自称完全统一为纯中文，杜绝“中文名 + 英文 ID”双轨歧义；智能体角色单名统一为 `写手`、`规划`、`检测`、`裁判`、`抽取`。详见 [`.agent/规范/术语规范.md`](.agent/规范/术语规范.md)。
2. **上下文洁癖**：Agent 运行时只加载纯中文执行正文；来源版本与历史修改记录物理隔离在溯源区，严禁历史元数据占用运行期 Token。
### 12.3 去 AI 味道工程规范
1. **人读文档**：坚决剔除“旨在、值得注意的是、综上所述、全面赋能、深度赋能”等清嗓子套话与假宏大叙事，直陈命令、默认值与失败后果。
2. **Agent 指令（Stop Ladder）**：以 Stop Ladder 决策阶梯与因果关联判据替代空洞说教，严格恪守“做被要求的工作，保留必要后果，其余全部停下”。详见 [`.agent/规范/去AI味道工程规范.md`](.agent/规范/去AI味道工程规范.md) 与 [`.agent/约束/红线约束.md`](.agent/约束/红线约束.md)。
---
<!-- my-skills-cli:begin -->
## 项目 harness

46
docs/2026-08-30-提交前四维审查报告.md Normal file
View File

@ -0,0 +1,46 @@
# 2026-08-30 提交前四维形而上审查报告
> 审查对象：本次「harness 规则与实现差异修复」全量改动（38 文件，+509/−339）。
> 审查方法：按 [`metaphysical-diff-review`](../muse/lifecycle/quality/skills/audit/metaphysical-diff-review/SKILL.md) 四维方法执行。
> **独立性局限声明**：本审查与改动作者同会话执行（当前宿主无子代理派发机制；直调外部模型审查会绕过额度治理红线）。程序与证据标准按技能合同执行，但真正独立的审查应在提交前由全新会话装载该技能复跑一次。
## verdict: PASS
四维全部通过；机械门前置条件满足（全量离线 118 passed + 9 设计内 blocked + 0 failed；`skill_harness --strict` 59 Skill 阻断 0 发现 0；`skills_index --check` 三方一致；architecture 9 文件逐个全绿；`git diff --check` 干净）。
## 1. 逻辑完整性 — PASS
- 三个新硬门（TOOL_NOT_READONLY / MODEL_POLICY_VIOLATION / governed-chain 放行）各有专属测试（`tests/skills/dispatch-agent-task/test_dispatch_agent_task.py` +88 行，28 用例全绿）。
- 删除物无孤儿：`project_paths.py` 删除前验证零引用；`offline_only` 参数 5 处引用全清且无文档残留；`harness/harness/` 仅含 pycache。
- `mismatched_models` 在回执引用前无条件绑定（检查块总是执行）。
- muse.db 清理闭环：删前集合与预期断言相等才执行 → 267MB 文件备份 → 删后计数复核（81/26/6 → 76/0/4）→ 污染源堵漏（`sqlite_path` 三层透传 + 9 处测试隔离）→ 复跑全量测试计数零漂移。
- 反向核对变更说明：Phase 0–3 报告声称的每一项修复均能在 diff 中定位对应 hunk，无凭空声明。
## 2. 一致性 — PASS
- 技能计数三方一致：59 = 15 方法 + 44 编排（AGENTS.md / 两份索引 / skills.json，`skills_index --check` 机械验证）。
- writer 输出契约三层对齐：writer.md 数据契约 ↔ `writer-candidate-body-v1` schema ↔ 角色合同两阶段登记。
- 角色名英文 ID 与 `ROLE_NAMES` / `EXPECTED_ROLES` / 五个提示词 frontmatter 一致（`test_skill_catalog` 绿）。
- SQLite 运行态账本在 AGENTS.md §1、红线 1.1、08 域 §2/§6.1、表映射.md 四处同一口径（不产生 Canonical、冲突以 PG 为准）。
- 检索语义分层明确：PG 面 `canonical_entity`/`draft`，本地面 `local_card`（docstring 声明 + 失败关闭字段），不冒充。
## 3. 合理性 — PASS
- 模型核对置于结构化校验之后（保持输出合同错误优先级），代码注释载明理由。
- provider 前缀剥离（`split("/", 1)[-1]`）与框架 `requested_model_id = provider/model` 构造同构，不引入宽松子串。
- 检索 truthful 化选择失败关闭（`bindingStatus=None`、`productionRetrievalEligible=False`）而非伪造资格，与 `ProductionCardIndexRepository` 的拒绝语义闭环——错误会被大声暴露而不是静默放行。
- web/app.py 按裁决方案 A 登记为本地留痕通道而非删除，保留单机闭环能力，写面闭集由既有 e2e 机械测试固定。
- 审计④后半（judge 输入禁看扫描）经核实判定为误报未实施：正确层（盲评桥 `FORBIDDEN_KEYS` + `_walk_for_leakage` + 组装即校验）已有机械门与测试，在通用派发入口重复扫描会误伤合法字段——不修反而是对的。
## 4. 可行性 — PASS
- 引用存在性：`role_policy.py` 对 `muse_llm`/`muse_role` 的导入路径在派发脚本上下文已建立（role_task 先行导入）；`Mapping` 已在 store.py 导入清单。
- README 门禁命令原样实跑通过（本轮验证记录在案）。
- 生产默认不变：`produce_next_chapter` 等生产入口不传 `sqlite_path`（缺省 data/muse.db 即生产账本），只有测试显式隔离。
- 迁移对账改为关联计数后语义自洽（迁移后新增本地人审不计入、不再误报）。
## 遗留观察（不阻断）
1. `RunDispatchTest` 的临时目录用 `mkdtemp` 未显式清理——测试卫生小项，非本轮范围。
2. 本地 muse.db 检索现在对无内容指针行返回空集（诚实行为）；真实内容检索仍依赖 PG 在线，单机离线检索能力是已登记的目标合同缺口（08 域 §10）。
3. `.agent/skills/_index.md` 经 `--write` 再生成内容零变化（无痕），前一会话对 `.agent/_index.md`/`.agent/目录.md` 的未提交修改保持原样未动。

3
framework/README.md
View File

@ -6,7 +6,8 @@
framework/
├── primitives/ # FrameworkExecutionRequest/Event/Result 与工件工具
├── adapters/pi/ # Pi argv、事件流和显式扩展桥
└── adapters/dsh/ # DSH headless、session JSONL 和通用事件归一
├── adapters/dsh/ # DSH headless、session JSONL 和通用事件归一
└── adapters/claude/ # Claude Code argv 与策略（与 Pi/DSH 同消费 FrameworkExecutionRequest，见 tests/adapters/）
```
Muse 业务侧先解析角色合同、模型策略、冻结输入和输出契约，再把通用执行请求交给端口；框架适配器不直接决定创作流程，也不绕过 Muse 的证据与主权链。全仓技能发现完全由 `AGENTS.md` 与渐进式目录契约驱动，彻底废除对宿主私有目录扫描（如 `.pi/skills`、`.dsh/skills`）的物理投影依赖。

15
muse/authority/db/表映射.md
View File

@ -101,3 +101,18 @@
| DDL | 表 | 用途 | 当前状态 |
|---|---|---|---|
| 96 | example_reference_authorization_snapshot | 参考作品原文件版本对应的不可变用途授权快照；同作品快照版本唯一，禁止 UPDATE/DELETE | **不启用**（单用户本地不做多租户授权，2026-07-30 拍板，见领域索引 §9）；DDL 留存不 apply |
## 本地运行态账本（data/muse.db，SQLite）
2026-08-28 存储裁决起，默认派发与单机工作面的运行态数据落本地单文件 SQLite（`data/muse.db`，gitignore）。它不产生 Canonical，与 PG 正式权威冲突时以 PG 为准（权威层级见 [08-数据权威与可视化领域](../../sot/domains/08-数据权威与可视化领域.md) §2）。schema 变更必须走 `data/migrations/` 版量化新迁移文件；连接统一走 `muse.store.connect`，本仓工作面写函数内聚事务。
| 表 | 迁移来源 | 用途 |
|---|---|---|
| runs | 0001_init | 默认派发运行留痕（kind/input_json/output_text/meta_json/skill_set_hash）；回放取单条同输入重跑 diff；`kind='user_decision'` 行是 PG 决策回填的锚点 |
| events | 0001_init | 运行事件流（run_id+seq，kind/role/tool/payload），append-only |
| reviews | 0001_init | 本地人审动作（adopt/revise/reject，含 reviewer 与理由）；web 工作台写面闭集之一 |
| revisions | 0001_init | 人审改写修订 diff（before/after 文本留痕） |
| cards | 0001_init | 卡片与向量镜像（kind/title/payload_json/embedding blob/work_id/source_path/content_hash）；`kind='embedding'` 行是 PG 嵌入边表指针迁移（draft_id/entity_id），不带正文内容 |
| lessons | 0002_lessons | lesson 本地状态机（proposed→promoted/rejected；source_run_ids/source_review_ids 双证据绑定，DB CHECK 强制非空） |
| snapshots | 0003_snapshots | 冻结快照（kind/payload_json），回放整取 |
| schema_migrations | 迁移框架 | 已应用迁移版本登记 |

24
muse/content/meta/schemas/README.md
View File

@ -10,29 +10,9 @@
- **状态**：23 型均已启用。`generation_context` 已于正文实验台启用；范式五型与参考书档案已于拆书场景（A8）启用并补全字段合同。
- **演进**：增删型或字段先过专题-06 §4.4 的四判据与降级规则；变更靠 git 追溯。
## 实例落点表（哪个型的实例长在哪）
## 实例落点（哪个型的实例长在哪）
| target_type | 实例载体 |
|---|---|
| novel_work | `works/<书>/设定.md` frontmatter |
| work_core | `设定.md` §作品核心 |
| world | `设定.md` §世界观总纲 |
| style | `设定.md` §文风画像 |
| outline | `大纲.md` |
| narrative_state | `状态.md` |
| chapter | `manuscript/第NNN章-*.md` frontmatter |
| scene | 章 frontmatter 的 `场景列表` 数组项 |
| character | `知识/人物/*.md` |
| character_relation | `知识/关系/*.md` |
| location | `知识/地点/*.md` |
| faction | `知识/势力/*.md` |
| power_system | `知识/功法体系/*.md` |
| item | `知识/物品/*.md` |
| event | `知识/事件/*.md` |
| reference_work | `knowledge/参考书/*/档案.md`（原文 txt 同目录） |
| craft / combat / emotion / scene_pattern / trope | 公共面 `knowledge/范式/{技法,打斗,情感,通用桥段,套路}/`；作品面 `知识/` 对应子目录 |
| generation_context | 阶段一以严格 JSON 上下文与 Markdown manifest 回显落 `works/*/评审/`，不建实例文件 |
| pacing | 卷中期节奏审计时使用 |
正式实例一律落 PostgreSQL（`muse-example`）：范式、实体、关系等知识型实例在 `muse_knowledge_draft`（草稿）与 `muse_knowledge_entity`（已确认），结构与字段合同以库内 `muse_meta_schema` 为权威（入库状态见文末）；检索与消费经 search-knowledge 授权面。历史文件形态（`works/<书>/设定.md`、`知识/**.md` 等）是迁移前留痕，不再是实例载体；本地 `data/muse.db` 的 cards 表是卡片与向量的运行态镜像，不是独立权威。
知识卡「值得立卡」的门槛：有跨章戏份或跨章履约；一次性龙套与单场景道具不立卡，写在章内即可。

28
muse/lifecycle/quality/harness/README.md
View File

@ -15,14 +15,18 @@ Harness 负责把这三类工作分开编排并保留证据，不能用其中一
## 2. 目录索引
harness 物理位于 `muse/lifecycle/quality/harness/`：
```text
harness/
muse/lifecycle/quality/harness/
├── README.md # 本入口：项目 harness 介绍、边界和索引
├── specs/
│ ├── skill-testing.md # Skill 测试与评测规范、证据分级
│ └── skill-quality-rubric.md # Skill 分类字段与质量评分标准
├── skill_harness.py # Skill 文档与分类的静态审计入口
├── run_selected.py # 按 manifest 选择性执行测试
├── skills_index.py # 两份技能索引与 skills.json 的对账工具
├── project_paths.py # harness 内共享的项目路径常量
├── test_skill_harness.py # 静态审计器离线测试
├── test_run_selected.py # 选择性执行器离线测试
├── manifests/
@ -33,25 +37,25 @@ harness/
├── test_skill_eval.py # 评测管道自测（不构成 Skill 行为证据）
└── skills/<skill>/ # 逐 Skill 场景与评测入口（真实模型需显式授权）
项目级实现测试位于 `../tests/skills/<skill>/`，不进入运行时 Skill 目录。
项目级实现测试位于 `tests/skills/<skill>/`，不进入运行时 Skill 目录。
```
现有专项支架：
| 路径 | 责任 | 证据边界 |
|---|---|---|
| `humanization/eval/run_eval.py` | 去 AI 味规则合同和回归陷阱试跑 | 规则合同回放，不证明文学效果 |
| `muse/lifecycle/quality/humanization/eval/run_eval.py` | 去 AI 味规则合同和回归陷阱试跑 | 规则合同回放，不证明文学效果 |
| `muse/lifecycle/quality/skills/replay/evaluate-frozen-replay/` | 正文/细纲冻结回放、盲评和质量门 | 评测编排与质量证据，不是通用 Skill 单测入口 |
| `harness/` | 跨 Skill 的开发验证与行为评测治理 | 只编排和裁决证据，不拥有业务合同 |
| `muse/lifecycle/quality/harness/` | 跨 Skill 的开发验证与行为评测治理 | 只编排和裁决证据，不拥有业务合同 |
## 3. 权威关系
- `skills.json` 的 `skill_path` 指向的 `SKILL.md`：Skill 的运行时行为合同；路径允许嵌套，不放开发测试说明。
- `skill_path` 同目录的 `scripts/`：Skill 使用的运行时确定性实现与机械门。
- `tests/skills/<skill>/`：对应 Skill 的实现测试、集成测试和 fake pipeline 测试；测试性质由 harness 清单标注。
- `harness/specs/`：测试、评测与质量评分规范；不被业务 Skill 当作运行时指令读取。
- `harness/manifests/`：测试/评测登记与执行配置；不复制业务字段合同。
- `harness/evals/`：外部行为评测案例、适配器和报告生成逻辑。
- `muse/lifecycle/quality/harness/specs/`：测试、评测与质量评分规范；不被业务 Skill 当作运行时指令读取。
- `muse/lifecycle/quality/harness/manifests/`：测试/评测登记与执行配置；不复制业务字段合同。
- `muse/lifecycle/quality/harness/evals/`：外部行为评测案例、适配器和报告生成逻辑。
- `muse/sot/domains/`：领域与数据权威 SoT；harness 只引用，不复制领域定义。
- `docs/`：单次设计、运行证据和历史资料；不替代 harness 规范。
@ -63,11 +67,13 @@ harness/
```bash
cd agent-example
.venv/bin/python harness/skill_harness.py --strict # 阻断与质量发现必须为零
.venv/bin/python harness/test_skill_harness.py -q # 审计器回归
.venv/bin/python muse/lifecycle/quality/harness/skill_harness.py --strict # 阻断与质量发现必须为零
.venv/bin/python muse/lifecycle/quality/harness/test_skill_harness.py -q # 审计器回归
```
- 全部 47 个 Skill 已按 `lifecycle` / `invocation` / `side_effects` / `compounding` 登记，阻断级问题为零；存量质量发现与复利改造方案见 `docs/2026-08-20-skill-质量审查与复利改造清单.md`。
- `test-inventory.json` 已登记实现测试、集成测试、fake pipeline、领域评测和 harness 自测的依赖与证据等级。
- 全部 59 个 Skill 已按 `lifecycle` / `invocation` / `side_effects` / `compounding` 登记，阻断级问题为零；存量质量发现与复利改造方案见 `docs/2026-08-20-skill-质量审查与复利改造清单.md`。
- `skills_index.py` 以 `--check` 对账两份技能索引与 `skills.json`；索引漂移时退出非零。
- `test-inventory.json` 登记实现测试、集成测试、fake pipeline、领域评测和 harness 自测的依赖与证据等级，磁盘测试资产与登记条目一一对账；新增测试文件必须同步登记，否则 `run_selected.py` 以 `manifest_invalid` 失败关闭。
- `run_selected.py` 已实现显式选择、磁盘/manifest 对账、危险依赖阻断、超时和执行证据检查；它不提供默认全仓一键通过结论。
- 项目运行时 Skill 的实现测试以 `tests/skills/<skill>/` 为目标位置，物理现状以 `test-inventory.json` 为准。
- `skill_behavior_eval` 脚手架已建立：评测引擎、diagnose-ai-flavor 参考场景与管道自测就位；真实模型适配器未授权时以稳定码失败关闭，真实行为评测执行数量仍为 0；没有外部 Agent/模型行为证据时，不声称 Skill 内容有效。

19
muse/lifecycle/quality/harness/specs/skill-quality-rubric.md
View File

@ -16,8 +16,8 @@
| 主题 | Owner |
|---|---|
| 证据分级、测试与行为评测边界、`SKILL.md` 禁止携带的开发测试内容 | [`skill-testing.md`](skill-testing.md) |
| 何时审、谁审、审查产出格式 | [`AGENTS.md`](../../../../../AGENTS.md) 第 11 节 |
| 合同责任方与领域 SoT | `AGENTS.md` 第 3 节与 `muse/sot/domains/` |
| 何时审、谁审、审查产出格式 | [`.agent/规范/审查标准.md`](../../../../../.agent/规范/审查标准.md) |
| 合同责任方与领域 SoT | `muse/sot/domains/` 与 [`创作周期与Skill导读.md`](../../../../sot/创作周期与Skill导读.md) |
| 经验升格链与升格判据 | [06-质量与复利领域](../../../../sot/domains/06-质量与复利领域.md) §6 |
| 范式生命周期与消费合同 | [03-范式领域](../../../../sot/domains/03-范式领域.md) |
| 业务字段合同 | `muse/content/muse/content/meta/schemas/` |
@ -172,7 +172,7 @@
### D7 机制优先
能由 frontmatter、schema、adapter 或 `scripts/` 强制的约束，不该写成散文叮嘱。这是 `AGENTS.md` 第 11.1 节问 3 在 Skill 层的落地。
能由 frontmatter、schema、adapter 或 `scripts/` 强制的约束，不该写成散文叮嘱。这是 [`.agent/规范/审查标准.md`](../../../../../.agent/规范/审查标准.md) §1 问 3 在 Skill 层的落地。
- **2**：所有可机制化的约束都已交给机制，散文只留执行者必须自行判断的部分。
- **1**：存在与机制重复的叮嘱（机制在，散文也反复写）。
@ -244,7 +244,16 @@ D8 不设阻断：接入复利是增量工程，不是正确性缺陷。但 0
明确**不做**跨 Skill 文本相似度检查：本仓 15 个方法 Skill 由 7 本写作书分批蒸馏而来，真重复是改写而非复制（实测跨 Skill 最高 Jaccard 0.223，且全部来自 `_coverage.md` 记账文件）。能命中真重复的阈值一定会被噪声淹没。共享案例范本检查是同一关切的正确工具。同理不设 `references/` 每 Skill 总量预算——那会惩罚"把大块内容外移"这个 D6 本就奖励的行为，只对单文件设上限。
严重与一般级发现记入报告的 `advisories`；默认模式不阻断退出码，**`--strict` 时一并阻断**。存量清零后仓库门禁长期开启 `--strict`（见 `AGENTS.md` §11 与本目录 `README.md`）。
严重与一般级发现记入报告的 `advisories`；默认模式不阻断退出码，**`--strict` 时一并阻断**。存量清零后仓库门禁长期开启 `--strict`（见 [`.agent/规范/审查标准.md`](../../../../../.agent/规范/审查标准.md) 与本目录 `README.md`）。
**已清零检查的直接阻断**：以下四项检查的存量已清零，回归成本只在“别再犯”，因此实现侧（`skill_harness.py` 的 `_BLOCKING_ADVISORY_CODES`）对它们无条件阻断，不等待 `--strict`——留在 advisories 里等于给回归开窗口：
- `dangling_internal_codename`：悬空内部代号；
- `reference_target_missing`：引用目标缺失；
- `orphan_reference_file`：孤儿 references 文件；
- `description_names_unknown_skill`：description 点名未登记技能。
其余严重/一般级检查仍进 advisories，`--strict` 时一并阻断。
## 7. 改动门禁
@ -252,5 +261,5 @@ D8 不设阻断：接入复利是增量工程，不是正确性缺陷。但 0
1. 同步 `muse/lifecycle/quality/harness/manifests/skills.json` 的四个分类字段；
2. 同步 `.agent/skills/_index.md`；
3. 同步 `AGENTS.md` 第 3 节领域表；绑创作 scenario 的同步 `muse/lifecycle/flow/chains/`；
3. 绑创作 scenario 的同步 `muse/lifecycle/flow/chains/`，涉及领域归属时同步对应领域 SoT；
4. 运行 `skill_harness.py`，阻断级问题为零。

11
muse/sot/domains/08-数据权威与可视化领域.md
View File

@ -20,6 +20,8 @@
PostgreSQL（muse-example 库） = 正式内容权威（SoT）
Git = 代码 / Skill / Agent 提示词 / meta（schema 与 chains）/ 文档 / DDL 的权威
+ 这些东西的版本历史与备份
本地 SQLite（data/muse.db） = 运行态账本：默认派发留痕、本地人审、卡片/向量镜像、lesson 本地状态机；
不产生 Canonical，与 PG 冲突时以 PG 为准（表清单见表映射.md）
库内向量索引（pgvector） = 数据库一侧的检索加速，不是独立权威，可从库重建
仓外 vault = 可选备份，不是合同要求
```
@ -27,6 +29,7 @@ Git = 代码 / Skill / Agent 提示词 / meta（schema
- 正式内容都在库里：作品、章、正文、实体、范式、用户决策、运行回执，以及 raw。判断“系统里有没有这个东西”，以库里能不能查到为准。
- Git 不是正式内容权威。它保存让系统能跑起来、能重建的代码和 DDL 及其变更历史；也可以对作品相关信息和作品文本留痕（历史、备份）。但留痕只是痕迹，不是权威——正式内容以库为准，看板只读库，两者冲突时以库为准。
- 向量索引只是加速检索（快速找出相关实体和知识）的手段，删掉或损坏不影响正式内容，能从库里的正文和知识重建。
- 本地 SQLite 运行态账本（2026-08-28 存储裁决）承接默认派发（未显式传 PG 连接工厂时）的 runs/events 留痕、本地人审动作（reviews/revisions）、卡片与向量镜像、lesson 本地状态机和外部反馈数据；schema 变更走 `data/migrations/` 版本化迁移文件。它不产生 Canonical；与 PG 冲突时以 PG 为准。
- 旧主张“Git 文件是正式内容 SoT、数据库是可删除投影、删库零丢失”已作废，全部反过来。
## 3. 一切输入产出落库（机制侧）
@ -53,7 +56,7 @@ Git = 代码 / Skill / Agent 提示词 / meta（schema
- 上表每一类都必须有库内记录；只读看板看不到的，就是没落库。
- 每条记录要能回答“它是谁产生的、针对哪个作品/章/候选、什么时候”。
- 落库写入必须走 `access-database` Skill 这一条数据库通道，不裸连、不散写一次性脚本（见 §9 与 [07-Agent与Skill领域](07-Agent与Skill领域.md)）。
- 落库写入走受控入口：PG 侧统一经 `muse_db.connect`（DSN 锁死 muse-example），各 Skill 的写函数内聚自己的事务与幂等；本地 SQLite 侧统一经 `muse.store.connect`。严禁智能体或一次性脚本裸连直写（见 §9 与 [07-Agent与Skill领域](07-Agent与Skill领域.md)）。
## 4. 写入顺序
@ -92,6 +95,10 @@ raw 指不适合直接当正文、但需要留存可查的完整材料：完整
完整合同（只读硬约束、技术形态、视图清单、raw 访问控制、验收）见 [可视化模块合同](../可视化模块合同.md)，那里是本模块的唯一 SoT，本节不复制。
### 6.1 本地人审工作台（web/app.py）
`web/app.py` 是与 PG 只读看板不同的另一个本地面：它只读 `data/muse.db`，另带三个受控写端点，写面闭集为 `reviews` / `revisions` / `adopt`（机械测试 `tests/e2e/test_compounding.py` 固定该闭集）。它是本地单机草稿人审留痕通道：采纳/修订只落在运行态账本的 reviews/revisions，不产生 Canonical；正式采纳仍走 `decide-candidate` → `write_canonical` 的 PG 注册决策通道。写入口统一为 `muse.flow.adopt.adopt_candidate` 与 `muse.store.add_review`，工作台不自行拼 SQL。
## 7. 运行回执库表合同
每次生成、检测、审核或接受运行，都在库内留下一条回执。旧版“作品内 `runs/` 文件合同”改为库表合同：回执存在库里，不再靠 Git 文件读出。
@ -107,6 +114,7 @@ raw 指不适合直接当正文、但需要留存可查的完整材料：完整
硬要求：
- 本节完整回执合同适用于 PG 侧 `example_run_receipt`（结构化身份回执，字段见上）。本地 SQLite 运行态账本的 `runs` 表是它的最小子合同：run_id、冻结输入 JSON、原始产出文本与 skill 集哈希，支撑同输入重跑 diff 回放；不要求携带本节全部字段。
- 回执写入后**不改写**；新的尝试产生新的记录（不可变账本）。
- 回执字段合同由本领域拥有；作品领域只提供一个在作品下的归档关系，质量领域只消费其中的结果摘要。
- 现有实现里 `record-run-evidence` 的不可改回执（内容寻址账本）与租约 raw 保险库（当前服务评测）即属此合同的落地。
@ -116,6 +124,7 @@ raw 指不适合直接当正文、但需要留存可查的完整材料：完整
数据库是权威，所以可恢复性围绕数据库建立：
- **库结构与数据**：靠数据库备份、快照或 dump 恢复。
- **本地运行态账本**：`data/muse.db` 以文件复制备份——run 前 `cp` 即得数据基线快照，哈希即冻结；误删可由最近副本加 `data/migrations/` 重建 schema 后回填。
- **从零重建**：用 Git 里的代码与 DDL（`muse/authority/db/ddl/` 审计文件）重建库结构，再恢复数据。
- **向量索引**：可从库里的正文与知识重建，不单独备份也不算丢。
- **代码与文档**：靠 Git 历史恢复。

5
muse/sot/创作周期与Skill导读.md
View File

@ -74,7 +74,7 @@
```text
身份段 ← .agent/agents/*.md Agent-facing 身份、Skill 路由和工具提示
角色合同段 ← architecture/角色合同.md 稳定边界、模型策略和失败规则
角色合同段 ← muse/sot/角色合同.md 稳定边界、模型策略和失败规则
功能指令段 ← 一只功能 Skill 的 SKILL.md 由 scenario 决定
L0 任务段 ← assemble-context 组装 本回合参数
```
@ -255,9 +255,12 @@ flowchart TD
| 字段 | 白话 |
|---|---|
| `targetChapter` | 目标章号（定位与冻结基准） |
| `sourceRef` | 来源指针（可回读的冻结原文引用） |
| `chapterGoal` | 本章要完成的戏剧任务 |
| `hardConstraints` | 不可删除、反转、提前回收的硬骨架 |
| `keyEvents` | 触发、参与者、行动、结果方向必须互相解释 |
| `adjustableBeats` | 可调拍：允许写手在约束内自由发挥的节拍 |
| `mustAppearEntities` | 必须出场的实体 |
| `chapterEndHook` | 章末钩子 |
| `declaredNewFacts` | 本章宣告的新事实 |

4
muse/sot/角色合同.md
View File

@ -44,6 +44,10 @@ roles:
派发器必须同时装载：角色身份提示、对应本文件章节、冻结任务输入和本次输出 Schema。`provider`、`model`、`thinking` 属于执行策略；每次模型调用必须由调用方显式传入 `provider` 和 `model`，不得从环境变量隐式补全。本文件是模型策略的事实源；执行侧的常量与校验是该事实的镜像，两者不一致即为缺陷。
角色别名登记（执行侧等价名，与本体同合同）：`blind_judge` ≡ judge（盲评形态，输入经 `FORBIDDEN_KEYS` 防泄漏走查后派发，禁看词汇以盲评桥为登记处）；`semantic_detector` ≡ detector（语义核查形态）。
两阶段写手形态登记：writer 的生产执行形态为“探索→生成”两阶段——探索阶段带任务包只读工具白名单自主取材并产出探索清单（结构化 JSON）；生成阶段零工具、单条回复成稿，输出 `writer-candidate-body-v1`（`{"candidateBody": ...}`）。两阶段共享同一 writer 合同与模型策略，派发实现见 `write-next-chapter/scripts/two_phase_writer.py`。
探索授权按角色差异化：规划、写作、检测、抽取获得任务包声明的只读工具集；评委获得圈定授权（见其章节）。每次工具读取自动进事件账本，形成本次运行的依赖清单；引用材料必须能回指依赖清单。
<!-- role-contract:writer -->