到了第 29 天，我開始整理這個專案要怎麼交到另一個人手上。前面的工作大多在處理功能：帳單怎麼分、現金怎麼填、多人資料怎麼確認，以及畫面怎麼變得容易使用。今天則回到一個很實際的問題：如果明天換一台電腦，或請別人幫忙測試，對方能不能知道要開哪個檔案、哪些功能可以用，以及哪些地方還沒有完成？

我先整理 README。隨著開發天數增加，原本的說明累積了不同時間點的狀態，有些段落仍寫著尚未提供登入，但後面的紀錄其實已經完成共享接線。如果直接交給第一次看專案的人，很容易誤解。因此，今天把首頁說明改成目前功能、啟動方法、操作順序、驗證方式與限制，舊內容另外保存為歷史紀錄。這樣既保留開發過程，也讓目前狀態有清楚的入口。

這次交付的定位是分帳與現金試算的審查候選版。目前已有本機帳本、共享登入與邀請、各自提交消費與現金，以及結算快照。兩人找零和多人交付順序也已經有程式與離線測試，但 Day 25、26 的雲端資料庫更新仍未收到成功回報，真正兩台裝置的完整流程也還需要驗收。雙方付款與收款確認尚未實作，所以不能把它包裝成已經能完成付款的正式版本。

今天也把測試重新跑過一次，17 組全部通過，並保存當日報告。這些檢查涵蓋本機保存、備份、登入狀態、分攤、權限、現金及快照等部分。不過，模擬畫面和嵌入式資料庫無法代替真實使用者的操作。我仍然把不同裝置、登入寄信、手機版面與完整找零流程保留在待驗收清單，沒有因為自動測試通過，就把這些項目一起勾選。

交付過程中，我特別把三種備份分開寫。第一種是專案檔案，包含畫面、程式、資料庫更新檔和操作文件，可以用封存包保存。第二種是瀏覽器裡的本機帳目，必須透過原本網址的匯出功能下載 JSON。第三種是共享資料庫裡的資料，需要另外備份。這三件事不能互相代替：把整個程式資料夾壓縮起來，並不會順便保存朋友填寫的共同帳單。

為了讓程式封存比較容易重做，今天新增了打包工具。它只收錄指定目錄與檔案類型，排除版本控制資料、套件目錄、環境設定檔和根目錄雜項，並為包內檔案產生 SHA-256 清單。完成後會重新讀取壓縮檔，確認檔案完整性和雜湊一致。這讓交付包不只是「有一個 ZIP」，而是有明確內容範圍，也能檢查是否損壞。它仍然只是專案封存，不是使用者資料備份或正式網站。

操作手冊也整理了資料庫更新的先後順序、如何先做唯讀檢查，以及解壓後怎麼啟動網站。還原程式時應先放在新資料夾，不直接覆蓋正在工作的專案。換網址或連接埠後，瀏覽器也可能把它當成另一個網站，因此不能期待原本的本機帳目自動出現；共享登入也可能需要重新驗證。這些看起來細小的事情，實際上都會影響第一次使用是否順利。

今天沒有進行公開部署。上線還需要確定正式網址、確認登入與邀請連結的設定，並補齊目前的雲端更新和真人驗收。雖然原訂 Day 29 包含部署準備，但把尚未確認的流程公開，並不能讓專案真的更完整。因此這次先交付可檢查、可啟動的候選版本，保留清楚的上線缺項。

經過今天的整理，我覺得交付不只是把功能做出來，還包括讓別人知道如何使用、如何驗證，以及遇到問題時可以從哪裡找答案。Day 29 完成了 README、交付與還原手冊、回歸報告和專案封存工具；公開部署、真實資料備份與完整跨裝置驗收仍待完成。最後一天會依照這些證據整理成果，也把尚未完成的工作如實列為後續里程碑。