4.3 KiB
4.3 KiB
Workflow交付件逐份审查检查清单 (2026-07-13 Doro要求)
触发条件
Doro说"逐一审查已交付合同的修订有哪些问题"或类似指令。
操作流程
- 全文阅读通用review-rules.md + 对应顾问单位特殊规则
- 列出今天交付的全部文件（
sudo find ... -newermt） - 一份一份审查，报告问题，等Doro说pass再做下一份
每份检查项
A0. 文件完整性（先于内容）
zipfile读word/comments.xml看有无批注- 统计
w:ins/w:del数量确认有修订痕迹 - 如果有多版本（v1/v2），每个都要独立检查性质
A. 格式验证
wb-ins-font-verify.py— 必须PASS- 原文同段run属性 vs INS run属性逐一比对
- 新增段落pPr（ind/spacing/numPr）vs原文邻近段落
B. 审查清单覆盖（10条逐条）
- 主体条款
- 违约责任（含赔偿上限删除、维权费用）
- 争议解决/管辖（甲方所在地法院）
- 保密/数据（归属+存续+泄露赔偿 三要素）
- 知识产权/系统
- 第三方侵权（全责+赔偿甲方损失）
- 转包/分包（限制+连带）
- 价款条款
- 服务成果持续使用权（仅持续性服务适用）
- 条款逻辑
C. 同模板一致性
- 同批同模板合同的修订是否完全统一
- 特别检查：编号顺延方式、章节结构、措辞、天数
D. 特殊交付物
- 读该顾问单位review-rules.md确认是否要求审查意见文档
- 缺失则标记
E. 批注审查
- 每条WB批注逐一比对规则
- 立场是否正确（站甲方）
- 是否违反"能改就不批注"
- 是否属于提醒性批注（禁止）
报告格式
## 【修】合同名称
**字体验证：** PASS/FAIL
**修订内容：** 逐条列出WB INS/DEL
**问题：**
1. [严重/一般] 具体问题描述
2. ...
**结论：** pass建议/需修复
F. 编号顺延完整性（2026-07-13 璞石合同教训）
- 章节标题编号顺延后（如七→八），子编号也必须顺延（7.1→8.1, 7.2→8.2...）
- Workflow常见遗漏：只改了章节标题的汉字编号（第七条→第八条），但内部子条款的阿拉伯数字编号（7.1/7.2/7.3/7.4）原封不动
- 检查方法：accepted text中搜索所有"X.Y"格式编号，确认X与所属章节标题的序号一致
- 修复方法：子编号通常拆为两个run（如"7" + ".1 "），只需DEL第一个run("7")+INS新数字("8")
G. 内容去重（2026-07-13 璞石合同教训）
- 新增的保密存续条款是否与原文已有的类似表述重复
- 典型：原文已有"乙方的保密义务不因合同解除或终止而免除"，WB又插入"本条保密义务不因本合同的终止或解除而终止"——语义完全重复
H. 赔偿上限全面检查（2026-07-13 璞石合同教训）
- 规则"赔偿上限能删就删"不仅适用于乙方赔偿甲方的上限
- 双向条款中的上限也要删：如"任何一方违约，违约金额为合同总金额的20%"——此上限同时限制了甲方可获赔偿
- P43甲方自身违约金上限保留是正确的（保护甲方），但P49双向上限应删除
- 判断方法：上限是否限制了对方向甲方赔偿？是→删；上限是否限制了甲方向对方赔偿？是→保留
I. 新增标题段落样式（2026-07-13 璞石合同教训）
- WB新增的章节标题段（如"第七条 转包与分包"）的pStyle必须与原文标题段一致
- 原文标题用Heading4→新增也用Heading4，不能用Style15（正文首行缩进）
- 标题文字中"第X条"与名称之间是否有空格？原文无空格（"第六条违约责任"）则新增也不加空格
J. 原文已有修订保持不动
- 对照原文确认：WB-1/86187/杨丽/富强等原文修订人的INS/DEL/批注是否全部原样保留
- WB的修改不能意外覆盖或嵌套进原文修订
- P29金额"27900"的sz=22是原文86187的修订→不是workflow问题
铁律
- 先tool call读文件再下结论（验证指令铁律）
- 不凭上一份的印象判断下一份
- comments.xml必须检查（2026-07-13教训）
- 原文自带【修】前缀的文件：按命名规则应为【修】【修】...，workflow通常不做双重前缀——记录为已知缺陷
- Doro说"看清楚前后文再回复"：意思是你漏了问题或误判了严重性，必须重新逐属性检查