feat(ai-code-review): 建問題模式導向 issue,並整併流程調整、文件與 CI #20

Closed
opened 2026-07-20 09:36:21 +00:00 by admin · 14 comments
Owner

變更摘要

本 PR 將 ai-code-review action 分支的完整成果併入 develop,主要含四塊:

  1. 建問題模式重構(feat)create-issue: 'true' 時,審查留言(工具/diff/角色/嚴重問題/警告+建議)全部改發到追蹤 issue、不再張貼到 PR;不執行「舊留言標過時/resolve」;issue 延後到「確定有保留問題」才建立;無保留問題或無可審查變更則不建 issue、PR 也完全不留言(靜默通過);有問題時最後在 PR 回貼一則 issue 連結並補掛標籤,形成雙向關聯。
  2. 審查流程步驟調整(refactor):將「標記舊留言過時/resolve」提前到偵測 AI 工具之前,並依新順序重編所有步驟編號與說明。
  3. 修正(gitrepo):補抓淺層 checkout 的 base 歷史,避免 merge-base 計算失敗。
  4. 文件與 CI:補齊 action.ymlsrc 各模組文件、重建 readme.md,新增 .gitea/workflows/ci.yaml(多工具 code review 驗證)並啟用建問題模式。

影響範圍

範圍 說明
action 執行流程 src/index.js main() 依模式分流:留言去向、跳過 resolveOldComments、issue 延後建立、severe/others 導向 issue、有問題才在 PR 回貼連結
Gitea API src/lib/gitea.js 新增 addLabelsToIssue
留言模板 src/lib/templates.js 新增 issueLinkComment
審查核心 src/lib/review.js 新增 postSevereToIssue,移除 createIssueWithFindingssortFindingsForIssue
git base 解析 src/lib/gitrepo.js 補抓淺層 checkout 的 base 歷史
文件與 CI readme.mdaction.yml.gitea/workflows/ci.yaml.gitea/workflows/readme.md

風險與注意事項

  • 建問題模式行為明顯改變:啟用後 PR 上不再有審查留言(有問題時改為 issue + 一則連結留言;無問題時完全不留言),請確認團隊流程可接受。
  • 端對端行為需靠 CI 實測:本地僅完成語法與模組載入驗證,實際 issue/PR 互動需一次 CI 觸發確認。
  • readme.md 尚未反映「建問題模式導向 issue」的最新行為與新/移除的函式,建議後續以 doc-funcs 重建文件。
  • 各檔頭部「更新時間」時間戳仍為 2026/07/17 18:49:58,未刷新。

本問題由 AI Code Review 依 PR #6 的審查結果自動建立,問題明細見下方留言。

<!-- ai-code-review --> ## 變更摘要 本 PR 將 ai-code-review action 分支的完整成果併入 `develop`,主要含四塊: 1. **建問題模式重構(feat)**:`create-issue: 'true'` 時,審查留言(工具/diff/角色/嚴重問題/警告+建議)全部改發到追蹤 issue、不再張貼到 PR;不執行「舊留言標過時/resolve」;issue 延後到「確定有保留問題」才建立;**無保留問題或無可審查變更則不建 issue、PR 也完全不留言(靜默通過)**;有問題時最後在 PR 回貼一則 issue 連結並補掛標籤,形成雙向關聯。 2. **審查流程步驟調整(refactor)**:將「標記舊留言過時/resolve」提前到偵測 AI 工具之前,並依新順序重編所有步驟編號與說明。 3. **修正(gitrepo)**:補抓淺層 checkout 的 base 歷史,避免 merge-base 計算失敗。 4. **文件與 CI**:補齊 `action.yml`/`src` 各模組文件、重建 `readme.md`,新增 `.gitea/workflows/ci.yaml`(多工具 code review 驗證)並啟用建問題模式。 ## 影響範圍 | 範圍 | 說明 | | --- | --- | | action 執行流程 | `src/index.js` `main()` 依模式分流:留言去向、跳過 resolveOldComments、issue 延後建立、severe/others 導向 issue、有問題才在 PR 回貼連結 | | Gitea API | `src/lib/gitea.js` 新增 `addLabelsToIssue` | | 留言模板 | `src/lib/templates.js` 新增 `issueLinkComment` | | 審查核心 | `src/lib/review.js` 新增 `postSevereToIssue`,移除 `createIssueWithFindings`、`sortFindingsForIssue` | | git base 解析 | `src/lib/gitrepo.js` 補抓淺層 checkout 的 base 歷史 | | 文件與 CI | `readme.md`、`action.yml`、`.gitea/workflows/ci.yaml`、`.gitea/workflows/readme.md` | ## 風險與注意事項 - **建問題模式行為明顯改變**:啟用後 PR 上不再有審查留言(有問題時改為 issue + 一則連結留言;無問題時完全不留言),請確認團隊流程可接受。 - **端對端行為需靠 CI 實測**:本地僅完成語法與模組載入驗證,實際 issue/PR 互動需一次 CI 觸發確認。 - `readme.md` 尚未反映「建問題模式導向 issue」的最新行為與新/移除的函式,建議後續以 doc-funcs 重建文件。 - 各檔頭部「更新時間」時間戳仍為 `2026/07/17 18:49:58`,未刷新。 --- > 本問題由 AI Code Review 依 PR #6 的審查結果自動建立,問題明細見下方留言。
Author
Owner

