# 旧交付包 · 补救源(本仓唯一入库的 zip,用户令 2026-09-17) | 项 | 值 | |---|---| | 文件 | `guanlan-rudong-v2_0.2.0_test_win64.zip`(仓库根目录) | | 大小 | 943.2 MiB(989,018,413 B) | | SHA256 | `3a2c31270834ba5d8c6b375d989c876b863ff7be3473e2d2f2cb8b6b50e58f19` | | 版本 | 观澜·如东样板 v2 **0.2.0**(打包日 2026-09-09)——**含产物**的旧版交付包 | | 入库令 | 用户令 2026-09-17:「把旧包纳入 git 管理以作备份」 | ## 为什么留下它(它是唯一来源) 包里 `outputs/rudong/**` 有 **586 件产物**,其中 **567 件是"包内没有生成端"的那批**——全库只有读取方、 0 处写入方(`docs/系统设计说明.md` §7)。按现行交付口径: * **交付包默认不含产物**(§9,用户令 2026-09-17); * **「清除产物」= 真删除、不留备份**(用户令 2026-09-16)。 两条叠加 ⇒ 一旦在目标机上清了产物,这批东西**没有任何来源可补**。本 zip 就是唯一的补件源。 2026-09-17 实测:控制台清产物后,用它一次补齐 **567 件**(补齐件与包内**逐字节相同** 538 件), 其中 39 件是构建日志,已按 §11.2 归位到 `logs/build/`。 ## 怎么用它补件(在目标机上) ```powershell # 只补"缺失"的件, 绝不覆盖由 data/raw 重算出来的件 scripts/products_restore_missing.py --stash guanlan-rudong-v2_0.2.0_test_win64.zip --dry-run # 先看要补什么 scripts/products_restore_missing.py --stash guanlan-rudong-v2_0.2.0_test_win64.zip # 真补, 并写来源台账 ``` 补完后 `outputs/<场>/_provenance.json` 会把它们记为 `shipped`(包内无生成端、用随包件补齐), `inventory_products.py --check` 应回到 rc=0。 ## 关于"入库"的代价(如实写,别假装没有) * 这个 blob 已压缩(zip),git 不能再压 ⇒ 仓库对象从 ~57 MB 涨到 ~1 GB,**每次 clone/换机拷仓都带着它**, 且**无法在保留历史的前提下删掉**(要么 `git filter-repo` 重写历史)。 * 因此本仓只保留**这一个**归档 zip:`.gitignore` 已加 `*.zip`(已跟踪的这个文件不受影响), 避免以后每打一次交付包就往仓库里塞一份。 * 它**不会进交付包**:`scripts/pack_dist.py` 对**顶层 `*.zip`** 有排除规则(避免包中包), `pack.bat dry` 可复核。 * 更省空间的替代方案(如果以后觉得太重):只把 `outputs/rudong/**` 那 567 件解出来入库 (未压缩 0.23 GB,多为可压缩的 json/md),代码部分由 git 历史承担。当前按用户令整包入库。 ## 与当前产物的差异(2026-09-17 逐件比对,详见 §13.5 与第 3 问答复) | 类别 | 数量 | 说明 | |---|---|---| | 两边都有 · 逐字节相同 | 538 | 补齐自本包的随包件与原包一致 | | 两边都有 · 不同 | 9 | `workorders` 旧 1,652 行 → 现 **5,876 行**(本次重算更全);`oil_samples_index` 旧 506 → 现 **404**(缺 2026-07 华标批 102 行,源 PDF 不在现场包);`alarms`/`temp_monthly`/`curve_lenses`/`stop_events`/`thermal_chain` 行数一致仅编码差;`objects.json`/`retrieval_index.json` 随本体重建而变 | | 只在旧包有 | 39 | 全是构建日志(`*_build.log`、`shared_component_*.log`)——按日志口径已归位 `logs/build/` | | 只在当前有 | 1,709 | 本次重算新出:振动窗谱库 `windows/w0316/**` 等 |