第十七日：資料庫鬧雙胞，工地現場小插曲

一、開場：當資料庫撞名的時候

今天一開工，立刻踩到一顆暗雷。由於我們的專案與另一個共用 codebase + Postgres 的專案共存在同一套開發環境，結果……資料庫名字撞車了！
本來應該是我們的 codex_teams，卻和另一個專案的設定打架，造成 migrations 跑錯 DB、測試亂入，開發現場瞬間變成 「誰的碗誰的湯，攪成一鍋粥」。

這一幕就像兩個工地都掛了同一塊招牌「XX大樓工程」，工人搬磚時不知道該送去哪邊，結果水泥倒到隔壁的地基，鬧出笑話。

二、處理過程：從混亂到整頓

1. 發現問題

• 執行 go test ./... 時出現資料表不對的錯誤訊息。
• Smoke test (./doc/test_api.sh) 也無法正常跑，因為 API Key 對應的表跑到別的專案裡去了。

2. 定位問題

• 查看 README.md 與 doc/DB_SETUP.md，發現 建立資料庫指令 跟隔壁專案相同，都是 codex_teams。
• 開發環境使用同一個 Postgres container，導致名字相同時直接覆蓋彼此。

3. 解決方法

• 直接 rename，本地開發資料庫正式更名為 teamsnotify2。
• 所有文件 (README.md, command.md, doc/DB_SETUP.md) 全部同步更新，避免新人再掉坑。
• commit 訊息清楚標註：chore(db): rename local database to teamsnotify2。

三、其他進展：Token Provider 升級

除了處理 DB 插曲，今天也補強了 Teams OAuth Token Provider：

• 加入 refresh window，避免 token 剛好過期時出現 401。
• 新增 retry/backoff 策略，失敗會自動重試幾次，並有指數退避。
• 增加單元測試，模擬 token 提前過期 → 成功刷新 → 確認新 token。

這代表我們的「報關員」不再臨時抱佛腳，而是會提前準備文件，不讓貨卡在海關。

四、Gemini 的驗收建議

Gemini 也來看工地，給了幾個方向：

1. 完成 TeamsBroadcastService：目前只做到拿 token，真正發訊息到 Teams 還沒上線。
2. 加入 Dead-Letter Queue：避免任務失敗後直接消失，至少留個「失敗倉庫」可以檢查。
3. 重構 Config：現在設定分散在各個 main.go，建議抽一個 config package。
4. 新增功能：像是訊息排程（利用 queue 延遲）、Billing API、第三方 bot 支援。

一句話：雖然今天被 DB 插曲耽誤了一下，但整體系統已經是「快要能商轉的雛型」。

五、復盤與感想

今天最大的教訓就是：
👉 共用環境要小心，名字一定要唯一，不然 Debug 時候哭笑不得。

我原本以為最花時間的會是 Token Provider，沒想到真正拖後腿的竟然是「資料庫撞名」。
這讓我反思：再好的程式碼，如果環境規劃不清楚，一樣會變成笑話。

不過也因此，我們補強了文件，把安裝指令、DB 名稱、測試流程全部寫死，這其實是一次 「文檔升級」的隱性收穫。

六、明日計畫

1. 把 TeamsBroadcastService 實作完，真正能送訊息到 Teams。
2. 考慮加一個 Dead-Letter Queue，避免任務直接掉地上。
3. 開始設計 Config package，統一管理環境變數。
4. 持續補測試，尤其是「多 worker + retry」情境。

✍️ Day17 收工感言
今天像是工地突然發現門牌號碼重複，工人送錯材料，笑中帶累。但還好及時 rename，才不至於把隔壁專案炸掉。
系統還在持續成長，Redis 倉庫、Worker 搬磚、Token 報關員都在線上，只差廣播歌手還沒登台。
明天，讓 Teams 聽到我們的聲音！ 🎤🚀