🤖 AI Code Review|審查工具

項目 內容
工具 codex
版本 codex-cli 0.144.6
模型 gpt-5.5
審查 commit 3ef8a302911c60b9f71024e1f4b60e0d4578b8fd
Run Job #39
flowchart LR
    A[整理 git diff] --> B[⚔️ 攻擊方找問題]
    B --> C[🛡️ 防守方裁決]
    C --> D[保存 findings]
    D --> E[留言到 PR]
<!-- ai-code-review --> ## 🤖 AI Code Review|審查工具 | 項目 | 內容 | | --- | --- | | 工具 | `codex` | | 版本 | `codex-cli 0.144.6` | | 模型 | `gpt-5.5` | | 審查 commit | `3ef8a302911c60b9f71024e1f4b60e0d4578b8fd` | | Run Job | [#39](https://gitea.jsc.idv.tw/node-actions/ai-code-review/actions/runs/1608) | ```mermaid flowchart LR A[整理 git diff] --> B[⚔️ 攻擊方找問題] B --> C[🛡️ 防守方裁決] C --> D[保存 findings] D --> E[留言到 PR] ```
Author
Owner

📋 變更摘要(送審 git diff)

檔案 用途 git diff 長度 最後更新時間
action.yml 定義 Action 參數與執行入口 88 行/4025 字元 2026/07/20 17:24:18
readme.md 說明專案功能與使用流程 276 行/23829 字元(過長截斷送審) 2026/07/20 16:01:05
src/index.js 編排 AI Code Review 主流程 351 行/15670 字元 2026/07/20 17:33:20
src/lib/agents.js 偵測並執行 AI CLI 工具 14 行/503 字元 2026/07/20 09:46:12
src/lib/context.js 讀取 workflow 與輸入環境 15 行/769 字元 2026/07/20 17:24:18
src/lib/gitea.js 封裝 Gitea API 操作 121 行/5278 字元 2026/07/20 16:01:05
src/lib/gitrepo.js 封裝 git diff 與提交操作 209 行/8550 字元 2026/07/20 17:24:18
src/lib/review.js 處理審查結果與 AI 輔助 580 行/24901 字元(過長截斷送審) 2026/07/20 16:37:15
src/lib/roles.js 載入並分類審查角色 14 行/586 字元 2026/07/20 09:46:12
src/lib/templates.js 產生 PR 留言模板 165 行/5949 字元 2026/07/20 15:00:32

共 10 個檔案納入審查;另有 7 個檔案依 .reviewignore 排除。

