今天沒有時間操作電腦，因此我把工作拆成兩部分：可以先由程式與自動測試完成的內容，以及必須等明天才能親自設定和驗收的內容。延續昨天的登入改善，今天開始補上真正的共同帳單，讓參與者各自填寫自己的消費。新的資料庫更新檔已準備好，但尚未在 Supabase 執行，所以今天完成的是待接上雲端的程式，不是已經正式啟用的功能。

這次的核心規則很簡單：同一張帳單只記一次總額。假設聚餐花了 901 元，系統保存一張 901 元帳單，再另外保存每位成員的分攤明細。即使有兩個人、三個人分別送出，也不會因此多算幾次支出。這和之前由一個人替所有人登記不同，現在每個登入帳號只需要負責自己的那一份。

我也把共用費用獨立列出，但它仍然包含在帳單總額裡。例如總額 901 元，其中 1 元是共用費用，兩位成員各自填 400 元和 500 元，系統再把那 1 元平均分配的零頭放到固定順序的其中一位身上，最後仍然是 901 元。使用者填的是自己的消費，不需要再把共用費用加進去。這一版的共用費用採平均分配，還沒有比例或權重設定。

共用費用的零頭依成員固定 ID 的排序分配，不依姓名，也不依送出先後。這樣即使有人改名字，或不同人先後操作，分配規則也不會跟著改變。這個排序和舊本機版的成員順序不同，因此介面與文件都有說明。最重要的檢查仍然是整數元與總額守恆，不會因為四捨五入而多出或少掉錢。

每個人填寫後，畫面會顯示已提交人數和目前差額。全員提交且金額完全相符，才顯示「分攤已齊」。零元是有效的份額，但空白代表尚未填寫；超額或不足都不能算完成。這裡的完成只代表分攤資料齊全，還不是已付款，也還沒有提供現金找零或轉帳確認。

權限也是今天的重點。有效成員可以看到共同帳目，但提交份額時，伺服器會從登入身分找到本人，不能相信前端傳來的任意成員 ID。帳本擁有者也不能代替別人填寫。整張帳單只有建立者可以修改或刪除；修改總額、代墊者或參與者後，原分攤會清除，所有參與者需要重新填寫，避免把舊帳單的確認沿用到新的內容。

多人一起使用，還要處理同時修改與網路重試。今天的寫入流程加入版本檢查、請求識別碼和資料庫交易。過期版本的修改會被拒絕，相同請求重送不會多建立一張帳單，而帳單與分攤的更新會一起成功或一起失敗。測試也確認，不能把另一個帳本的成員偷偷混進這張帳單。

同步部分，這次先採用每十秒檢查一次的方式。頁面開著且可見時，會讀取新的帳目資料；沒有正在填寫的內容，就更新清單。如果使用者正在填份額，則保留草稿，提示有新資料，等使用者按「讀取最新資料」並確認數字後再送出。這是定時讀取同步，還不是 WebSocket 即時推送；離線時也不會假裝已經儲存到雲端。

介面方面，今天新增共同帳單的獨立頁面，從共享空間選擇帳本後進入。我也把本機帳本、共享空間與共同帳單頁的基礎樣式整理到同一份檔案，以天空奶霜藍為主要方向，統一主按鈕、卡片、字型、圓角和焦點提示。這讓不同入口開始使用一致的視覺規則，但今天沒有進行真實手機與瀏覽器畫面驗收，因此整體和諧度仍需要明天實際查看。

今天共通過九十五項自動檢查，其中二十三項實際執行嵌入式 PostgreSQL，驗證支出與分攤的資料庫邏輯；六項檢查金額和請求處理，八項模擬新共同帳單頁的操作，其餘是既有登入、共享與本機流程的回歸測試。這些結果支持程式的基本行為，但資料庫測試仍使用替代的登入身分來源，介面測試也是模擬 DOM，不能當成 Supabase 雲端與真實裝置已經驗收成功。

明天需要先在既有 Supabase 專案執行新的 Day 22 SQL，不能重跑 Day 20 的初始建表檔。接著補上昨天「記住我」的實際驗收，再用兩個帳號建立帳單、各自填寫、觀察更新與差額，並補驗邀請撤銷和移除成員權限。現金面額、找零最佳化、真正的跨裝置測試，以及完整視覺驗收仍列為缺項。

今天的進展，是把「希望大家各自填」變成具體的畫面、權限和資料規則。先完成能離線驗證的程式，再把需要本人操作的設定整理清楚，明天就能從確定的步驟接續。預計明天完成的項目仍是計畫，只有實際操作通過後，才會在紀錄中改成完成。