.gitea/ai-review/exclusions.json

@@ -834,5 +834,115 @@
     "endLine": 72,
     "problem": "`agentFailureDetail` 現在會把 stderr/stdout 片段寫進 CI log，雖然有 `redactSecrets`，但沒有看到測試驗證遮罩規則與截斷邊界。這不是快樂路徑；一旦 AI CLI 失敗，未驗證的遮罩就會變成長期保存的 log 風險。",
     "reason": "Paladin：可排除（重複）。歷史 finding 已涵蓋 redactSecrets／agentFailureDetail 對 Authorization、token、URL 帳密、控制字元、截斷與空輸出等邊界缺少測試。"
+  },
+  {
+    "addedAt": "2026/07/20 17:36:21",
+    "prNumber": 6,
+    "reviewer": "Assassin",
+    "severity": "嚴重",
+    "file": "src/lib/review.js",
+    "startLine": 72,
+    "endLine": 75,
+    "problem": "這裡把 AI CLI 的 stderr/stdout 片段預設寫進 CI log。攻擊者可以讓 CLI 失敗並把 prompt、diff、環境診斷、token、JWT、內部 URL 或 PR 內容中的敏感資料噴到 stdout/stderr；`redactSecrets` 只是正規表示式盡力遮罩，漏掉格式外的憑證或 PII 時，機密就被長期保存到多人可讀的 CI log。",
+    "reason": "Paladin：可排除（重複）。歷史 finding 已針對 debug/失敗診斷輸出 AI CLI stderr/stdout、黑名單式遮罩可繞過，以及機密或個資外洩提出相同問題。"
+  },
+  {
+    "addedAt": "2026/07/20 17:36:21",
+    "prNumber": 6,
+    "reviewer": "Bard",
+    "severity": "建議",
+    "file": "src/index.js",
+    "startLine": 180,
+    "endLine": 235,
+    "problem": "`main()` 裡新增了兩個閉包 helper，再各自搭配整段 JSDoc，像把副歌、橋段與註腳全塞進同一小節。這些註解本身不差，但放在主流程中間會稀釋流程主線，讓讀者在真正開始步驟 3 前先穿過一大段實作細節。",
+    "reason": "Paladin：可排除（重複）。歷史 findings 已涵蓋 `main()` 內留言路由、issue 建立、緩衝佇列與閉包 helper 造成主流程職責混雜，並提出抽出發布協作者的相同方向。"
+  },
+  {
+    "addedAt": "2026/07/20 17:36:21",
+    "prNumber": 6,
+    "reviewer": "Leo",
+    "severity": "警告",
+    "file": "src/index.js",
+    "startLine": 180,
+    "endLine": 234,
+    "problem": "`main()` 這次被塞進建問題模式的留言路由、issue 暫存佇列、issue 建立流程與標籤套用邏輯。未來只要要調整「留言要發到 PR 還是 issue」、「何時 flush 暫存留言」、「哪些模式要靜默通過」，維護者都必須在主流程裡追閉包狀態（`issueBuffer`、`issue`、`currentRunCommentIds`），主流程會越來越像狀態機但沒有清楚邊界。",
+    "reason": "Paladin：可排除（命中已知排除事項且重複）。既有紀錄已涵蓋 `main()` 中 issue 狀態、`issueBuffer`、留言路由與發布狀態機職責耦合的同一問題。"
+  },
+  {
+    "addedAt": "2026/07/20 17:36:21",
+    "prNumber": 6,
+    "reviewer": "Leo",
+    "severity": "警告",
+    "file": "src/index.js",
+    "startLine": 309,
+    "endLine": 390,
+    "problem": "建問題模式的收束流程散在多段 `if (ctx.createIssue)` 分支中：建立 issue、選標籤、嚴重問題留言、其他問題留言、PR 回貼連結、設定 dependency 都在 `main()` 裡交錯。這讓「建問題模式」沒有單一可讀入口，未來維護者要確認模式行為時必須跨多個區塊拼湊流程，尤其容易漏掉 `issue` 只在 `kept.length > 0` 後才存在的隱含前提。",
+    "reason": "Paladin：可排除（重複）。歷史 findings 已指出建問題模式的 issue 建立、留言分流、PR 回貼與 dependency 等流程散落在 `main()`，同屬發布流程邊界不清。"
+  },
+  {
+    "addedAt": "2026/07/20 17:36:21",
+    "prNumber": 6,
+    "reviewer": "Leo",
+    "severity": "建議",
+    "file": "src/lib/review.js",
+    "startLine": 30,
+    "endLine": 44,
+    "problem": "`agentFailureDetail` 的文件先說「原始輸出預設隱藏」，後面又說預設附上遮罩後的 stderr/stdout 片段。這種註解與實作語意互相打架，未來維護者很容易誤判 CI log 會不會包含 CLI 輸出，進而在調整遮罩或除錯策略時做錯取捨。",
+    "reason": "Paladin：可排除（重複）。與 F003 指涉同一段 `agentFailureDetail` 文件，問題同為「預設隱藏原始輸出」與「預設輸出遮罩片段」語意互相衝突。"
+  },
+  {
+    "addedAt": "2026/07/20 17:36:21",
+    "prNumber": 6,
+    "reviewer": "Mage",
+    "severity": "嚴重",
+    "file": "src/index.js",
+    "startLine": 397,
+    "endLine": 415,
+    "problem": "在 `create-issue=true` 且本輪有保留的嚴重問題、但 `excluded` 為空時，`exclusionsChanged` 會是 `false`，建問題模式又不 commit findings，因此收尾會「略過 commit/push」後直接 `return 0`。最小重現：PR 只有 1 條嚴重 finding、沒有任何誤判排除、問題相依 API 未啟用或設定失敗；流程會建立 issue、相依設定被 catch 成 WRN，沒有 `[failure]` 結果 commit，也沒有下一輪步驟 1 可回報失敗，最後 CI 成功通過。",
+    "reason": "Paladin：可排除（重複）。與 F001 指涉同一個嚴重 finding gate 依賴後續 commit/push 或 dependency side effect、而本輪可能直接回傳 0 的問題。"
+  },
+  {
+    "addedAt": "2026/07/20 17:36:21",
+    "prNumber": 6,
+    "reviewer": "Maya",
+    "severity": "警告",
+    "file": "src/index.js",
+    "startLine": 180,
+    "endLine": 409,
+    "problem": "建問題模式的流程被大幅改寫，但 diff 沒看到對應測試驗證這些新分支：留言先暫存到 `issueBuffer`、`kept.length > 0` 才建立 issue、無保留問題／無可審查變更時靜默通過、PR 回貼 issue 連結，以及只有嚴重問題才呼叫 `addIssueDependency`。這些都是使用者可觀察行為，沒有測試就很容易在之後調整流程時被改壞。",
+    "reason": "Paladin：可排除（重複）。歷史 findings 已涵蓋建問題模式的暫存留言、有 finding 才建 issue、靜默通過、PR 回貼、嚴重問題與 dependency 等核心分支缺少測試。"
+  },
+  {
+    "addedAt": "2026/07/20 17:36:21",
+    "prNumber": 6,
+    "reviewer": "Maya",
+    "severity": "警告",
+    "file": "src/lib/gitrepo.js",
+    "startLine": 102,
+    "endLine": 159,
+    "problem": "`resolveMergeBase` 新增了多段 fetch／unshallow／deepen fallback 與錯誤診斷，但沒有看到針對淺層 checkout、fetch 失敗、merge-base 首次失敗後成功、所有策略失敗等邊界的測試。這段決定送審 diff 的基準，一旦 fallback 順序或錯誤處理壞掉，審查可能漏看或多看變更。",
+    "reason": "Paladin：可排除（重複）。歷史 findings 已針對 `resolveMergeBase` 多階段 fetch、淺層 checkout、成功停止條件與全部失敗診斷缺少測試提出相同問題。"
+  },
+  {
+    "addedAt": "2026/07/20 17:36:21",
+    "prNumber": 6,
+    "reviewer": "Maya",
+    "severity": "警告",
+    "file": "src/lib/gitrepo.js",
+    "startLine": 266,
+    "endLine": 297,
+    "problem": "push 行為改成一律走 `pushWithCredential`，並宣稱 token 不進 argv、失敗時隱藏 URL／認證資訊，但沒有測試覆蓋成功與失敗路徑。這裡一旦 regression，可能導致結果 commit 推不上去，或失敗訊息洩漏認證材料。",
+    "reason": "Paladin：可排除（重複）。歷史 findings 已涵蓋 pushToken／pushWithCredential 的推送策略、認證環境變數、失敗遮蔽與成功失敗路徑缺少測試。"
+  },
+  {
+    "addedAt": "2026/07/20 17:36:21",
+    "prNumber": 6,
+    "reviewer": "Maya",
+    "severity": "警告",
+    "file": "src/lib/review.js",
+    "startLine": 13,
+    "endLine": 84,
+    "problem": "`agentFailureDetail` 現在會把 AI CLI 的 stderr/stdout 片段寫進 CI log，並依賴 `redactSecrets` 遮罩機密；但新增的遮罩規則與截斷規則沒有測試。這是典型失敗路徑，平常快樂路徑不會跑到，沒測過就無法相信它真的能處理 Authorization、token、URL 帳密、控制字元與長金鑰。",
+    "reason": "Paladin：可排除（重複）。歷史 findings 已涵蓋 `redactSecrets`／`agentFailureDetail` 對 Authorization、token、URL 帳密、控制字元、長輸出與空輸出等邊界缺少測試。"
   }
 ]