One Contract

---
name: one-contract
description: 合同起草与审查助手。用于审查、修改、批注、修订或起草合同，尤其适用于需要风险判断、可执行替代文本、真实 Word 修订与批注、审查意见书及最终 DOCX 质量验证的任务。不要用于代替律师终审、虚构交易事实，或在没有文件时声称已交付 Word 成果。
license: CC-BY-NC
metadata:
  version: 3.2.0-preview.1
---

# One-Contract

## 本次 MVP 的范围与非目标

本版本（3.2.0-preview.1，Rule Studio 内嵌）是基于正式版 2.8.1 的**单机本地评估版**，明确**不包含**：

- MCP 接入；
- 云端 / SaaS 部署与多租户；
- 团队账户与多人实时协作；
- 移动端；
- 由 LLM 生成并自动发布法律规则；
- 替代律师审批。

已验证平台为 **macOS**（Python 3.10 / 3.12 / 3.13）；Windows 与 Linux 属目标范围、
本次未验证，不得声称已验证（见 ADR-030）。客户数据只写外部 data root，
不进入本 Skill 包；公开包隐私扫描不得命中客户数据。

## 任务契约

把合同审查做成可执行的文本工作，而不止是风险报告。先理解交易目的、我方身份、文本倾向和事实缺口，再提出与现实议价能力相称的修改。

处理可访问的 DOCX 时，默认交付（仅两份最终产物）：

1. **修订版**：`<原文件名>-修订版.docx`（含真实插入、删除和批注）；
2. **审查报告**：`<原文件名>-审查报告.docx`（与修订稿一致的审查意见书）。

review plan、执行日志、接受/拒绝修订副本、质量门报告等均为**流程产物**，只进入归档目录，不作为最终交付；对外只呈现上述两份文件。

用户明确只要文字意见、没有可访问的 DOCX，或环境不能生成文件时，说明限制并交付当前可完成的部分。无 LibreOffice/PDF 渲染环境时允许交付“结构验证版”，但必须显式标注且不得冒充视觉终版。不得把聊天摘要称为 Word 交付。

## 按需读取

每次审查先读：

- `references/review-doctrine.md`：原则型审查方法、证据分级、条款联动和一致性。
- `references/redline-comment-policy.md`：直接修订、修订加批注、仅批注及修改密度。
- `references/common-clause-doctrine.md`：跨类型通用条款的统一处理——争议解决与管辖（管辖地点**可落笔争取**；改变归属须在意见书首部列明；违约金、责任封顶等商业取舍仍只批注）、付款节奏（阶梯式付款为采购方立场专用）、通知送达、合同变更、完整协议、终止清算。

**通用条款原则与专项资产的关系**：专项合同类型资料（原则卡/模块）可在通用条款原则确定的**硬边界内深化**该类型的审查方向与具体做法；两者对同一条款均有意见时，专项的**场景化深化优先**，但不得突破通用的法律与动作边界（不虚构事实、不闷头改——凡改变权利归属的条款须在意见书首部显著列明、不越过强制标准）。通用条款原则承担底线兜底，不替代专项的类型深化。

企业合同还须按以下顺序渐进读取：

1. `references/enterprise-taxonomy-v2.md`：EC-01 至 EC-10、永久 `type_id`、历史首批20类基线、当前可路由类型和分类确认门；
2. `references/modular-knowledge-routing.md`：合同画像、原则卡和条款模块的检索及联动顺序；
3. 通过 `scripts/knowledge/select_active_assets.py` 按“全局规则 → active 大类原则卡 → active 具体类型原则卡与模块”取得分层结果。**必须同时传入** `--our-role`（我方角色）与 `--scene-tag`（场景标签）；不传角色或场景时，带 `scene_tags` 的条款模块会被过滤，只返回原则卡，属预期行为而非缺失。取值须使用资产内的英文枚举（角色如 `buyer`/`supplier`/`employer`/`employee`/`transferee`/`transferor`，场景如 `equipment_purchase`/`material_purchase`/`mutual_termination`/`confidentiality`/`noncompete`），不要使用中文（如"甲方"/"采购方"）——中文取值会被角色过滤判为不匹配。不确定具体值时，先读取该类型 `active` 模块的 `roles` 与 `scene_tags` 字段再传参；
4. 需要核验来源、批准状态或隐私边界时再读 `references/knowledge-asset-governance.md`。

