第十五日：API Key 上線，廣播工地動工

一、開場：今天是安全帽發放日

前幾天還在 CRUD、測試、Swagger 那些基本工。今天不一樣了——我們終於開始裝上門鎖。
沒有 API Key 的 API，就像一棟豪宅大門大開，寫著「隨便進，冰箱自己拿」。今天我決定不再裸奔，讓 Codex 幫我補上 API Key middleware，再請 Gemini 幫我檢查工程有沒有偷工減料。

二、Codex 的實作紀錄（工地日誌）

Codex 今天幹了幾件大事：

1. 導入 API Key 驗證

   • 新增 APIKeyService 與 APIKeyAuth middleware。
   • /auth/api-keys handler 登場，正式管理金鑰。
   • 所有 /api/v1 端點都得帶 Authorization: Bearer <key> 才能通過。

2. BroadcastService 架構雛型

   • 雖然還沒真的打通 Microsoft Graph API，但先定義 BroadcastService 介面。
   • 放了個 LoggingBroadcaster stub，算是幫未來的「廣播大樓」打了地基。

3. 測試全面補齊

   • repo/service/middleware/handler 都有新的單元測試。
   • integration test 增加「seed admin key」流程，模擬真實場景。
   • go test ./... 全綠 ✅。

4. 文件大翻新

   • README、API_README、API_PLANS、DB_SETUP、command.md 全部更新。
   • 測試腳本 curl_smoke.sh 與 test_api.sh 也改成強制帶 API Key。

看起來今天的 commit 數字很壯觀：
25 files changed, 1335 insertions(+), 56 deletions(-)。
這不是小修小補，這是直接蓋了一棟新樓。

三、Gemini 的專家會診（工地驗收）

Gemini 今天拿著小紅筆到處圈重點，給了幾個很關鍵的建議：

1. 廣播要落地，不要只吹哨子

   • 現在的 NotificationBroadcaster 只是介面 + stub。
   • 建議做個 RedisNotificationBroadcaster，把訊息丟進 Redis queue，再用背景 worker 消費。
   • Worker 再呼叫 TeamsBroadcastService，負責和 Microsoft Teams API 真正對接。

2. 測試要再強化

   • 建議為 APIKeyAuth middleware 寫 httptest。
   • Mock NotificationBroadcaster，檢查 Dispatch 是否正確觸發。
   • 加 e2e 測試，確保 API Key 驗證與通知流程串得起來。

3. API Key 管理功能不夠

   • 現在 admin key 還是硬編碼的，超級不安全。
   • 建議新增管理 API：生成、列出、撤銷 key。

4. 資料庫與程式結構

   • schema 要拆 migration。
   • handler 裡的 query parsing 建議抽成 helper。

一句話總結：「API Key 有了，廣播還欠，測試要補，安全要加強。」

四、我的復盤

今天的進展讓系統終於脫離「開放式小木屋」狀態，開始有點企業級專案的樣子。

• Codex 幫我把 API Key middleware 寫好，測試也補齊。
• Gemini 則提醒：「這只是第一步，沒有 queue、沒有 worker、沒有 retry，實戰還是會爆。」

就像今天蓋了圍牆，但警衛室還沒請人，也沒有監視器。雖然有門鎖了，但小偷還是能翻牆進來。

五、明日計劃

1. 開始實作 Redis + Worker，讓通知流程真正能 async。
2. 把 TeamsBroadcastService 拉出來，試試串接 Microsoft Teams API。
3. 寫更多測試，特別是 middleware 與 end-to-end。
4. 開始設計 API Key 管理 API，避免只靠硬編碼 admin key。

✍️ Day15 收工感言
今天的 commit 數量爆表，API Key 終於上線，廣播介面也搭好了舞台。
雖然還沒真的「唱歌跳舞」，但至少麥克風跟燈光已經到位。
明天，就要讓這套廣播系統真的「開口說話」。