chore: update ai-review findings [ai-review-bot][failure]

.gitea/ai-review/findings.json

@@ -1,42 +1,66 @@
 [
   {
-    "level": "warning",
-    "role": "Assassin",
-    "location": "src/index.js:169",
-    "problem": "這個驗證只擋掉非數字，`0` 仍然會通過；若攻擊者能控制 `KEEP_COUNT`，就能把保留數設成 0，後續流程會把所有 release 刪光，還會把所有未被保留的 tag 一併清掉。",
-    "suggestion": "把下限改成至少 `1`，並在進入刪除流程前再做一次保護檢查；如果真的需要全清，應該改成獨立的高風險開關，而不是混在一般輸入參數裡。",
+    "level": "critical",
+    "role": "Mage",
+    "location": "src/index.js:400",
+    "problem": "這裡在刪除 tag 的流程中只把失敗記進 `hadFailure`，但流程結束後沒有再檢查或拋錯。最小重現：只要任一個 tag 刪除回傳 404/500，程式仍會以 0 結束，外層 CI 會誤判為清理成功，但實際上遺留的 tag 還在。",
+    "suggestion": "在 `processInBatches(tagJson, ...)` 結束後補上 `if (hadFailure) throw new Error(...)`，讓任何 tag 刪除失敗都會正確回傳非 0 狀態。",
     "is_new": true
   },
   {
     "level": "warning",
     "role": "Assassin",
-    "location": "src/index.js:233",
-    "problem": "這裡把 API 回應 body 直接拼進例外訊息，任何錯誤回應都可能被寫進 action log；如果伺服器或中間層回傳內部路徑、設定值或其他敏感內容，就會被一起外洩。",
-    "suggestion": "錯誤訊息只保留狀態碼與必要識別資訊，回應內容改成固定摘要或更嚴格的截斷與紅字處理，不要把完整 body 直接丟進例外。",
+    "location": "src/index.js:155",
+    "problem": "這裡把 `GITEA_SERVER_URL` 原樣寫進 log，若 URL 內含 userinfo、查詢字串或被惡意塞入敏感資訊，這些內容會直接落到 action log，形成可被讀取的資料外洩點。",
+    "suggestion": "不要記錄完整 URL；只輸出必要的非敏感資訊，例如遮罩後的主機名，或改成只記錄是否存在。",
     "is_new": true
   },
   {
     "level": "warning",
-    "role": "Bard",
-    "location": "src/index.js:107",
-    "problem": "`section()` 與 `currentStage` 混用兩套詞彙，一個像段落、一個像階段，語意不夠統一。這種命名會讓人讀到一半還要猜：它到底是在切 log 區塊，還是在切執行階段。",
-    "suggestion": "統一成同一套語彙，例如把 `section()` 改成 `setLogSection()`，並讓相關變數名稱也跟著一致。",
+    "role": "Assassin",
+    "location": "src/index.js:345",
+    "problem": "`releaseItem.id` 直接進入 DELETE URL，完全信任 API 回來的值；如果回應被污染或伺服器回傳惡意資料，攻擊者就能把刪除請求導向非預期路徑。",
+    "suggestion": "在組 URL 前先確認 `id` 一定是正整數，拒絕任何非數字或異常範圍的值，再送出刪除請求。",
     "is_new": true
   },
   {
     "level": "warning",
     "role": "Mage",
-    "location": "src/index.js:282",
-    "problem": "`Promise.all` 只要其中一個刪除任務拋出 reject，整個 batch 會立刻失敗，外層 `main().catch(...)` 也會直接結束。這代表只要某一筆 release 或 tag 遇到網路中斷、DNS 失敗、連線逾時，後續同 batch 的項目就不會再處理，清理流程會在半途中停住。",
-    "suggestion": "把每個 item 的刪除包在個別 `try/catch`，或改用 `Promise.allSettled` 後統一彙總失敗；至少要確保單筆失敗不會中止同批其他清理工作。",
+    "location": "src/index.js:144",
+    "problem": "這個空值判斷把字串 `'null'` 也當成空值。最小重現：若某個 release 的 `tag_name` 真的就是 `null`，它會在 `releaseTags` 建立時被排除，後續 tag 清理會把這個原本應保留的 tag 誤刪。",
+    "suggestion": "不要在通用空值判斷裡把字串 `'null'` 視為空值；只保留 `undefined`、`null` 與空字串。如果某些輸入來源真的會傳出字面值 `'null'`，請在那個來源各自做正規化。",
+    "is_new": true
+  },
+  {
+    "level": "warning",
+    "role": "Rogue",
+    "location": "src/index.js:183",
+    "problem": "這裡每次 request 都重新走一次預設 HTTPS 連線，沒有重用 keep-alive 連線。後面又會連續打多次頁面查詢與刪除 API，TLS 握手和 socket 建立會被重複支付，release/tag 數量一多就很浪費延遲與 CPU。",
+    "suggestion": "改成共用 `https.Agent({ keepAlive: true })`，並把同一個 agent 傳給所有 GET/DELETE request，減少重複建連線的成本。",
     "is_new": true
   },
   {
     "level": "info",
-    "role": "Mage",
-    "location": "src/index.js:146",
-    "problem": "這個 helper 把字串 `'null'` 也當成空值。若真的存在名稱剛好是 `null` 的 tag、repo 名稱或其他合法輸入，就會被誤判成缺值而跳過或拒絕，造成清理邏輯和實際資料不一致。",
-    "suggestion": "只把 `undefined`、`null` 和空字串視為空值；若需要處理來自環境變數的字面字串 `'null'`，應該在特定參數的解析層單獨處理，不要放進通用空值判斷。",
+    "role": "Assassin",
+    "location": "src/index.js:228",
+    "problem": "分頁迴圈沒有上限，只要對方持續回傳非空頁面，這個 action 就會無限抓取；惡意或故障中的 API 可以把 runner 卡死，消耗時間與配額。",
+    "suggestion": "加入最大頁數、重複頁檢測或總筆數上限，超過就中止並回報異常，避免被外部回應拖成無限迴圈。",
+    "is_new": true
+  },
+  {
+    "level": "info",
+    "role": "Bard",
+    "location": "src/index.js:337",
+    "problem": "批次大小直接裸寫 `4`，而且在後面同樣又出現一次；這種數字沒有名字，像臨時即興的節拍，之後要調整時很難一眼找到所有節點。",
+    "suggestion": "把批次大小抽成具名常數，例如 `const DELETE_CONCURRENCY = 4;`，兩個呼叫點共用，畫面會更整齊，也更好維護。",
+    "is_new": true
+  },
+  {
+    "level": "info",
+    "role": "Leo",
+    "location": "src/index.js:409",
+    "problem": "在 `catch` 裡先把 `currentStage` 清空再記錄錯誤，會讓最後那筆失敗 log 失去「到底是在哪個階段炸掉」的上下文。等到未來有人要追問題時，只能回頭翻前面的輸出，比對成本會很高。",
+    "suggestion": "保留最後的 `currentStage`，或在進入 `catch` 時把階段一起寫進錯誤訊息；如果擔心汙染後續輸出，可以在輸出完成後再重設，而不是先清空。",
     "is_new": true
   }
 ]