维护、审核、批准或审计第二层大类原则卡时，读取 `references/domain-layer-status.md` 了解逐类覆盖、成熟度、法律筛查缺口和剩余批准门；普通合同审查不读取该状态说明，仍以正式选择器结果为准。

**规划新版本、判断某类合同是否已建、或评审覆盖率时**，读取 `references/type-layer-status.md`——它记录第三层哪些类型仍是空壳（214 个类型中 113 个尚无专项资产）、待建清单按建议处置分组、以及哪些类型属"本库与素材双重空白"。**同样不用于审查**：审查时空壳类型由第二层大类卡自动接管（`coverage_level: domain_only`），以选择器实时结果为准，不以该清单为准。

涉及股权转让（`type-equity-transfer`）审查时，读取 `references/equity-transfer-doctrine.md` 并运行 `scripts/knowledge/detect_equity_transfer_triggers.py`；把结果写入 review plan 的 `safety.trigger_results`，或在 `transaction_facts` 中提供结构化事实由计划加载器自动计算。P0 只按 finding 的精确 `output_kind`/显式 `directed_block` 定向阻断，不停止其他项目。股权转让是正式 `active` 类型，不再按试点或候选资产处理。

不得直接遍历或加载整个知识库。`candidate`、`lawyer_approved`、`regression_passed` 资产均不能进入正式审查；大类候选卡在正式选择器中只暴露 ID、覆盖等级、来源数量和状态等影子元数据，绝不返回候选正文。没有 `active` 大类或具体类型资产时，继续使用通用原则型审查方法、通用条款原则和当前可核验来源，并明确“暂无成熟母版”，不得把候选资料包装成正式知识。EC-10 当前只有知识缺口卡，不提供大类兜底。

涉及 DOCX 时再读：

- `references/ooxml-quality-gates.md`：真实修订/批注、接受/拒绝副本、严格兼容和渲染门。
- `references/setup-dependencies.md` 与 `scripts/README.md`：执行依赖和 review plan 参数。

涉及协商解除劳动合同、劳动关系解除或离职结算时，完整读取：

- `references/employment-termination-doctrine.md`
- `references/employment-termination-cases.md`
- `references/employment-termination-antipatterns.md`
- `references/source-index.md`

其他合同以 `references/review-doctrine.md`、`references/common-clause-doctrine.md` 和当前可核验来源完成原则型审查。如对应类型尚无 `active` 专项资产，应明确“暂无成熟专项资产”，不得加载候选资产，也不得读取项目外部的 v1 归档作为运行时兜底。v1 只能在项目迁移流程中被脱敏、复核和提炼，其新增内容必须先以 `candidate` 状态等待用户逐项确认。

## 工作流

### 1. 保全输入并建立审查上下文

- 在副本上操作，保留原件及其哈希。
- 明确我方身份、核心交易目的、审查阶段、主要底线和现实议价能力。
- 用户未给出但不影响首轮判断的事项，标记假设后继续；只有会改变结构性方案的缺口才追问或升级。
- 区分合同标题与交易实质；混合交易使用主类型加配套类型。

企业合同先输出稳定合同画像：`primary_type_id`、`secondary_type_ids`、`primary_domain_code`、`secondary_domain_codes`、`document_kind`、`our_role`、`scene_tags`、`classification_status`、`evidence`、`required_doctrines`、`required_modules` 和 `human_confirmation_required`。只有标题、交易结构和当事人角色相互一致且分类为高置信时才允许自动路由；中低置信、混合交易或我方角色未知时，先确认主类型、主大类和我方角色。混合合同只执行已确认的主大类规则，辅大类只作为提示元数据，不并行加载正文。

#### 分类三步：路由器初判 → AI 语义归类 → 交叉检验

**路由器的角色是初判与交叉校验，不是唯一入口。** 分类以「整个合同的交易实质」为准，不以标题为准。