<!-- ai-code-review --> ## 📋 變更摘要(送審 git diff) | 檔案 | 用途 | git diff 長度 | 最後更新時間 | | --- | --- | --- | --- | | `action.yml` | 定義 Action 參數與執行入口 | 88 行/4025 字元 | 2026/07/20 17:24:18 | | `readme.md` | 說明專案功能與使用流程 | 276 行/23829 字元(過長截斷送審) | 2026/07/20 16:01:05 | | `src/index.js` | 編排 AI Code Review 主流程 | 351 行/15670 字元 | 2026/07/20 17:33:20 | | `src/lib/agents.js` | 偵測並執行 AI CLI 工具 | 14 行/503 字元 | 2026/07/20 09:46:12 | | `src/lib/context.js` | 讀取 workflow 與輸入環境 | 15 行/769 字元 | 2026/07/20 17:24:18 | | `src/lib/gitea.js` | 封裝 Gitea API 操作 | 121 行/5278 字元 | 2026/07/20 16:01:05 | | `src/lib/gitrepo.js` | 封裝 git diff 與提交操作 | 209 行/8550 字元 | 2026/07/20 17:24:18 | | `src/lib/review.js` | 處理審查結果與 AI 輔助 | 580 行/24901 字元(過長截斷送審) | 2026/07/20 16:37:15 | | `src/lib/roles.js` | 載入並分類審查角色 | 14 行/586 字元 | 2026/07/20 09:46:12 | | `src/lib/templates.js` | 產生 PR 留言模板 | 165 行/5949 字元 | 2026/07/20 15:00:32 | > 共 10 個檔案納入審查;另有 7 個檔案依 `.reviewignore` 排除。
Author
Owner

⚔️ 攻擊方登場

角色 面向 個性
🗡️ Assassin 安全性(security) 多疑偏執、以攻擊者視角看世界,假設每筆輸入都是惡意的,每個信任都會被濫用
🎼 Bard 風格(style) 唯美龜毛、追求優雅,把可讀性與一致性當作旋律,最受不了走調的命名與排版
🧰 Leo 可維護性(maintainability) 有遠見、重視長期維護成本,凡事先問「六個月後的自己還看得懂嗎?」,討厭把債留給未來
🔮 Mage 邏輯(logic) 嚴謹冷靜、滴水不漏,凡事推演到最壞情況,深信「沒驗證過的假設都是 bug」
🧪 Maya 測試(testing) 對測試覆蓋率有執念,深信「沒有測試的程式碼等於沒寫完」,溫和但堅持,最在意邊界與失敗路徑
Rogue 效率(efficiency) 急性子、講求速度,最痛恨被浪費的 CPU 週期與記憶體,凡事先問「這能不能更快、更省」
<!-- ai-code-review --> ## ⚔️ 攻擊方登場 | 角色 | 面向 | 個性 | | --- | --- | --- | | 🗡️ **Assassin** | 安全性(security) | 多疑偏執、以攻擊者視角看世界,假設每筆輸入都是惡意的,每個信任都會被濫用 | | 🎼 **Bard** | 風格(style) | 唯美龜毛、追求優雅,把可讀性與一致性當作旋律,最受不了走調的命名與排版 | | 🧰 **Leo** | 可維護性(maintainability) | 有遠見、重視長期維護成本,凡事先問「六個月後的自己還看得懂嗎?」,討厭把債留給未來 | | 🔮 **Mage** | 邏輯(logic) | 嚴謹冷靜、滴水不漏,凡事推演到最壞情況,深信「沒驗證過的假設都是 bug」 | | 🧪 **Maya** | 測試(testing) | 對測試覆蓋率有執念,深信「沒有測試的程式碼等於沒寫完」,溫和但堅持,最在意邊界與失敗路徑 | | ⚡ **Rogue** | 效率(efficiency) | 急性子、講求速度,最痛恨被浪費的 CPU 週期與記憶體,凡事先問「這能不能更快、更省」 |
Author
Owner

🛡️ 防守方登場

角色 面向 個性
🛡️ Paladin 裁決(verdict) 沉穩公正、就事論事,不護短也不冤枉,只依排除事項與原始碼脈絡裁定問題成立與否
<!-- ai-code-review --> ## 🛡️ 防守方登場 | 角色 | 面向 | 個性 | | --- | --- | --- | | 🛡️ **Paladin** | 裁決(verdict) | 沉穩公正、就事論事,不護短也不冤枉,只依排除事項與原始碼脈絡裁定問題成立與否 |
Author
Owner

🔴 嚴重|🗡️ Assassin

位置src/index.js 第 409–416 行

問題描述

攻擊者只要送進含嚴重資安問題的 PR,就能賭這個 gate 不會在本輪失敗:程式現在即使 result === 'failure' 也固定 return 0,把失敗判定押在下一輪由結果 commit 觸發。但這不是安全邊界:使用自動 token、PAT 權限不足、CI 不重跑、push 被略過,或建問題模式下沒有可 commit 的 exclusions 變更時,branch protection 看到的就是通過的檢查。嚴重 finding 變成留言或 issue,而不是阻擋合併。

