1.9 KiB
1.9 KiB
文件版本管理纪律（2026-07-01 总结多次返工教训）
铁律：操作前备份，操作后验证，不覆盖不重做
1. 操作前必须备份
任何对 docx 文件的修改操作前，先 cp 一份到 /tmp/contract-backup/ 并带时间戳：
cp /tmp/反委托_版本1.docx /tmp/contract-backup/反委托_版本1_$(date +%H%M).docx
2026-07-01教训：反委托代发工资协议做了7-8个版本，每次覆盖前一版，最终华诚-Z的修订痕迹差点不可恢复（在v1_doro_updated.docx中找到最后一份）。
2. 增量修复，不从头重做
出问题时修补当前版本，不从原文件重新做一遍。重做=覆盖=丢失中间状态。
3. 操作后验证完整性
每次修改 docx 后必须验证：
- comments.xml：批注数量、作者、ID 是否完整（与修改前对比）
- document.xml：tracked changes 的 author 集合是否正确
- 文件大小：是否合理（不应比修改前小太多）
4. 中间版本命名规范
反委托_版本1_v1.docx → 第一版
反委托_版本1_v2.docx → 第二版（不覆盖v1）
反委托_版本1_v3.docx → 第三版
反委托_版本1_final.docx → 确认后的最终版（覆盖上传到Nextcloud）
5. Subagent 输出必须验证
delegate_task 返回后：
- 检查 result.status 是否 "completed"
- 对文件类结果：用 zipfile 打开验证 comments/tracked changes 完整性
- 不能假设 subagent 正确——它可能丢批注、改错 author、漏条款
常见覆盖事故
| 事故 | 根因 | 预防 |
|---|---|---|
| 华诚-Z修订被全部改成WB | 多次重做时每次都"统一author=WB" | 备份原始含华诚-Z的版本 |
| 批注丢失（4条变2条） | 从头重建时没对比原文件的comments.xml | 修改后立即验证批注数量 |
| 字体覆盖（仿宋_GB2312→仿宋） | 重做时用了错误的字体名 | 从原文件克隆rPr，不手写 |