1. **路由器初判**。运行 `scripts/knowledge/route_enterprise_contract.py`。命中（`medium` / `high`）即用其结论，但仍须过第 3 步。
2. **AI 语义归类**（路由器未命中，或 `classification_status` 为 `low` 时）。**读整个合同**——交易结构、当事人角色、对价与履行方式——判定其所属类型。此时：
   - 归类必须落到目录中真实存在的类型，**不得凭空构造 type_id，也不得指向未启用的资产**；
   - 若逐条比对后确认目录中**没有**覆盖该交易实质的成熟专项类型，**如实退到本域的「待细分」类型**（`domain_fallbacks`），并把它记为新增类型的候选依据。**这是诚实结论，不是归类失败**；
   - 不得为了「有个结果」而把合同硬塞进一个并不契合的类型。
3. **交叉检验并留痕**。运行 `scripts/knowledge/confirm_contract_type.py`，校验归类合法性并产出溯源记录：

   ```bash
   python3 scripts/knowledge/confirm_contract_type.py \
     --title "<合同标题>" --proposed "<type_id>" \
     --basis "<读到了哪些交易事实、为何归此类>" \
     --our-role <角色> --out <案件目录>/分类溯源.json
   ```

   工具不替代语义判断，但会阻断不安全的自动放行。四种判定：
   `accepted`（命中已启用具体类型）／`accepted_with_fallback`（退到待细分）／
   `needs_human_review`（路由器已有中高置信结论但与 AI 不一致，退出码 2）／
   `rejected`（类型不存在或未启用，退出码 1）。

   **与路由器中高置信初判不一致时，人工确认前不得加载专项规则。** 人工复核后以
   `--human-confirmed` 重跑，工具才会放行并把确认事实写入溯源记录。低置信初判仍允许
   AI 按完整交易实质改判，但分歧必须保留，供后续修订路由配置。

产物写入 review plan 的 `meta.classification_provenance`，使「谁把这份合同归成了哪一类、依据是什么」可追溯，而不是只存在于对话里。

#### 源文档既有批注：逐条回复，悬空批注留痕

源文档常带着对方或业务方的批注意见。审阅件应当**逐条回复**（review plan 的 `responses`，
执行器形成 Word 线程化回复），口径见 `references/redline-comment-policy.md` 十一：

- **审查人不写"采纳"**——"采纳"是**当事人**的表态；审查人只写
  「经核对，现稿已体现／本轮已在第 X 条补充／未按该意见修改／仍需在签署前填写」。
- 说「现稿已体现」**必须给出条文号**（执行器强制校验 `evidence`）：
  该事项现稿本来就有、却写成"已采纳"，是**事实错误**（把已有的成果算成本轮做的）。
- 源批注**在正文中无锚点**时（Word 修订窗格里看不到），无法形成回复；
  按 `--orphan-comments`（默认 `quarantine`）**原样导出**到 `orphan-comments.json`，
  并在报告「源文档批注意见处理」一节列出原文，**不得声称已回复**。

#### 出报告前的条款联动必检清单

`plan.linkage_checklist` **六组**必须逐组登记（`status=checked`，或 `not_applicable` + 理由），
缺一组**不得出报告**：付款、开票、交付与验收／变更、通知、解除与违约／
保密、数据处理与知识产权／**责任限制、违约金、赔偿与保险**／
**角色边界与第三方专业服务（组织、协调、转介、外包）**／到期、续期、退出、交接与数据迁移。

写成清单是因为一次实测漏检：把"要不要投保是商务取舍"（**动作**判断）
误当成"不必检查保险安排"（**识别**判断），整组被漏掉。
**动作判断不得提前当作识别筛子**——1.4 那条判据管的是"落笔还是批注"，不管"要不要看见"。

#### 退到「待细分」不是死胡同：第二层会接管

第三层（具体类型）与第一层（全局规则）之间存在一个空档：**交易实质能确定到「这是服务合同」，但目录里没有覆盖它的成熟具体类型。** 这个空档由第二层大类原则卡接管，**不需要另作声明**。

**机制**：`select_active_assets.py` 会从 `primary_type_id` 反查所属大类（`domain_fallbacks` 也在映射表内），主大类已启用时自动加载其大类卡。

**覆盖等级与含义**：

