docs(app): 回填維護項 5＋6（清殘留分支／清 dev DB）——並救回一份未合併的測試、更正一條寫錯的機制

[thothawei]

做了什麼

TODO「下次任務」裡唯一不需外部資源、也不寫 DB 的項目：維護項 5 清開發殘留 worktree／舊分支。

項目	前	後
本地分支（三 repo 合計）	76	5
worktree	18	3（僅剩兩個進行中工作區）
remote 舊分支	17	0

app 55→2、admin 2→1、dispatch 19→2；admin 的 remote 本來就乾淨。

重點不是刪，是刪之前的舉證

前兩批「救回」（app #48、dispatch #49）之所以存在，就是因為有人把未合併的分支當成已合併。所以這次的判定不看 commit message、也不只看 PR 狀態：

1. git merge-base --is-ancestor <branch> main → ancestor 即安全。
2. 非 ancestor 者查對應 PR；MERGED 還要再比對 headRefOid——squash merge 後本地 tip 可能又長出新 commit，PR 頁面不會告訴你。→ 40 條 MERGED 分支的本地 tip 全數等於合併時的 tip。
3. 剩下 4 條例外逐條看 diff。

分支	判定
app claude/todo-review-priority-54ffe7（#40 CLOSED）	已救回（測試在 #48、功能碼在 #41）
app claude/project-planning-docs-803c8e（#37 CLOSED）	純文件，T1–T5 逐項都已在現行 TODO 有對應
dispatch claude/driver-phone-profile（#42 CLOSED）	已被取代——那份 service 測試每一條都被 main 的 handler/driver_profile_test.go（真 DB）覆蓋；且「空字串＝清除電話」在 main 已改成 400 拒絕，原測拿到 main 反而會 FAIL
dispatch claude/determined-shannon-17f4ac（從未開 PR）	🐛 有漏，見下

撈到的東西：dispatch PR #50

determined-shannon 的功能碼（PickUpResult／dropoff_lat／tracking ETA）都在 main，但它帶著一份 main 沒有的 internal/repository/ride_dropoff_integration_test.go。原檔測的 GetDropoffCoords 已從 main 移除，故改寫成對現有 API 的等價覆蓋，救回為 fleet-dispatch#50。

真正的價值在其中一條：「未指定目的地 → DropoffPoint 必須是 nil」main 完全沒有。它守的是踩過的 GeoPoint.Scan 坑——NULL 被當成掃描成功而留下 (0,0)，導航與計費會把幾內亞灣外海當成真目的地，而且不會報錯。真 PostGIS 實跑 2/2 PASS。

教訓：「從未開過 PR」是最危險的一種殘留——它不在任何 PR 列表裡，只有逐條比對 diff 才看得到。

這個 PR 本身

只動 docs/TODO.md（回填完成證據＋把「下次開工第一件事」寫清楚：維護項 6 清 dev DB 會寫入，動手前必須先問過使用者）。沒有任何程式碼改動，所以沒有跑 flutter test。

remote 分支刪除已取得使用者同意（含 4 條未合併的；GitHub 的 PR 頁面仍看得到 diff）。

🤖 Generated with Claude Code

[thothawei]

追加：維護項 6「清 dev DB 測試殘留」也完成了（commit 6977b84）

清理

docker compose down -v 砍掉 line-fleet-dispatch_postgis_data（使用者拍板「砍掉重練」）。動手前先核對不會損失設定：fleet_settings 每個值都等於 migration 預設、admin 由 app 啟動時重種。順手清掉維護項 5 遺留的兩個孤兒 volume（各 114MB、LINKS=0，共釋出 228MB）。

驗證重建後仍可用（不只是刪掉）：migration 自動跑到 000023、admins 重種 1 筆、fleet_settings 回預設、其餘業務表全 0；POST /api/admin/login（admin/admin）200 拿到 token、未帶 token 的 GET /api/customer/fees 正確 401。

比「刪掉了」更重要的兩件事

1. 原待辦寫錯的機制，已更正。 舊敘述說殘留的「線上」司機擋在派單佇列前。讀 dispatchRound → Store.NearbyDriverIDs 後確認跨 session 不成立：候選只從 Redis drivers:geo 取，且每個候選還要 driver:<id>:loc 的 updated_at 在心跳鮮度內。compose 的 redis 沒掛 volume，down 之後派單池是空的（實測 dbsize 0、zcard drivers:geo 0）。2026-07-27 那次白跑是同一個 session 內司機還在送心跳造成的，不是跨 session 的殘留。

2. 盤點到真正會咬下一次的坑。 GoOnline 對 status=OnTrip 的司機直接 return、不改狀態，GoOffline 回 ErrDriverOnTrip。上次留下 3 個卡在「載客中」的司機（id 4 o5-driver、11、13）——重用這些帳號時，App 顯示上線成功，但派單要求 Idle 所以永遠收不到單，也無法離線，而且沒有任何錯誤訊息。另有 4 張未結案訂單讓 4 個測試乘客一律拿到「已有進行中訂單」。

下次做 E2E 前請注意

DB 是全新的，沒有任何測試帳號——司機／乘客都要重新註冊，司機還要走 O5 車輛審核（admin 核准）才能接單。

🤖 Generated with Claude Code