guanlan-src/旧包_补救源_说明.md

旧交付包 · 补救源（本仓唯一入库的 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/。

怎么用它补件（在目标机上）

# 只补"缺失"的件, 绝不覆盖由 data/raw 重算出来的件
<PY> scripts/products_restore_missing.py --stash guanlan-rudong-v2_0.2.0_test_win64.zip --dry-run   # 先看要补什么
<PY> 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/** 等