[
  {
    "level": "warning",
    "role": "Mage",
    "location": "app/releases.js:46",
    "problem": "刪除邏輯未針對網路不穩定或特定 HTTP 狀態碼(502, 503, 504)實作重試機制,且遇到失敗時未停止後續請求。",
    "suggestion": "針對特定 HTTP 狀態碼實作指數退避重試,並引入錯誤閾值,失敗次數過高時中斷流程。",
    "status": "deferred",
    "defer_reason": "屬功能性增強與設計取捨。此清理 Action 以排程執行,單次失敗可於下次補刪;重試/退避/錯誤閾值涉及次數、間隔與冪等性等決策,保留待人工評估。"
  },
  {
    "level": "warning",
    "role": "Mage",
    "location": "app/releases.js:38",
    "problem": "清理流程對網路請求依賴強,若 API 呼叫失敗,整個 main 流程中斷,無法確保後續清理的一致性與部分成功重試。",
    "suggestion": "引入更細緻的錯誤處理(如錯誤閾值機制)或部分清理成功後的重試策略。",
    "status": "deferred",
    "defer_reason": "與 app/releases.js:46 同屬錯誤處理/重試策略的設計取捨。目前單筆刪除失敗會記錄並繼續,讀取失敗則中止屬合理保守行為;是否引入閾值/重試保留待人工評估。"
  },
  {
    "level": "warning",
    "role": "Leo",
    "location": "app/releases.js:37",
    "problem": "cleanupReleases 同時處理資料獲取、邏輯判斷與副作用執行,違反單一職責原則,不易單獨測試刪除邏輯。",
    "suggestion": "拆分邏輯與執行層,將刪除副作用抽象化為獨立函式。",
    "status": "deferred",
    "defer_reason": "純邏輯(selectReleasesToDelete)已抽離且函式短小、已具失敗路徑與編碼測試;進一步拆出刪除迴圈為設計偏好,效益有限,保留待人工評估。"
  },
  {
    "level": "warning",
    "role": "Rogue",
    "location": "app/releases.js:43",
    "problem": "清理成品與刪除 tag 使用序列化迴圈,API 請求逐一排隊,整體執行時間拉長。",
    "suggestion": "改用 Promise.all 搭配 map 將刪除請求並行化。",
    "status": "deferred",
    "defer_reason": "刻意保留序列化:避免對 Gitea API 造成併發壓力與觸發速率限制,並維持可預期的記錄輸出順序;無上限並行化非等價變更,保留待人工評估(可日後改為有上限並行)。"
  },
  {
    "level": "info",
    "role": "Rogue",
    "location": "app/gitea-client.js:33",
    "problem": "fetchAllPages 採線性逐頁請求,資料龐大時效能不佳。",
    "suggestion": "若 API 支援,先取得總頁數後並行請求。",
    "status": "deferred",
    "defer_reason": "Gitea 分頁未可靠提供總頁數,需解析 Link 標頭且各端點支援度不一;線性逐頁搭配逾時與 MAX_PAGES 上限已足夠穩健,並行化屬最佳化取捨,保留待人工評估。"
  }
]