今天是鐵人賽第十二天。
昨天修正 ID 使用 UUID，今天終於要開始做新功能了。
首先一樣請 AI 同事先了解現況，並建構計畫。
建構完計畫後，再請 AI 同事用後端的角度分析計畫是否有遺漏，或者有哪些地方可以優化，以便完善計畫。

AI 同事規劃的建構計畫：

認證與授權工具
2.1：強化認證工具
2.2：實作授權依賴
2.3：標準化錯誤處理
2.4：API 端點（路由）補充與強化

整合與測試
3.1：整合路由
3.2：初始資料填充（Seeding）
3.3：編寫測試

看了 AI 同事給的計畫後，感覺沒什麼大問題，就請他開始執行。
不過可能是我沒有先告訴他「做到哪個階段再停」，結果他一次做到底，步伐太大，複雜度上升，導致錯誤變多。
除此之外，人工要介入的困難度也增加，因為一次新增太多東西，判斷哪裡可能有問題變得更吃力。
感覺下次應該明確告訴他先執行到哪個階段，人工介入測試後再繼續，這樣才不會一次做太多，讓人工檢查的範圍與複雜度上升。

這裡想提一個人工介入時需注意的地方：
AI 同事讀完檔案後，會將資訊放在 old_string 變數裡。
如果在他工作時手動修改檔案內容，很容易造成混亂，甚至會讓他認為你改的地方與他的認知不同，進而把你的修改改回舊版。
目前合作上感覺最好的方式還是：

1. 請 AI 同事直接幫你改，他才會更新資料。
2. 或者用 /clear 指令清理所有資料，再重新讀一次檔案。
3. 更新完檔案，用 @請他重新讀檔案。

在 AI 同事建構完計畫內容、人工測試前，我請他將今天內容更新到檔案內以便追蹤錯誤。
結果他又不小心蓋掉昨天的更新日誌，我只好請他恢復再修正。
他說無法還原，要我人工處理。
我先找到他覆蓋前的內容並恢復，再用 @ 讓他讀取最新檔案並更新，最後才成功更新。

更新完之後，我請 AI 同事幫我設計手動測試今天更新功能的流程，方便測試。
結果又出包了，我明明說「先不要開始後續建置」，先幫我設計手動測試方法，結果他聽成「使用者要他繼續」XD
看來是前面文本太長，造成 AI 同事混亂。

我請 AI 同事恢復後，先推送 Git 做版本控制，以防再出現類似情況。
結果第一次推送失敗，加上文本混亂，AI 同事突然不清楚自己在做什麼，跑去做 20 分鐘前的事情。
我趕緊請他停下來，再推送一次，才成功將檔案推送成功。

明天會繼續將今天的功能手動測試，測試結束就可以開始刻功能了。

以下為今天的研究流程

首先開始前的老樣子，請AI同事了解應用現況。
我給AI的指令:

@ai_context.md @README.md @軟體核心架構規劃.md @功能需求總覽.md   了解目前現況

等AI同事了解完，請他規劃今天建構計畫。
我給AI的指令：

請幫我規劃建構計畫，希望步驟顆粒度小

AI同事根據步驟幫我規劃蠻多步驟，不過我請AI同事繼續透過後端的視角分析並優化目前計畫。
我給AI的指令：

@agents/engineering/backend-architect.md 請以你的角度分析這個計畫是否有遺漏或可以優化的地方

AI同事以後端角度給予了優化建議：

遺漏與建議補充

1. 速率限制 (Rate Limiting)：

   • 遺漏點：在 ai_context.md 和 功能需求總覽.md 中明確提到了對登入和註冊等敏感端點實施速率限制，以防止暴力破解攻擊。這在目前的細化計畫中並未明確列出。
   • 建議：應在「子階段 2.3：API 端點 (路由)」中，為登入和註冊路由增加實施速率限制的步驟。這可以透過FastAPI 的依賴注入或使用第三方庫來實現。

2. 審計日誌 (Audit Logging)：

   • 遺漏點：在 ai_context.md 和 功能需求總覽.md 中也提到了在敏感操作（如使用者註冊、登入、密碼變更、權限修改）中加入審計日誌。這在目前的細化計畫中也未明確列出。
   • 建議：應在「子階段 2.3：API 端點(路由)」中，為相關的敏感操作端點增加記錄審計日誌的步驟。這對於安全審計和問題追蹤至關重要。

優化建議