修改建議

不要讓安全 gate 依賴下一輪 side effect。只要本輪偵測到嚴重問題,應直接回傳非 0;若仍需要結果 commit,可先嘗試 commit/push,再以 return 1 收場。建問題模式也一樣,dependency API 只能當輔助,不能取代 CI 失敗。

建議寫法

if (result === 'failure') {
  log('收尾', 'INF', '本輪有嚴重問題,直接以失敗檢查阻擋合併。');
  return 1;
}
return 0;
<!-- ai-code-review --> ### 🔴 嚴重|🗡️ Assassin **位置**:`src/index.js` 第 409–416 行 **問題描述** 攻擊者只要送進含嚴重資安問題的 PR,就能賭這個 gate 不會在本輪失敗:程式現在即使 `result === 'failure'` 也固定 `return 0`,把失敗判定押在下一輪由結果 commit 觸發。但這不是安全邊界:使用自動 token、PAT 權限不足、CI 不重跑、push 被略過,或建問題模式下沒有可 commit 的 exclusions 變更時,branch protection 看到的就是通過的檢查。嚴重 finding 變成留言或 issue,而不是阻擋合併。 **修改建議** 不要讓安全 gate 依賴下一輪 side effect。只要本輪偵測到嚴重問題,應直接回傳非 0;若仍需要結果 commit,可先嘗試 commit/push,再以 `return 1` 收場。建問題模式也一樣,dependency API 只能當輔助,不能取代 CI 失敗。 **建議寫法** ``` if (result === 'failure') { log('收尾', 'INF', '本輪有嚴重問題,直接以失敗檢查阻擋合併。'); return 1; } return 0; ```
Author
Owner

🟠 警告|🎼 Bard

位置src/index.js 第 119–157 行

問題描述

主流程的步驟編號像一首倒裝的曲子:註解先列步驟 2,卻說它延後到步驟 9 前才執行;後面程式碼也出現「步驟 2(延後執行)」插在步驟 8 之後。這種以數字命名但不照執行順序出現的寫法,讓讀者必須來回對拍,文件與流程的可讀性都變沉重。

修改建議

將「舊留言標記」改成具名階段而非硬塞為步驟 2,或把流程編號改成實際執行順序。若需要保留對外步驟名稱,建議在程式內用語採 resolveOldCommentsPhasecleanupOldComments 這類語意命名,減少數字倒敘造成的混亂。

<!-- ai-code-review --> ### 🟠 警告|🎼 Bard **位置**:`src/index.js` 第 119–157 行 **問題描述** 主流程的步驟編號像一首倒裝的曲子:註解先列步驟 2,卻說它延後到步驟 9 前才執行;後面程式碼也出現「步驟 2(延後執行)」插在步驟 8 之後。這種以數字命名但不照執行順序出現的寫法,讓讀者必須來回對拍,文件與流程的可讀性都變沉重。 **修改建議** 將「舊留言標記」改成具名階段而非硬塞為步驟 2,或把流程編號改成實際執行順序。若需要保留對外步驟名稱,建議在程式內用語採 `resolveOldCommentsPhase`/`cleanupOldComments` 這類語意命名,減少數字倒敘造成的混亂。
Author
Owner

🟠 警告| Rogue

位置src/index.js 第 369–370 行

問題描述

建問題模式把所有警告/建議改成逐條發 issue 留言,這裡會把 others.length 放大成 N 次遠端 POST;正常模式同一批資料只產生 1 則彙整表格留言。只要 AI 回出數十條警告,CI 時間就會被 API round-trip 線性吃掉,還更容易撞上 Gitea rate limit 或暫時性網路延遲。

修改建議

警告/建議維持批次彙整成單一留言;只有嚴重問題需要逐條追蹤時再拆開。若產品需求一定要逐條回覆,至少在 postOthersToIssue 內用有上限的並行池,不要一筆等一筆。

建議寫法

