CLI 的行為有契約了，最後一個工具問題是：這整包東西出貨時，怎麼證明包裡的就是 repo 裡的？今天的核心主張是：可重現封裝需要一條證據鏈——測試、建置、白名單、checksum，缺一環，「這包沒問題」就只是一句口號。

先解釋「內容相同」與「位元組相同」的差別，這是整篇的軸心。兩個 ZIP 裝著一模一樣的檔案，位元組卻可以不同——壓縮時間戳、檔案順序、權限位都會寫進 ZIP。想讓「同一份源碼建置兩次得到同一個 hash」成立，build.py 得刻意做三件事：固定 ZIP 內的時間戳、排序所有條目、用 SKILL_NAMES 白名單決定什麼能進包——白名單同時是安全機制，私密材料與快取檔案根本沒有入場資格，tests/test_build.py 有專門的測試盯著敏感目錄不得入包，也盯著兩次組裝結果必須一致。

然後是實際執行結果，只列命令與 exit code。2026-08-08：python -m compileall build.py scripts tests skills exit 0；build.py --check exit 0；完整建置跑兩次、中間刪掉 dist/ 重來，兩次 exit 0，兩次產出的 plan-write-blog-series-0.1.0.zip SHA-256 完全相同（21a4e01d…5020）。2026-08-14 換一個乾淨環境、從 repo 重新 clone 再跑一次同樣的流程：同樣的兩個 exit 0，兩次建置的 checksums.sha256 檔案內容逐位元組相同，Skill ZIP 的 SHA-256 仍是 21a4e01d…5020。隔了六天、換了機器、hash 不動——可重現性到這裡才算有第二個獨立資料點，而不是同一台機器自說自話。

誠實註記照列：兩次執行的環境都是 Python 3.11，低於 repo 宣告的 3.12 需求；pytest 兩次都因環境限制未執行。所以以上結果只能當旁證，正式驗證以 CI 為準——那邊是 ubuntu 加 windows 的矩陣、Python 3.12，跑 compileall、pytest 與 build --check 全套。

證據鏈的最後一環是 checksums.sha256：dist/ 裡每個檔案的 SHA-256 清單，讓拿到包的人能逐檔核對。而這條鏈的價值，我手上就有一個反面教材：老闆提供的 pack-0.1.0.zip 與我從 repo 現況建出的 pack-0.1.0.zip，版本字串都是 0.1.0，SHA-256 卻不同。最可能的解釋是兩者來自不同 commit（這是推論），但教訓不需要推論：版本字串證明不了同一性，hash 才可以。這件事 Day 29 出貨核對時還會算總帳。

工具實作階段到此收工：從原始碼到 ZIP，每一步都有 hash 可對——出貨的底氣是算出來的，不是喊出來的。