chore(ai-review 狀態): 清空已處理 findings

.gitea/ai-review/findings.json

@@ -1,42 +1 @@
-[
-  {
-    "level": "critical",
-    "role": "Assassin",
-    "location": "src/index.js:299",
-    "problem": "這裡把 `GITEA_SERVER_URL` 直接拼進帶有 `Authorization: token ...` 的 API 請求，只檢查是不是 `https` 並不能防止攻擊者把環境變數指到自己的 HTTPS 主機。只要外部能影響這個值，就能把 runner token 一起送出，等於把這個 action 變成可用來外洩憑證的 SSRF 入口。",
-    "suggestion": "不要只驗證協定，必須把目標主機固定在預期的 Gitea 來源；改成解析 `URL` 後比對 `origin`/host 白名單，拒絕任何非預期網域，並且只在確認是可信任的 Gitea 站台時才附加 `Authorization` header。",
-    "is_new": true
-  },
-  {
-    "level": "warning",
-    "role": "Assassin",
-    "location": "Dockerfile:8",
-    "problem": "這裡仍然使用可浮動的 `node:22-alpine` 標籤，沒有鎖定到不可變的 digest。攻擊者只要污染上游映像或讓標籤漂移，就可能在 action 啟動前先取得執行權，進而竊取後續流程中的 token 與 repo 資料。",
-    "suggestion": "把基底映像改成固定 digest，例如 `node:22-alpine@sha256:...`，並定期以受控流程更新；不要依賴會隨時間變動的映像標籤。",
-    "is_new": true
-  },
-  {
-    "level": "warning",
-    "role": "Leo",
-    "location": "src/index.js:1",
-    "problem": "這個檔案同時承擔 log 格式化、輸入驗證、HTTP 呼叫、分頁抓取、刪除流程與錯誤彙總，責任切得太散。半年後只要想改一個 API 規則，維護者就得在同一個大檔裡來回跳，單元測試也很難把純邏輯跟 I/O 分開。",
-    "suggestion": "把共用基礎能力拆成獨立模組，例如 `logger`、`gitea client`、`cleanup workflow`，並讓主程式只負責組裝依賴與啟動流程。",
-    "is_new": true
-  },
-  {
-    "level": "warning",
-    "role": "Mage",
-    "location": "src/index.js:177",
-    "problem": "這裡直接拒絕 `http:` 連線，導致任何使用 `http://` 的 Gitea 部署都會在第一個 API 請求就失敗。最小重現情境是把 `GITEA_SERVER_URL` 設成內網常見的 `http://gitea.local`，整個清理流程會完全無法執行。",
-    "suggestion": "若這個 action 需要支援常見的自架環境，應移除固定只允許 HTTPS 的限制，或把協定限制做成可配置；若確實只支援 HTTPS，也要在 action 說明中明確標示，避免使用者在 `http` 環境下直接踩雷。",
-    "is_new": true
-  },
-  {
-    "level": "warning",
-    "role": "Rogue",
-    "location": "src/index.js:184",
-    "problem": "這裡先把每一頁資料全部塞進 `all`，等於把整個 API 結果完整具現化；release/tag 數量一大時，記憶體會吃到 O(n)，而且陣列反覆擴容與拷貝也會多耗 CPU。",
-    "suggestion": "改成邊抓邊處理，不要先合併成單一大陣列；如果 API 支援，順便加大每頁筆數，減少往返次數。",
-    "is_new": true
-  }
-]
+[]