chore(ci/ai-review): ci.yaml token 改用 secrets.TOKEN，更新 findings 並登記誤報至 exclusions

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

.gitea/ai-review/exclusions.json

@@ -10,5 +10,11 @@
     "role": "Leo",
     "original_finding": "main 函式過於龐大，擔任 Step1 到 Step11 的總指揮與細節實作，隨流程增加將難以閱讀與維護，建議拆成獨立函式。",
     "reason": "刻意設計：main 為線性 pipeline orchestrator，Step1~Step11 以註解清楚分段、依序執行；拆分為多函式屬風格偏好，會增加間接性與重構風險，現階段不採納（非邏輯缺陷）。"
+  },
+  {
+    "location": "app/llm.js:232",
+    "role": "Leo",
+    "original_finding": "extractJSONText is returning an unexpected result; suggest returning an empty array or throwing when no JSON is found.",
+    "reason": "誤報：extractJSONText 的合約刻意是「盡力擷取，找不到合法 JSON 時回傳去 fence 後的原文」，呼叫端（chatJSON 等）依賴此行為再做後續解析與 AI 修復。改成回 [] 或丟例外會破壞既有呼叫鏈，且型別不一致（回傳值為字串非陣列），故不採納。"
   }
 ]

.gitea/ai-review/findings.json

@@ -7,45 +7,6 @@
     "suggestion": "正式環境嚴禁使用 `--no-check-certificate`。若遇到憑證問題，應排查環境配置（如是否缺少根憑證），或是確實解決憑證驗證問題，確保套件來源可信。",
     "is_new": false
   },
-  {
-    "level": "critical",
-    "role": "Maya",
-    "problem": "isSafeRepoPath 函式對於路徑穿越（Directory Traversal）的驗證邏輯至關重要，但目前新增處完全沒有相對應的安全性測試案例，無法確保無法被惡意路徑繞過。",
-    "suggestion": "請補齊測試案例，驗證包含 '../', '..\\', 或以絕對路徑開頭的惡意輸入，確保該函式能正確阻擋所有非預期的路徑穿越攻擊。",
-    "location": "app/resolve.js:142",
-    "is_new": false
-  },
-  {
-    "level": "critical",
-    "role": "Rogue",
-    "location": "app/findings.js:84",
-    "problem": "這函式在 inner loop 被瘋狂呼叫，每次都跑四次重量級的字串正則替換 (normalize, replace, trim)，若這與排除規則做笛卡爾積比對，效能直接雪崩。",
-    "suggestion": "針對 findings 與 exclusions 的內容，採用「首次計算後快取 (Memoization)」機制，不要重複對同一段文字計算正規化。",
-    "is_new": true
-  },
-  {
-    "level": "critical",
-    "role": "Maya",
-    "location": "app/json.js:69",
-    "problem": "validateJSONArrayFile 函式在 AI 修復後會直接覆寫檔案，但這部分邏輯完全沒有對應的單元測試，如果 AI 修復失敗或產生了無效 JSON，系統可能會產生毀損的 findings 檔案。",
-    "suggestion": "補上測試案例，模擬 repairJSONArrayWithAI 失敗、模擬修復後產生 invalid JSON，確保程式會拋出例外且不會覆寫原檔案。"
-  },
-  {
-    "level": "critical",
-    "problem": "`findingRow` 直接存取 `f.role` 且無空值檢查，`f` 為空值時會造成程式崩潰。",
-    "suggestion": "加入空值判斷，避免程式崩潰",
-    "location": "app/comments.js:15",
-    "role": "Mage",
-    "is_new": true
-  },
-  {
-    "level": "critical",
-    "role": "Maya",
-    "problem": "extractBalancedJSON 處理括號平衡解析的邏輯相當複雜，且直接操作字串索引，非常容易在處理特殊字元或不完整 JSON 片段時產生錯誤，目前完全沒有針對邊界條件的單元測試。",
-    "suggestion": "建議編寫針對性的單元測試，包含深層巢狀結構、跳脫字元字串、不完整 JSON、與非法起始字元的邊界測試案例，以確保解析器的魯棒性。",
-    "location": "app/llm.js:99",
-    "is_new": false
-  },
   {
     "level": "warning",
     "role": "Assassin",
@@ -62,84 +23,12 @@
     "suggestion": "若此 flag 僅為暫時性，應盡快優化環境以移除它；若不可避免，應將此設定集中管理，而非在 Dockerfile 中寫死此類不安全的設定。",
     "is_new": false
   },
