.gitea/ai-review/exclusions.json

@@ -1582,5 +1582,115 @@
     "endLine": 370,
     "problem": "建問題模式下把 `others` 交給 `review.postOthersToIssue` 逐條發 issue 留言，這是在拿遠端 API latency 燒時間。警告／建議通常可能比嚴重問題多很多，若有 50 條、每次 Gitea API 往返 200ms，光留言就可能多花 10 秒以上，還會增加 rate limit 壓力。",
     "reason": "Paladin：可排除（重複）。歷史 finding 已指出建問題模式將警告／建議逐條發成 issue 留言，會造成 O(n) 遠端 POST、增加 CI 時間與 rate limit 壓力。"
+  },
+  {
+    "addedAt": "2026/07/21 13:49:59",
+    "prNumber": 6,
+    "reviewer": "Assassin",
+    "severity": "警告",
+    "file": "action.yml",
+    "startLine": 19,
+    "endLine": 24,
+    "problem": "文件鼓勵呼叫端傳入「能觸發 CI 的 PAT」。這把原本自動 token 的防遞迴與範圍限制換成長效、較高權限的秘密。若 workflow 會在不受信任的 PR 程式碼或可被 PR 修改的 action 版本上執行，攻擊者可以在 CI 中讀取或外送 PAT，接著用它 push commit、改 issue、或觸發更多 workflow。",
+    "reason": "Paladin：可排除（重複）。歷史 findings 已針對 action.yml 建議使用可觸發 CI 的 PAT 所帶來的長效高權限憑證風險提出相同問題。"
+  },
+  {
+    "addedAt": "2026/07/21 13:49:59",
+    "prNumber": 6,
+    "reviewer": "Bard",
+    "severity": "建議",
+    "file": "action.yml",
+    "startLine": 2,
+    "endLine": 3,
+    "problem": "檔頭 `更新時間` 仍寫著 `2026/07/17 18:49:58`，但本次變更描述顯示此檔最後更新為 `2026/07/20 17:24:18`。文件時間戳若成了舊拍子，讀者會開始懷疑整份 manifest 的註解是否也同樣過期。",
+    "reason": "Paladin：可排除（重複）。歷史 finding 已指出 action.yml 檔頭手動更新時間容易過期且與實際內容不同。"
+  },
+  {
+    "addedAt": "2026/07/21 13:49:59",
+    "prNumber": 6,
+    "reviewer": "Bard",
+    "severity": "建議",
+    "file": "src/index.js",
+    "startLine": 7,
+    "endLine": 7,
+    "problem": "啟動 banner 的 `更新時間` 被改成 `2026/07/17 18:49:58`，但這次主流程明顯新增了建 issue、延後解決舊留言等大量段落。這個時間戳像留在舊譜上的小節號，和目前程式內容不再合拍。",
+    "reason": "Paladin：可排除（重複）。歷史 finding 已指出 src/index.js 啟動 banner 的手動更新時間與程式實際變更不同，屬同一問題。"
+  },
+  {
+    "addedAt": "2026/07/21 13:49:59",
+    "prNumber": 6,
+    "reviewer": "Leo",
+    "severity": "警告",
+    "file": "src/index.js",
+    "startLine": 180,
+    "endLine": 390,
+    "problem": "`main()` 這次把建問題模式的暫存留言、issue 建立、標籤挑選、PR 回貼、相依設定、一般模式舊留言清理全部塞進同一個流程函式。半年後要改任何一個輸出通道時，維護者必須重新推演 `ctx.createIssue`、`issue`、`issueBuffer`、`currentRunCommentIds` 與步驟 2 延後執行之間的狀態關係，這會讓主流程變成難以安全修改的編排巨石。",
+    "reason": "Paladin：可排除（命中已知排除事項且重複）。main() 內建問題模式狀態、留言路由、issue 建立與發布職責耦合，已由既有排除事項與歷史 findings 涵蓋。"
+  },
+  {
+    "addedAt": "2026/07/21 13:49:59",
+    "prNumber": 6,
+    "reviewer": "Leo",
+    "severity": "警告",
+    "file": "src/index.js",
+    "startLine": 199,
+    "endLine": 232,
+    "problem": "`queueOrPostComment` 透過閉包同時讀寫 `ctx.createIssue`、`issue`、`issueBuffer`、`currentRunCommentIds`，回傳型別也會依狀態變成 `Object|null`。這種隱性狀態機短期能跑，但未來要追「這則留言到底會發到 PR、issue，還是只進 buffer」時，必須靠讀整個 `main()` 的執行順序才能理解。",
+    "reason": "Paladin：可排除（重複）。queueOrPostComment 的閉包狀態與留言目的地隱性分流，與既有 main() 留言路由、issue 狀態與緩衝佇列耦合問題相同。"
+  },
+  {
+    "addedAt": "2026/07/21 13:49:59",
+    "prNumber": 6,
+    "reviewer": "Leo",
+    "severity": "建議",
+    "file": "readme.md",
+    "startLine": 76,
+    "endLine": 131,
+    "problem": "README 的功能列表繼續維護大量硬編碼到 `develop` 分支與精確行號的連結。這次 diff 已經為了行號漂移更新一整片表格；之後任何新增註解、移動函式或插入測試都會讓文件連結過期，維護成本會隨每次重構累積。",
+    "reason": "Paladin：可排除（重複）。歷史 findings 已多次指出 README 大量硬編 develop 分支與精確行號連結，會隨程式碼移動失準。"
+  },
+  {
+    "addedAt": "2026/07/21 13:49:59",
+    "prNumber": 6,
+    "reviewer": "Mage",
+    "severity": "嚴重",
+    "file": "src/index.js",
+    "startLine": 409,
+    "endLine": 418,
+    "problem": "建問題模式下若有嚴重問題但 `exclusions.json` 沒變更，`filesToCommit` 會是空陣列，流程會走到「略過 commit/push」後直接 `return 0`。最小重現：`create-issue=true`、攻擊方保留 1 條 `severity: '嚴重'`、防守方沒有排除任何 finding，因此 `exclusionsChanged=false`。此時本輪檢查成功，且沒有推出 `[ai-review-bot][failure]` commit 觸發下一輪步驟 1 回報失敗；若 issue dependency API 未啟用或設定失敗，嚴重問題不會阻擋合併。",
+    "reason": "Paladin：可排除（重複）。與 F001 指涉同一個建問題模式下嚴重 finding 可能未產生可阻擋失敗訊號、最後回傳成功的問題。"
+  },
+  {
+    "addedAt": "2026/07/21 13:49:59",
+    "prNumber": 6,
+    "reviewer": "Maya",
+    "severity": "警告",
+    "file": "src/index.js",
+    "startLine": 323,
+    "endLine": 390,
+    "problem": "建問題模式的核心流程新增了多個可觀察行為，但目前測試沒有驗證：有保留問題才建立 issue、無保留問題靜默通過、暫存的工具／diff／角色留言會 flush 到 issue、PR 只回貼 issue 連結、且只有嚴重問題才呼叫 `addIssueDependency`。這些都是本次 PR 新增／改動的主要行為，沒有試煉過就等於還沒完成。",
+    "reason": "Paladin：可排除（重複）。歷史 findings 已涵蓋建問題模式有問題才建 issue、無問題靜默通過、暫存留言 flush、PR 回貼與嚴重問題相依設定等核心分支缺少測試。"
+  },
+  {
+    "addedAt": "2026/07/21 13:49:59",
+    "prNumber": 6,
+    "reviewer": "Maya",
+    "severity": "警告",
+    "file": "src/lib/gitrepo.js",
+    "startLine": 130,
+    "endLine": 190,
+    "problem": "`resolveMergeBase` 新增了多段 fetch 補歷史策略、每步後重試 merge-base、淺層 repo 才 `--unshallow`、以及失敗診斷彙整，但新增測試只驗證不安全 `baseRef` 會被拒絕，沒有覆蓋這些成功與失敗路徑。這裡最怕的是淺層 checkout 或 PR head 歷史不足時，實際 CI 才發現 fetch 順序或 refspec 錯了。",
+    "reason": "Paladin：可排除（重複）。歷史 findings 已針對 resolveMergeBase 的多階段 fetch、淺層／非淺層分支、停止條件、降級與最終失敗診斷缺少測試提出相同問題。"
+  },
+  {
+    "addedAt": "2026/07/21 13:49:59",
+    "prNumber": 6,
+    "reviewer": "Maya",
+    "severity": "警告",
+    "file": "src/lib/gitrepo.js",
+    "startLine": 303,
+    "endLine": 358,
+    "problem": "推送結果 commit 的認證方式改成 `pushWithCredential`：不走 origin、自訂 `GIT_CONFIG_*` extraheader、先清掉 checkout token、URL origin 必須相符、失敗時隱藏遠端與 token。這些安全與 CI 觸發相關行為目前完全沒有測試；現有 `gitrepo.test.js` 只測分支名稱驗證。",
+    "reason": "Paladin：可排除（重複）。歷史 findings 已記錄 commitAndPushFindings／pushWithCredential 的 token 認證推送路徑、推送目標、錯誤遮蔽與安全行為缺少測試。"
   }
 ]