# 已交付合同批量质检方法 (2026-07-13)

## 触发条件
Doro要求"逐一审查已交付合同的修订有哪些问题"

## 方法

### 准备
1. 读通用 review-rules.md + 对应顾问单位特殊规则——**每次都tool call读取，不凭记忆**
2. 确认哪些是今天交付的（按任务交付目录文件的mtime筛选）
3. 一份一份做，pass一份再做下一份

### numPr断裂检查（2026-07-13 消防设施检测案教训，最易遗漏）
新增WB INS段落如果插在auto-numbered序列（原文段落有numPr）中，必须有相同numPr：
- 检查原文被插入位置前后段落是否有numPr
- 如果有（如numId=4, ilvl=0），新增段落也必须有同一numPr
- `add_clause`默认strip numPr（A类设计），在B类自动编号段落中会导致编号断裂
- **修法**：手动用zipfile+lxml克隆邻近段落的pPr（含numPr）给新增段落

### 独立段落 vs 合并到现有条款的判断
当新增内容插在有手动编号（1、2、3、）的章节中时：
- 新内容与前一条**主题紧密相关**（如数据归属+保密）→ 合并到前一条末尾，不独立编号
- 新内容是**独立主题**→ 编号为下一个序号
- 这是审查者应当自行判断的专业决定，不问Doro

### 字体修复的per-paragraph策略
同一合同中不同段落可能有不同的字体继承模式：
- 段落A: `ascii=宋体, hAnsi=宋体, cs=宋体, sz=24`（显式设置）
- 段落B: 完全无rFonts（靠docDefaults继承）
**不能全局统一处理**——必须逐段对比orig run属性，INS run匹配同段orig run

### 每份合同检查项

#### A0. 完整性检查（先于内容审查）
- **必须同时检查** tracked changes + comments.xml + footers/headers
- 用 `zipfile` 读 `word/comments.xml` 提取所有批注数量和内容
- 段落文本100%相同 ≠ 文件完全相同（可能有批注但无修订）
- 2026-07-13教训：v2被误判为"与原文完全相同"，实际有6条WB批注。python-docx的`.text`不反映批注内容

#### A. 检测重复处理
待审查文件是否已有WB修订？如果有，交付版是否产生了重复文字/重复INS。

#### B. 修订内容 vs 审查清单（10条逐条对照）
1. 主体条款：名称是否正确、是否直接改了不批注
2. 违约责任：是否有维权费用（律师费、诉讼费、保全费）
3. 争议解决：是否甲方所在地法院
4. 保密/数据：数据归属+保密存续+泄露责任
5. 知识产权：成果归甲方+终止后继续使用
6. 第三方侵权：乙方全责+全额赔偿甲方
7. 转包/分包：限制条款
8. 价款条款：金额不一致是否批注
9. 服务成果持续使用权
10. 条款逻辑

#### C. 批注合规检查
- 每个WB批注逐条对照规则：
  - 是否涉及商业条款？（日期/期限/金额/支付方式/频率/天数 → 不应有）
  - 是否能直接修订？（能改就改不批注）
  - 是否有【】标签或理由解释？（禁止）
  - 是否有"建议考虑""请考虑是否"等模糊措辞？（禁止）

#### D. 格式检查
- INS run的rPr与同段原文run逐属性对比（sz/rFonts/bold）
- 新增章节标题格式是否与原文章节标题一致
- 新增正文段落pPr（ind/spacing/numPr）是否与原文同类型段落一致
- 单段正文不加numPr（"有2才有1"规则）

#### E. 交叉引用/编号
- 新增条款后原文编号是否顺延
- 接受修订后无重复编号/无跳号

### 报告格式
每份合同列出：
- 问题1/2/3...（严重/中等/轻微）
- 格式是否OK
- 是否需要修复

### 铁律
- 先查文件再说话（不凭印象判断）
- 一份做完确认后再做下一份
- 修复时从待审查原文出发，不在被污染的交付版上修