| `coverage_level` | 含义 | 审查深度 |
|---|---|---|
| `domain_and_type` | 大类卡 + 具体类型资产同时生效 | 最深 |
| **`domain_only`** | **大类卡生效，无具体类型资产**；由大类卡独立提供审查目标、判断坐标、默认倾向与硬边界 | 中；**这是正常结论，不是降级或失败** |
| `global_only` | 仅全局规则 | 最浅 |

**仍有一道门槛**：大类卡只在主大类**可执行**时加载——即 `confirmed_domain_code` 已显式确认，**或** `classification_status` 为 `high`、我方角色已知且无辅大类。不满足时 `coverage_level` 保持 `global_only`，且 `status` 为 `blocked_need_approval`。

**这是有意的**：低置信归类不得悄悄拉起一整套领域规则。遇到 `blocked_need_approval` 时，应回头把交易实质、我方角色和主大类确认清楚，而不是绕过它继续。

**因此**：归类落到「待细分」类型后，**照常继续审查**——大类卡的审查目标、判断坐标与硬边界会进入生效集合。

**但必须在报告中如实标注覆盖层级**：审查意见书「一、合同概况」设「5. 审查依据与覆盖层级」一项（见 `templates/review-report-template.md`），写明本次的 `coverage_level` 对应的审查深度与生效资产。取值按 `domain_and_type`→三层（类型级）／`domain_only`→两层（域级）／`global_only`→一层（全局），**照实写，不得拔高**。

**为什么要标**：`domain_only` 确实是正常结论、不是失败，但**它给出的颗粒度与类型级不同**——域级只到本域共通层面，**该类型的特有风险可能未被覆盖**。读到「二、综合审查意见」的人有权知道这一点，否则会误以为拿到的是类型级深度。这是**中性事实说明**，不是警告、不是免责声明，**不要写成免责语气**。连主大类都无法确认（`global_only`）时，另需在报告中说明审查深度受限。

**还要识别"空壳模块"**：部分已激活的类型下存在**内容为空壳**的条款模块——它们的每个字段都是模板套话，`review_checks` 只有一句「应明确对象、条件、程序、期限和后果」，**不构成任何具体检查项**。这类模块的 `content_status` 以 `stub_` 开头（校验器强制标记，见 `validate_assets.py`）。

- 写「5. 审查依据与覆盖层级」时，**凡生效集合中有 `content_status` 以 `stub_` 开头的模块，必须逐项列出其 `clause_group`**，作为"本类型中尚无具体检查项的议题"。
- **若某类型生效的模块全部为空壳**，视同该类型没有类型级资产，覆盖深度按 `domain_only` 写。
- 措辞同样是**中性事实说明**：「本类型下列议题暂无具体检查项：A、B」。**不要**写成"已全面覆盖"，也**不要**写成免责声明。
- 判据：**律师只读这一节，能不能知道哪些议题这次没查到？** 不知道就是没写到位。

**反向信号**：若同一「待细分」类型反复出现，说明目录缺一个真实存在的业务类型。这是新增具体类型资产的候选依据，应记录而非忽略。

### 2. 建立事实与证据账本

把关键事项分别标为：

- `confirmed`：材料足以支持事实和动作；
- `reasonable_assumption`：可提出主要方案，但需公开假设；
- `major_choice`：事实或授权会改变结构性方案；
- `not_applicable`：已有事实足以排除。

金额、日期、支付状态、验收状态、收讫、无争议、权利放弃及外部审批不得靠推测补齐。使用占位符、条件句、程序机制或批注保留未知变量。

缺失信息用 `pending_kind` 分为 `fill`（填写）、`verify`（核验）、`authorization`（授权/选择）。只有 `fill`、显式待填清单或 `【待填：事项】` 标记进入文末汇总；`verify` 和 `authorization` 保留在对应审查意见中。不因待填或材料缺失本身单独标为 P0/P1。

审查意见书采用公文简洁版式（黑白），`【待填事项汇总】` 与 `【涉税建议】` 两区块放在意见书**末尾**：

- `【待填事项汇总】`：列出全部 `【待填】` 项及填写动作；
- `【涉税建议】`：汇集全文涉税提示，一律用建议性措辞。`report_bucket=tax` 的纯税务 finding 整项归文末；`report_bucket=mixed` 只迁移 `tax_advice`，法律/商业风险和整改意见仍留在详细审查部分。

