昨天把共同帳單拆成每個人各自提交，今天繼續處理另一個聚餐時常見的問題：大家帶的現金面額不一樣。有人帶一千元，有人只有幾張一百元，也有人帶了很多零錢。即使算出誰應該付多少，現場還是可能卡在「我沒有剛好的錢」。因此今天先完成現金資料的輸入與確認，為後續找零計算準備可靠的資料。

這次增加獨立的「我的現金」頁面，從共同帳單就能進入。頁面提供 1000、500、100、50、10、5、1 元七種面額，使用者填寫的是每種紙鈔或硬幣的數量，系統會換算自己的現金總額。例如一張一千元、兩張一百元、一枚五十元與三枚十元，合計就是 1280 元。介面延續目前的淡藍、奶油白與圓角卡片，讓現金輸入保持單一用途；實際手機畫面的視覺驗收仍留待明天。

我特別把「還沒填」和「沒有現金」分開。剛開啟頁面時，各欄保持空白，不會替使用者假設全部是零。如果真的沒有帶現金，可以按「沒有現金，全部填 0」，但仍要自己按儲存。數量只能是 0 到 9999 的整數，空白、負數、小數和不完整的面額資料都不能送出。這樣後面的計算才不會把漏填誤認為真的沒有錢。

儲存與確認也分成兩步。儲存代表資料已記錄，確認代表本人檢查過目前的數量；確認並不等於付款，也不是最終結算。只要重新儲存修改，原本的確認就會取消，需要再次確認。如果另一個分頁已更新資料，舊版本不能直接覆蓋新版本，畫面會保留目前草稿並顯示錯誤，讓使用者自行決定如何重新讀取。

現金比一般的帳單明細更私密，所以其他成員只會看到是否已確認，不會看到別人的現金總額或各面額數量。這個限制也適用於帳本管理者，不能因為建立了帳本就代填或讀取別人的錢包。後端會依登入身分取得本人資料，私人資料表也沒有開放一般使用者直接讀取。服務管理端仍具有資料管理權限，這不是端對端加密。

今天的驗證包含 18 項嵌入式 PostgreSQL 檢查、4 項現金核心檢查及 7 項模擬介面檢查，共 29 項新增檢查通過，另外 8 項共同帳單介面回歸檢查也通過。內容涵蓋零元和未填的差異、輸入限制、重送保護、版本衝突、管理者不能冒充別人，以及成員被移除後無法讀寫。這些測試提供程式與 SQL 行為的證據，但不能取代 Supabase 雲端與真實雙帳號操作。

今天因為無法操作電腦，完成範圍是程式、離線測試與文章。Day 22 和 Day 23 的新 SQL 還沒有套用到雲端，記住登入、邀請撤銷、共同帳單及現金頁的實際驗收也仍有缺項，已排到 2026 年 10 月 8 日。接下來會先補齊這些前置驗證，再處理結算快照與找零方案；今天尚未實作找零演算法，也不會把未驗收的部分提前寫成完成。