-  {
-    "level": "warning",
-    "role": "Rogue",
-    "location": "app/config.js:21",
-    "problem": "每次呼叫都 new https.Agent()，這會建立全新的 TCP 連線池，不僅增加記憶體碎片，還浪費三次握手建立連線的時間，根本沒發揮連線池的優勢。",
-    "suggestion": "將 Agent 實例化為模組層級的靜態變數（Singleton），只在第一次呼叫時建立，後續重複使用。",
-    "is_new": true
-  },
-  {
-    "level": "warning",
-    "role": "Maya",
-    "problem": "normalizeText 執行了複雜的字元正規化（NFKC、標點符號壓縮），這是 findings 去重比對的核心邏輯，但目前缺乏測試來驗證其對各種 Unicode 變體、全形/半形符號的處理是否符合預期。",
-    "suggestion": "請補上測試用例，輸入包含全形/半形標點符號、各種 Unicode 組合字元的測試資料，確保正規化結果的一致性。",
-    "location": "app/findings.js:73",
-    "is_new": false
-  },
-  {
-    "level": "warning",
-    "role": "Maya",
-    "problem": "repairJSONArrayWithAI 是修正 JSON 陣列的重要邏輯，但新增後未見針對其「對 LLM 輸出內容進行修復」的情境進行測試，若模型輸出異常或格式混亂時，此函式是否能穩定產出合法 JSON 陣列未被驗證。",
-    "suggestion": "請建立測試用例，模擬各類 malformed JSON 字串（如缺少括號、註解、 markdown 殘留），驗證 repairer 是否能確實將其修復為可解析的 JSON 陣列。",
-    "location": "app/json.js:22",
-    "is_new": false
-  },
-  {
-    "level": "warning",
-    "role": "Rogue",
-    "location": "app/comments.js:51",
-    "problem": "每一項比較都在做 LEVEL_ORDER.includes 與 indexOf 搜尋，若 findings 超過千筆，這些無謂的搜尋將浪費大量 CPU 週期。",
-    "suggestion": "在 bySeverity 外部將 LEVEL_ORDER 預先處理成 Map<string, number>，排序時直接 Map 取值，時間複雜度從 O(N log N * M) 降至 O(N log N)。",
-    "is_new": true
-  },
-  {
-    "level": "warning",
-    "role": "Maya",
-    "location": "app/git.js:146",
-    "problem": "`commitAndPush` 函式在 `git push` 失敗時僅記錄了 warning 且不拋出例外。這意味著如果 push 失敗（例如網路問題、衝突），系統會誤以為 review 已完成並發布，測試案例中沒有驗證 push 失敗後對於整個 CI pipeline 狀態的影響。",
-    "suggestion": "即使不希望中斷流程，也應該在測試中明確驗證此時是否會觸發後續的告警機制或讓狀態檢查器偵測到失敗，確保沒有被誤當成執行成功。",
-    "is_new": true
-  },
-  {
-    "level": "info",
-    "role": "Maya",
-    "problem": "新增了許多輔助性的 formatting 函式（如 findingRow, buildTable 等），雖為內部使用，但這類字串處理邏輯若沒有測試覆蓋，極易因修改格式而導致 Markdown 輸出損壞。",
-    "suggestion": "雖然是輔助函式，但建議在 test/comments.test.js 中補齊這些 formatting 函式的斷言測試，確保輸出格式穩定。",
-    "location": "app/comments.js:16",
-    "is_new": false
-  },
-  {
-    "level": "info",
-    "role": "Bard",
-    "problem": "這裡同時出現了普通註解與 JSDoc，內容描述重複，顯得較為冗餘。",
-    "suggestion": "移除該行普通註解（// 等級無法...），僅保留下方的 JSDoc 即可。",
-    "location": "app/comments.js:103",
-    "is_new": false
-  },
-  {
-    "level": "info",
-    "role": "Leo",
-    "location": "app/llm.js:232",
-    "problem": "`extractJSONText` is returning an unexpected result.",
-    "suggestion": "Modify `extractJSONText` to return an empty array or throw an exception when no JSON is found.",
-    "is_new": true
-  },
   {
     "level": "info",
     "role": "Leo",
     "location": "app/git.js:194",
     "problem": "`withAskpass` is tightly coupled with Gitea's bot-trigger behavior.",
     "suggestion": "Encapsulate bot commit logic within `commitAndPush`, auto-selecting the correct `GITEA_COMMENT_TOKEN`.",
-    "is_new": true
-  },
-  {
-    "level": "info",
-    "role": "Maya",
-    "location": "app/test/json.test.js:33",
-    "problem": "雖然有 `repairJSONArrayWithAI` 的測試，但沒有測試當 `chatFn` 拋出錯誤時，`validateJSONArrayFile` 是否正確地向上拋出該例外，缺乏失敗路徑的健壯性驗證。",
-    "suggestion": "在 `json.test.js` 增加一個測試案例，mock `repairer` 為拋出 Error，驗證 `validateJSONArrayFile` 的錯誤傳遞路徑。",
-    "is_new": true
+    "is_new": false
   }
 ]

.gitea/workflows/ci.yaml

@@ -42,7 +42,7 @@ jobs:
       # 傳遞給 composite action 的輸入參數
       with:
         # 留言用 token：取自 secret COMMENT_TOKEN，供 action 在 PR 上發布審查留言
-        token: ${{ secrets.COMMENT_TOKEN }}
+        token: ${{ secrets.TOKEN }}
         opencode_base_url: ${{ vars.OPENCODE_BASE_URL }}
         opencode_provider: ${{ vars.OPENCODE_PROVIDER }}
         opencode_model: ${{ vars.OPENCODE_PROVIDER_MODEL }}