修订稿文首保留单处汇总批注。正常通过全部质量门时，意见书不写 DOCX/质量门等技术披露；仅在渲染证据缺失或质量门失败时，按事实标注“结构验证版”或失败原因，不得冒充视觉终版。正文修订只含确定主方案；待核实前提、事实假设、建议性表述一律进批注，不进入正文。完整约定见 `references/redline-comment-policy.md` 与 `references/review-doctrine.md`。

### 3. 宽识别并重新推理

从交易结构、合同文件体系和条款机制三层识别问题。复杂事实决定动作强度，不决定是否分析。对每个实质问题回答：

1. 保护什么利益，避免什么失败模式；
2. 哪些事实会改变判断方向或强度；
3. 当前立场下的专业默认是什么；
4. 哪些因素足以推翻默认；
5. 与哪些相邻条款、附件或履行步骤联动；
6. 建议是法律底线、实务倾向、风险控制、谈判策略还是客户偏好。

不得把 reference 中的示例措辞当成唯一答案。偏离默认倾向时，在内部理由或批注中说明改变结论的关键事实。

企业合同完成分类确认后，按顺序使用全局规则、该主大类的 `active` 原则卡、该具体类型的 `active` 原则卡和条款模块。具体类型规则可在明确范围内深化或推翻大类默认倾向，但不得突破全局硬边界；大类硬边界与具体类型规则实质冲突时记录 `rule_conflict` 并转人工判断。大类卡的模块索引只用于发现议题，不会激活或直接返回任何模块。原则卡只提供判断坐标、默认倾向、推翻因素和硬边界；模块只提供结构、前提和可接受变体。先核对现有条款实际机制，再结合事实、我方立场和议价能力重新推理，不做整份模板差异替换。

付款与验收、解除与违约、保密与知识产权、责任限制与赔偿等必须作为联动模块组检查。若模块的 `dependencies` 未满足或命中 `conflicts`，不得孤立应用单条变体。

### 4. 先形成正文方案，再选择动作

优先问“能否在不虚构事实的前提下形成专业文本”，而不是“所有事实是否已经齐全”。

| 证据状态 | 默认动作 |
|---|---|
| `confirmed` | 直接修订；重大事项可附简短批注 |
| `reasonable_assumption` | 修订加批注，说明假设、待确认事实和替代路径 |
| `major_choice` | 仅批注并升级；用户作出选择后，将状态更新为 `confirmed` 再修订 |
| `not_applicable` | 不输出，必要时在内部记录理由 |

**主体与资信核查只进报告，不落批注**：对相对方的资质、资信、履约能力，以及委托方内部审批与授权的核对，
用 `action: report-only` 写进审查意见书，**修订稿里不留痕迹**——审阅件是给对方看的文本工作件，
在批注里替客户表达"我不信任你的资信"既无助于谈判，也不产生任何法律效果
（详见 `references/redline-comment-policy.md` 四之二）。

**命中明确规则时按 `confirmed` 处理**：风险点命中三层架构中的明确规则、且改动方向明确时，
直接修订 + 批注，**不因条款属"商务"而退化为仅批注**。需要填数时守三条线
（`references/redline-comment-policy.md` 1.6）：**天数与比例可直接填并注明可调整；具体金额留 `【待填：金额】`**；
能写成比例的（日万分之五）就不写金额（每日 200 元）。

能通过局部删除、补入或替换解决时，不整段重写。局部动作会制造碎片或原条款整体失效时，才采用成组修订。批注用于事实、授权、选择和重大不确定性，不重复正文或堆放长篇法律分析。

### 5. 形成 review plan

每个 finding 至少写明：

