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

Closed
opened 2026-07-20 09:21:16 +00:00 by admin · 12 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 321a717f91303bd4b865eacb0d11546ef9e79e11
Run Job #33
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 | `321a717f91303bd4b865eacb0d11546ef9e79e11` | | Run Job | [#33](https://gitea.jsc.idv.tw/node-actions/ai-code-review/actions/runs/1602) | ```mermaid flowchart LR A[整理 git diff] --> B[⚔️ 攻擊方找問題] B --> C[🛡️ 防守方裁決] C --> D[保存 findings] D --> E[留言到 PR] ```
Author
Owner

📋 變更摘要(送審 git diff)

檔案 用途 git diff 長度 最後更新時間
action.yml 定義 Action 輸入與執行入口 95 行/4205 字元 2026/07/20 15:00:23
readme.md 說明 AI Code Review 用法與流程 276 行/23829 字元(過長截斷送審) 2026/07/20 16:01:05
src/index.js 編排 AI code review 主流程 320 行/14204 字元 2026/07/20 15:00:15
src/lib/agents.js 偵測並執行可用 AI 工具 14 行/503 字元 2026/07/20 09:46:12
src/lib/context.js 載入 workflow 與 PR 執行脈絡 31 行/1398 字元 2026/07/20 15:00:23
src/lib/gitea.js 封裝 Gitea API 操作 121 行/5278 字元 2026/07/20 16:01:05
src/lib/gitrepo.js 封裝 git diff 與提交操作 222 行/9110 字元 2026/07/20 16:01:05
src/lib/review.js 整理 diff 並執行審查邏輯 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 留言 Markdown 模板 165 行/5949 字元 2026/07/20 15:00:32

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

<!-- ai-code-review --> ## 📋 變更摘要(送審 git diff) | 檔案 | 用途 | git diff 長度 | 最後更新時間 | | --- | --- | --- | --- | | `action.yml` | 定義 Action 輸入與執行入口 | 95 行/4205 字元 | 2026/07/20 15:00:23 | | `readme.md` | 說明 AI Code Review 用法與流程 | 276 行/23829 字元(過長截斷送審) | 2026/07/20 16:01:05 | | `src/index.js` | 編排 AI code review 主流程 | 320 行/14204 字元 | 2026/07/20 15:00:15 | | `src/lib/agents.js` | 偵測並執行可用 AI 工具 | 14 行/503 字元 | 2026/07/20 09:46:12 | | `src/lib/context.js` | 載入 workflow 與 PR 執行脈絡 | 31 行/1398 字元 | 2026/07/20 15:00:23 | | `src/lib/gitea.js` | 封裝 Gitea API 操作 | 121 行/5278 字元 | 2026/07/20 16:01:05 | | `src/lib/gitrepo.js` | 封裝 git diff 與提交操作 | 222 行/9110 字元 | 2026/07/20 16:01:05 | | `src/lib/review.js` | 整理 diff 並執行審查邏輯 | 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 留言 Markdown 模板 | 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

🟠 警告|🧰 Leo

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

問題描述

流程步驟編號現在變成維護負擔:步驟 2 被描述為「延後執行」,實際程式順序又在步驟 8 後、步驟 9 前才跑;同一批編號還同步出現在 readme.mdtemplates.jsreview.jsgitea.jsagents.js 的註解與 log。這類人工同步的流程編號很容易在下一次調整時再次漂移,讀者會拿到一份看似精準、其實要逐檔對照才敢相信的文件。

修改建議

把對外文件保留高層流程即可,程式內 log 建議改用穩定語意名稱,例如 tool-detectdiff-summaryresolve-old-commentspublish-findings,不要依賴會重排的數字。若一定要顯示步驟,集中定義在一個 workflow metadata 常數,由 README 產生或至少讓 templates/log 共用同一份來源。

<!-- ai-code-review --> ### 🟠 警告|🧰 Leo **位置**:`src/index.js` 第 119–149 行 **問題描述** 流程步驟編號現在變成維護負擔:步驟 2 被描述為「延後執行」,實際程式順序又在步驟 8 後、步驟 9 前才跑;同一批編號還同步出現在 `readme.md`、`templates.js`、`review.js`、`gitea.js`、`agents.js` 的註解與 log。這類人工同步的流程編號很容易在下一次調整時再次漂移,讀者會拿到一份看似精準、其實要逐檔對照才敢相信的文件。 **修改建議** 把對外文件保留高層流程即可,程式內 log 建議改用穩定語意名稱,例如 `tool-detect`、`diff-summary`、`resolve-old-comments`、`publish-findings`,不要依賴會重排的數字。若一定要顯示步驟,集中定義在一個 workflow metadata 常數,由 README 產生或至少讓 templates/log 共用同一份來源。
Author
Owner

🟠 警告| Rogue

位置src/lib/gitrepo.js 第 133–134 行

問題描述

這裡把 --unshallow origin 放在第一個補抓策略。淺層 checkout 一旦首次 merge-base 失敗,就可能直接下載整個遠端歷史與多個 ref;大型 repo 會把原本幾秒的 diff 準備拖成數分鐘,還吃掉大量網路與磁碟。這不是微優化,是 CI 熱路徑上的整包歷史下載。

修改建議

先用有界的 refspec deepen 補 base 與 HEAD,只有都失敗時才把 --unshallow 當最後手段。這樣大多數 PR 只補需要的歷史深度,不會一開始就吞完整 repo。

建議寫法

const strategies = [
  [
    'deepen base',
    'fetch', '--no-tags', '--deepen=1000', 'origin', `+refs/heads/${baseRef}:refs/remotes/${remoteBase}`,
  ],
  ['deepen HEAD', 'fetch', '--no-tags', '--deepen=1000', 'origin', 'HEAD'],
];
if (gitTrim(cwd, 'rev-parse', '--is-shallow-repository') === 'true') {
  strategies.push(['unshallow', 'fetch', '--no-tags', '--unshallow', 'origin']);
}
<!-- ai-code-review --> ### 🟠 警告|⚡ Rogue **位置**:`src/lib/gitrepo.js` 第 133–134 行 **問題描述** 這裡把 `--unshallow origin` 放在第一個補抓策略。淺層 checkout 一旦首次 `merge-base` 失敗,就可能直接下載整個遠端歷史與多個 ref;大型 repo 會把原本幾秒的 diff 準備拖成數分鐘,還吃掉大量網路與磁碟。這不是微優化,是 CI 熱路徑上的整包歷史下載。 **修改建議** 先用有界的 refspec deepen 補 base 與 HEAD,只有都失敗時才把 `--unshallow` 當最後手段。這樣大多數 PR 只補需要的歷史深度,不會一開始就吞完整 repo。 **建議寫法** ``` const strategies = [ [ 'deepen base', 'fetch', '--no-tags', '--deepen=1000', 'origin', `+refs/heads/${baseRef}:refs/remotes/${remoteBase}`, ], ['deepen HEAD', 'fetch', '--no-tags', '--deepen=1000', 'origin', 'HEAD'], ]; if (gitTrim(cwd, 'rev-parse', '--is-shallow-repository') === 'true') { strategies.push(['unshallow', 'fetch', '--no-tags', '--unshallow', 'origin']); } ```
Author
Owner

🟠 警告|🔮 Mage

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

問題描述

淺層 checkout 且 --unshallow 失敗時,deepen HEAD 策略實際執行的是 git fetch --deepen=1000 origin HEAD。這裡的 origin HEAD 是遠端預設分支,不一定是目前 PR 的 head 分支或目前 detached HEAD 的祖先。

最小重現情境:PR 來源分支是 feature/x,runner checkout 到該 PR head 的 shallow commit;遠端預設分支是 develop--unshallow 因伺服器限制失敗。此時 deepen 的是 develop,不是 feature/xmerge-base origin/<baseRef> HEAD 仍可能失敗,導致整個審查流程中止。

修改建議

不要用遠端預設 HEAD 代表 PR head。把 PR head ref 或 head SHA 傳入 resolveMergeBase,針對實際 PR head 補抓歷史;若只能取得 SHA,至少在錯誤訊息中明確指出無法 deepen PR head,而不是執行不相關的 origin HEAD

<!-- ai-code-review --> ### 🟠 警告|🔮 Mage **位置**:`src/lib/gitrepo.js` 第 143–143 行 **問題描述** 淺層 checkout 且 `--unshallow` 失敗時,`deepen HEAD` 策略實際執行的是 `git fetch --deepen=1000 origin HEAD`。這裡的 `origin HEAD` 是遠端預設分支,不一定是目前 PR 的 head 分支或目前 detached HEAD 的祖先。 最小重現情境:PR 來源分支是 `feature/x`,runner checkout 到該 PR head 的 shallow commit;遠端預設分支是 `develop`;`--unshallow` 因伺服器限制失敗。此時 deepen 的是 `develop`,不是 `feature/x`,`merge-base origin/<baseRef> HEAD` 仍可能失敗,導致整個審查流程中止。 **修改建議** 不要用遠端預設 `HEAD` 代表 PR head。把 PR head ref 或 head SHA 傳入 `resolveMergeBase`,針對實際 PR head 補抓歷史;若只能取得 SHA,至少在錯誤訊息中明確指出無法 deepen PR head,而不是執行不相關的 `origin HEAD`。
Author
Owner

🔵 建議|🎼 Bard

位置action.yml 第 3–3 行

問題描述

手寫的「更新時間」仍停在 2026/07/17,但本次變更明顯新增了 push-token 等內容;這種時間戳像失準的節拍器,會讓讀者懷疑文件是否可信。

修改建議

移除手動維護的更新時間,或改由發布/產檔流程自動產生,避免每次修改都要靠人肉同步。

<!-- ai-code-review --> ### 🔵 建議|🎼 Bard **位置**:`action.yml` 第 3–3 行 **問題描述** 手寫的「更新時間」仍停在 2026/07/17,但本次變更明顯新增了 `push-token` 等內容;這種時間戳像失準的節拍器,會讓讀者懷疑文件是否可信。 **修改建議** 移除手動維護的更新時間,或改由發布/產檔流程自動產生,避免每次修改都要靠人肉同步。
Author
Owner

🔵 建議|🧰 Leo

位置src/lib/review.js 第 13–72 行

問題描述

redactSecrets()agentFailureDetail() 是低階日誌診斷/遮罩邏輯,現在放在 review.js 這個負責 diff 整理與審查決策的模組頂端。這會讓 review.js 的職責繼續膨脹:未來若其他模組也要安全輸出 CLI 錯誤,只能複製這段或反向依賴 review 模組,邊界會越來越不清楚。

修改建議

把這兩個函式搬到專門的工具模組,例如 src/lib/diagnostics.jssrc/lib/log-redaction.js,並由 review.js 引入。這樣遮罩規則可集中測試與重用,review.js 也能維持在「審查流程資料處理」的邊界內。

<!-- ai-code-review --> ### 🔵 建議|🧰 Leo **位置**:`src/lib/review.js` 第 13–72 行 **問題描述** `redactSecrets()` 與 `agentFailureDetail()` 是低階日誌診斷/遮罩邏輯,現在放在 `review.js` 這個負責 diff 整理與審查決策的模組頂端。這會讓 `review.js` 的職責繼續膨脹:未來若其他模組也要安全輸出 CLI 錯誤,只能複製這段或反向依賴 review 模組,邊界會越來越不清楚。 **修改建議** 把這兩個函式搬到專門的工具模組,例如 `src/lib/diagnostics.js` 或 `src/lib/log-redaction.js`,並由 `review.js` 引入。這樣遮罩規則可集中測試與重用,`review.js` 也能維持在「審查流程資料處理」的邊界內。
Author
Owner

🔵 建議|🎼 Bard

位置src/lib/review.js 第 41–45 行

問題描述

這段註解的旋律前後走調:摘要先說「原始輸出預設隱藏」,下一段卻說失敗時「預設附上 stderr 與 stdout」。讀者還沒進函式本體,文件本身就已經互相拉扯。

修改建議

請讓摘要與實作同拍,直接說明會輸出經遮罩與限長的診斷片段;若真的要隱藏原始輸出,也應同步改實作。

建議寫法

* 從 `runAgent` 的失敗結果組出可診斷的一行摘要:退出碼/訊號為主,並附上經遮罩與限長的 stderr/stdout 片段。
<!-- ai-code-review --> ### 🔵 建議|🎼 Bard **位置**:`src/lib/review.js` 第 41–45 行 **問題描述** 這段註解的旋律前後走調:摘要先說「原始輸出預設隱藏」,下一段卻說失敗時「預設附上 stderr 與 stdout」。讀者還沒進函式本體,文件本身就已經互相拉扯。 **修改建議** 請讓摘要與實作同拍,直接說明會輸出經遮罩與限長的診斷片段;若真的要隱藏原始輸出,也應同步改實作。 **建議寫法** ``` * 從 `runAgent` 的失敗結果組出可診斷的一行摘要:退出碼/訊號為主,並附上經遮罩與限長的 stderr/stdout 片段。 ```
Author
Owner

🔵 建議|🎼 Bard

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

問題描述

issueFindingComment 的文件只唱「嚴重 finding」,但新版流程也讓警告與建議逐條發到 issue。函式名稱是通用的,註解卻把用途寫窄,後續讀者會誤以為它只服務嚴重問題。

修改建議

把註解改成涵蓋所有 finding 等級,讓文件與函式名稱、呼叫情境保持一致。

建議寫法

* 使用情境:建問題模式下,`review.postSevereToIssue` 與 `review.postOthersToIssue`
 * 會把各等級 finding 以本函式產生留言內容、經 `gitea.createCommentOnIssue`
 * 發布到追蹤 issue 上,作為問題明細的追蹤紀錄。
<!-- ai-code-review --> ### 🔵 建議|🎼 Bard **位置**:`src/lib/templates.js` 第 334–338 行 **問題描述** `issueFindingComment` 的文件只唱「嚴重 finding」,但新版流程也讓警告與建議逐條發到 issue。函式名稱是通用的,註解卻把用途寫窄,後續讀者會誤以為它只服務嚴重問題。 **修改建議** 把註解改成涵蓋所有 finding 等級,讓文件與函式名稱、呼叫情境保持一致。 **建議寫法** ``` * 使用情境:建問題模式下,`review.postSevereToIssue` 與 `review.postOthersToIssue` * 會把各等級 finding 以本函式產生留言內容、經 `gitea.createCommentOnIssue` * 發布到追蹤 issue 上,作為問題明細的追蹤紀錄。 ```
Member

🧩 code-review-resolve 處理進度

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

# 等級 審查員 位置 處理結果 說明
1 🟠 警告 Leo src/index.js 第 119–149 行 🚫誤報 步驟編號「步驟2延後執行」造成閱讀負擔屬設計取捨,已於 exclusions 有等價條目裁決為誤報。
2 🟠 警告 Rogue src/lib/gitrepo.js 第 133–134 行 已解決 現行 gitrepo.js 已改為先 deepen base/PR HEAD,--unshallow 僅在仍失敗且為淺層 repo 時當最後手段。
3 🟠 警告 Mage src/lib/gitrepo.js 第 143–143 行 已解決 現行程式碼已改用 rev-parse HEAD 取得 headSha 並以策略名 deepen PR HEAD 補抓,不再 deepen origin 預設分支。
4 🔵 建議 Bard action.yml 第 3–3 行 🚫誤報 檔頭更新時間時間戳過期已列入 exclusions 為誤報;且所指 push-token 內容早已自 action.yml 移除。
5 🔵 建議 Leo src/lib/review.js 第 13–72 行 ⏭️待人工 將 redactSecrets/agentFailureDetail 抽到獨立工具模組屬模組邊界重構取捨,skill 規範不得硬改。
6 🔵 建議 Bard src/lib/review.js 第 41–45 行 ⏭️待人工 agentFailureDetail 摘要與實作對隱藏/附上原始輸出的敘述不一致屬 JSDoc 用語取捨,須人工研判。
7 🔵 建議 Bard src/lib/templates.js 第 334–338 行 ⏭️待人工 issueFindingComment JSDoc 用途描述過窄的風格問題,屬需人工調整的 Bard 風格類項目。

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

⏭️ 待人工處理項目屬設計/效能/慣例取捨(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 | 🟠 警告 | Leo | `src/index.js` 第 119–149 行 | 🚫誤報 | 步驟編號「步驟2延後執行」造成閱讀負擔屬設計取捨,已於 exclusions 有等價條目裁決為誤報。 | | 2 | 🟠 警告 | Rogue | `src/lib/gitrepo.js` 第 133–134 行 | ✅已解決 | 現行 gitrepo.js 已改為先 deepen base/PR HEAD,--unshallow 僅在仍失敗且為淺層 repo 時當最後手段。 | | 3 | 🟠 警告 | Mage | `src/lib/gitrepo.js` 第 143–143 行 | ✅已解決 | 現行程式碼已改用 rev-parse HEAD 取得 headSha 並以策略名 deepen PR HEAD 補抓,不再 deepen origin 預設分支。 | | 4 | 🔵 建議 | Bard | `action.yml` 第 3–3 行 | 🚫誤報 | 檔頭更新時間時間戳過期已列入 exclusions 為誤報;且所指 push-token 內容早已自 action.yml 移除。 | | 5 | 🔵 建議 | Leo | `src/lib/review.js` 第 13–72 行 | ⏭️待人工 | 將 redactSecrets/agentFailureDetail 抽到獨立工具模組屬模組邊界重構取捨,skill 規範不得硬改。 | | 6 | 🔵 建議 | Bard | `src/lib/review.js` 第 41–45 行 | ⏭️待人工 | agentFailureDetail 摘要與實作對隱藏/附上原始輸出的敘述不一致屬 JSDoc 用語取捨,須人工研判。 | | 7 | 🔵 建議 | Bard | `src/lib/templates.js` 第 334–338 行 | ⏭️待人工 | issueFindingComment JSDoc 用途描述過窄的風格問題,屬需人工調整的 Bard 風格類項目。 | **小計**:✅ 已解決 2 條、🚫 誤報(已列入 exclusions)2 條、⏭️ 待人工處理 3 條。 > ⏭️ 待人工處理項目屬設計/效能/慣例取捨(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#17