From 892a79c9bc5c843cb4657cc2c4ab007d7d1cc303 Mon Sep 17 00:00:00 2001 From: Jeffery Date: Tue, 23 Jun 2026 15:36:19 +0800 Subject: [PATCH] =?UTF-8?q?chore(ai-review=20=E7=8B=80=E6=85=8B):=20?= =?UTF-8?q?=E8=A7=A3=E6=B1=BA=E8=A1=8C=E8=99=9F=E7=9B=B8=E9=97=9C=20findin?= =?UTF-8?q?gs=E3=80=81=E6=8E=92=E9=99=A4=20extractUsage=20=E8=AA=A4?= =?UTF-8?q?=E5=A0=B1=EF=BC=8C=E6=B8=85=E7=A9=BA=20findings.json?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .gitea/ai-review/exclusions.json | 6 ++++++ .gitea/ai-review/findings.json | 35 +------------------------------- 2 files changed, 7 insertions(+), 34 deletions(-) diff --git a/.gitea/ai-review/exclusions.json b/.gitea/ai-review/exclusions.json index 56f7c61..4ffa10c 100644 --- a/.gitea/ai-review/exclusions.json +++ b/.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 與錯誤記錄屬過度設計。" } ] diff --git a/.gitea/ai-review/findings.json b/.gitea/ai-review/findings.json index 467c2be..fe51488 100644 --- a/.gitea/ai-review/findings.json +++ b/.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 - } -] +[]