报告版本管理
分析与鉴定报告会经历多轮修改，版本管理要解决的是「交出去的到底是哪一版」。通行做法是 v1.0 为初稿、v1.1 为小幅修正、v2.0 为影响结论的重大变更，并配套修订记录表登记版本号、日期、变更摘要与修订人。
基本信息
| 版本规则 | v1.0 初稿、v1.1 修正、v2.0 重大变更 |
|---|---|
| 登记内容 | 版本号、日期、变更摘要、修订人 |
| 呈现位置 | 报告首页或附录的修订记录表 |
| 分发规则 | 草稿分发也要带版本号与草稿标识 |
| 冻结方式 | 对交付件计算哈希并与版本号绑定 |
| 一致性 | 版本号、文件哈希与移交记录三者对应 |
典型使用场景
- 交付前确认拿出的就是最新签发版本
- 变更后说明与上一版的差异
- 出现争议时回溯每一版的改动与责任人
- 多人协作时避免互相覆盖版本
- 与哈希清单绑定，确认对方收到的文件未被替换
最小示例
最小示例
sha256sum report-v2.0.pdf | tee report-v2.0.pdf.sha256 # 交付件固化哈希
ls -l --time-style=long-iso /case/2026-001/deliverables/ # 交付目录清单
# 修订记录表示例（写入报告附录）
# v1.0 2026-01-05 初稿（张三）
# v1.1 2026-01-06 修正时间偏移 3.4s 为 3.2s（李四）
# v2.0 2026-01-09 增加数据恢复结果章节（张三）修订记录要素
| 要素 | 说明 | 要求 |
|---|---|---|
| 版本号 | 标识修订层级 | 同一版本号不得重复使用 |
| 日期 | 修订完成日期 | 与文档内时间表述一致 |
| 变更摘要 | 改动了什么 | 写清章节与是否影响结论 |
| 修订人 | 责任人 | 便于回溯与追责 |
| 文件哈希 | 该版本的 sha256 | 与交付与移交记录绑定 |
交付时只认签发版本；草稿即使内容一致也要标注状态，避免对方引用未定稿的结论。
文件名建议与版本号统一，例如 report-v2.0.pdf，避免使用最终版、定稿版这类没有顺序含义的名称。
已交付并冻结的版本不得原地修改；任何改动都要升版本并重新计算哈希，否则哈希清单与交付件不再对应。