今天原本打算繼續做共享支出與同步，但實際開始操作後，我發現更需要先處理的是登入體驗。如果每次打開 App 都要重新收驗證碼，即使功能慢慢增加，使用起來仍然會很不方便。因此，我把今天的重點調整為接通真實登入、驗證共享帳本的加入流程，以及讓登入狀態能夠保留下來。原訂的共享支出與同步工作則移到明天接續。

首先，我在 Supabase 建立了開發專案，執行共享帳本與邀請的 SQL，並完成前端公開連線設定。接著設定開發測試用的 Gmail SMTP，希望 App 能真正寄出登入驗證碼。這段過程讓我發現，設定頁顯示儲存成功，只代表設定被接受，並不等於使用者已經收到信，還是需要從實際操作確認整條流程。

一開始按下寄送按鈕時，畫面沒有明顯變化，後來又出現連線失敗。我們透過瀏覽器的 Network 面板觀察，發現沒有出現 otp 請求，問題可能發生在真正發出網路請求之前。檢查程式後，修正了 fetch 被當成物件方法呼叫的方式，避免瀏覽器因呼叫對象不正確而拒絕執行。修正後，畫面終於出現 otp 請求，正式請求也回傳了 HTTP 200。

這次排錯也提醒我，錯誤提示不能全部寫成「連線失敗」。程式原本把不同原因都放在同一種訊息裡，讓使用者容易以為是自己的網路或 SMTP 設定有問題。今天將斷線、等待逾時、非預期回應與寄信請求的伺服器錯誤分開提示，也延長了寄信請求的等待時間。不過，HTTP 200 仍然不等於信件一定到達收件匣，最後還是要確認收信。

收到第一封信時，它是英文的註冊確認連結，並不是我們期待的數字驗證碼。原因是之前只修改了 Magic link or OTP 範本，第一次註冊使用的 Confirm sign up 範本仍維持預設內容。把註冊範本也改成顯示驗證碼後，終於完成真實收信與登入。這讓我更清楚地理解，第一次註冊和之後登入雖然看起來相似，實際上可能走不同的郵件範本。

登入之後，我建立了共享測試帳本，再用同一台電腦的無痕視窗和第二個信箱模擬另一位成員。第二個帳號成功透過邀請加入，回到原帳號並按 App 裡的重新整理，也能看到新成員。這次確認的是兩個獨立帳號能加入同一本帳本，以及成員資料能從伺服器重新讀取；它還不是共享支出的即時同步，也不代表手機跨裝置測試已經完成。

接著測試撤銷邀請時，雖然無法再次加入，但沒有出現預期的撤銷提示，因此這項驗收仍然保留待確認。測試帳號本來就已經是成員，不能只看到沒有增加人數，就認定撤銷機制已完整驗證。後續還需要確認邀請狀態、實際錯誤回應，以及移除成員後是否確實失去存取權限。

操作過程中，我提出了另一個很直接的問題：為什麼每次重新打開都要驗證一次？目前版本只把登入狀態存在當前頁面的記憶體，重新整理或離開頁面就會失去登入。於是今天優先加入「記住我」：勾選時將登入狀態保存在目前瀏覽器；取消勾選時則使用分頁儲存，讓同分頁重新整理和往返頁面時仍能恢復。共用電腦使用完畢，仍應主動登出。

除了保存狀態，也加入了登入憑證的自動更新。程式會在需要時使用 refresh token 取得新的登入憑證，避免只因短期憑證到期就再次要求使用者收信。遇到暫時斷線或伺服器錯誤時，保留登入紀錄以便重試；授權失效時才清除並要求重新驗證。這些登入資料和帳本備份分開保存，不會放進匯出的 JSON 帳本。

今天這次登入改善通過十一項登入生命週期測試、十九項 client 測試與九項模擬共享介面測試，合計三十九項。它們涵蓋保存、恢復、憑證更新、登出清除，以及離線時保留登入狀態等情境。但自動測試仍不能取代實際瀏覽器操作；今天尚未完成升級後重新登入，再按 F5 確認恢復登入的驗收，也還沒有實際等到憑證輪替來驗證整條更新流程。

今天先做到這裡。第 21 天完成的是登入流程排錯、真實雙帳號加入驗證、登入持續保存程式與這篇文章。明天預計先完成登入恢復、登出及邀請權限驗收，再接續原訂的共享支出、同步與各自填寫功能，同時整理本機與共享空間的介面一致性。這些是明天的目標，尚未算入今天完成的成果。

這一天讓我感受到，讓 App 好用，不只是讓功能增加，也包括減少使用者反覆操作的次數。先把登入這條每天都會經過的流程做好，朋友才更容易真正開始使用這個共同帳本。