.gitea/ai-review/exclusions.json

@@ -482,5 +482,11 @@
         "role": "Bard",
         "original_finding": "`fetchAccountQuota` 中的 `QUOTA_STRATEGIES` 物件定義龐大，將所有平台策略硬編碼於此，未來新增供應商難以維護；建議抽離至獨立檔案或策略模式。",
         "reason": "過早最佳化（與先前已排除的 usage.js SRP 拆檔建議等價）。目前 QUOTA_STRATEGIES 為精簡的查表物件、各平台策略短小且集中易讀；在供應商數量出現實際膨脹痛點前抽檔，徒增檔案與匯入複雜度。"
+    },
+    {
+        "location": "app/usage.js",
+        "role": "Assassin",
+        "original_finding": "extractUsage 對不預期 payload 僅返回 null，過度信任 API 回應結構，可能導致計費或配額相關監控被繞過；建議增加 Schema Validation、異常明確記錄。",
+        "reason": "誤判／過度設計。extractUsage 僅用於「使用量顯示統計」，非計費或配額強制；回傳 null 是「此回應無可辨識 usage 資訊」的正確訊號，呼叫端以 0 計入並降級顯示，不影響任何金流或門檻判斷。對 best-effort 顯示統計加 schema validation 與錯誤記錄屬過度設計。"
     }
 ]

.gitea/ai-review/findings.json

@@ -1,34 +1 @@
-[
-  {
-    "level": "critical",
-    "role": "Maya",
-    "location": "app/comments.test.js",
-    "problem": "在 `postFindingsReview` 測試中，雖然增加了驗證 usageSection 的案例，但對於舊問題（is_new: false）不應被標註的邏輯，缺乏針對「舊問題數量是否正確統計進總計」的邊界測試。",
-    "suggestion": "補上一個測試案例：驗證當存在新問題與舊問題時，統計表格中「新問題」與「舊問題」的行數與數字皆正確，且舊問題確實沒有產生對應的行內評論。",
-    "is_new": true
-  },
-  {
-    "level": "warning",
-    "role": "Assassin",
-    "location": "app/usage.test.js",
-    "problem": "`extractUsage` 對不預期 payload 僅返回 `null`，過度信任 API 回應結構，可能導致計費或配額相關監控被繞過。",
-    "suggestion": "增加嚴格結構驗證（Schema Validation），異常時應明確記錄並標示，而非默默忽略。",
-    "is_new": false
-  },
-  {
-    "level": "warning",
-    "role": "Maya",
-    "location": "app/findings.test.js",
-    "problem": "在 `appendExclusions` 測試中，測試案例僅檢查了「檔案路徑 + 原文」的去重，未測試當只有檔案路徑相同、但原問題內容不同時的行為（理應視為不同排除條目）。",
-    "suggestion": "補上測試案例：輸入兩條路徑相同但原問題不同的 exclusion，確保兩者皆被成功寫入。",
-    "is_new": true
-  },
-  {
-    "level": "warning",
-    "role": "Maya",
-    "location": "app/findings.test.js",
-    "problem": "在 `filterFalsePositivesWithAI` 的測試中，測試了 LLM 呼叫失敗時會保守保留，但未測試當 `chatFn` 回傳結構不完整（例如缺少 verdict 欄位）時，是否真的有正確過濾或保留。",
-    "suggestion": "增加一個測試案例，模擬 `chatFn` 回傳一個包含錯誤 verdict 格式的物件，驗證該問題是否如預期被保守保留。",
-    "is_new": true
-  }
-]
+[]