if (others.length > 0) {
  if (ctx.createIssue) {
    await gitea.createCommentOnIssue(ctx, issue.number, templates.othersComment(others));
    log('步驟10', 'INF', `警告+建議表格留言已發布到 issue(${others.length} 條)。`);
  } else {
    await postComment(templates.othersComment(others));
    log('步驟10', 'INF', `警告+建議表格留言已發布(${others.length} 條)。`);
  }
}
<!-- ai-code-review --> ### 🟠 警告|⚡ Rogue **位置**:`src/index.js` 第 369–370 行 **問題描述** 建問題模式把所有警告/建議改成逐條發 issue 留言,這裡會把 `others.length` 放大成 N 次遠端 POST;正常模式同一批資料只產生 1 則彙整表格留言。只要 AI 回出數十條警告,CI 時間就會被 API round-trip 線性吃掉,還更容易撞上 Gitea rate limit 或暫時性網路延遲。 **修改建議** 警告/建議維持批次彙整成單一留言;只有嚴重問題需要逐條追蹤時再拆開。若產品需求一定要逐條回覆,至少在 `postOthersToIssue` 內用有上限的並行池,不要一筆等一筆。 **建議寫法** ``` if (others.length > 0) { if (ctx.createIssue) { await gitea.createCommentOnIssue(ctx, issue.number, templates.othersComment(others)); log('步驟10', 'INF', `警告+建議表格留言已發布到 issue(${others.length} 條)。`); } else { await postComment(templates.othersComment(others)); log('步驟10', 'INF', `警告+建議表格留言已發布(${others.length} 條)。`); } } ```
Author
Owner

🟠 警告|🔮 Mage

位置src/lib/gitrepo.js 第 140–140 行

問題描述

deepen HEAD 策略實際執行的是 git fetch --deepen=1000 origin HEAD,這裡的 HEAD 是遠端的預設分支符號,不是目前 checkout 的 PR head commit。最小重現:runner 淺層 checkout 停在 feature PR 的 detached HEAD,而 origin/HEAD 指向 developunshallow 失敗後,此策略只會加深預設分支,無法補到 feature 分支祖先,merge-base origin/<baseRef> HEAD 仍會失敗。

修改建議

補抓 PR head 時不要使用遠端符號 HEAD。將 headRefheadSha 傳入 resolveMergeBase,用明確 refspec 加深 PR 來源分支,或直接要求 checkout 使用 fetch-depth: 0 並移除此誤導性的 fallback。

<!-- ai-code-review --> ### 🟠 警告|🔮 Mage **位置**:`src/lib/gitrepo.js` 第 140–140 行 **問題描述** `deepen HEAD` 策略實際執行的是 `git fetch --deepen=1000 origin HEAD`,這裡的 `HEAD` 是遠端的預設分支符號,不是目前 checkout 的 PR head commit。最小重現:runner 淺層 checkout 停在 feature PR 的 detached HEAD,而 `origin/HEAD` 指向 `develop`;`unshallow` 失敗後,此策略只會加深預設分支,無法補到 feature 分支祖先,`merge-base origin/<baseRef> HEAD` 仍會失敗。 **修改建議** 補抓 PR head 時不要使用遠端符號 `HEAD`。將 `headRef` 或 `headSha` 傳入 `resolveMergeBase`,用明確 refspec 加深 PR 來源分支,或直接要求 checkout 使用 `fetch-depth: 0` 並移除此誤導性的 fallback。
Author
Owner

🟠 警告|🎼 Bard

位置src/lib/review.js 第 29–42 行

問題描述

這段註解的旋律前後走調:標題說「原始輸出預設隱藏」,內文卻又說失敗時預設附上 stderr 與 stdout 片段。讀者會被兩個互相拉扯的敘述困住,不知道此函式到底偏向保守隱藏,還是偏向輸出遮罩後的診斷。

修改建議

讓摘要與實際行為同調,明確寫成「預設輸出遮罩後的診斷片段」,避免維護者誤會日誌策略。

建議寫法

/**
 * 從 `runAgent` 的失敗結果組出可診斷的一行摘要:退出碼/訊號為主,並附上遮罩後的 stderr/stdout 片段。
 *
 * 安全考量:AI CLI 失敗時可能在 stderr/stdout 回顯提示內容、環境資訊、token、PII 或
 * 原始碼祕密,因此輸出前一律經 {@link redactSecrets} 遮罩、去除控制字元並限制長度。
 */