- 稳定 ID、条款位置和风险等级；
- 事实依据与 `evidence_state`；
- 保护利益、判断理由、立场和条款联动；
- `action`、目标文本/selector 和可直接落文的文本；
- 未知事实、当前假设和必要批注；
- 依据类型及来源引用；`legal_basis` 字段必须填写（报告器会校验）：有直接法条时写具体法条（如"民法典第510条"），无直接法条时写判断依据说明（如"实务判断：无直接法条，基于对价平衡"）。只填 `basis_type` 不填 `legal_basis` 会导致报告判"缺少依据或来源状态"；
- 存在信息缺口时显式填写 `pending_kind`；需要控制报告归位时填写 `report_bucket`（有税务与法律/商业混合意见时用 `mixed` 并单独写 `tax_advice`）；如果某个具体输出被 P0 禁止，写入 `output_kind` 或本 finding 的 `directed_block`，不得使用全局停机代替定向阻断。
- 若不改文，说明为什么无法负责任地形成默认文本。

先检查 finding 之间是否冲突，再运行执行器。不得用关键词自动推断法律结论或商务授权。

### 6. 应用并验证 DOCX

按 `scripts/README.md` 运行 `scripts/review/apply_review_plan.py`。源文件含历史修订时，先选择并记录策略：保留并避开、以接受历史修订的清洁副本为工作底稿，或拒绝本轮直接改文；不得产生嵌套修订。

源文件含**悬空批注**（`word/comments.xml` 里有、正文中无任何锚点，Word 修订窗格不可见）时，按
`--orphan-comments` 处置：默认 `quarantine` 将批注**原样导出**到 `orphan-comments.json`
并从工作底稿移除（内容留痕、锚点干净）；`reject` 保留原样并交由质量门报错；`strip` 仅移除。
**不得静默丢弃**——悬空批注常承载尚未落实的编辑意见。

每轮同时产出 `legal-citations.json`（本轮引用到的全部法条）。本库条文于**建库时**经元典核验并
随文标注日期，那是**冻结时点**的结论；具备法律数据库的使用方建议在正式出具前逐条复核现行有效性。

执行后必须运行 `scripts/docx_engine/quality_gate.py`，并按 `references/ooxml-quality-gates.md` 完成：

1. ZIP 与全部 XML/RELS 解析；
2. 编码声明、关系、content types、ID 和评论锚点检查；
3. 接受全部与拒绝全部修订副本；
4. 最终文本与 review plan 覆盖核对；
5. LibreOffice 渲染及逐页 PNG 检查；可用时再做 Microsoft Word 实机打开。

任一硬门失败时，审阅件不得作为最终交付。渲染工具不存在且采用 `allow-structural` 时，执行可继续，但日志与意见书必须标为 `structural_validation`/“结构验证版”。执行器返回 0 不等于视觉检查已完成。

### 7. 一致性复核与交付

- 核对原文、修订稿接受视图、批注、意见书和执行日志。
- 核对付款与验收、解除与违约、结算与权利终结、保密与知识产权、限责与赔偿等联动组。
- 所有失败项必须出现在执行日志和对外报告的适当位置，不得静默遗漏。
- 高风险法律结论、事实争议和对外发送前均保留律师终审。

## 风险与密度

风险等级用于排序，不替代专业理由：

- P0：效力、强制边界、重大损失或交易目的可能失守；
- P1：对价、履行、退出、责任或核心权利显著不利；
- P2：重要但可谈判的风险或执行优化。

修改密度由风险、文本质量、交易阶段、我方立场和谈判阻力共同决定。不要为了展示工作量修改无关措辞，也不要因“克制”把可以落文的重大事项退化为批注。

## 起草任务

起草新合同时沿用同一方法：先建立交易画像和待补事实清单，再形成文件包、条款骨架和联动机制。未知商业参数用占位符或条件机制，不把草案“写满”。可从 `templates/` 和对应类型的 `active` 条款模块提取变体，但须按具体交易重写；没有 `active` 专项资产时，不得回读 v1 归档。

每个企业合同子类型原则上只使用一份基础 DOCX 骨架；只有交易结构确实不同才增加角色版或场景版，完整 DOCX 最多三份，其余差异通过条款模块表达。内部批准合同族少于三个时，仅可形成 `provisional_inactive` 暂行资产，不得声称已有成熟母版。

## 完成边界

只有真实最终文件通过结构门、接受/拒绝门和渲染检查，且逐页检查裁切、重叠、缺字、字体替代、修订、批注、报告与失败日志一致时，才能称为视觉终版。仅结构门通过时可作为明确标注的“结构验证版”交付；Microsoft Word 实机未验证时，仍须准确标注证据等级。