1. 權限快取 (Caching Permissions)：

   • 優化點：在「步驟 2.2.2：實作 has_permission
     依賴」中，如果權限檢查頻繁且涉及複雜的資料庫查詢，可以考慮將使用者的權限資訊快取起來 (例如在 Redis中，或在 JWT Payload 中，但需注意 Payload 大小和敏感性)。
   • 建議：在實作 has_permission 依賴後，評估其性能。如果成為瓶頸，可以考慮引入權限快取機制。

2. 標準化錯誤響應的錯誤碼/類型 (Error Codes/Types in Standardized Error Responses)：

   • 優化點：在「子階段 2.3：標準化錯誤處理」中，除了返回錯誤訊息外，建議在標準化錯誤響應中包含特定的錯誤碼或錯誤類型。這將使前端或其他客戶端能夠更程式化地處理不同類型的錯誤。
   • 建議：在 backend/exceptions.py中定義異常時，為每個異常類型分配一個唯一的錯誤碼，並在異常處理器中將其包含在響應中。

3. 輸入驗證的強調 (Emphasis on Input Validation)：

   • 優化點：雖然 FastAPI 結合 Pydantic 已經提供了強大的輸入驗證能力，但作為架構師，仍需強調所有使用者輸入都應進行嚴格驗證和清理，以防止常見的安全漏洞 (如 SQL 注入、XSS)。
   • 建議：在實作過程中，確保所有接收使用者輸入的 Pydantic 模型都定義了適當的驗證規則。

4. 整合測試的全面性 (Comprehensive Integration Testing)：

   • 優化點：計畫中提到了單元測試，這很好。但對於認證和授權這樣關鍵的模組，全面的整合測試至關重要。
   • 建議：在「階段四：整合與測試」中，除了單元測試外，應特別強調編寫涵蓋整個認證和授權流程的整合測試，例如：
     • 註冊新使用者後能否成功登入。
     • 使用有效/無效/過期/黑名單的令牌存取受保護資源。
     • 不同角色使用者存取不同權限的端點。
     • 刷新令牌的流程。

看起來都是不錯的著眼點，因此請AI同事根據建議改良規劃內容。
我給AI的指令：

好的，請根據建議改良原本規劃 

AI同事給了我一版蠻細的規劃，我列出規劃標題：

認證與授權工具 (認證與授權工具)
2.1：強化認證工具 (強化認證工具))
2.2：實作授權依賴 (實作授權依賴)
2.3：標準化錯誤處理 (標準化錯誤處理)
2.4：API 端點 (路由) - 補充與強化
整合與測試
3.1：整合路由
3.2：初始資料填充 (Seeding)
3.3：編寫測試

看起來沒問題後，我就請AI同事開始執行。
中間過程還算順利，不過中間遇到一個問題:

AttributeError: module 'redis.asyncio' has no attribute 'exceptions' 

這時因為AI同事鬼打牆三次了，我按esc暫停他，指示他使用context7去查正確用法後，AI同事嘗試兩三次終於解決。

我請AI同事規劃的顆粒度雖然細，但我沒指示AI同事執行到哪個階段，他就一直就構下去，感覺邁的步伐太大，除了AI同事一次處理的事情多導致複雜度上升外，我要跟著去看他做了哪些事情也開始吃力。

不過我自從手動介入請他用context7去後，AI同事遇到錯誤就有比較聰明的去解決了。
最後全數通過程式測試後，在手動測試前，我請他先將今天更新內容更新到檔案以方便追蹤，但這時出現了他把昨天的更新日誌蓋掉了，請AI同事恢復也失敗，他告訴我他無法恢復讓我手動更新。我只好根據他上面改之前的內容修正，修正後我將資料@給他，讓他讀取修正內容。
我給AI的指令：

@README.md 修復好了，請幫我將更新日誌格式調整一致

AI同事正確讀取後，開始更新ai_context.md，不過發生AI同事以為這個檔案資料錯誤，在這個階段AI同事為了嘗試修復這個問題進入了無限迴圈，但我手動打開檔案確認內容沒問題，因此中斷AI同事迴圈並用@的方式請他更新內容，他才正確讀到檔案內容並更新。
我給AI的指令：

@ai_context.md 你的old資料好像有誤，請重新讀取

更新完之後，我請AI同事幫我設計手動測試今天更新功能的流程方便我測試：
我給AI的指令：

先不要開始 核心專案與任務管理，我要手動測試今天更新的內容，請幫我設計手動測試方法

結果AI出包了，AI同事聽成使用者要他繼續建置，結果直接開始產生程式碼，但這不是我要的，我趕快按esc中斷，請他將剛剛的內容還原。
還原後，為了等等要出現一樣的情況，我請AI同事先git推送做版本控制。
結果第一次由於前面太多文本導致AI同事有點混亂，我又叫他推送了第二次才成功。