昨天處理的是兩人付款與找零，今天把範圍推進到多人現金交付。多人分帳最容易忽略的地方，是最後每個人拿到的金額正確，不代表每一步都做得到。若某一步需要的零錢還在別人手上，就不能提前拿來付款。因此今天的目標，是找到可以逐步執行的順序，而且每一步都符合當時的庫存。

新功能沿用昨天鎖定的有效快照，先以代墊金額減去分攤金額，得到每個人的應收應付。只有兩個非零淨額時仍使用 Day 25 的兩人求解；多人情況再進入 Day 26 的搜尋。每次計算都重新检查帳本成員資格和快照版本，不能拿已失效的資料繼續安排交付。

多人演算法把所有人的現金分布視為一個狀態。從目前狀態出發，嘗試把一張紙鈔或一枚硬幣交給另一位成員，交出者的庫存減一，接收者加一。只有交出者當時真的持有該面額，這個步驟才成立。接著再探索新的狀態，直到每個人的現金增減都符合應收應付。收到的錢可以在後續使用，不能在還沒收到之前使用。

例如三人之間需要中繼交付時，「A 給 B 五十元，再由 B 給 C 五十元」的順序可行，但若 B 原本沒有現金，倒過來就不成立。測試會重播每個步驟，確認沒有負庫存，並檢查最後每個人的現金變化等於目標淨額。求解器也允許直接交給最終收款人，並不是每次都需要中繼，真正的判斷依據是當下庫存和最終金額是否正確。

為了控制伺服器負擔，這版先支援最多四位有效成員、合計十二張紙鈔或硬幣，以及最多三千個狀態。這個範圍對日常零錢多的情境仍偏小，是目前明確的限制。超過人數、庫存或狀態上限，都會顯示搜尋未完成，不會把尚未找完說成沒有辦法付款。只有完整遍歷支援範圍仍無方案，或已能證明某人的現金總額不足，才回報無解。

找到方案時也不直接稱作最佳。今天每一步以一張或一枚為搜尋單位，沒有完整最佳化多人交付次數，更沒有保證將多張現金合併後仍是最佳。因此介面寫的是「已找到可行順序」，而不是最少次數。Day 25 在兩人條件下的最佳化仍保留，兩種結果的保證範圍不混在一起。

隱私也延續先前設計。完整錢包只留在後端計算，不回傳到每個人的瀏覽器。每位使用者只看到與自己有關步驟的交出者、接收者和面額；其他步驟顯示等待。大家使用相同快照與固定搜尋順序，可以依相同的步驟編號協調。不過這仍是試算，尚未提供付款完成回報或同步勾選，所以不能同時跳步執行，也不能以畫面有方案就認定款項已交付。

今天通過十項求解器檢查、六十項 SQL 整合與回歸檢查、十三項結算及找零模擬介面檢查、八項共同帳單回歸檢查，共九十一項。內容涵蓋逐步庫存、反向重播被拒、三人小庫存的各種目標分配、庫存無解、搜尋上限、固定結果、快照失效與身分權限。這些仍是離線資料庫及模擬介面測試，不能取代手機、平板和雲端操作。

今天同時整理了之前的介面調整與平板連線紀錄：同 Wi-Fi 的區域網路網址及新版 QR Code 已由使用者確認能在平板開啟，但妹妹是否完成登入加入、找零功能是否通過跨裝置驗收，還沒有回報。Day 25 SQL 也尚未收到成功執行的回覆，因此接續清單會保留先套用 Day 25、再套用 Day 26 的順序。完成程式和文章之後，下一步才是上雲與真人驗收，而不是把所有待辦提前勾選。