diff --git a/.gitea/ai-review/findings.json b/.gitea/ai-review/findings.json
index e9450a2..9e9c815 100644
--- a/.gitea/ai-review/findings.json
+++ b/.gitea/ai-review/findings.json
@@ -1,18 +1,12 @@
 [
   {
-    "level": "critical",
+    "level": "warning",
     "role": "Mage",
     "location": "app/tags.js:52",
-    "problem": "在 `cleanupOrphanTags` 中，分兩次 API 呼叫取得 releases 與 tags，且過濾過程未保證原子性。若期間 Gitea 狀態變更，可能導致誤刪並非孤立的 tag。",
-    "suggestion": "考量原子性需求，或在刪除操作前增加確認機制；並明確文件化此風險。"
-  },
-  {
-    "level": "critical",
-    "role": "Maya",
-    "problem": "在 `loadConfig` 中，`serverUrl`、`repository`、`token` 以及 `keepCount` 雖有呼叫驗證函式，但這些驗證函式（如 `requireValue`、`requireInteger`）在失敗時會直接拋出錯誤，且沒有相對應的單元測試去驗證這些設定錯誤的情境，尤其是當環境變數輸入惡意或無效字串時的系統行為。",
-    "suggestion": "補上針對 `config.js` 的完整錯誤處理測試，特別是模擬 `process.env` 各項缺失或異常時，確認是否確實會拋出預期的 Error，並確保清理流程在設定錯誤時能安全停止。",
-    "location": "app/config.js:63",
-    "is_new": false
+    "problem": "cleanupOrphanTags 分兩次 API 呼叫取得 releases 與 tags,過濾過程未保證原子性;期間 Gitea 狀態變更可能誤刪非孤立 tag。",
+    "suggestion": "考量原子性需求,或在刪除前增加確認機制;並明確文件化此風險。",
+    "status": "deferred",
+    "defer_reason": "已於 cleanupOrphanTags 以註解明確文件化此 TOCTOU 殘餘競態;現行於開頭重新抓取最新 release 為主要緩解,屬排程任務可接受範圍。完整原子性(每筆刪除前複查)為一致性/成本設計取捨,保留待人工評估。"
   },
   {
     "level": "warning",
@@ -21,43 +15,42 @@
     "problem": "清理流程對網路請求依賴強,若 API 呼叫失敗,整個 main 流程中斷,無法確保後續清理的一致性與部分成功重試。",
     "suggestion": "引入更細緻的錯誤處理(如錯誤閾值機制)或部分清理成功後的重試策略。",
     "status": "deferred",
-    "defer_reason": "錯誤處理/重試策略的設計取捨。目前單筆刪除失敗(非 204)會記錄並繼續、讀取失敗則中止屬合理保守行為;是否引入閾值/重試保留待人工評估。",
-    "is_new": false
+    "defer_reason": "錯誤處理/重試策略的設計取捨。目前單筆刪除失敗(非 204)會記錄並繼續、讀取失敗則中止屬合理保守行為;是否引入閾值/重試保留待人工評估。"
   },
   {
     "level": "warning",
     "role": "Maya",
     "location": "app/releases.js:46",
     "problem": "cleanupReleases 中若刪除過程拋出例外(如網路中斷),會終止整個流程,無法保證已讀取的舊 release 都被嘗試清理。",
-    "suggestion": "將逐筆刪除包在 try/catch,單筆刪除拋例外時記錄後續刪下一筆;或明確標示部分清理狀態。",
+    "suggestion": "將逐筆刪除包在 try/catch,單筆拋例外時記錄後續刪下一筆;或明確標示部分清理狀態。",
     "status": "deferred",
-    "defer_reason": "同屬錯誤處理策略的設計取捨(與 releases.js:38)。目前 deleteResource 對 HTTP 失敗回傳狀態碼、迴圈已續行;僅網路層例外會中止,屬 fail-fast 保守行為。是否改為逐筆吞例外續行保留待人工評估(清理為冪等,下次排程會補做)。",
-    "is_new": false
+    "defer_reason": "同屬錯誤處理策略設計取捨。deleteResource 對 HTTP 失敗回傳狀態碼、迴圈已續行;僅網路層例外會中止,屬 fail-fast 保守行為(清理冪等,下次排程補做)。是否逐筆吞例外續行保留待人工評估。"
   },
   {
     "level": "warning",
     "role": "Maya",
-    "location": "app/gitea-client.js:115",
-    "problem": "deleteResource 僅回傳狀態碼,對於 401/403/404 等錯誤未做區分處理。",
-    "suggestion": "在 deleteResource 內針對常見錯誤碼拋出更有意義的例外,讓呼叫方可採取跳過/重試/中止等策略。",
-    "status": "deferred",
-    "defer_reason": "現行刻意讓 deleteResource 單純回傳狀態碼、由呼叫端記錄 HTTP code 後續行;依狀態碼採取不同策略與重試/閾值同屬錯誤處理設計取捨,與 releases.js:38 一併保留待人工評估。",
-    "is_new": false
-  },
-  {
-    "level": "warning",
-    "role": "Mage",
     "location": "app/releases.js:47",
-    "problem": "在 `cleanupReleases` 迴圈中，對於每一個 release 都呼叫 `await client.deleteResource(url)`。若 release 數量眾多，這種依序刪除的方式非常耗時，且若 API 負載過高，容易導致部分請求逾時。",
-    "suggestion": "如果 API 允許，建議採用併發刪除（例如使用 `Promise.all` 限制併發數），或者在日誌中增加處理進度，並考慮增加對 API 錯誤的重試機制。",
-    "is_new": true
+    "problem": "cleanupReleases 迴圈逐筆 await deleteResource,release 眾多時依序刪除耗時,且 API 負載高時易逾時。",
+    "suggestion": "若 API 允許,採有上限的併發刪除(如限流 Promise.all),或增加進度日誌與重試。",
+    "status": "deferred",
+    "defer_reason": "刻意保留序列化:避免對 Gitea API 造成併發壓力與觸發速率限制、維持記錄順序,且與原 bash 行為一致;有上限併發/重試屬效能與錯誤處理取捨,保留待人工評估。"
   },
   {
     "level": "warning",
     "role": "Maya",
     "location": "app/tags.js:54",
-    "problem": "在刪除 tag 的迴圈中，同樣缺少對 `deleteResource` 拋出例外的防禦，一旦發生網路錯誤，後續的 tag 將無法被清理。",
-    "suggestion": "在 `for` 迴圈內增加 `try...catch` 區塊，記錄錯誤並 `continue` 以確保後續 tag 能正常被刪除；應比照 `releases.js` 新增測試驗證此行為。",
-    "is_new": true
+    "problem": "刪除 tag 的迴圈缺少對 deleteResource 拋例外的防禦,網路錯誤會中止後續 tag 清理。",
+    "suggestion": "在 for 迴圈內加 try/catch,記錄錯誤並 continue;比照 releases 補測試。",
+    "status": "deferred",
+    "defer_reason": "與 app/releases.js:46 同屬「逐筆吞例外續行 vs fail-fast」的錯誤處理設計取捨;HTTP 失敗已回傳狀態碼並續行,僅網路層例外會中止。保留待人工評估。"
+  },
+  {
+    "level": "warning",
+    "role": "Maya",
+    "location": "app/gitea-client.js:115",
+    "problem": "deleteResource 僅回傳狀態碼,對 401/403/404 等錯誤未做區分處理。",
+    "suggestion": "在 deleteResource 內針對常見錯誤碼拋出更有意義的例外,讓呼叫方採取跳過/重試/中止策略。",
+    "status": "deferred",
+    "defer_reason": "現行刻意讓 deleteResource 單純回傳狀態碼、由呼叫端記錄 HTTP code 後續行;依狀態碼分流與重試/閾值同屬錯誤處理設計取捨,保留待人工評估。"
   }
 ]