
店家專區、代點餐、儲值方式、訂單統計都已經有自己的畫面。功能越來越多後,真正難的問題反而變簡單:
同一個業務事實,系統有沒有共同答案?
如果個人頁顯示一個餘額、管理頁顯示另一個;員編登入和 LINE 登入被當成兩個人;店家頁說還能訂,下單 API 卻判定已截止——那不是「功能很多但有幾個小 bug」,而是同一件事在系統裡沒有共同語意。
餘額會出現在個人畫面、代點流程與管理清單。Day 17 已談過帳務來源,這裡只看一件事:不同入口是否回到同一套 balance truth。
currentBalanceProjection 會優先取最新 sequenced ledger 的 balance_after,沒有 ledger 時才退回 users.balance;管理摘要也沿用同一套投影。餘額讀取來源、管理摘要
2026-10-08 的正式 D1 唯讀查核也做了 aggregate comparison:58 位成員中,26 位使用最新 ledger 投影、32 位走 fallback,projection 與 users.balance 的比較為 0 筆差異。這能證明該次資料庫快照沒有出現這類結構性不一致;它仍不能替代個人頁與管理頁的實際 runtime 對照。

一般使用者可以從員編或 LINE 進入,但訂單與餘額應該屬於同一個 canonical user。Repo 的測試會讓兩種 session 收斂到同一個使用者,並檢查不會多出第二筆使用者。跨入口身份測試
真實系統還是遇過 identity split:使用者輸入另一個合法員編後,employee ID、LINE ID 與同日訂單唯一性都沒有違反 constraint,卻形成兩個實際屬於同一人的 canonical users。Issue #29:identity split 與 guarded repair
這個案例留下的重點不是修復腳本,而是:identifier 唯一,不等於 person identity 正確。 修復最後仍需要人確認歸屬,再在明確 precondition 下保留 orders、ledger、history,退休錯誤 identity。系統能不能解釋「為什麼這兩筆其實是同一個人」,比 unique constraint 有沒有 PASS 更接近成熟度。
店家專區會顯示某天是否可訂;真正送單時,訂單授權也要判斷 deadline。兩邊如果各算一次,很容易一邊顯示可訂、另一邊拒絕。
目前店家專區從 calendar 取得開團資訊,再呼叫 deadlineInfo;訂單授權也使用同一套日期/截止計算。截止規則的使用位置
共同來源不代表所有角色都得到一樣的答案。Admin 可能有不同權限,Mode A / B、時區、日期也會改變結果。成熟不是「全部顯示相同」,而是差異能從同一組業務規則被解釋。
Day 24 已談過歷史資料:今天可以用 fallback 幫畫面補圖,不代表有權把那張圖寫回歷史紀錄。
這也是共同答案的一部分。系統可以同時回答:
如果為了「看起來一致」把未知歷史全部補成現在的值,反而失去可追查性。
2026-10-08 的唯讀查核確認正式 Worker、D1 binding 與資料範圍,並檢查 users、orders、ledger、items、status history、orphan relation 與重複 identifier group。這讓文章可以確認:正式環境已有可追溯的資料責任,而不是只靠 source code 推測。
目前真正還沒完成的,是同一匿名既有成員、同一部署版本下的跨入口 runtime sample:例如 ledger、個人餘額、管理摘要與 refresh 條件是否真的對上。
這個缺口不用靠新交易補。只要未來有安全、已授權的唯讀樣本,就能繼續驗證;如果發現不一致,也應保留它,而不是為了讓文章 PASS 去改 Production。
所以 D28 的結論不是「系統已經全部一致」,而是:
成熟度不是功能數,而是同一個業務事實是否有共同來源、共同規則,以及可解釋的差異。
這是一套持續開發中的便當訂購系統。文章著重「為什麼」,GitHub 保留實際程式碼、文件與演進紀錄。
GitHub:https://github.com/henryfir456/bento-order-app
下一篇會回頭區分:哪些責任值得更早建立,哪些細節則必須等真實使用後才有足夠依據?