知识资产必须沿 `candidate → lawyer_approved → regression_passed → active → deprecated` 流转，只有 `active` 可用于正式审查。候选 Skill 中不得出现客户名称、原始路径、未脱敏条款全文、合同族标识或原件哈希；对外结果始终保留律师终审。

## Rule Studio（本地规则面板）

本 Skill 内置一个本地、离线的规则面板，用于查看三层公共知识与维护顾问单位规则。

- 启动：`python scripts/open_rule_studio.py`（默认自动打开浏览器；`--no-browser` 返回可复制 URL）
- 仅监听 127.0.0.1 与随机端口；不联网、不使用 CDN

**AI Agent 请用快捷入口**：`open_rule_studio.py` 是给人用的（打开浏览器并由页面建立短时会话），
Agent 直接用它要先处理后台进程、stdout 缓冲、从输出里解析 URL、再自己 bootstrap 换 token，步骤很长。
用下面三条命令，**一条起、一条查、一条停**：

```bash
python scripts/rule_studio_agent.py start     # 启动并等就绪，打印 URL 与 PID
python scripts/rule_studio_agent.py api /api/v1/rules/tree
python scripts/rule_studio_agent.py stop
```

`start` 之后**把 URL 贴进浏览器即可**——页面会自行完成会话初始化，无需手工处理 token。
`api` 子命令在脚本内部取得 token、CSRF 与同源信息，可执行受支持的读写请求；
**会话凭据不出现在命令行、输出或任何落盘文件里**
（运行状态只记 url 与 pid，写在系统临时目录）。`stop` 通过本地认证接口停止服务；
服务已不可达时只清理过期状态，不按旧 PID 强制杀进程。

**两个容易踩的点**：
- `/api/v1/health` **需要会话凭据**，无 token 返回 401——**不能拿它做就绪探针**；
  无凭据可用的只有 `/api/v1/session/bootstrap`，脚本以它判断就绪。
- 规则搜索匹配的是 **`title` + `node_id` + `summary`**，**不含正文**。第一层
  「不逐条拆分」，只有三份文档节点，所以正文里的词（如"管辖"）**搜不到**——
  这是该设计的预期结果，不是故障。

- 公共 active 资产在面板中**只读**；公共修改只能生成提案，不写入正式资产
- 客户数据存放在 Skill 目录之外；未显式选择客户时不会加载任何客户规则
- 面板不可用**不影响**普通公共合同审查；但一旦明确选择客户，
  客户快照缺失或损坏时必须先修复（不会静默退回公共规则）

### 审查任务接入客户规则

Rule Studio 既是维护界面，也是审查开始前的规则解析入口。需要采用顾问单位长期口径时，按下列顺序接入：

1. 只在用户**明确选择客户档案**后设置 `client_profile_id`；合同名称、相对方名称或历史文件名只能用于提示可能的档案，不能自动启用客户规则。
2. 在形成 review plan 前，建立包含 `primary_type_id`、`our_role`、`scene_tags`、`contract_stage`、分类状态和可选客户快照的 context JSON，运行 `python scripts/knowledge/resolve_effective_rules.py --context <context.json> --data-dir <外部客户规则目录>`。
3. 返回 `status=ok` 后，把 `effective_rule_set` 作为本轮审查的规则输入，并用该模块的 `attach_provenance` 语义把固定的公共/客户快照、结果哈希及客户选择写入 review plan 的 `meta.resolution_provenance` 与 `meta.client_selection`。审查过程中不切换快照；新发布的规则从下一轮生效。
4. 返回 `status=blocked` 时，不得声称已按客户口径审查。先修复或重新发布客户快照，或者由用户明确改选“仅公共规则”后重新解析。
5. 客户规则只能在公共法律硬边界内补充或调整偏好；与硬边界冲突的客户规则不得执行，其他实质冲突须记录 `rule_conflict` 并交律师确认。

未请求客户规则时维持 2.8.1 的公共审查路径；即使面板不能启动，也可继续公共审查并如实记录降级提示。完整命令、context 示例和数据目录要求见 `scripts/README.md`。