chore(ai-review 狀態): 回寫已處理 findings
This commit is contained in:
Jeffery
@@ -8,19 +8,6 @@
|
||||
"model": "（工具預設）"
|
||||
},
|
||||
"findings": [
|
||||
{
|
||||
"id": "F001",
|
||||
"reviewer": "Leo",
|
||||
"focus": "maintainability",
|
||||
"badge": "🧰",
|
||||
"severity": "警告",
|
||||
"file": "src/index.js",
|
||||
"startLine": 210,
|
||||
"endLine": 224,
|
||||
"problem": "`ensureIssueCreated` 同時建立 issue、修改外層 `issue` 狀態、逐筆清空 `issueBuffer`，但整段流程沒有可重入或冪等機制。若 issue 建立成功後，寫入其中一則暫存留言時失敗，主流程會中止；重跑後又會建立另一個 issue，留下內容不完整的孤兒 issue。這種依賴閉包可變狀態的半完成狀態，半年後要加入重試、續傳或測試失敗情境都會很痛苦。",
|
||||
"suggestion": "把「建立追蹤 issue 並沖刷留言」抽成獨立、可注入 Gitea client 的服務函式，明確回傳 issue 與已寫入進度；建立前以 PR 編號或隱藏識別標記查找既有追蹤 issue，讓重跑能接續而非重複建立。至少也應保留已建立的 issue 編號並在錯誤訊息中回報，避免留下無法追蹤的半成品。",
|
||||
"suggestedCode": ""
|
||||
},
|
||||
{
|
||||
"id": "F002",
|
||||
"reviewer": "Maya",
|
||||
@@ -34,19 +21,6 @@
|
||||
"suggestion": "新增主流程測試並 mock Gitea、agent 與 git 操作，至少涵蓋：`kept=[]` 時不建立 issue 且不留言；僅嚴重問題；僅警告／建議；混合問題；建立 issue 或寫入暫存留言失敗；標籤查詢、AI 選標籤及補掛標籤失敗時仍回貼 issue 連結。除了呼叫次數，也應斷言 API 呼叫順序、目標 issue 編號及留言內容。",
|
||||
"suggestedCode": ""
|
||||
},
|
||||
{
|
||||
"id": "F003",
|
||||
"reviewer": "Maya",
|
||||
"focus": "testing",
|
||||
"badge": "🧪",
|
||||
"severity": "警告",
|
||||
"file": "src/lib/gitea.js",
|
||||
"startLine": 188,
|
||||
"endLine": 191,
|
||||
"problem": "新增的 `addLabelsToIssue` 沒有對應測試，尚未驗證空值捷徑與實際 API 請求格式。這個函式位於新建問題流程的收尾路徑；若 endpoint、HTTP method 或 `{ labels }` payload 不符預期，追蹤 issue 將無法取得標籤，而空陣列是否真的不發出請求也未被保護。",
|
||||
"suggestion": "新增單元測試，分別傳入 `undefined`、`null`、空陣列及多個 label id；斷言前三者回傳 `null` 且完全不呼叫 API，多個 id 時以 POST 呼叫正確的 owner／repo／issue endpoint 並傳送 `{ labels: [...] }`，另驗證 API 拋錯會原樣往上傳遞。",
|
||||
"suggestedCode": ""
|
||||
},
|
||||
{
|
||||
"id": "F004",
|
||||
"reviewer": "Maya",
|
||||
@@ -59,19 +33,6 @@
|
||||
"problem": "`resolveMergeBase` 新增多階段 fetch 與淺層 checkout 修復邏輯，但沒有看到測試驗證成功、降級與最終失敗路徑。尤其初次 merge-base 失敗後，淺層與非淺層 repository 會走不同路徑，且多個 `tryGit` 失敗會被刻意吞掉；若參數、refspec 或重試順序有誤，只會在實際 CI checkout 深度不足時才暴露。",
|
||||
"suggestion": "以 stub 的 git 執行器或暫存 repository 補齊案例：首次 merge-base 成功；淺層 repository 經 `--unshallow` 後成功；`--unshallow` 失敗但 `--deepen=1000` 後成功；非淺層首次失敗後重試成功；所有策略失敗時拋出含 `baseRef` 且保留原始 `cause` 的錯誤。並斷言 base/head fetch 的 refspec 與執行順序。",
|
||||
"suggestedCode": ""
|
||||
},
|
||||
{
|
||||
"id": "F005",
|
||||
"reviewer": "Maya",
|
||||
"focus": "testing",
|
||||
"badge": "🧪",
|
||||
"severity": "建議",
|
||||
"file": "src/lib/review.js",
|
||||
"startLine": 17,
|
||||
"endLine": 45,
|
||||
"problem": "新增的 agent 失敗診斷涵蓋逾時、數字或字串 exit code、signal、空輸出及 500 字截斷等多個邊界，但沒有測試鎖定輸出。這些資訊只在失敗路徑出現，正常審查不會自然覆蓋；日後修改時可能悄悄遺失真正的 CLI 錯誤內容，或破壞單行與截斷約束。",
|
||||
"suggestion": "將摘要邏輯匯出供測試，或透過失敗的 `runAttackers`／`runDefenders`／`fillPurposes` 測試間接斷言 log。至少覆蓋 killed、數字 exit code、字串 code、signal、stderr 與 stdout 同時存在、超過 500 字、完全無資訊，以及 `res` 為 null／undefined 的案例。",
|
||||
"suggestedCode": ""
|
||||
}
|
||||
],
|
||||
"excluded": []
|
||||
|
||||
@@ -8,32 +8,6 @@
|
||||
"model": "（工具預設）"
|
||||
},
|
||||
"findings": [
|
||||
{
|
||||
"id": "F001",
|
||||
"reviewer": "Assassin",
|
||||
"focus": "security",
|
||||
"badge": "🗡️",
|
||||
"severity": "嚴重",
|
||||
"file": "src/lib/review.js",
|
||||
"startLine": 72,
|
||||
"endLine": 81,
|
||||
"problem": "開啟 ACTIONS_STEP_DEBUG=true 後，會把攻擊者可間接操控的 AI CLI stderr／stdout（經黑名單式 redactSecrets 遮罩）寫入長期保存的 CI log。短 token、JWT、含標點或空白的密碼、非典型金鑰及 PII 仍可能繞過遮罩。建議即使除錯模式也只記錄退出碼／signal／逾時／診斷 ID，若需原文則寫入受限、短期保存、需授權取得的安全 artifact。",
|
||||
"suggestion": "CI log 不輸出 AI CLI 原文，即使 debug 模式；需要原文時改寫入存取受限的安全 artifact，並套用允許清單式結構化診斷與 PII／機密掃描。此為安全性與可除錯性的政策取捨：現行已刻意保留 debug-gated 遮罩輸出，是否完全移除需維護者裁示。",
|
||||
"suggestedCode": "function agentFailureDetail(res) {\n const err = res && res.error;\n if (err && err.killed) return '已逾時終止';\n if (err && typeof err.code === 'number') return `exit ${err.code}`;\n if (err && err.signal) return `signal ${err.signal}`;\n return 'AI CLI 執行失敗（原始輸出已隱藏）';\n}"
|
||||
},
|
||||
{
|
||||
"id": "F002",
|
||||
"reviewer": "Leo",
|
||||
"focus": "maintainability",
|
||||
"badge": "🧰",
|
||||
"severity": "警告",
|
||||
"file": "src/index.js",
|
||||
"startLine": 176,
|
||||
"endLine": 218,
|
||||
"problem": "main() 內新增 issueBuffer、可變 issue、postComment 與 ensureIssueCreated 閉包，後續多處依 ctx.createIssue 分支。留言路由、issue 生命週期、標籤、相依關係與審查編排共享同一批可變狀態；未來增加發布目的地或重試策略時須同步理解並修改整個超長主流程，測試也只能透過 main() 間接覆蓋。",
|
||||
"suggestion": "抽出具明確介面的發布器（如 PrReviewPublisher 與 IssueReviewPublisher），封裝留言暫存、issue 建立、沖刷、問題明細與收束關聯；main() 只呼叫一致的 publishContext／publishFindings／finalize，便於分別注入假的 Gitea client 測試兩種模式並移除散落的模式判斷。屬大範圍重構＋設計取捨，需維護者確認方向。",
|
||||
"suggestedCode": ""
|
||||
},
|
||||
{
|
||||
"id": "F003",
|
||||
"reviewer": "Maya",
|
||||
@@ -60,19 +34,6 @@
|
||||
"suggestion": "以參數化測試覆蓋 findings 四種組合，斷言 API 呼叫順序／次數／issue number／統計；並分別讓 listLabels／selectLabels／createIssue／問題留言／PR 連結留言／addIssueDependency 拋錯，驗證哪些中止、哪些僅記警告續行；零 findings 時斷言所有寫入 API 皆不呼叫。屬測試架構決策。",
|
||||
"suggestedCode": ""
|
||||
},
|
||||
{
|
||||
"id": "F005",
|
||||
"reviewer": "Maya",
|
||||
"focus": "testing",
|
||||
"badge": "🧪",
|
||||
"severity": "警告",
|
||||
"file": "src/lib/gitea.js",
|
||||
"startLine": 171,
|
||||
"endLine": 215,
|
||||
"problem": "新增的問題相依 API 包裝沒有測試驗證 endpoint、HTTP method 與 payload。特別是 addIssueDependency 容易顛倒的「PR 相依於 issue」方向未被斷言；若 index 或 body 欄位放反，合併阻擋語意會相反。（原併列的 addLabelsToIssue 已於本次移除。）",
|
||||
"suggestion": "mock 底層 API，對相依關係使用不同的 PR／issue 編號，精確斷言 URL 指向 PR、body.index 指向阻擋來源 issue，並覆蓋 API 非 2xx 時錯誤原樣往上拋出的案例。屬測試架構決策。",
|
||||
"suggestedCode": ""
|
||||
},
|
||||
{
|
||||
"id": "F006",
|
||||
"reviewer": "Maya",
|
||||
@@ -99,19 +60,6 @@
|
||||
"suggestion": "mock git 執行器與 URL／env 組裝，補測 pushToken 有值／空、origin 成功／失敗、PAT 推送失敗及含特殊字元等案例；斷言 push 目標與呼叫次數，並確保任何拋出的錯誤、log 或快照都不含原始 token。屬測試架構決策。",
|
||||
"suggestedCode": ""
|
||||
},
|
||||
{
|
||||
"id": "F008",
|
||||
"reviewer": "Maya",
|
||||
"focus": "testing",
|
||||
"badge": "🧪",
|
||||
"severity": "警告",
|
||||
"file": "src/lib/review.js",
|
||||
"startLine": 16,
|
||||
"endLine": 80,
|
||||
"problem": "redactSecrets／agentFailureDetail 直接決定 CI 日誌是否洩漏內容及失敗診斷是否可用，但沒有測試覆蓋。空值、控制字元、Authorization/Bearer、URL 帳密、各種 token 樣式、截斷，以及 ACTIONS_STEP_DEBUG 大小寫與未啟用時隱藏 stdout/stderr 等邊界尚未驗證。",
|
||||
"suggestion": "為這兩個純函式補單元測試（必要時受控匯出或抽獨立模組），以假憑證逐一測試遮罩規則與換行注入並斷言輸出不含原始秘密；保存還原 ACTIONS_STEP_DEBUG 驗證預設／true／混合大小寫／逾時／exit code／signal／無 error／超長輸出。屬測試架構決策。",
|
||||
"suggestedCode": ""
|
||||
},
|
||||
{
|
||||
"id": "F009",
|
||||
"reviewer": "Bard",
|
||||
@@ -124,19 +72,6 @@
|
||||
"problem": "push-token 的用途與退回行為在區塊註解、欄位描述、required 與 default 註解中反覆說明，且單行 description 過長，資訊雖完整但重複，日後修改語意易只改到一處。",
|
||||
"suggestion": "保留一段「為何需要 PAT」的必要背景，其餘讓欄位名稱、required、default 自行表意，將 description 收斂成呼叫端真正需要知道的契約。註：本專案採 doc-funcs 高密度註解慣例，是否精簡屬慣例取捨，需維護者確認。",
|
||||
"suggestedCode": " # 專用推送 PAT；以 PAT 推送可重新觸發 CI。留空時沿用 token。\n push-token:\n description: '推送審查結果 commit 的 PAT（留空時沿用 token）'\n required: false\n default: ''"
|
||||
},
|
||||
{
|
||||
"id": "F010",
|
||||
"reviewer": "Bard",
|
||||
"focus": "style",
|
||||
"badge": "🎼",
|
||||
"severity": "建議",
|
||||
"file": "src/index.js",
|
||||
"startLine": 203,
|
||||
"endLine": 226,
|
||||
"problem": "ensureIssueCreated 之名帶有「已存在便沿用」的冪等語意，實際卻無條件建立新 issue 並悄悄改寫外層 issue；名稱、行為與副作用不一致，閱讀呼叫處易形成錯誤預期。",
|
||||
"suggestion": "若此函式只允許呼叫一次，改用直接表達「建立並沖刷暫存留言」的名稱並回傳建立結果，由呼叫端明確指派 issue，讓資料流一眼可見。註：本項與 F002（抽出 publisher 大重構）指向同一段核心流程、維護者正審視中，宜與該重構一併處理，避免重複改動。",
|
||||
"suggestedCode": "const createIssueAndFlushBuffer = async (labelIds = []) => {\n const createdIssue = await gitea.createIssue(ctx, {\n title: ctx.prTitle || `AI Code Review：PR #${ctx.prNumber}`,\n body: templates.issueBody({ prNumber: ctx.prNumber, prBody: ctx.prBody }),\n labels: labelIds,\n });\n for (const body of issueBuffer) {\n await gitea.createCommentOnIssue(ctx, createdIssue.number, body);\n }\n issueBuffer.length = 0;\n return createdIssue;\n};\nissue = await createIssueAndFlushBuffer(labelIds);"
|
||||
}
|
||||
],
|
||||
"excluded": []
|
||||
|
||||
@@ -21,19 +21,6 @@
|
||||
"suggestion": "共用函式 JSDoc 改以語意階段名稱描述、不引用易變動的數字；日誌集中定義階段名稱或由單一流程描述產生編號；README 流程圖也以語意名稱為主。屬跨檔重構＋設計取捨。",
|
||||
"suggestedCode": "const STAGE = Object.freeze({\n TOOL_DETECTION: '偵測工具',\n DIFF_COLLECTION: '整理差異',\n ATTACK_REVIEW: '攻擊方審查',\n DEFENSE_REVIEW: '防守方裁決',\n});\nlog(STAGE.DIFF_COLLECTION, 'INF', message);"
|
||||
},
|
||||
{
|
||||
"id": "F002",
|
||||
"reviewer": "Maya",
|
||||
"focus": "testing",
|
||||
"badge": "🧪",
|
||||
"severity": "警告",
|
||||
"file": "src/lib/gitea.js",
|
||||
"startLine": 172,
|
||||
"endLine": 215,
|
||||
"problem": "建立 issue 相依關係的 API 封裝（addIssueDependency）沒有對應測試：尚未驗證 URL 的 issue 編號與 {index, owner, repo} payload 正確、以及非 2xx 錯誤是否原樣往上傳遞。（原併提的 addLabelsToIssue 已於先前 commit 移除。）",
|
||||
"suggestion": "mock 底層 API，驗證 addIssueDependency 的 URL issue 編號與 payload，加入 4xx／5xx 拋錯案例，並搭配主流程測試確認相依失敗會被降級而不阻斷審查。屬測試架構決策（專案無測試框架）。",
|
||||
"suggestedCode": ""
|
||||
},
|
||||
{
|
||||
"id": "F003",
|
||||
"reviewer": "Leo",
|
||||
|
||||
@@ -33,32 +33,6 @@
|
||||
"problem": "commitAndPushFindings 的推送行為（有無變更、認證方式、空 commit 防護、是否觸發 CI）缺少測試證明。此為本次變更的核心行為，卻沒有任何測試覆蓋。",
|
||||
"suggestion": "mock git 命令，斷言：無 staged diff 時回傳 false 且不執行 commit／push；有變更時以認證方式推送到正確 refspec 與分支。注意：原 finding 描述的 pushToken 對比 origin 雙軌邏輯已於重構後移除（現行一律以 token 經 pushWithCredential 認證推送），撰寫測試前需依現行程式碼重新界定情境。",
|
||||
"suggestedCode": ""
|
||||
},
|
||||
{
|
||||
"id": "F003",
|
||||
"reviewer": "🗡️ Assassin",
|
||||
"focus": "security",
|
||||
"badge": "🗡️",
|
||||
"severity": "警告",
|
||||
"file": "src/lib/review.js",
|
||||
"startLine": 64,
|
||||
"endLine": 80,
|
||||
"problem": "agentFailureDetail 於 AI CLI 失敗時會把（經 redactSecrets 盡力遮罩的）stderr／stdout 片段寫入 CI log。redactSecrets 屬盡力遮罩，無法可靠辨識 PII、短密碼或私鑰片段；長期保存且多人可讀的 CI log 有洩漏風險。",
|
||||
"suggestion": "屬安全（避免洩漏）與可除錯性的設計取捨：現行程式碼已於註解明確權衡並選擇「附上遮罩後輸出以利除錯」。是否改為只記錄退出碼／訊號／逾時狀態＋隨機診斷 ID（內容級診斷改寫入有存取控制與短保存期的獨立 artifact）需由維護者裁示，故保留現行行為、標為待人工處理。",
|
||||
"suggestedCode": "if (verbose) {\n parts.push('已啟用除錯；為避免洩漏原始碼、PII 或憑證，CLI 輸出仍不寫入日誌');\n}"
|
||||
},
|
||||
{
|
||||
"id": "F004",
|
||||
"reviewer": "🧪 Maya",
|
||||
"focus": "testing",
|
||||
"badge": "🧪",
|
||||
"severity": "建議",
|
||||
"file": "src/lib/gitea.js",
|
||||
"startLine": 171,
|
||||
"endLine": 215,
|
||||
"problem": "addLabelsToIssue 與 addIssueDependency 缺少契約測試驗證 endpoint、HTTP method 與 request body；相依關係方向由 URL 與 body 決定，參數次序寫反時粗略 mock 的主流程測試不易察覺。",
|
||||
"suggestion": "補 Gitea client 單元測試：labels 為空或缺少時不呼叫 API 並回傳 null；有 labels 時送出正確陣列；相依 API 以 PR 編號置於 URL、追蹤 issue 編號置於 index，並帶入正確 owner／repo。",
|
||||
"suggestedCode": ""
|
||||
}
|
||||
],
|
||||
"excluded": []
|
||||
|
||||
@@ -36,48 +36,6 @@
|
||||
"suggestedCode": "```\n| 功能名稱 | 功能描述 |\n| --- | --- |\n| [gitrepo.resolveMergeBase](src/lib/gitrepo.js) | [解析 base 分支與 HEAD 的 merge-base](#gitreporesolvemergebase) |\n```",
|
||||
"sourceIssue": 12
|
||||
},
|
||||
{
|
||||
"id": "F003",
|
||||
"reviewer": "Leo",
|
||||
"focus": "",
|
||||
"badge": "🧰",
|
||||
"severity": "建議",
|
||||
"file": "src/lib/review.js",
|
||||
"startLine": 13,
|
||||
"endLine": 82,
|
||||
"problem": "`agentFailureDetail()` 同時負責解析程序失敗、決定 debug 政策、讀取全域環境變數、截斷輸出及遮罩機密。尤其直接讀取 `process.env.ACTIONS_STEP_DEBUG` 形成隱藏相依，測試不同輸出政策時必須修改程序全域狀態；日後若其他呼叫端需要不同診斷層級，也只能繼續往這個函式堆條件。",
|
||||
"suggestion": "把診斷政策改成明確參數，並將「錯誤中繼資料整理」與「輸出片段清理」拆成小函式；在 `main` 或 context 載入階段解析環境設定後注入。這能讓各種 exit code、signal、空輸出與 verbose 模式以純輸入輸出直接測試。",
|
||||
"suggestedCode": "```\nfunction agentFailureDetail(res, { includeStdout = false, inputLimit = 2000, outputLimit = 500 } = {}) {\n const parts = failureMetadata(res && res.error);\n appendSanitizedOutput(parts, 'stderr', res && res.stderr, inputLimit, outputLimit);\n if (includeStdout) {\n appendSanitizedOutput(parts, 'stdout', res && res.output, inputLimit, outputLimit);\n }\n return parts.length ? parts.join('｜') : 'AI CLI 執行失敗（無診斷輸出）';\n}\n```",
|
||||
"sourceIssue": 12
|
||||
},
|
||||
{
|
||||
"id": "F004",
|
||||
"reviewer": "Bard",
|
||||
"focus": "",
|
||||
"badge": "🎼",
|
||||
"severity": "警告",
|
||||
"file": "src/lib/review.js",
|
||||
"startLine": 42,
|
||||
"endLine": 61,
|
||||
"problem": "`agentFailureDetail` 的文件自相矛盾：開頭宣稱「原始輸出預設隱藏」，後文卻明言預設附上經遮罩的 `stderr` 與 `stdout` 片段；另提到 `ACTIONS_STEP_DEBUG`，函式內卻沒有相應分支。註解與實作各唱各的調，維護者無法從文件判斷實際日誌行為。",
|
||||
"suggestion": "統一文件敘述為實際行為：預設輸出經遮罩且限長的診斷片段；若目前並未依 `ACTIONS_STEP_DEBUG` 改變輸出，就移除該段說明，或待真正實作開關後再補上。",
|
||||
"suggestedCode": "",
|
||||
"sourceIssue": 13
|
||||
},
|
||||
{
|
||||
"id": "F005",
|
||||
"reviewer": "Rogue",
|
||||
"focus": "",
|
||||
"badge": "⚡",
|
||||
"severity": "嚴重",
|
||||
"file": "src/index.js",
|
||||
"startLine": 216,
|
||||
"endLine": 218,
|
||||
"problem": "在 `ensureIssueCreated` 函式中，使用 `for...of` 迴圈搭配 `await` 來逐條對 Gitea API 發送留言請求。由於網路請求存在延遲（每次 RTT 約 100-300ms），在迴圈內阻塞式等待會導致整體執行時間隨留言數量線性增加，浪費大量 CPU 週期與網路連線資源。",
|
||||
"suggestion": "可以將 `issueBuffer` 中的所有情境留言合併為單一 Markdown 留言發送，僅需一次 API 呼叫；或者使用 `Promise.all` 將這些無相依性的留言請求並行化發送，大幅降低總延遲。",
|
||||
"suggestedCode": "```\nif (issueBuffer.length > 0) {\n const combinedBody = issueBuffer.join('\\n\\n---\\n\\n');\n await gitea.createCommentOnIssue(ctx, issue.number, combinedBody);\n }\n issueBuffer.length = 0;\n```",
|
||||
"sourceIssue": 14
|
||||
},
|
||||
{
|
||||
"id": "F006",
|
||||
"reviewer": "Rogue",
|
||||
@@ -106,20 +64,6 @@
|
||||
"suggestedCode": "```\n} catch (err) {\n // 過濾敏感資訊後保留錯誤細節\n const safeMessage = err.message ? redactSecrets(err.message) : '未知錯誤';\n const error = new Error(`推送審查結果 commit 失敗（${safeMessage}）。`);\n error.cause = err;\n throw error;\n }\n```",
|
||||
"sourceIssue": 14
|
||||
},
|
||||
{
|
||||
"id": "F008",
|
||||
"reviewer": "Assassin",
|
||||
"focus": "",
|
||||
"badge": "🗡️",
|
||||
"severity": "警告",
|
||||
"file": "src/lib/gitrepo.js",
|
||||
"startLine": 299,
|
||||
"endLine": 299,
|
||||
"problem": "在 `pushWithCredential` 中，環境變數 `GIT_CONFIG_KEY_0` 被動態拼接為 `http.${remoteUrl}.extraheader`。如果 `remoteUrl` 來自外部或未經嚴格驗證的 context，且 URL 中包含特殊字元（如點號、路徑分隔符號或引號等），可能會導致 Git 配置解析錯誤，或在特定平台下引發 Git 配置參數注入風險。",
|
||||
"suggestion": "由於該執行程序僅為一次性的 `git push` 操作，可直接將該憑證應用於所有 HTTP 請求，將 `GIT_CONFIG_KEY_0` 設定為靜態的 `http.extraheader`，以避免動態拼接 URL 所帶來的注入風險。",
|
||||
"suggestedCode": "```\nGIT_CONFIG_KEY_0: 'http.extraheader',\n```",
|
||||
"sourceIssue": 14
|
||||
},
|
||||
{
|
||||
"id": "F009",
|
||||
"reviewer": "Bard",
|
||||
@@ -148,20 +92,6 @@
|
||||
"suggestedCode": "```\nconst commentPromise = gitea.createIssueComment(\n ctx,\n templates.issueLinkComment({\n issueNumber: issue.number,\n issueUrl: issue.html_url,\n severeCount: severe.length,\n otherCount: others.length,\n })\n );\n const dependencyPromise = gitea.addIssueDependency(ctx, ctx.prNumber, issue.number)\n .then(() => log('建問題', 'INF', `已將 PR #${ctx.prNumber} 設為相依於 issue #${issue.number}。`))\n .catch((err) => log('建問題', 'WRN', `設定 PR 相依失敗：${err.message}。`));\n \n await Promise.all([commentPromise, dependencyPromise]);\n```",
|
||||
"sourceIssue": 14
|
||||
},
|
||||
{
|
||||
"id": "F011",
|
||||
"reviewer": "Bard",
|
||||
"focus": "",
|
||||
"badge": "🎼",
|
||||
"severity": "建議",
|
||||
"file": "src/lib/review.js",
|
||||
"startLine": 33,
|
||||
"endLine": 34,
|
||||
"problem": "在 redactSecrets 函式中，針對 authorization 以及其他憑證關鍵字（如 token、secret、password 等）的敏感資訊遮蔽，分別使用了兩條結構極為相似的正規表示式進行替換。這造成了重複的替換邏輯與額外的處理開銷，程式碼的旋律顯得不夠俐落。",
|
||||
"suggestion": "建議將這兩條正規表示式合併為單一表達式，消除重複的 replace 呼叫，使程式碼更加簡潔優雅且提升運行效率。",
|
||||
"suggestedCode": "```\n.replace(/((?:authorization|api[_-]?key|token|password|secret|bearer)\\s*[:=]\\s*)\\S+/gi, '$1***')\n```",
|
||||
"sourceIssue": 14
|
||||
},
|
||||
{
|
||||
"id": "F012",
|
||||
"reviewer": "Rogue",
|
||||
@@ -176,20 +106,6 @@
|
||||
"suggestedCode": "```\nconst stderr = redactSecrets(String((res && res.stderr) || '').slice(0, 500));\n if (stderr) parts.push(`stderr：${stderr}`);\n const stdout = redactSecrets(String((res && res.output) || '').slice(0, 500));\n if (stdout) parts.push(`stdout：${stdout}`);\n```",
|
||||
"sourceIssue": 14
|
||||
},
|
||||
{
|
||||
"id": "F013",
|
||||
"reviewer": "Bard",
|
||||
"focus": "",
|
||||
"badge": "🎼",
|
||||
"severity": "建議",
|
||||
"file": "src/lib/templates.js",
|
||||
"startLine": 335,
|
||||
"endLine": 337,
|
||||
"problem": "issueFindingComment 函式的 @remarks 文件註解中，說明其使用情境為『建問題模式下 review.postSevereToIssue 把每條嚴重 finding... 作為問題明細的追蹤紀錄』。然而實際上，非嚴重的警告與建議（others）也會透過 review.postOthersToIssue 呼叫此模板進行發布，導致文件描述不夠完整。",
|
||||
"suggestion": "修正 @remarks 的使用情境說明，將 postOthersToIssue 亦併入描述中，使 JSDoc 文件能如實且精準地反映實際程式碼的呼叫情境。",
|
||||
"suggestedCode": "```\n* 使用情境：建問題模式下 `review.postSevereToIssue` 與 `review.postOthersToIssue`（src/lib/review.js）把保留的各級問題明細\\n * 以本函式產生留言內容、經 `gitea.createCommentOnIssue` 發布到追蹤 issue 上，\\n * 作為問題明細的追蹤紀錄。\n```",
|
||||
"sourceIssue": 14
|
||||
},
|
||||
{
|
||||
"id": "F014",
|
||||
"reviewer": "Leo",
|
||||
@@ -218,48 +134,6 @@
|
||||
"suggestedCode": "```\nfunction addIssueDependency(ctx, issueNumber, dependencyIssueNumber) {\n return api(ctx, 'POST', `/repos/${ctx.owner}/${ctx.repo}/issues/${issueNumber}/dependencies`, {\n index: dependencyIssueNumber,\n owner: ctx.owner,\n repo: ctx.repo,\n });\n}\n```",
|
||||
"sourceIssue": 15
|
||||
},
|
||||
{
|
||||
"id": "F016",
|
||||
"reviewer": "Bard",
|
||||
"focus": "",
|
||||
"badge": "🎼",
|
||||
"severity": "建議",
|
||||
"file": "src/lib/review.js",
|
||||
"startLine": 28,
|
||||
"endLine": 37,
|
||||
"problem": "這段註解的旋律前後打架：開頭說「原始輸出預設隱藏」，後文卻說失敗時預設附上遮罩後的 stderr/stdout 片段。讀者才剛建立心智模型，下一拍就被改調。",
|
||||
"suggestion": "請讓摘要句與實際行為一致，明確說明「原始輸出不直接輸出，但會輸出遮罩與截斷後的診斷片段」。",
|
||||
"suggestedCode": "```\n* 從 `runAgent` 的失敗結果組出可診斷的一行摘要：退出碼／訊號為主，並附上遮罩、去控制字元且截斷後的 stderr/stdout 片段。\n```",
|
||||
"sourceIssue": 15
|
||||
},
|
||||
{
|
||||
"id": "F017",
|
||||
"reviewer": "Bard",
|
||||
"focus": "",
|
||||
"badge": "🎼",
|
||||
"severity": "建議",
|
||||
"file": "src/lib/templates.js",
|
||||
"startLine": 334,
|
||||
"endLine": 341,
|
||||
"problem": "`issueFindingComment` 的註解只提到 `review.postSevereToIssue`，但主流程也以 `postOthersToIssue` 發布警告與建議。文件把共用模板寫成嚴重問題專用，讀起來像少了一個聲部。",
|
||||
"suggestion": "把 remarks 改成同時涵蓋嚴重、警告與建議的 issue 留言產生器，避免維護者誤以為它只服務嚴重 finding。",
|
||||
"suggestedCode": "",
|
||||
"sourceIssue": 15
|
||||
},
|
||||
{
|
||||
"id": "F018",
|
||||
"reviewer": "Assassin",
|
||||
"focus": "",
|
||||
"badge": "🗡️",
|
||||
"severity": "嚴重",
|
||||
"file": "src/lib/gitrepo.js",
|
||||
"startLine": 102,
|
||||
"endLine": 149,
|
||||
"problem": "攻擊者可以透過提交惡意 Pull Request，將 `baseRef`（PR 目標分支）命名為包含路徑穿越（Path Traversal）的字串，例如 `../../hooks/pre-push`。由於 `resolveMergeBase` 直接將 `baseRef` 拼接至 `git fetch` 的 Refspec 參數中（例如 `+refs/heads/${baseRef}:refs/remotes/origin/${baseRef}`），這將導致 `git fetch` 寫入至 `.git/refs/remotes/origin/../../hooks/pre-push`（即 `.git/hooks/pre-push`）。這會覆寫或建立 Git Hook，並在後續執行 git 操作時自動觸發該惡意 Hook，從而造成遠端程式碼執行（RCE）。同樣地，`commitAndPushFindings` 函數中的 `headRef` 也存在類似的拼接風險。",
|
||||
"suggestion": "在將 `baseRef` 與 `headRef` 傳入 git 指令之前，應進行嚴格的合法性檢查。建議使用正則表達式限制分支名稱僅能包含安全的字元（如英數字、斜線、底線、連字號、句點），且絕對不得含有 `..` 或以 `-` 開頭，必要時亦可使用 `git check-ref-format` 命令先行驗證該分支名稱是否安全。",
|
||||
"suggestedCode": "```\nfunction resolveMergeBase(cwd, baseRef) {\n // 嚴格的分支名稱白名單檢查，防止路徑穿越與參數注入\n const safeBranchRegex = /^(?!-)(?!.*?\\.\\.)[a-zA-Z0-9/_.-]+$/;\n if (!safeBranchRegex.test(baseRef)) {\n throw new Error(`偵測到不合法的分支名稱: ${baseRef}`);\n }\n const remoteBase = `origin/${baseRef}`;\n```",
|
||||
"sourceIssue": 16
|
||||
},
|
||||
{
|
||||
"id": "F019",
|
||||
"reviewer": "Leo",
|
||||
@@ -274,34 +148,6 @@
|
||||
"suggestedCode": "",
|
||||
"sourceIssue": 17
|
||||
},
|
||||
{
|
||||
"id": "F020",
|
||||
"reviewer": "Bard",
|
||||
"focus": "",
|
||||
"badge": "🎼",
|
||||
"severity": "建議",
|
||||
"file": "src/lib/review.js",
|
||||
"startLine": 41,
|
||||
"endLine": 45,
|
||||
"problem": "這段註解的旋律前後走調：摘要先說「原始輸出預設隱藏」，下一段卻說失敗時「預設附上 stderr 與 stdout」。讀者還沒進函式本體，文件本身就已經互相拉扯。",
|
||||
"suggestion": "請讓摘要與實作同拍，直接說明會輸出經遮罩與限長的診斷片段；若真的要隱藏原始輸出，也應同步改實作。",
|
||||
"suggestedCode": "```\n* 從 `runAgent` 的失敗結果組出可診斷的一行摘要：退出碼／訊號為主，並附上經遮罩與限長的 stderr／stdout 片段。\n```",
|
||||
"sourceIssue": 17
|
||||
},
|
||||
{
|
||||
"id": "F021",
|
||||
"reviewer": "Bard",
|
||||
"focus": "",
|
||||
"badge": "🎼",
|
||||
"severity": "建議",
|
||||
"file": "src/lib/templates.js",
|
||||
"startLine": 334,
|
||||
"endLine": 338,
|
||||
"problem": "`issueFindingComment` 的文件只唱「嚴重 finding」，但新版流程也讓警告與建議逐條發到 issue。函式名稱是通用的，註解卻把用途寫窄，後續讀者會誤以為它只服務嚴重問題。",
|
||||
"suggestion": "把註解改成涵蓋所有 finding 等級，讓文件與函式名稱、呼叫情境保持一致。",
|
||||
"suggestedCode": "```\n* 使用情境：建問題模式下，`review.postSevereToIssue` 與 `review.postOthersToIssue`\n * 會把各等級 finding 以本函式產生留言內容、經 `gitea.createCommentOnIssue`\n * 發布到追蹤 issue 上，作為問題明細的追蹤紀錄。\n```",
|
||||
"sourceIssue": 17
|
||||
},
|
||||
{
|
||||
"id": "F022",
|
||||
"reviewer": "Leo",
|
||||
@@ -414,20 +260,6 @@
|
||||
"suggestedCode": "```\nfunction prIssueLinkComment({ issueNumber, issueUrl, severeCount, otherCount }) {\n return `${MARK}\n## 🔍 AI Code Review｜已建立追蹤問題\n\n本次審查結果已彙整到 issue [#${issueNumber}](${issueUrl})（🔴 嚴重 ${severeCount} 條、🟠🔵 警告＋建議 ${otherCount} 條），請至該問題追蹤與討論。`;\n}\n```",
|
||||
"sourceIssue": 19
|
||||
},
|
||||
{
|
||||
"id": "F030",
|
||||
"reviewer": "Rogue",
|
||||
"focus": "",
|
||||
"badge": "⚡",
|
||||
"severity": "警告",
|
||||
"file": "src/index.js",
|
||||
"startLine": 369,
|
||||
"endLine": 370,
|
||||
"problem": "建問題模式把所有警告／建議改成逐條發 issue 留言，這裡會把 `others.length` 放大成 N 次遠端 POST；正常模式同一批資料只產生 1 則彙整表格留言。只要 AI 回出數十條警告，CI 時間就會被 API round-trip 線性吃掉，還更容易撞上 Gitea rate limit 或暫時性網路延遲。",
|
||||
"suggestion": "警告／建議維持批次彙整成單一留言；只有嚴重問題需要逐條追蹤時再拆開。若產品需求一定要逐條回覆，至少在 `postOthersToIssue` 內用有上限的並行池，不要一筆等一筆。",
|
||||
"suggestedCode": "```\nif (others.length > 0) {\n if (ctx.createIssue) {\n await gitea.createCommentOnIssue(ctx, issue.number, templates.othersComment(others));\n log('步驟10', 'INF', `警告＋建議表格留言已發布到 issue（${others.length} 條）。`);\n } else {\n await postComment(templates.othersComment(others));\n log('步驟10', 'INF', `警告＋建議表格留言已發布（${others.length} 條）。`);\n }\n}\n```",
|
||||
"sourceIssue": 20
|
||||
},
|
||||
{
|
||||
"id": "F031",
|
||||
"reviewer": "Leo",
|
||||
@@ -470,34 +302,6 @@
|
||||
"suggestedCode": "```\nfunction addIssueDependency(ctx, blockedIssueNumber, blockingIssueNumber) {\n return api(ctx, 'POST', `/repos/${ctx.owner}/${ctx.repo}/issues/${blockedIssueNumber}/dependencies`, {\n index: blockingIssueNumber,\n owner: ctx.owner,\n repo: ctx.repo,\n });\n}\n```",
|
||||
"sourceIssue": 21
|
||||
},
|
||||
{
|
||||
"id": "F034",
|
||||
"reviewer": "Bard",
|
||||
"focus": "",
|
||||
"badge": "🎼",
|
||||
"severity": "建議",
|
||||
"file": "src/lib/review.js",
|
||||
"startLine": 36,
|
||||
"endLine": 43,
|
||||
"problem": "`agentFailureDetail` 的 JSDoc 先說「原始輸出預設隱藏」，下一段又說「預設附上 stderr 與 stdout 片段」。同一段說明前後轉調，讀者會搞不清楚失敗診斷到底會不會輸出 CLI 內容。",
|
||||
"suggestion": "請統一描述：若設計是輸出已遮罩片段，就刪掉「預設隱藏」；若設計是隱藏原始輸出，就把後段改成條件式說明。",
|
||||
"suggestedCode": "",
|
||||
"sourceIssue": 21
|
||||
},
|
||||
{
|
||||
"id": "F035",
|
||||
"reviewer": "Bard",
|
||||
"focus": "",
|
||||
"badge": "🎼",
|
||||
"severity": "建議",
|
||||
"file": "src/lib/templates.js",
|
||||
"startLine": 334,
|
||||
"endLine": 338,
|
||||
"problem": "`issueFindingComment` 是通用 finding 留言模板，但更新後的說明只寫 `review.postSevereToIssue` 與「嚴重 finding」。然而主流程也將警告／建議逐條發到 issue，這段文件把模板唱窄了，和實際用途不一致。",
|
||||
"suggestion": "把 remarks 改成涵蓋嚴重、警告與建議的通用 issue finding 留言，避免日後維護者誤以為此模板只能用於嚴重問題。",
|
||||
"suggestedCode": "",
|
||||
"sourceIssue": 21
|
||||
},
|
||||
{
|
||||
"id": "F036",
|
||||
"reviewer": "Rogue",
|
||||
@@ -512,48 +316,6 @@
|
||||
"suggestedCode": "```\nconst { kept, excluded } = findings.length === 0\n ? { kept: [], excluded: [] }\n : await review.runDefenders({ tool, model: ctx.model, cwd, defenders, findings });\n```",
|
||||
"sourceIssue": 22
|
||||
},
|
||||
{
|
||||
"id": "F037",
|
||||
"reviewer": "Bard",
|
||||
"focus": "",
|
||||
"badge": "🎼",
|
||||
"severity": "建議",
|
||||
"file": "src/lib/gitrepo.js",
|
||||
"startLine": 310,
|
||||
"endLine": 310,
|
||||
"problem": "`pushWithCredential` 的參數名叫 `secret`，但同一檔其他區段與呼叫端都稱它為 `token`；同一個旋律忽然換調，讀者需要多花心力確認這是不是另一種憑證。",
|
||||
"suggestion": "沿用既有命名，把 `secret` 改成 `token`，並同步調整 JSDoc 與 `Buffer.from` 內的引用。",
|
||||
"suggestedCode": "```\nfunction pushWithCredential(cwd, remoteUrl, token, refspec, serverUrl) {\n const basic = Buffer.from(`ai-review-bot:${token}`).toString('base64');\n // ...\n}\n```",
|
||||
"sourceIssue": 22
|
||||
},
|
||||
{
|
||||
"id": "F038",
|
||||
"reviewer": "Leo",
|
||||
"focus": "",
|
||||
"badge": "🧰",
|
||||
"severity": "建議",
|
||||
"file": "src/lib/review.js",
|
||||
"startLine": 31,
|
||||
"endLine": 46,
|
||||
"problem": "`agentFailureDetail` 的註解前後語意不一致：開頭寫「原始輸出預設隱藏」，但後段又說預設會附上遮罩後的 stderr/stdout；最後還提到用 `ACTIONS_STEP_DEBUG=true` 取得原始輸出，但程式碼沒有任何 debug flag 分支。這種文件與實作脫節，會讓未來維護者誤判 CI log 會暴露多少診斷內容。",
|
||||
"suggestion": "把註解改成符合目前實作：預設輸出限長且遮罩後的 stderr/stdout；若要支援 debug 模式，再補實作分支。不要在註解承諾程式沒有做的行為。",
|
||||
"suggestedCode": "",
|
||||
"sourceIssue": 22
|
||||
},
|
||||
{
|
||||
"id": "F039",
|
||||
"reviewer": "Bard",
|
||||
"focus": "",
|
||||
"badge": "🎼",
|
||||
"severity": "建議",
|
||||
"file": "src/lib/templates.js",
|
||||
"startLine": 337,
|
||||
"endLine": 340,
|
||||
"problem": "`issueFindingComment` 是一般 finding 留言模板，但註解只寫 `review.postSevereToIssue` 的嚴重問題用途；和主流程中「警告＋建議也逐條發到 issue」的描述不一致，註解像只唱了半段副歌。",
|
||||
"suggestion": "把 remarks 改成涵蓋嚴重、警告與建議的共用用途，避免後續維護者誤以為此模板只服務嚴重問題。",
|
||||
"suggestedCode": "",
|
||||
"sourceIssue": 22
|
||||
},
|
||||
{
|
||||
"id": "F040",
|
||||
"reviewer": "Assassin",
|
||||
@@ -581,20 +343,6 @@
|
||||
"suggestion": "改用 repo 相對連結、不固定行號，或把這段功能表改由腳本從 JSDoc 自動產生。若需要連到特定實作，優先連到檔案或錨點，避免每次重排程式碼都要同步更新幾十個行號。",
|
||||
"suggestedCode": "```\n| log.taipeiNow | [src/lib/log.js](src/lib/log.js) | 取得台北時區 yyyy/MM/dd HH:mm:ss 時間字串 |\n| review.runAttackers | [src/lib/review.js](src/lib/review.js) | 攻擊方 sub agent 並行找問題並合併列表 |\n```",
|
||||
"sourceIssue": 23
|
||||
},
|
||||
{
|
||||
"id": "F042",
|
||||
"reviewer": "Bard",
|
||||
"focus": "",
|
||||
"badge": "🎼",
|
||||
"severity": "建議",
|
||||
"file": "src/lib/review.js",
|
||||
"startLine": 31,
|
||||
"endLine": 40,
|
||||
"problem": "這段註解的旋律前後失和：開頭寫「原始輸出預設隱藏」，下一句卻說預設附上 stderr 與 stdout 片段。讀者尚未進入程式碼，就已被兩個互相拉扯的描述絆住。",
|
||||
"suggestion": "請讓文件只唱一個調性：若目前設計是預設輸出遮罩後的診斷片段，就刪掉「原始輸出預設隱藏」或改成「原始輸出會先遮罩與截斷」。",
|
||||
"suggestedCode": "",
|
||||
"sourceIssue": 23
|
||||
}
|
||||
],
|
||||
"excluded": []
|
||||
|
||||
Reference in New Issue
Block a user