chore: update ai-review findings [ai-review-bot][failure]

2026-07-20 08:03:45 +00:00
parent 4c2b6d4265
commit 7823718ff4
1 changed files with 132 additions and 0 deletions
@@ -196,5 +196,137 @@
    "endLine": 268,
    "problem": "舊審查留言仍在本回合結果完整發布前就被標記為過時；建議把清理舊留言移到本輪所有必要結果均成功產生之後，避免失敗重跑留下「舊結果已清除、新結果不完整」的中間狀態。",
    "reason": "維護者裁示（議題 #8 留言 #4838，系統管理員）：此功能用途為把前一輪 PR 產生的訊息標記為已解決／過時，讓審查人員辨識舊訊息，因此刻意在本回合結果之前執行，不可延後，否則會誤導審查人員。依維護者決定不採納此修改，記為排除以免後續審查重複提出。"
+  },
+  {
+    "addedAt": "2026/07/20 16:03:44",
+    "prNumber": 6,
+    "reviewer": "Assassin",
+    "severity": "嚴重",
+    "file": "src/lib/review.js",
+    "startLine": 54,
+    "endLine": 75,
+    "problem": "開啟 `ACTIONS_STEP_DEBUG=true` 後會把 AI CLI 的原始 stderr/stdout 寫入永久 CI log，但 `redactSecrets` 是可繞過的黑名單，也完全沒有移除 PII。攻擊者可透過惡意 diff／提示注入，要求 CLI 以未涵蓋的格式輸出憑證、電子郵件或其他敏感資料；例如短版金鑰、含標點的 token、JWT 或拆段輸出都可能避開現有正規表示式，造成機密與 PII 外洩。",
+    "reason": "Paladin：可排除（重複）。歷史 finding 已針對 debug 模式輸出 AI CLI stderr／stdout、黑名單遮罩可繞過及敏感內容外洩提出相同問題。"
+  },
+  {
+    "addedAt": "2026/07/20 16:03:44",
+    "prNumber": 6,
+    "reviewer": "Bard",
+    "severity": "建議",
+    "file": "src/index.js",
+    "startLine": 220,
+    "endLine": 231,
+    "problem": "`ensureIssueCreated` 之名暗示「若尚未建立才建立」的冪等保證，實作卻會無條件建立新 issue。即使目前只呼叫一次，命名仍會誤導後續維護者，長註解也無法替代準確的動詞。",
+    "reason": "Paladin：可排除（重複）。歷史 finding 已明確指出 `ensureIssueCreated` 名稱暗示冪等沿用，實際卻建立新 issue 並修改外層狀態。"
+  },
+  {
+    "addedAt": "2026/07/20 16:03:44",
+    "prNumber": 6,
+    "reviewer": "Bard",
+    "severity": "建議",
+    "file": "action.yml",
+    "startLine": 45,
+    "endLine": 57,
+    "problem": "新增的 `push-token` 以區塊註解、欄位描述、選填註解與預設值註解反覆敘述「PAT 觸發 CI、留空退回 token」；同一旋律重奏過多，真正重要的使用方式反而埋在十餘行說明裡，且明顯比鄰近 input 冗長。",
+    "reason": "Paladin：可排除（重複）。歷史 finding 已針對 `push-token` 在註解、description、required 與 default 說明中重複敘述相同問題。"
+  },
+  {
+    "addedAt": "2026/07/20 16:03:44",
+    "prNumber": 6,
+    "reviewer": "Leo",
+    "severity": "警告",
+    "file": "src/index.js",
+    "startLine": 180,
+    "endLine": 234,
+    "problem": "`main()` 新增 `issueBuffer`、可變的 `issue`、`postComment` 與 `ensureIssueCreated`，把「決定留言目的地、建立 issue、暫存與沖刷留言」等多項職責綁在閉包狀態中。後續流程又必須知道 issue 是否已建立並直接讀取 `issue.number`；半年後若增加留言種類、重試或其他發布目的地，維護者得同時修改多個分支，也很難隔離單元測試發布狀態轉換。",
+    "reason": "Paladin：可排除（命中已知排除事項且重複）。已知排除事項與歷史 finding 均已涵蓋 `main()` 內留言路由、issue 狀態、緩衝佇列及發布職責耦合的問題。"
+  },
+  {
+    "addedAt": "2026/07/20 16:03:44",
+    "prNumber": 6,
+    "reviewer": "Leo",
+    "severity": "警告",
+    "file": "src/index.js",
+    "startLine": 221,
+    "endLine": 234,
+    "problem": "`ensureIssueCreated` 在所有暫存留言成功寫入前，就先把閉包中的 `issue` 設為已建立；沖刷途中任何一則 API 呼叫失敗，都會留下只寫入部分內容的 issue，且主流程沒有保存進度或可重入機制。重新執行時又會建立另一個 issue。這種部分完成狀態日後很難追查，也會讓重試與錯誤處理持續累積例外分支。",
+    "reason": "Paladin：可排除（命中已知排除事項且重複）。issue 建立後沖刷留言失敗、留下部分完成狀態並在重跑時建立重複 issue，正是既有排除事項與歷史 finding 記錄的同一問題。"
+  },
+  {
+    "addedAt": "2026/07/20 16:03:44",
+    "prNumber": 6,
+    "reviewer": "Mage",
+    "severity": "嚴重",
+    "file": "src/index.js",
+    "startLine": 342,
+    "endLine": 344,
+    "problem": "一般模式在發布新的嚴重／警告留言前，就先把舊審查留言標為過時。最小重現：`resolveOldComments` 成功後，步驟 9 的 `createReview` 或步驟 10 的留言 API 暫時失敗；本次 action 以失敗結束，但上一回合完整結果已被清除，新結果也未完整發布，PR 會失去可信的審查結果。這仍違反本次改動宣稱的「沒有新結果時保留舊結果」語義。",
+    "reason": "Paladin：可排除（命中已知排除事項）。維護者已明確裁示舊留言必須刻意在本回合結果之前標記為過時，以免舊資訊繼續誤導審查人員。"
+  },
+  {
+    "addedAt": "2026/07/20 16:03:44",
+    "prNumber": 6,
+    "reviewer": "Mage",
+    "severity": "警告",
+    "file": "src/index.js",
+    "startLine": 224,
+    "endLine": 233,
+    "problem": "追蹤 issue 的建立與暫存留言寫入不是可重入操作。最小重現：`createIssue` 成功，但寫入 `issueBuffer` 第 2 則留言時 API 失敗；action 結束前沒有在 PR 留下連結或保存已建立的 issue 編號。工作流程重跑時會再建立一個新 issue，留下孤立且內容不完整的舊 issue，並可能持續產生重複 issue。",
+    "reason": "Paladin：可排除（命中已知排除事項且重複）。建立 issue 後留言寫入失敗、未保存可恢復狀態而使重跑建立重複 issue，已由多筆既有排除事項及歷史 finding 完整涵蓋。"
+  },
+  {
+    "addedAt": "2026/07/20 16:03:44",
+    "prNumber": 6,
+    "reviewer": "Maya",
+    "severity": "警告",
+    "file": "src/index.js",
+    "startLine": 311,
+    "endLine": 386,
+    "problem": "建問題模式的核心流程已大幅改寫，但本次 diff 沒有對應測試驗證：有保留問題時才建立 issue、標籤失敗時降級、暫存留言依序送出、嚴重與其他問題分流、PR 回貼連結，以及相依 API 失敗不阻斷流程。這些分支牽涉多次外部呼叫與狀態變化，未經測試容易出現 issue 未建立卻存取 `issue.number`、留言遺失或呼叫順序錯誤。",
+    "reason": "Paladin：可排除（重複）。歷史 finding 已涵蓋建問題模式的 issue 建立條件、標籤降級、暫存留言、問題分流、PR 回貼及相依 API 失敗等核心分支缺少測試。"
+  },
+  {
+    "addedAt": "2026/07/20 16:03:44",
+    "prNumber": 6,
+    "reviewer": "Maya",
+    "severity": "警告",
+    "file": "src/lib/gitrepo.js",
+    "startLine": 103,
+    "endLine": 151,
+    "problem": "`resolveMergeBase` 新增多階段 fetch 復原與錯誤診斷，但沒有測試覆蓋淺層與失敗路徑。尚未驗證 unshallow 成功後會立即停止、fetch 失敗會繼續下一策略、非淺層 repo 不會執行 unshallow，以及所有策略失敗時的錯誤與 `cause` 是否正確；這類 git 邊界通常只會在 CI 的 shallow checkout 才暴露。",
+    "reason": "Paladin：可排除（重複）。歷史 finding 已針對 `resolveMergeBase` 的淺層與非淺層分支、多階段 fetch、停止條件及最終錯誤資訊缺少測試提出相同問題。"
+  },
+  {
+    "addedAt": "2026/07/20 16:03:44",
+    "prNumber": 6,
+    "reviewer": "Maya",
+    "severity": "警告",
+    "file": "src/lib/gitrepo.js",
+    "startLine": 270,
+    "endLine": 313,
+    "problem": "新增的 PAT 推送與憑證注入路徑沒有對應測試。尚未驗證有 `pushToken` 時必須略過 origin、無 `pushToken` 時只有 origin 失敗才使用一般 token、Authorization 僅透過環境變數傳入，以及推送失敗時不會把 token、遠端 URL或原始命令帶入錯誤。這些未驗證行為同時影響 CI 是否重觸發與失敗路徑的機密保護。",
+    "reason": "Paladin：可排除（重複）。歷史 finding 已明確記錄 pushToken、origin 與一般 token 的兩套推送策略、認證資訊遮蔽及失敗路徑缺少測試。"
+  },
+  {
+    "addedAt": "2026/07/20 16:03:44",
+    "prNumber": 6,
+    "reviewer": "Maya",
+    "severity": "警告",
+    "file": "src/lib/review.js",
+    "startLine": 16,
+    "endLine": 80,
+    "problem": "新增的失敗診斷與機密遮罩會處理不可信的 stderr/stdout，但沒有測試驗證邊界與失敗格式。特別是換行控制字元、Authorization、URL 帳密、各種 token 格式、超長輸出截斷，以及 `ACTIONS_STEP_DEBUG` 開關；任何漏測都可能造成除錯模式洩漏機密或產生可偽造的多行 CI 日誌。",
+    "reason": "Paladin：可排除（重複）。歷史 finding 已涵蓋 `redactSecrets`／`agentFailureDetail` 對控制字元、各類憑證、URL 帳密、截斷及 debug 開關等邊界缺少測試。"
+  },
+  {
+    "addedAt": "2026/07/20 16:03:44",
+    "prNumber": 6,
+    "reviewer": "Rogue",
+    "severity": "警告",
+    "file": "src/index.js",
+    "startLine": 224,
+    "endLine": 226,
+    "problem": "`issueBuffer` 內每則留言都逐一 `await` 遠端 API，總耗時為 O(n × API RTT)。目前固定情境留言也會累加多次網路往返；若日後增加階段，等待時間會線性成長。",
+    "reason": "Paladin：可排除（命中已知排除事項）。逐筆 `await` 是為維持暫存留言的 FIFO 發布順序，留言數量有限；現有證據不足以證明延遲構成缺陷，而並行發送會增加順序不確定及 API 限流風險。"
  }
 ]