成本收益算完，結論是這套東西值得交出去——那就進入出貨程序。出貨前的最後一關只問一個問題：讀者拿到的套件，跟他看到的原始碼，真的是同一版嗎？今天的核心主張是：「同一版」不是宣稱，是核對出來的結果；版本字串證明不了它，hash 才可以。

以下是 2026-08-14 的實際核對紀錄，含所有失敗與差異，如實列出。

第一項，Release 狀態：查 GitHub Releases 頁面，結果是沒有任何 Release。這是第三次得到同樣結果，前兩次分別是 2026-08-04 的 gh release list 空清單與 2026-08-08 的頁面查詢。結論照舊：手上任何 pack-0.1.0.zip 都不得稱為「最新 Release」，因為 Release 根本還不存在——出貨的第一步是承認貨架還是空的。

第二項，建置可重現性：從公開 repo 重新 clone，同一環境完整建置兩次，中間刪除 dist/ 重來，兩次 exit 0，兩次產出的 checksums.sha256 內容逐位元組相同，單一 Skill ZIP 的 SHA-256 是 21a4e01d…5020——與 2026-08-08 在另一次執行取得的值完全相同。Day 17 講過的固定時戳與排序，隔了六天在另一次獨立執行裡兌現了。附帶差異揭露：本次建置環境是 Python 3.11，低於 repo 宣告的 3.12 需求；pytest 因環境限制未執行。這兩條不影響 hash 比對本身，但影響「正式驗證」的宣稱資格，所以列在這裡。

第三項，也是最有教育意義的一項——版本字串對決。老闆最初提供的 pack-0.1.0.zip，SHA-256 是 313e14…；今天從 repo 現況（commit 0966f3d6）建出來的 pack-0.1.0.zip，SHA-256 是 e13719…。兩個檔案，同名，版本字串都寫 0.1.0，位元組不同。差異範圍可以再收斂一格：把兩者拆開比對 Skill 指示本體，來源清冊裡登錄的 SKILL.md SHA-256 是 12b22188…，與今天建置產物中的 SKILL.md 完全一致——所以差異不在 SKILL.md，最可能落在打包時機或整合層的檔案上，而「最可能」三個字表示這仍是推論，不是結論。但教訓不需要推論：如果 Day 30 我告訴讀者「去拿 0.1.0 就對了」，他拿到的可能是這兩包的任何一包，而我連自己都分不出來。版本字串是給人看的名牌，hash 才是身分證。

所以完整的出貨核對清單長這樣：repo 當日狀態與預設分支、Release 存在與否、VERSION 檔內容、兩次建置的 hash 比對、checksums.sha256 逐檔核對、套件頂層結構與源碼逐項對照——本次已執行的項目與結果記錄在工作報告，未完成的（Release 發布本身）明白寫著未完成。

出貨關卡的精神跟這個系列一路的精神是同一個：可以有缺口，不可以有裝作沒有缺口。貨還沒上架，但清單已經誠實——這一關，過了。