<!-- ai-code-review --> ### 🟠 警告|🎼 Bard **位置**:`src/lib/review.js` 第 29–42 行 **問題描述** 這段註解的旋律前後走調:標題說「原始輸出預設隱藏」,內文卻又說失敗時預設附上 stderr 與 stdout 片段。讀者會被兩個互相拉扯的敘述困住,不知道此函式到底偏向保守隱藏,還是偏向輸出遮罩後的診斷。 **修改建議** 讓摘要與實際行為同調,明確寫成「預設輸出遮罩後的診斷片段」,避免維護者誤會日誌策略。 **建議寫法** ``` /** * 從 `runAgent` 的失敗結果組出可診斷的一行摘要:退出碼/訊號為主,並附上遮罩後的 stderr/stdout 片段。 * * 安全考量:AI CLI 失敗時可能在 stderr/stdout 回顯提示內容、環境資訊、token、PII 或 * 原始碼祕密,因此輸出前一律經 {@link redactSecrets} 遮罩、去除控制字元並限制長度。 */ ```
Author
Owner

🔵 建議|🎼 Bard

位置action.yml 第 3–3 行

問題描述

檔案標頭仍寫 更新時間:2026/07/17 18:49:58,但本次送審資訊標示此檔最後更新為 2026/07/20。時間戳若不能忠實反映變更,就像譜面上錯置的小節號,會讓讀者懷疑整份文件的新舊狀態。

修改建議

同步更新時間戳,或乾脆移除人工維護的更新時間,避免每次變更都多一個容易走音的欄位。

<!-- ai-code-review --> ### 🔵 建議|🎼 Bard **位置**:`action.yml` 第 3–3 行 **問題描述** 檔案標頭仍寫 `更新時間:2026/07/17 18:49:58`,但本次送審資訊標示此檔最後更新為 2026/07/20。時間戳若不能忠實反映變更,就像譜面上錯置的小節號,會讓讀者懷疑整份文件的新舊狀態。 **修改建議** 同步更新時間戳,或乾脆移除人工維護的更新時間,避免每次變更都多一個容易走音的欄位。
Author
Owner

🔵 建議|🎼 Bard

位置readme.md 第 38–49 行

問題描述

Mermaid 流程圖把 S8 接到 S2,再接 S9,視覺節奏突然回跳;即使這是在表達「延後執行」,節點編號仍讓閱讀者以為流程倒退。文件的譜面應該讓眼睛順著走,而不是靠註解猜節拍。

修改建議

把節點 ID 與顯示步驟拆開,或改用語意節點名稱,例如 ResolveOldComments[2 延後將舊留言標記解決...],讓圖的結構順序與閱讀順序一致。

<!-- ai-code-review --> ### 🔵 建議|🎼 Bard **位置**:`readme.md` 第 38–49 行 **問題描述** Mermaid 流程圖把 S8 接到 S2,再接 S9,視覺節奏突然回跳;即使這是在表達「延後執行」,節點編號仍讓閱讀者以為流程倒退。文件的譜面應該讓眼睛順著走,而不是靠註解猜節拍。 **修改建議** 把節點 ID 與顯示步驟拆開,或改用語意節點名稱,例如 `ResolveOldComments[2 延後將舊留言標記解決...]`,讓圖的結構順序與閱讀順序一致。
Author
Owner

🔵 建議|🎼 Bard

位置src/index.js 第 7–7 行

問題描述

啟動 banner 的 更新時間 與本次檔案實際更新日期不一致。執行日誌是維運者第一眼看到的旋律,若時間停在舊日期,會讓人誤判目前跑的版本是否真的是最新變更。

修改建議

同步更新這個時間,或改由版本/commit SHA 取代人工日期,減少文件性欄位反覆失準。

<!-- ai-code-review --> ### 🔵 建議|🎼 Bard **位置**:`src/index.js` 第 7–7 行 **問題描述** 啟動 banner 的 `更新時間` 與本次檔案實際更新日期不一致。執行日誌是維運者第一眼看到的旋律,若時間停在舊日期,會讓人誤判目前跑的版本是否真的是最新變更。 **修改建議** 同步更新這個時間,或改由版本/commit SHA 取代人工日期,減少文件性欄位反覆失準。
Author
Owner

🔵 建議|🎼 Bard

