feat(ai-code-review): 建問題模式導向 issue，並整併流程調整、文件與 CI #6
@@ -570,5 +570,93 @@
|
|||||||
"endLine": 195,
|
"endLine": 195,
|
||||||
"problem": "新加入的 `addIssueDependency` API 封裝沒有契約測試，尚未驗證 URL 中使用相依方 PR 編號，而 request body 的 `index` 使用阻擋來源 issue 編號；兩者若對調，請求可能仍是合法格式，卻會建立反向的相依關係。",
|
"problem": "新加入的 `addIssueDependency` API 封裝沒有契約測試，尚未驗證 URL 中使用相依方 PR 編號，而 request body 的 `index` 使用阻擋來源 issue 編號；兩者若對調，請求可能仍是合法格式，卻會建立反向的相依關係。",
|
||||||
"reason": "Paladin：可排除（重複）。歷史 finding 已指出 addIssueDependency 缺少 endpoint、HTTP method、payload 與相依方向的契約測試。"
|
"reason": "Paladin：可排除（重複）。歷史 finding 已指出 addIssueDependency 缺少 endpoint、HTTP method、payload 與相依方向的契約測試。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/20 17:21:16",
|
||||||
|
"prNumber": 6,
|
||||||
|
"reviewer": "Assassin",
|
||||||
|
"severity": "嚴重",
|
||||||
|
"file": "src/lib/review.js",
|
||||||
|
"startLine": 70,
|
||||||
|
"endLine": 73,
|
||||||
|
"problem": "攻擊者可以把惡意內容塞進 PR diff 或 AI 工具輸出，誘使 AI CLI 在失敗時把環境變數、原始碼片段、token、PR 內容或 PII 印到 stdout/stderr；這裡預設把 stdout/stderr 前 500 字寫進 CI log。`redactSecrets` 只是黑名單式遮罩，擋不住 Gitea PAT、JWT、雲端金鑰、短 token、帶標點的密碼或一般 PII。尤其本 PR 又新增 `push-token` PAT，失敗診斷變成一條可被 prompt injection 利用的外洩通道。",
|
||||||
|
"reason": "Paladin：可排除（重複）。歷史 finding 已針對 debug/失敗診斷輸出 AI CLI stdout/stderr、黑名單式遮罩可繞過，以及機密或個資外洩提出相同問題。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/20 17:21:16",
|
||||||
|
"prNumber": 6,
|
||||||
|
"reviewer": "Leo",
|
||||||
|
"severity": "警告",
|
||||||
|
"file": "src/index.js",
|
||||||
|
"startLine": 180,
|
||||||
|
"endLine": 365,
|
||||||
|
"problem": "`main()` 這次把「留言目的地切換、issue 暫存與 flush、標籤挑選、PR 回貼、issue dependency、舊留言清理時機」全部塞進同一段流程。半年後要改建問題模式時，維護者必須同時理解 `ctx.createIssue`、`issue`、`issueBuffer`、`currentRunCommentIds` 這幾個閉包狀態的互動，任何一個留言新增在錯誤位置，都可能變成被暫存後丟棄、發錯地方，或被舊留言清理誤處理。這不是單純長度問題，而是 orchestration 和 delivery policy 已經耦合在一起。",
|
||||||
|
"reason": "Paladin：可排除（命中已知排除事項且重複）。既有紀錄已涵蓋 main() 內留言路由、issue 狀態、緩衝佇列與發布職責耦合的問題；本條只是擴充描述同一設計負擔。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/20 17:21:16",
|
||||||
|
"prNumber": 6,
|
||||||
|
"reviewer": "Leo",
|
||||||
|
"severity": "建議",
|
||||||
|
"file": "src/lib/review.js",
|
||||||
|
"startLine": 30,
|
||||||
|
"endLine": 39,
|
||||||
|
"problem": "`agentFailureDetail()` 的說明文字前後不一致：開頭說「原始輸出預設隱藏」，下一段又說失敗時預設附上遮罩後的 stderr/stdout 片段。這種註解矛盾會讓未來維護者不確定目前政策到底是偏向保守隱藏，還是偏向可診斷輸出，尤其這段又是多個 AI CLI 失敗路徑共用的行為。",
|
||||||
|
"reason": "Paladin：可排除（列表內重複）。與 F002 指涉同一段 agentFailureDetail 註解前後政策描述不一致的問題。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/20 17:21:16",
|
||||||
|
"prNumber": 6,
|
||||||
|
"reviewer": "Mage",
|
||||||
|
"severity": "警告",
|
||||||
|
"file": "src/index.js",
|
||||||
|
"startLine": 213,
|
||||||
|
"endLine": 224,
|
||||||
|
"problem": "`ensureIssueCreated` 先建立追蹤 issue，再逐則寫入 `issueBuffer`。只要 issue 建立成功後任一 buffered comment 發生暫時性 API 失敗，例外會往上拋出，action 以失敗結束，但已建立的 issue 不會回滾，也沒有被記錄成可重用狀態。\n\n最小重現情境：`create-issue=true`、有保留問題；`gitea.createIssue` 成功建立 #10；第一則 `createCommentOnIssue` timeout。這次 run 失敗；下次重跑又建立 #11，造成重複追蹤 issue，且 PR 可能沒有任何連結指向第一次建立的 issue。",
|
||||||
|
"reason": "Paladin：可排除（命中已知排除事項且重複）。issue 建立成功後 buffered comment 失敗、重跑產生重複追蹤 issue，正是既有排除事項與歷史 finding 已裁定涵蓋的同一問題。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/20 17:21:16",
|
||||||
|
"prNumber": 6,
|
||||||
|
"reviewer": "Maya",
|
||||||
|
"severity": "警告",
|
||||||
|
"file": "src/index.js",
|
||||||
|
"startLine": 309,
|
||||||
|
"endLine": 381,
|
||||||
|
"problem": "建問題模式這次改了主要行為：有保留問題時才建 issue、先暫存工具/diff/角色留言、之後逐條留言到 issue、再回貼 PR 連結並建立 dependency；但 diff 沒看到對應測試。這條路徑牽涉多個外部 API 呼叫與順序，沒有測試就無法驗證「PR 只留連結、issue 收到完整內容、無保留問題時靜默通過」這些新契約。",
|
||||||
|
"reason": "Paladin：可排除（重複）。歷史 findings 已涵蓋建問題模式有 finding 才建 issue、暫存留言 flush、PR 只回貼連結、dependency 失敗降級等核心分支缺少測試。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/20 17:21:16",
|
||||||
|
"prNumber": 6,
|
||||||
|
"reviewer": "Maya",
|
||||||
|
"severity": "警告",
|
||||||
|
"file": "src/lib/gitrepo.js",
|
||||||
|
"startLine": 102,
|
||||||
|
"endLine": 146,
|
||||||
|
"problem": "`resolveMergeBase` 新增了多段 fetch fallback（明確更新 base、淺層時 unshallow、deepen base、deepen HEAD）以及失敗診斷，但沒有看到測試覆蓋這些邊界與失敗路徑。這段是 diff 基準來源；只要淺層 checkout 或 fetch 策略順序沒被驗證，審查範圍可能整個錯掉。",
|
||||||
|
"reason": "Paladin：可排除（重複）。歷史 findings 已指出 resolveMergeBase 多階段 fetch、淺層與非淺層路徑、停止條件及最終失敗診斷缺少測試。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/20 17:21:16",
|
||||||
|
"prNumber": 6,
|
||||||
|
"reviewer": "Maya",
|
||||||
|
"severity": "警告",
|
||||||
|
"file": "src/lib/gitrepo.js",
|
||||||
|
"startLine": 267,
|
||||||
|
"endLine": 324,
|
||||||
|
"problem": "`push-token` 與 `pushWithCredential` 是新的提交推送行為，但 diff 沒有對應測試驗證分支選擇與失敗處理。尤其 `pushToken` 存在時會跳過 origin、未提供時才 fallback，這些都是會影響 CI 是否重新觸發的關鍵行為。",
|
||||||
|
"reason": "Paladin：可排除（重複）。歷史 findings 已涵蓋 pushToken、origin fallback、認證傳遞與推送失敗遮蔽等分支缺少測試。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/20 17:21:16",
|
||||||
|
"prNumber": 6,
|
||||||
|
"reviewer": "Maya",
|
||||||
|
"severity": "建議",
|
||||||
|
"file": "src/lib/review.js",
|
||||||
|
"startLine": 13,
|
||||||
|
"endLine": 72,
|
||||||
|
"problem": "`redactSecrets` / `agentFailureDetail` 新增了輸出 stderr/stdout 診斷的行為，但沒有測試驗證遮罩規則與限長。這不是單純格式調整；一旦正規式或順序被改壞，失敗 log 可能變得不可診斷，或把控制字元與憑證樣式原樣輸出。",
|
||||||
|
"reason": "Paladin：可排除（重複）。歷史 findings 已針對 redactSecrets／agentFailureDetail 的控制字元、憑證樣式、URL 帳密、截斷與 debug 開關缺少測試提出相同問題。"
|
||||||
}
|
}
|
||||||
]
|
]
|
||||||
|
|||||||
Reference in New Issue
Block a user