hermes-skills/skills/legal/contract-reviewer/references/delivered-contract-audit-workflow.md

已交付合同审查工作流（Doro要求逐份复核）

2026-07-13 实战确立

当Doro要求"逐一审查已交付合同，告诉我有什么问题"时，执行以下流程。

触发条件

• Doro说"重新审查"/"逐份检查"/"没说pass的都要重新审查"
• 发现workflow出错率高需要全面复核

流程（每份合同严格按顺序）

Step 0: 读规则

必须先读review-rules.md（通用+顾问单位特殊规则），不凭记忆。

Step 1: 获取原文

从Nextcloud待审查目录取原始文件（.doc需libreoffice转.docx）。

Step 2: 获取交付物

从Nextcloud任务交付目录取【修】文件。

Step 3: 格式对比（原文 vs 交付物）

必须做，不可跳过：

1. 原文run属性基线：读原文P4等代表性段落的run rPr（eastAsia/ascii/hint/sz各是什么）
2. 交付物同段落orig run属性：读交付物中相同段落的orig run rPr
3. 比对是否被污染：ContractEditor已知会给orig runs添加eastAsia/cs/sz属性
   • 原文: ascii=宋体, hint=eastAsia, szCs=21（NO eastAsia, NO sz）
   • 被污染后: ascii=宋体, hint=eastAsia, eastAsia=宋体, cs=宋体, sz=21（多了3个属性）
   • 后果：原文字号从继承docDefaults变成显式值，可能导致整体缩小0.5pt
4. INS run属性检查：wb-ins-font-verify.py 跑一遍
5. 关键区分：
   • "MISMATCH" = 真实问题（INS与orig不一致）
   • "MISSING HINT (无同段原文可比)" = 整段INS新增段落的脚本已知限制，非真实问题

Step 4: 内容覆盖核查

逐条对照review-rules.md审查清单（10项）打勾：

• 规则4（保密/数据）必须同时有：存续 + 泄露赔偿 + 数据归属
• 规则7（转包）必须有：限制 + 连带责任
• 同模板合同必须一致（修订方案、编号、措辞完全统一）

Step 5: 编号检查（最易遗漏！）

新增独立段落的编号问题是最高频错误：

1. 有numPr的序列中插入新段落：新段落必须加入相同numId序列，否则编号断裂
2. 手动文本编号序列中插入新段落：新段落必须带编号前缀（如"4.9""7.6"），或合并到前一条末尾
3. 判断方法：查看前后段落是否有编号（numPr或run文字中的"X.X"格式），有则新段也必须有

Step 6: 特殊交付物检查

• 朱家角：是否有【审】审查意见文档
• 练塘：footer是否有"法律顾问修订版"

Step 7: 文件命名检查

• "【修】+ 原文件名一字不动"
• 原文自带【修】前缀时，交付物名应为"【修】【修】..."

报告格式

## 【修】合同名称

字体：PASS/FAIL
编号：OK/问题描述

修订内容：（列出所有WB changes）

审查清单：
✅/❌ 1. 主体
✅/❌ 2. 违约
...

问题：
1. xxx
2. xxx

铁律（2026-07-13 Doro多次纠正）

1. "查清楚再说"：任何结论必须基于tool call读文件的结果，不凭之前输出的印象。被Doro说"你看文件去不是让你瞎说"就是违反了这条
2. 不要遗漏：先前说"无问题"后被Doro追问"编号没问题吗？"→ 说明审查不够仔细。每份合同必须完整过完所有检查项
3. 一份一份：Doro说pass再做下一份，不要批量报告
4. 发现问题就修：Doro说"按照workflow的规则，手动修改"时直接修，不要再问

常见遗漏清单（每份必检）

• 新增INS段落是否有编号（numPr或手动文本编号）
• 保密条款是否三要素齐全（存续+泄露赔偿+数据归属）
• 原文run属性是否被ContractEditor污染
• 同模板合同是否一致
• 特殊交付物（审查意见/脚注）是否齐全
• 文件命名是否正确