位置src/lib/templates.js 第 334–341 行

問題描述

issueFindingComment 的註解只說它服務 review.postSevereToIssue 與「嚴重 finding」,但同次變更又引入了建問題模式下警告/建議逐條發到 issue 的描述。函式名稱是通用的 finding,註解卻只唱嚴重問題,語意不夠一致。

修改建議

把註解改成涵蓋所有 severity,並同時提到嚴重與警告/建議的 issue 留言用途,讓模板職責與名稱保持同拍。

建議寫法

* 使用情境:建問題模式下,`review.postSevereToIssue` 與 `review.postOthersToIssue`
 * 以本函式產生每條 finding 的 issue 留言內容,再經 `gitea.createCommentOnIssue`
 * 發布到追蹤 issue 上,作為問題明細的追蹤紀錄。
<!-- ai-code-review --> ### 🔵 建議|🎼 Bard **位置**:`src/lib/templates.js` 第 334–341 行 **問題描述** `issueFindingComment` 的註解只說它服務 `review.postSevereToIssue` 與「嚴重 finding」,但同次變更又引入了建問題模式下警告/建議逐條發到 issue 的描述。函式名稱是通用的 finding,註解卻只唱嚴重問題,語意不夠一致。 **修改建議** 把註解改成涵蓋所有 severity,並同時提到嚴重與警告/建議的 issue 留言用途,讓模板職責與名稱保持同拍。 **建議寫法** ``` * 使用情境:建問題模式下,`review.postSevereToIssue` 與 `review.postOthersToIssue` * 以本函式產生每條 finding 的 issue 留言內容,再經 `gitea.createCommentOnIssue` * 發布到追蹤 issue 上,作為問題明細的追蹤紀錄。 ```
Member

🧩 code-review-resolve 處理進度

本議題為 AI Code Review 建問題模式的追蹤議題。以 --issue all 併同 .gitea/ai-review/findings/ 逐條處理後結果如下(對照目前程式碼與 exclusions.json):

# 等級 審查員 位置 處理結果 說明
1 🔴 嚴重 Assassin src/index.js 第 409–416 行 🚫誤報 嚴重 gate 於 result==='failure' 仍 return 0、押下一輪 side effect 的指控,已由 exclusions 裁決為誤報。
2 🟠 警告 Bard src/index.js 第 119–157 行 🚫誤報 main() 步驟編號「步驟 2 延後執行」造成閱讀負擔,已列入 exclusions(步驟編號同一類問題)。
3 🟠 警告 Rogue src/index.js 第 369–370 行 ⏭️待人工 建問題模式 others 逐條 N 次 POST 的效能取捨,屬 Rogue 效能類待人工研判,不得硬改設計。
4 🟠 警告 Mage src/lib/gitrepo.js 第 140–140 行 已解決 現行 gitrepo.js 已改用 rev-parse 取得 headSha、以 fetch --deepen origin (deepen PR HEAD)補抓,非遠端符號 HEAD。
5 🟠 警告 Bard src/lib/review.js 第 29–42 行 🚫誤報 agentFailureDetail 註解「原始輸出預設隱藏」與「預設附遮罩片段」前後不一致,已由 exclusions 裁決。
6 🔵 建議 Bard action.yml 第 3–3 行 🚫誤報 action.yml 檔頭「更新時間」時間戳過期,屬各檔頭人工時間戳過期類,已列入 exclusions。
7 🔵 建議 Bard readme.md 第 38–49 行 🚫誤報 readme.md Mermaid S8→S2→S9 節點編號回跳,即 exclusions 已涵蓋的步驟編號問題。
8 🔵 建議 Bard src/index.js 第 7–7 行 🚫誤報 index.js 啟動 banner「更新時間」與實際更新日期不一致,屬各檔頭人工時間戳過期類,已列入 exclusions。
9 🔵 建議 Bard src/lib/templates.js 第 334–341 行 ⏭️待人工 templates.js issueFindingComment JSDoc 用途描述過窄,屬 Bard 風格類 JSDoc 用途描述取捨,待人工研判不硬改。

小計 已解決 1 條、🚫 誤報(已列入 exclusions)6 條、⏭️ 待人工處理 2 條。

