node-actions/ai-code-review
2
0
Fork 0
Code Issues 1 Pull Requests 1 Actions Releases 14 Activity

chore(ai-review 狀態): 回寫已處理 findings
node-actions/template: CI / BUILD (pull_request) Successful in 5s
Details
CI / TEST (Claude) (pull_request) Successful in 28s
Details
CI / TEST (Antigravity) (pull_request) Successful in 52s
Details
CI / TEST (Codex) (pull_request) Successful in 2m58s
Details

Browse Source
This commit is contained in:
Jeffery
2026-07-21 13:46:48 +08:00
parent 55b349da07
commit e0ae6f886f
5 changed files with 0 additions and 395 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.gitea/ai-review/findings/2026-07-20-18:31:07.json
-252
View File
@@ -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": []