feat(ai-code-review): 建問題模式導向 issue,並整併流程調整、文件與 CI #21
Notifications
Due Date
No due date set.
Blocks
#6 feat(ai-code-review): 建問題模式導向 issue,並整併流程調整、文件與 CI
node-actions/ai-code-review
Reference: node-actions/ai-code-review#21
Reference in New Issue
Block a user
變更摘要
本 PR 將 ai-code-review action 分支的完整成果併入
develop,主要含四塊:create-issue: 'true'時,審查留言(工具/diff/角色/嚴重問題/警告+建議)全部改發到追蹤 issue、不再張貼到 PR;不執行「舊留言標過時/resolve」;issue 延後到「確定有保留問題」才建立;無保留問題或無可審查變更則不建 issue、PR 也完全不留言(靜默通過);有問題時最後在 PR 回貼一則 issue 連結並補掛標籤,形成雙向關聯。action.yml/src各模組文件、重建readme.md,新增.gitea/workflows/ci.yaml(多工具 code review 驗證)並啟用建問題模式。影響範圍
src/index.jsmain()依模式分流:留言去向、跳過 resolveOldComments、issue 延後建立、severe/others 導向 issue、有問題才在 PR 回貼連結src/lib/gitea.js新增addLabelsToIssuesrc/lib/templates.js新增issueLinkCommentsrc/lib/review.js新增postSevereToIssue,移除createIssueWithFindings、sortFindingsForIssuesrc/lib/gitrepo.js補抓淺層 checkout 的 base 歷史readme.md、action.yml、.gitea/workflows/ci.yaml、.gitea/workflows/readme.md風險與注意事項
readme.md尚未反映「建問題模式導向 issue」的最新行為與新/移除的函式,建議後續以 doc-funcs 重建文件。2026/07/17 18:49:58,未刷新。🤖 AI Code Review|審查工具
codexcodex-cli 0.144.6gpt-5.5deb20bb07852967328c70baace1409e259c32fdd📋 變更摘要(送審 git diff)
action.ymlreadme.mdsrc/index.jssrc/lib/agents.jssrc/lib/context.jssrc/lib/gitea.jssrc/lib/gitrepo.jssrc/lib/review.jssrc/lib/roles.jssrc/lib/templates.js⚔️ 攻擊方登場
🛡️ 防守方登場
🔴 嚴重|🗡️ Assassin
位置:
src/index.js第 386–392 行問題描述
建問題模式下,有嚴重問題時把「阻擋合併」完全交給 issue dependency;但
addIssueDependency失敗只記WRN後繼續。攻擊者只要遇到未啟用問題相依、token 權限不足或 Gitea 版本不支援的 repo,就能讓 action 最後仍return 0。若同時exclusions.json沒變更,也不會產生[failure]結果 commit,嚴重資安 finding 只剩一個 issue 留言,CI 不失敗、PR 也不一定被擋。修改建議
嚴重問題的阻擋機制必須 fail-closed。若 dependency 建立失敗,應直接回傳失敗,或保證推出
[failure]結果 commit;不能只警告後放行。建議寫法
🔵 建議|🧰 Leo
位置:
readme.md第 56–132 行問題描述
README 的功能表大量硬編遠端分支名稱與行號,這次只是從
master改成develop並同步行號,但這種文件很容易在下一次函式移動、預設分支更名或重排時再次整批失準。未來維護者會被迫反覆做低價值的連結校正,文件也可能在沒人注意時指到錯誤位置。修改建議
若 README 是 repo 內文件,優先改成相對路徑連結,並避免固定行號;若必須保留行號,建議用產生腳本統一輸出這張表,讓分支名與行號只從單一來源計算。
🔵 建議|🎼 Bard
位置:
src/index.js第 183–224 行問題描述
issue與issueBuffer的命名過於泛泛;在 Gitea 裡 PR 也是 issue,追蹤問題也是 issue,單靠issue這個名字無法唱出它究竟是哪一個聲部。修改建議
建議改成更具語義的名稱,例如
trackingIssue、trackingIssueCommentBuffer,讓讀者不用回讀 create-issue 模式的整段脈絡。建議寫法
🔵 建議|🎼 Bard
位置:
src/lib/gitea.js第 190–194 行問題描述
addIssueDependency(ctx, issueNumber, dependency)的兩個參數名稱太相似,且dependency少了 issue 語義。這支 API 的方向性本來就容易讀錯,命名再模糊就像兩個音符共用同一個名字。修改建議
建議把參數改成能表達方向的名稱,例如
blockedIssueNumber與blockingIssueNumber,呼叫端也會更清楚是誰被誰擋住。建議寫法
🔵 建議|🎼 Bard
位置:
src/lib/review.js第 36–43 行問題描述
agentFailureDetail的 JSDoc 先說「原始輸出預設隱藏」,下一段又說「預設附上 stderr 與 stdout 片段」。同一段說明前後轉調,讀者會搞不清楚失敗診斷到底會不會輸出 CLI 內容。修改建議
請統一描述:若設計是輸出已遮罩片段,就刪掉「預設隱藏」;若設計是隱藏原始輸出,就把後段改成條件式說明。
🔵 建議|🎼 Bard
位置:
src/lib/templates.js第 334–338 行問題描述
issueFindingComment是通用 finding 留言模板,但更新後的說明只寫review.postSevereToIssue與「嚴重 finding」。然而主流程也將警告/建議逐條發到 issue,這段文件把模板唱窄了,和實際用途不一致。修改建議
把 remarks 改成涵蓋嚴重、警告與建議的通用 issue finding 留言,避免日後維護者誤以為此模板只能用於嚴重問題。
🧩 code-review-resolve 處理進度
本議題為 AI Code Review 建問題模式的追蹤議題。以
--issue all併同.gitea/ai-review/findings/逐條處理後結果如下(對照目前程式碼與exclusions.json):src/index.js第 386–392 行readme.md第 56–132 行src/index.js第 183–224 行src/lib/gitea.js第 190–194 行src/lib/review.js第 36–43 行src/lib/templates.js第 334–338 行小計:✅ 已解決 0 條、🚫 誤報(已列入 exclusions)1 條、⏭️ 待人工處理 5 條。
resolveMergeBase補抓策略調整、deepen PR HEAD改用 head SHA、留言閉包改名、push-tokeninput 移除等)。.gitea/ai-review/exclusions.json既有裁決等價,不重複新增排除條目。處理完成,依 code-review-resolve 流程關閉本議題。