 Leo
|
89d9b314fb
|
出貨 1.4.20：安裝器釘子 → 8be98b8＋收 daemon 去重的規模測試
釘子：c1566cf → 8be98b8（release 1.4.20，source Arcrun@c7a0b31）
jsDelivr 已驗（用戶端的路，四個檔全 200 且內容逐項對）：
manifest release=1.4.20 core=5 顆（懶載設計保住）
cypher ANALYTICS_KV.put 殘留 0／kbdb empty_reason 5／UI 匯出診斷檔按鈕 1
順帶收 daemon agent 留下的 scan_dedup_scale_test.go（它沙盒推不了）。
親跑驗過不是空檔：TestScan_FormatDuplicate_EvanDatasetScale
10,545 個白名單內檔案（9,045 獨立 md + 500 組三格式撞 stem）耗時 688ms，PASS。
🔴 出貨時抓到兩個「用 staging 覆蓋 prod」的陷阱（已避開，記入 wiki）：
1. rsync --delete 會砍掉 prod 才有的 daemon/（20 個安裝檔）與 README.md
=> 推上去封測者就下載不到 daemon。靠 git status 顯示 D 才抓到。
2. core 陣列會從 5 顆變 24 顆——prod 只裝 5 顆是懶載設計（其他用到才長）。
歷史警察指出 bbb433e 就是修「core 陣列被整個蓋掉」=> 同一個坑有前科，今天差點重演。
共同教訓：staging 與 prod 的內容範圍不一樣，不能整包蓋。
⏸️ 安裝器部署（wrangler deploy --config）被 classifier 擋，等 leo 執行。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-07 23:33:21 +08:00 |
|