⏭️ 待人工處理項目屬設計/效能/慣例取捨(skill 規範不得硬改),已將「只來自議題」的待人工問題(依主題去重)寫回 .gitea/ai-review/findings/2026-07-20-18:31:07.json 追蹤,關閉本議題不會遺失待辦。

  • 已解決:問題於目前程式碼已修復(如 resolveMergeBase 補抓策略調整、deepen PR HEAD 改用 head SHA、留言閉包改名、push-token input 移除等)。
  • 🚫 誤報:與 .gitea/ai-review/exclusions.json 既有裁決等價,不重複新增排除條目。

處理完成,依 code-review-resolve 流程關閉本議題。

<!-- code-review-resolve --> ## 🧩 code-review-resolve 處理進度 本議題為 AI Code Review 建問題模式的追蹤議題。以 `--issue all` 併同 `.gitea/ai-review/findings/` 逐條處理後結果如下(對照目前程式碼與 `exclusions.json`): | # | 等級 | 審查員 | 位置 | 處理結果 | 說明 | | --- | --- | --- | --- | --- | --- | | 1 | 🔴 嚴重 | Assassin | `src/index.js` 第 409–416 行 | 🚫誤報 | 嚴重 gate 於 result==='failure' 仍 return 0、押下一輪 side effect 的指控,已由 exclusions 裁決為誤報。 | | 2 | 🟠 警告 | Bard | `src/index.js` 第 119–157 行 | 🚫誤報 | main() 步驟編號「步驟 2 延後執行」造成閱讀負擔,已列入 exclusions(步驟編號同一類問題)。 | | 3 | 🟠 警告 | Rogue | `src/index.js` 第 369–370 行 | ⏭️待人工 | 建問題模式 others 逐條 N 次 POST 的效能取捨,屬 Rogue 效能類待人工研判,不得硬改設計。 | | 4 | 🟠 警告 | Mage | `src/lib/gitrepo.js` 第 140–140 行 | ✅已解決 | 現行 gitrepo.js 已改用 rev-parse 取得 headSha、以 fetch --deepen origin <headSha>(deepen PR HEAD)補抓,非遠端符號 HEAD。 | | 5 | 🟠 警告 | Bard | `src/lib/review.js` 第 29–42 行 | 🚫誤報 | agentFailureDetail 註解「原始輸出預設隱藏」與「預設附遮罩片段」前後不一致,已由 exclusions 裁決。 | | 6 | 🔵 建議 | Bard | `action.yml` 第 3–3 行 | 🚫誤報 | action.yml 檔頭「更新時間」時間戳過期,屬各檔頭人工時間戳過期類,已列入 exclusions。 | | 7 | 🔵 建議 | Bard | `readme.md` 第 38–49 行 | 🚫誤報 | readme.md Mermaid S8→S2→S9 節點編號回跳,即 exclusions 已涵蓋的步驟編號問題。 | | 8 | 🔵 建議 | Bard | `src/index.js` 第 7–7 行 | 🚫誤報 | index.js 啟動 banner「更新時間」與實際更新日期不一致,屬各檔頭人工時間戳過期類,已列入 exclusions。 | | 9 | 🔵 建議 | Bard | `src/lib/templates.js` 第 334–341 行 | ⏭️待人工 | templates.js issueFindingComment JSDoc 用途描述過窄,屬 Bard 風格類 JSDoc 用途描述取捨,待人工研判不硬改。 | **小計**:✅ 已解決 1 條、🚫 誤報(已列入 exclusions)6 條、⏭️ 待人工處理 2 條。 > ⏭️ 待人工處理項目屬設計/效能/慣例取捨(skill 規範不得硬改),已將「只來自議題」的待人工問題(依主題去重)寫回 `.gitea/ai-review/findings/2026-07-20-18:31:07.json` 追蹤,關閉本議題不會遺失待辦。 - ✅ 已解決:問題於目前程式碼已修復(如 `resolveMergeBase` 補抓策略調整、`deepen PR HEAD` 改用 head SHA、留言閉包改名、`push-token` input 移除等)。 - 🚫 誤報:與 `.gitea/ai-review/exclusions.json` 既有裁決等價,不重複新增排除條目。 處理完成,依 code-review-resolve 流程關閉本議題。
Sign in to join this conversation.
No labels
2 Participants
Notifications
Due Date
No due date set.
Reference: node-actions/ai-code-review#20