.gitea/ai-review/exclusions.json

@@ -658,5 +658,104 @@
     "endLine": 72,
     "problem": "`redactSecrets` / `agentFailureDetail` 新增了輸出 stderr/stdout 診斷的行為，但沒有測試驗證遮罩規則與限長。這不是單純格式調整；一旦正規式或順序被改壞，失敗 log 可能變得不可診斷，或把控制字元與憑證樣式原樣輸出。",
     "reason": "Paladin：可排除（重複）。歷史 findings 已針對 redactSecrets／agentFailureDetail 的控制字元、憑證樣式、URL 帳密、截斷與 debug 開關缺少測試提出相同問題。"
+  },
+  {
+    "addedAt": "2026/07/20 17:27:30",
+    "prNumber": 6,
+    "reviewer": "Assassin",
+    "severity": "嚴重",
+    "file": "src/lib/review.js",
+    "startLine": 74,
+    "endLine": 77,
+    "problem": "攻擊者只要讓 AI CLI 失敗，這裡就會把 stderr/stdout 片段寫進 CI log。那些輸出可能包含 prompt、diff 內容、環境診斷、第三方 CLI 錯誤訊息，甚至 token、API key、JWT、email 或其他 PII；`redactSecrets` 只是樣式比對，漏掉未列舉格式時，秘密會被永久留在多人可讀的建置紀錄裡。",
+    "reason": "Paladin：可排除（重複）。歷史 finding 已針對 AI CLI stderr/stdout 寫入 CI log、黑名單式遮罩可繞過，以及 token／PII 外洩風險提出相同問題。"
+  },
+  {
+    "addedAt": "2026/07/20 17:27:30",
+    "prNumber": 6,
+    "reviewer": "Bard",
+    "severity": "建議",
+    "file": "src/index.js",
+    "startLine": 206,
+    "endLine": 217,
+    "problem": "`ensureIssueCreated` 這個名字唱的是「確保存在」，但實作每次呼叫都會直接建立新 issue；名稱與行為不同拍，日後重用時很容易誤讀。",
+    "reason": "Paladin：可排除（重複）。歷史 finding 已明確指出 `ensureIssueCreated` 名稱暗示冪等沿用，實作卻會建立新 issue，與本條指控相同。"
+  },
+  {
+    "addedAt": "2026/07/20 17:27:30",
+    "prNumber": 6,
+    "reviewer": "Leo",
+    "severity": "警告",
+    "file": "src/index.js",
+    "startLine": 176,
+    "endLine": 363,
+    "problem": "建問題模式把「留言目的地切換、issue 延後建立、標籤挑選、嚴重/非嚴重發布、PR 回貼連結、相依設定」全部塞進 `main()`，讓主流程同時承擔流程編排與發布策略。六個月後要改任何一種輸出模式時，很容易漏改其中一個 `ctx.createIssue` 分支，或讓一般模式與建問題模式的行為逐步分岔。",
+    "reason": "Paladin：可排除（命中已知排除事項且重複）。既有紀錄已涵蓋 `main()` 內留言路由、issue 生命週期、標籤、相依設定與發布職責耦合的問題。"
+  },
+  {
+    "addedAt": "2026/07/20 17:27:30",
+    "prNumber": 6,
+    "reviewer": "Leo",
+    "severity": "建議",
+    "file": "src/lib/review.js",
+    "startLine": 31,
+    "endLine": 53,
+    "problem": "`agentFailureDetail` 的說明提到「需要原始輸出診斷時，於 workflow 設定 secret `ACTIONS_STEP_DEBUG=true` 再重跑」，但實作其實不看 `ACTIONS_STEP_DEBUG`，預設就會輸出遮罩後的 stderr/stdout 片段。註解與行為不一致會讓未來維護者誤判這段診斷的暴露條件。",
+    "reason": "Paladin：可排除（與 F001 重複）。本條同樣指向 `agentFailureDetail` 預設輸出 stderr/stdout 片段、與 debug 暴露條件不一致的同一行為；F001 已保留其核心風險。"
+  },
+  {
+    "addedAt": "2026/07/20 17:27:30",
+    "prNumber": 6,
+    "reviewer": "Mage",
+    "severity": "警告",
+    "file": "src/index.js",
+    "startLine": 219,
+    "endLine": 228,
+    "problem": "`ensureIssueCreated` 先建立 issue，再逐則寫入暫存留言；任一留言 API 在中途失敗時，流程會直接丟出例外結束，但已建立的 issue 不會回滾，也沒有可重用的識別。最小情境：issue 建立成功，寫入第 2 則 `issueBuffer` 留言時 Gitea 暫時回 500；本次 action 失敗，下一次重跑會再建立一個新 issue，留下重複且內容不完整的追蹤 issue。",
+    "reason": "Paladin：可排除（命中已知排除事項且重複）。建立 issue 後沖刷暫存留言失敗、重跑又建立重複 issue，正是既有排除事項與多筆歷史 finding 已涵蓋的問題。"
+  },
+  {
+    "addedAt": "2026/07/20 17:27:30",
+    "prNumber": 6,
+    "reviewer": "Maya",
+    "severity": "警告",
+    "file": "src/index.js",
+    "startLine": 312,
+    "endLine": 383,
+    "problem": "建問題模式的核心流程被大幅改寫，但這段新增行為還沒看到對應測試驗證：`kept.length > 0` 才建 issue、標籤挑選失敗要降級、嚴重與非嚴重問題要改發到 issue、最後還要回貼 PR 並嘗試建立 issue dependency。這些都是跨 API 的分支與失敗路徑，沒有測試時很容易只跑到快樂路徑，漏掉「沒有保留問題」「標籤 API 失敗」「dependency API 不支援」這類實際會發生的情境。",
+    "reason": "Paladin：可排除（重複）。歷史 findings 已涵蓋建問題模式的 issue 建立條件、標籤降級、問題分流、PR 回貼與 dependency 失敗路徑缺少測試。"
+  },
+  {
+    "addedAt": "2026/07/20 17:27:30",
+    "prNumber": 6,
+    "reviewer": "Maya",
+    "severity": "警告",
+    "file": "src/lib/gitrepo.js",
+    "startLine": 102,
+    "endLine": 151,
+    "problem": "`resolveMergeBase` 新增了淺層 checkout 修復策略與多段 fallback，但邊界與失敗路徑還沒被驗證：初次 fetch 成功但 merge-base 失敗、`--unshallow` 成功後立即成功、`deepen base` 成功、`deepen HEAD` 成功，以及所有策略都失敗時錯誤訊息要包含診斷。這段是 review diff 的基準點，沒測到 fallback 行為就等於沒有確認淺層 checkout 的修復真的可用。",
+    "reason": "Paladin：可排除（重複）。歷史 findings 已針對 `resolveMergeBase` 多階段 fetch、淺層／非淺層分支、停止條件與最終診斷缺少測試提出相同問題。"
+  },
+  {
+    "addedAt": "2026/07/20 17:27:30",
+    "prNumber": 6,
+    "reviewer": "Maya",
+    "severity": "警告",
+    "file": "src/lib/gitrepo.js",
+    "startLine": 266,
+    "endLine": 314,
+    "problem": "push 行為從「先 origin、失敗才帶 token URL 重試」改成一律透過 `pushWithCredential` 用環境變數注入 Basic header，但新增的認證與錯誤遮蔽行為沒有測試驗證。這裡的失敗路徑如果沒測，很容易在 push 失敗時回歸成洩漏 argv/token，或 refspec/remoteUrl 組錯卻直到 CI 才發現。",
+    "reason": "Paladin：可排除（重複）。歷史 finding 已涵蓋 `pushToken`、origin 與 credential push 策略、認證遮蔽及 push 失敗路徑缺少測試。"
+  },
+  {
+    "addedAt": "2026/07/20 17:27:30",
+    "prNumber": 6,
+    "reviewer": "Maya",
+    "severity": "警告",
+    "file": "src/lib/review.js",
+    "startLine": 14,
+    "endLine": 73,
+    "problem": "`agentFailureDetail` 現在會把 AI CLI 的 stderr/stdout 片段寫進 log，並依賴 `redactSecrets` 做遮罩與單行化；但這段新增的失敗診斷路徑沒有看到測試覆蓋。這不只是快樂路徑問題，邊界包含空輸出、只有 stdout、逾時 killed、換行控制字元、Authorization/token/URL credentials/長 token 等格式，任何一個漏掉都會讓診斷品質或遮罩行為失真。",
+    "reason": "Paladin：可排除（重複）。歷史 finding 已記錄 `agentFailureDetail`／`redactSecrets` 對空輸出、控制字元、憑證格式、URL 帳密、截斷與 debug 開關缺少測試。"
   }
 ]