.gitea/ai-review/exclusions.json

@@ -530,5 +530,23 @@
         "role": "Leo",
         "original_finding": "測試案例直接引用 describe 外層定義的 `usage` 變數，若被其他測試修改會造成測試間隱性耦合；建議改用區域變數或工廠函式生成測試資料。",
         "reason": "誤判。該 `const usage` 為不可變的測試夾具，所有測試只讀不寫、未曾被任何案例 mutate，不存在跨測試耦合；新增的邊界測試已各自使用區域 usage 物件。為一個唯讀 fixture 改工廠函式屬過度設計。"
+    },
+    {
+        "location": "app/usage.test.js:254",
+        "role": "Mage",
+        "original_finding": "測試情境雖處理了 NaN，但未涵蓋 limit 為 0 或負數等極端數值，可能輸出 Infinity 或負百分比。",
+        "reason": "誤判，測試已存在。`returns null percent for non-finite or non-positive quota limits` 與 `does not output Infinity/NaN/negative percent for invalid quota numbers` 已涵蓋 limit 為 0／負數／Infinity／NaN／undefined，皆驗證輸出「無法計算」、不含 NaN/Infinity/負百分比。"
+    },
+    {
+        "location": "app/usage.test.js:200",
+        "role": "Bard",
+        "original_finding": "邊界測試迴圈 [0, -5, Infinity, NaN, undefined] 混用不同型別，建議拆成多個測試以提升可讀性。",
+        "reason": "主觀風格／不採納。該迴圈已對每個值帶入 assert 訊息（如 `quota.limit=${limit} 應算不出百分比`），測試失敗時可直接定位是哪個輸入；用單一資料驅動迴圈反而精簡、不易遺漏案例。"
+    },
+    {
+        "location": "app/usage.js:216",
+        "role": "Maya",
+        "original_finding": "isFinitePositive 沒有對 null/undefined 做顯式檢查，未來可能被錯誤複用。",
+        "reason": "誤判。`isFinitePositive` 對 null（Number(null)=0 → 0>0 為 false）與 undefined（Number(undefined)=NaN → Number.isFinite 為 false）皆正確回傳 false，本就涵蓋這些輸入；函式名已表明只接受有限正數，無須再加冗餘檢查。"
     }
 ]

.gitea/ai-review/findings.json

@@ -1,26 +1 @@
-[
+[]
-  {
-    "level": "critical",
-    "role": "Mage",
-    "problem": "測試情境雖處理了 NaN，但未涵蓋 `limit` 為 0 或負數等極端數值（例如除以零導致的錯誤或異常百分比計算）。若 `formatUsageStatsLine` 內部有計算 `(used / limit) * 100` 或類似邏輯，傳入 0 會產生 `Infinity`，傳入負數則會產生荒謬的邏輯結果。",
-    "suggestion": "建議新增對 `limit: 0` 以及負數邊界值的測試案例，確保函式對這些非預期的數值輸入同樣能輸出「無法計算」或相應的錯誤處理訊息，而非輸出 `Infinity` 或負百分比。",
-    "location": "app/usage.test.js:254",
-    "is_new": false
-  },
-  {
-    "level": "warning",
-    "role": "Bard",
-    "location": "app/usage.test.js:200",
-    "problem": "測試迴圈中的陣列 `[0, -5, Infinity, NaN, undefined]` 直接混用了不同型別與邊界值，雖然測試目的明確，但在測試碼中，將邏輯測試與邊界測試分開撰寫會更具可讀性。",
-    "suggestion": "建議將測試案例拆分，例如分開測試「非數字類型」、「負數」與「邊界值（Infinity/NaN）」，這樣在測試失敗時能更快速釐清是哪種輸入類型導致的問題。",
-    "is_new": true
-  },
-  {
-    "level": "warning",
-    "role": "Maya",
-    "location": "app/usage.js:216",
-    "problem": "新增的 `isFinitePositive` 函數雖然確保了大於 0，但當 `n` 是類似 \"100\" 的數字字串時，`Number(n)` 可以正常運作，然而如果是 `null` 或 `undefined`，`Number(n)` 分別會變成 `0` 和 `NaN`。雖然在目前的使用邏輯下（`limit != null`）似乎安全，但這個檢查函數本身沒有對 `null`/`undefined` 做明確的防禦性處理，容易在未來被錯誤複用。",
-    "suggestion": "建議在 `isFinitePositive` 內部補上對 `null` 或 `undefined` 的顯式檢查，或是增加對輸入型別的限制，確保該函數作為基礎邏輯檢查更健壯。",
-    "is_new": true
-  }
-]