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

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

New Issue
Closed
opened 2026-07-20 10:36:02 +00:00 by admin · 10 comments
admin commented 2026-07-20 10:36:02 +00:00
Owner
Copy Link
Copy Source

變更摘要

本 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 的審查結果自動建立，問題明細見下方留言。

<!-- 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 的審查結果自動建立，問題明細見下方留言。
admin commented 2026-07-20 10:36:02 +00:00
Author
Owner
Copy Link
Copy Source

🤖 AI Code Review｜審查工具

項目 內容
工具 codex
版本 codex-cli 0.144.6
模型 gpt-5.5
審查 commit d7cecc8fa858abd63e5ba43f80d6545a55ff3495
Run Job #51 
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 | `d7cecc8fa858abd63e5ba43f80d6545a55ff3495` | | Run Job | [#51](https://gitea.jsc.idv.tw/node-actions/ai-code-review/actions/runs/1620) | ```mermaid flowchart LR A[整理 git diff] --> B[⚔️ 攻擊方找問題] B --> C[🛡️ 防守方裁決] C --> D[保存 findings] D --> E[留言到 PR] ```
admin commented 2026-07-20 10:36:02 +00:00
Author
Owner
Copy Link
Copy Source

📋 變更摘要（送審 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 主流程 360 行／16212 字元（過長截斷送審） 2026/07/20 18:04:23
src/lib/agents.js 偵測並執行 AI 審查工具 14 行／503 字元 2026/07/20 09:46:12
src/lib/context.js 載入 workflow 與 PR 上下文 15 行／769 字元 2026/07/20 17:24:18
src/lib/gitea.js 封裝 Gitea API 操作 130 行／5744 字元 2026/07/20 18:04:23
src/lib/gitrepo.js 封裝 git diff 與提交操作 224 行／9542 字元 2026/07/20 18:04:23
src/lib/review.js 處理審查、裁決與留言內容 582 行／25065 字元（過長截斷送審） 2026/07/20 18:04:23
src/lib/roles.js 載入並分類審查角色提示 14 行／586 字元 2026/07/20 09:46:12
src/lib/templates.js 產生 PR 留言 Markdown 模板 165 行／5966 字元 2026/07/20 18:04:23

共 10 個檔案納入審查；另有 10 個檔案依 .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 主流程 | 360 行／16212 字元（過長截斷送審） | 2026/07/20 18:04:23 | | `src/lib/agents.js` | 偵測並執行 AI 審查工具 | 14 行／503 字元 | 2026/07/20 09:46:12 | | `src/lib/context.js` | 載入 workflow 與 PR 上下文 | 15 行／769 字元 | 2026/07/20 17:24:18 | | `src/lib/gitea.js` | 封裝 Gitea API 操作 | 130 行／5744 字元 | 2026/07/20 18:04:23 | | `src/lib/gitrepo.js` | 封裝 git diff 與提交操作 | 224 行／9542 字元 | 2026/07/20 18:04:23 | | `src/lib/review.js` | 處理審查、裁決與留言內容 | 582 行／25065 字元（過長截斷送審） | 2026/07/20 18:04:23 | | `src/lib/roles.js` | 載入並分類審查角色提示 | 14 行／586 字元 | 2026/07/20 09:46:12 | | `src/lib/templates.js` | 產生 PR 留言 Markdown 模板 | 165 行／5966 字元 | 2026/07/20 18:04:23 | > 共 10 個檔案納入審查；另有 10 個檔案依 `.reviewignore` 排除。
admin commented 2026-07-20 10:36:02 +00:00
Author
Owner
Copy Link
Copy Source

⚔️ 攻擊方登場

角色 面向 個性
🗡️ 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 週期與記憶體，凡事先問「這能不能更快、更省」 |
admin commented 2026-07-20 10:36:02 +00:00
Author
Owner
Copy Link
Copy Source

🛡️ 防守方登場

角色 面向 個性
🛡️ Paladin 裁決（verdict） 沉穩公正、就事論事，不護短也不冤枉，只依排除事項與原始碼脈絡裁定問題成立與否
<!-- ai-code-review --> ## 🛡️ 防守方登場 | 角色 | 面向 | 個性 | | --- | --- | --- | | 🛡️ **Paladin** | 裁決（verdict） | 沉穩公正、就事論事，不護短也不冤枉，只依排除事項與原始碼脈絡裁定問題成立與否 |
admin commented 2026-07-20 10:36:02 +00:00
Author
Owner
Copy Link
Copy Source

🔴 嚴重｜🗡️ Assassin

位置：src/index.js 第 386–392 行

問題描述

建問題模式下，嚴重問題只靠 addIssueDependency 阻擋 PR；但這裡把相依設定失敗降級成 WRN。攻擊者只要讓目標 Gitea 未啟用 issue dependencies、API 不支援、token 權限不足，或相依建立暫時失敗，嚴重安全 finding 仍可能只留下提示留言，而檢查流程繼續成功收場。這是審查閘門可被環境設定繞過。

修改建議

有嚴重問題時，相依關係建立失敗不得靜默放行。至少要讓本輪檢查失敗，或保證推出 [failure] 結果 commit；若建問題模式不提交 findings，也應有一個固定結果檔或直接 return 1 作為保底。

建議寫法

if (severe.length > 0) {
  try {
    await gitea.addIssueDependency(ctx, ctx.prNumber, issue.number);
    log('建問題', 'INF', `有嚴重問題：已將 PR #${ctx.prNumber} 設為相依於 issue #${issue.number}。`);
  } catch (err) {
    log('建問題', 'ERR', `有嚴重問題但設定 PR 相依失敗：${err.message}。`);
    return 1;
  }
}
<!-- ai-code-review --> ### 🔴 嚴重｜🗡️ Assassin **位置**：`src/index.js` 第 386–392 行 **問題描述** 建問題模式下，嚴重問題只靠 `addIssueDependency` 阻擋 PR；但這裡把相依設定失敗降級成 WRN。攻擊者只要讓目標 Gitea 未啟用 issue dependencies、API 不支援、token 權限不足，或相依建立暫時失敗，嚴重安全 finding 仍可能只留下提示留言，而檢查流程繼續成功收場。這是審查閘門可被環境設定繞過。 **修改建議** 有嚴重問題時，相依關係建立失敗不得靜默放行。至少要讓本輪檢查失敗，或保證推出 `[failure]` 結果 commit；若建問題模式不提交 findings，也應有一個固定結果檔或直接 `return 1` 作為保底。 **建議寫法** ``` if (severe.length > 0) { try { await gitea.addIssueDependency(ctx, ctx.prNumber, issue.number); log('建問題', 'INF', `有嚴重問題：已將 PR #${ctx.prNumber} 設為相依於 issue #${issue.number}。`); } catch (err) { log('建問題', 'ERR', `有嚴重問題但設定 PR 相依失敗：${err.message}。`); return 1; } } ```
admin commented 2026-07-20 10:36:02 +00:00
Author
Owner
Copy Link
Copy Source

🔴 嚴重｜🔮 Mage

位置：src/index.js 第 397–414 行

問題描述

在有「嚴重」finding 的本輪審查中，程式改成一律回傳 0，並假設後續由 [ai-review-bot][failure] commit 觸發下一輪才讓檢查失敗。這個假設沒有被驗證，最小重現：workflow 仍依 action.yml 說明傳入自動 token（例如 gitea.token / GITHUB_TOKEN），push 出 failure commit 後不會再觸發 CI；或在建問題模式下 exclusionsChanged === false，程式直接略過 commit/push。兩種情境都會讓本輪含嚴重問題的檢查以 exit 0 通過，PR 可能被誤判為可合併。

修改建議

不要把失敗狀態完全交給未保證會發生的下一輪 workflow。當 severe.length > 0 時，若沒有成功推出可觸發下一輪的 failure commit，就應在本輪回傳 1；建問題模式即使沒有 exclusions 變更，也需要有可提交的結果標記檔，或直接 exit 1。

<!-- ai-code-review --> ### 🔴 嚴重｜🔮 Mage **位置**：`src/index.js` 第 397–414 行 **問題描述** 在有「嚴重」finding 的本輪審查中，程式改成一律回傳 0，並假設後續由 `[ai-review-bot][failure]` commit 觸發下一輪才讓檢查失敗。這個假設沒有被驗證，最小重現：workflow 仍依 action.yml 說明傳入自動 token（例如 gitea.token / GITHUB_TOKEN），push 出 failure commit 後不會再觸發 CI；或在建問題模式下 `exclusionsChanged === false`，程式直接略過 commit/push。兩種情境都會讓本輪含嚴重問題的檢查以 exit 0 通過，PR 可能被誤判為可合併。 **修改建議** 不要把失敗狀態完全交給未保證會發生的下一輪 workflow。當 `severe.length > 0` 時，若沒有成功推出可觸發下一輪的 failure commit，就應在本輪回傳 1；建問題模式即使沒有 exclusions 變更，也需要有可提交的結果標記檔，或直接 exit 1。
admin commented 2026-07-20 10:36:03 +00:00
Author
Owner
Copy Link
Copy Source

🔵 建議｜🎼 Bard

位置：src/lib/review.js 第 63–66 行

問題描述

INPUT_LIMIT 與 AGENT_DIAGNOSTIC_OUTPUT_LIMIT 被放在 agentFailureDetail() 函式內，旁邊還用註解解釋它們是政策常數。既然是診斷輸出政策，藏在函式中段會讓設定散在樂句裡，不如放到檔案頂端與其他常數並列。

修改建議

將兩個限制值提升到模組層級，靠命名表達政策，函式內就不需要這麼多鋪陳註解。

建議寫法

const AGENT_DIAGNOSTIC_INPUT_LIMIT = 2_000;
const AGENT_DIAGNOSTIC_OUTPUT_LIMIT = 500;
<!-- ai-code-review --> ### 🔵 建議｜🎼 Bard **位置**：`src/lib/review.js` 第 63–66 行 **問題描述** `INPUT_LIMIT` 與 `AGENT_DIAGNOSTIC_OUTPUT_LIMIT` 被放在 `agentFailureDetail()` 函式內，旁邊還用註解解釋它們是政策常數。既然是診斷輸出政策，藏在函式中段會讓設定散在樂句裡，不如放到檔案頂端與其他常數並列。 **修改建議** 將兩個限制值提升到模組層級，靠命名表達政策，函式內就不需要這麼多鋪陳註解。 **建議寫法** ``` const AGENT_DIAGNOSTIC_INPUT_LIMIT = 2_000; const AGENT_DIAGNOSTIC_OUTPUT_LIMIT = 500; ```
admin commented 2026-07-20 10:37:50 +00:00
Author
Owner
Copy Link
Copy Source

🔴 嚴重｜🗡️ Assassin

位置：src/index.js 第 386–392 行

問題描述

建問題模式下，嚴重問題只靠 addIssueDependency 阻擋 PR；但這裡把相依設定失敗降級成 WRN。攻擊者只要讓目標 Gitea 未啟用 issue dependencies、API 不支援、token 權限不足，或相依建立暫時失敗，嚴重安全 finding 仍可能只留下提示留言，而檢查流程繼續成功收場。這是審查閘門可被環境設定繞過。

修改建議

有嚴重問題時，相依關係建立失敗不得靜默放行。至少要讓本輪檢查失敗，或保證推出 [failure] 結果 commit；若建問題模式不提交 findings，也應有一個固定結果檔或直接 return 1 作為保底。

建議寫法

if (severe.length > 0) {
  try {
    await gitea.addIssueDependency(ctx, ctx.prNumber, issue.number);
    log('建問題', 'INF', `有嚴重問題：已將 PR #${ctx.prNumber} 設為相依於 issue #${issue.number}。`);
  } catch (err) {
    log('建問題', 'ERR', `有嚴重問題但設定 PR 相依失敗：${err.message}。`);
    return 1;
  }
}

我可以接受這個風險，請幫我加入排除事項

> <!-- ai-code-review --> > ### 🔴 嚴重｜🗡️ Assassin > > **位置**：`src/index.js` 第 386–392 行 > > **問題描述** > > 建問題模式下，嚴重問題只靠 `addIssueDependency` 阻擋 PR；但這裡把相依設定失敗降級成 WRN。攻擊者只要讓目標 Gitea 未啟用 issue dependencies、API 不支援、token 權限不足，或相依建立暫時失敗，嚴重安全 finding 仍可能只留下提示留言，而檢查流程繼續成功收場。這是審查閘門可被環境設定繞過。 > > **修改建議** > > 有嚴重問題時，相依關係建立失敗不得靜默放行。至少要讓本輪檢查失敗，或保證推出 `[failure]` 結果 commit；若建問題模式不提交 findings，也應有一個固定結果檔或直接 `return 1` 作為保底。 > > **建議寫法** > > ``` > if (severe.length > 0) { > try { > await gitea.addIssueDependency(ctx, ctx.prNumber, issue.number); > log('建問題', 'INF', `有嚴重問題：已將 PR #${ctx.prNumber} 設為相依於 issue #${issue.number}。`); > } catch (err) { > log('建問題', 'ERR', `有嚴重問題但設定 PR 相依失敗：${err.message}。`); > return 1; > } > } > ``` 我可以接受這個風險，請幫我加入排除事項
admin commented 2026-07-20 10:38:21 +00:00
Author
Owner
Copy Link
Copy Source

🔴 嚴重｜🔮 Mage

位置：src/index.js 第 397–414 行

問題描述

在有「嚴重」finding 的本輪審查中，程式改成一律回傳 0，並假設後續由 [ai-review-bot][failure] commit 觸發下一輪才讓檢查失敗。這個假設沒有被驗證，最小重現：workflow 仍依 action.yml 說明傳入自動 token（例如 gitea.token / GITHUB_TOKEN），push 出 failure commit 後不會再觸發 CI；或在建問題模式下 exclusionsChanged === false，程式直接略過 commit/push。兩種情境都會讓本輪含嚴重問題的檢查以 exit 0 通過，PR 可能被誤判為可合併。

修改建議

不要把失敗狀態完全交給未保證會發生的下一輪 workflow。當 severe.length > 0 時，若沒有成功推出可觸發下一輪的 failure commit，就應在本輪回傳 1；建問題模式即使沒有 exclusions 變更，也需要有可提交的結果標記檔，或直接 exit 1。

我可以接受這個風險，請幫我加入排除事項

> <!-- ai-code-review --> > ### 🔴 嚴重｜🔮 Mage > > **位置**：`src/index.js` 第 397–414 行 > > **問題描述** > > 在有「嚴重」finding 的本輪審查中，程式改成一律回傳 0，並假設後續由 `[ai-review-bot][failure]` commit 觸發下一輪才讓檢查失敗。這個假設沒有被驗證，最小重現：workflow 仍依 action.yml 說明傳入自動 token（例如 gitea.token / GITHUB_TOKEN），push 出 failure commit 後不會再觸發 CI；或在建問題模式下 `exclusionsChanged === false`，程式直接略過 commit/push。兩種情境都會讓本輪含嚴重問題的檢查以 exit 0 通過，PR 可能被誤判為可合併。 > > **修改建議** > > 不要把失敗狀態完全交給未保證會發生的下一輪 workflow。當 `severe.length > 0` 時，若沒有成功推出可觸發下一輪的 failure commit，就應在本輪回傳 1；建問題模式即使沒有 exclusions 變更，也需要有可提交的結果標記檔，或直接 exit 1。 我可以接受這個風險，請幫我加入排除事項
jiantw83 commented 2026-07-20 10:42:53 +00:00
Member
Copy Link
Copy Source

🧩 code-review-resolve 處理進度

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

# 等級 審查員 位置 處理結果 說明
1 🔴 嚴重 Assassin src/index.js 第 386–392 行 🚫誤報 建問題模式僅靠 addIssueDependency（best-effort）阻擋合併屬既有設計取捨，exclusions.json 已有多筆等價 Mage 嚴重裁決，不重複新增。
2 🔴 嚴重 Mage src/index.js 第 397–414 行 🚫誤報 本輪一律 return 0、失敗改由下一輪讀 [ai-review-bot][failure] 結果 commit 回報，為刻意兩階段設計，已列入 exclusions。
3 🔵 建議 Bard src/lib/review.js 第 63–66 行 ✅已解決 已將 INPUT_LIMIT／AGENT_DIAGNOSTIC_OUTPUT_LIMIT 診斷輸出長度常數提升至模組頂層，與既有 PER_FILE_DIFF_LIMIT／TOTAL_DIFF_LIMIT 並列。

小計：✅ 已解決 1 條、🚫 誤報（已列入 exclusions）2 條、⏭️ 待人工處理 0 條。

本議題無「只來自議題的待人工處理」項目，無需寫回 findings。✅ 項目之程式碼修正將隨本次 code-review-resolve 一併提交並 push。

處理完成，依 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` 第 386–392 行 | 🚫誤報 | 建問題模式僅靠 addIssueDependency（best-effort）阻擋合併屬既有設計取捨，`exclusions.json` 已有多筆等價 Mage 嚴重裁決，不重複新增。 | | 2 | 🔴 嚴重 | Mage | `src/index.js` 第 397–414 行 | 🚫誤報 | 本輪一律 return 0、失敗改由下一輪讀 `[ai-review-bot][failure]` 結果 commit 回報，為刻意兩階段設計，已列入 exclusions。 | | 3 | 🔵 建議 | Bard | `src/lib/review.js` 第 63–66 行 | ✅已解決 | 已將 `INPUT_LIMIT`／`AGENT_DIAGNOSTIC_OUTPUT_LIMIT` 診斷輸出長度常數提升至模組頂層，與既有 `PER_FILE_DIFF_LIMIT`／`TOTAL_DIFF_LIMIT` 並列。 | **小計**：✅ 已解決 1 條、🚫 誤報（已列入 exclusions）2 條、⏭️ 待人工處理 0 條。 > 本議題無「只來自議題的待人工處理」項目，無需寫回 findings。✅ 項目之程式碼修正將隨本次 code-review-resolve 一併提交並 push。 處理完成，依 code-review-resolve 流程關閉本議題。
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No labels
Milestone
No items
No Milestone
Assignees
Clear assignees
admin (系統管理員) jiantw83 (Jeffery)
No Assignees
2 Participants
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#24