今天先把前幾天累積的手動驗收補上。用同一台電腦的兩個帳號，實際走過登入、共同帳單、現金確認、邀請撤銷與成員恢復。這次也遇到一個容易誤會的地方：瀏覽器重新整理會清掉未儲存的草稿，但 App 裡的「讀取最新資料」會保留草稿。當有草稿時，系統先提示有新資料，讓使用者自己決定何時更新。這些實測讓我更清楚，功能正確之外，提示的位置和文字也必須容易理解。

完成這一輪驗收後，今天開始處理結算前的共同確認。以前每個人提交份額，只代表各自把數字填完；有人修改帳單、現金或成員後，其他人之前看過的內容就可能不再是同一版。如果直接拿這些資料計算找零，大家以為確認的是同一件事，實際上卻可能看到不同的金額。因此 Day 24 的重點，是讓所有人確認同一版資料，再保存不可被覆寫的結算快照。

新的「一起確認結算」頁面放在共同帳單入口旁。所有帳單必須分攤已齊，每位目前仍在帳本裡的成員也必須先確認自己的現金，才能進行本版確認。没有帶現金的人仍可填零並確認，沒有填寫的人則不能被當作零元。接著每位成員各自確認；只有全員確認同一版資料後，擁有者才能按下鎖定快照。

這裡的鎖定，是保存那一刻的資料，不是禁止大家繼續修改帳本。系統以帳目、成員與現金版本組合成版本識別，確認與快照都綁定該版本。一旦有人修改資料，舊確認就不再適用，舊快照也會顯示失效。即使金額改回相同數字，版本已經改變，仍需要重新確認。目前採保守規則，邀請管理若增加帳本版本，也會要求重新確認。

快照內包含後續找零需要的現金資料，但存放在私人資料表，不會把所有人的錢包傳回瀏覽器。成員看到的是共同帳目、各人的確認狀態，以及快照是否有效。擁有者擁有鎖定操作權限，也不能藉此查看別人的現金面額。未加入或已被移除的帳號不能讀取確認頁或建立快照。

伺服器會在同一筆交易中核對目前版本、資料是否備齊、全員是否確認以及操作人的權限。若有人在另一個頁面先修改了資料，舊版本確認會被拒絕，使用者需要讀取最新狀態並重新核對。重送同一個鎖定請求不會多建立一份快照；相同版本用新的請求重試，也會取得同一份快照。若舊版本已失效，重播舊請求也不能把它說成仍可使用。

今天通過 41 項嵌入式 PostgreSQL 檢查，其中包含先前現金與恢復成員的回歸案例，以及 15 項 Day 24 檢查。另外 6 項新頁面模擬介面檢查與 8 項共同帳單回歸檢查也通過，共 55 項。這些驗證涵蓋資料未齊不能確認、全員未確認不能鎖定、一般成員無法鎖定、現金與帳目修改後失效，以及私人資料不可直接讀取。模擬測試不等於真實瀏覽器與 Supabase 上雲驗收。

付款狀態今天只建立「尚未開始」的基礎模型。鎖定快照不等於轉帳成功，也沒有現金找零演算法或付款按鈕。後面的工作會以有效快照作為計算依據，再加入找零方案與實際付款流程。Day 24 程式、測試與文章已完成，但新的 SQL 尚待手動套用，雙帳號確認與失效流程仍待實測。這樣記錄進度，才能讓下一天接手時知道哪些已經驗證，哪些還需要完成。