Compare commits
17
Commits
| Author | SHA1 | Date | |
|---|---|---|---|
 Jeffery
|
34aecf6e43 | ||
|
Jeffery
|
2d3128eb45 | ||
|
Jeffery
|
885b79f8b3 | ||
|
Jeffery
|
db83b54c2d | ||
|
Jeffery
|
3c1cd55444 | ||
 admin
|
cce35b3bef | ||
|
ai-review-bot
|
25f76e6e6e | ||
|
Jeffery
|
44c33b6c1e | ||
|
Jeffery
|
449b17480b | ||
|
ai-review-bot
|
b60f50f2b4 | ||
|
Jeffery
|
43ad2b56d2 | ||
|
Jeffery
|
8e18bbacc2 | ||
|
Jeffery
|
1f012c6cfb | ||
|
ai-review-bot
|
76617dd9dc | ||
|
Jeffery
|
216bc39255 | ||
|
Jeffery
|
75ca8cdb83 | ||
|
Jeffery
|
aaf2e484d5 |
@@ -1890,5 +1890,467 @@
|
|||||||
"endLine": 69,
|
"endLine": 69,
|
||||||
"problem": "`redactSecrets` 與 `agentFailureDetail` 是新加入的安全診斷防線，但測試只覆蓋 Authorization/token 的基本遮罩。控制字元單行化、URL 內嵌帳密、長 token/hex、輸入與輸出長度截斷、以及沒有 error code 時的 fallback 訊息都還沒被驗證。",
|
"problem": "`redactSecrets` 與 `agentFailureDetail` 是新加入的安全診斷防線，但測試只覆蓋 Authorization/token 的基本遮罩。控制字元單行化、URL 內嵌帳密、長 token/hex、輸入與輸出長度截斷、以及沒有 error code 時的 fallback 訊息都還沒被驗證。",
|
||||||
"reason": "Paladin：可排除（重複）。歷史 findings 已涵蓋 redactSecrets／agentFailureDetail 對控制字元、URL 帳密、token 格式、截斷與 fallback 診斷等邊界缺少測試。"
|
"reason": "Paladin：可排除（重複）。歷史 findings 已涵蓋 redactSecrets／agentFailureDetail 對控制字元、URL 帳密、token 格式、截斷與 fallback 診斷等邊界缺少測試。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/21 16:00:33",
|
||||||
|
"prNumber": 6,
|
||||||
|
"reviewer": "Bard",
|
||||||
|
"severity": "警告",
|
||||||
|
"file": "src/index.js",
|
||||||
|
"startLine": 166,
|
||||||
|
"endLine": 223,
|
||||||
|
"problem": "`main()` 這段新添的建問題模式狀態、暫存佇列、三個閉包輔助函式，全塞在主流程開頭，讓主旋律還沒開始就先進入一大段插曲。`issueModeActive`、`trackingIssue`、`pendingIssueCommentBodies` 彼此共享可變狀態，讀者必須在腦中追蹤閉包副作用，主流程的步驟節奏因此變得沉重。",
|
||||||
|
"reason": "Paladin：可排除（重複）。此條指涉 main() 內 issue 模式狀態、暫存佇列與閉包職責混雜，已由既有排除事項與歷史 findings 多次涵蓋。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/21 16:00:33",
|
||||||
|
"prNumber": 6,
|
||||||
|
"reviewer": "Bard",
|
||||||
|
"severity": "建議",
|
||||||
|
"file": "src/index.js",
|
||||||
|
"startLine": 230,
|
||||||
|
"endLine": 239,
|
||||||
|
"problem": "註解標成「步驟 2：延後執行」，但實際位置夾在快速檢查與步驟 3 之前，後面又在步驟 8 後再次出現「步驟 2（延後執行）」。同一個步驟號在不同位置反覆變奏，雖然註解有解釋，閱讀節拍仍容易打結。",
|
||||||
|
"reason": "Paladin：可排除（重複）。歷史 findings 已指出流程步驟編號散落且實際順序變成 1、3～8、2、9～10，與本條「步驟 2 延後但仍用線性編號」相同。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/21 16:00:33",
|
||||||
|
"prNumber": 6,
|
||||||
|
"reviewer": "Leo",
|
||||||
|
"severity": "警告",
|
||||||
|
"file": "src/index.js",
|
||||||
|
"startLine": 166,
|
||||||
|
"endLine": 235,
|
||||||
|
"problem": "`main()` 現在同時負責流程編排、PR 留言、issue 模式暫存、issue 建立、fallback 狀態切換與留言 flush。這段靠 `issueModeActive`、`trackingIssue`、`pendingIssueCommentBodies`、`currentRunCommentIds` 多個閉包變數互相配合，半年後要改「留言要發去哪裡」或「建 issue 失敗怎麼降級」時，很容易漏掉某個狀態轉換，尤其後面收尾 commit、resolve 舊留言、嚴重／其他問題發布都還會讀這些狀態。",
|
||||||
|
"reason": "Paladin：可排除（命中已知排除事項且重複）。main() 同時承擔留言路由、issue 狀態、fallback 與 flush 的發布狀態管理，已由既有排除事項與歷史 findings 涵蓋。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/21 16:00:33",
|
||||||
|
"prNumber": 6,
|
||||||
|
"reviewer": "Leo",
|
||||||
|
"severity": "建議",
|
||||||
|
"file": "src/index.js",
|
||||||
|
"startLine": 222,
|
||||||
|
"endLine": 230,
|
||||||
|
"problem": "註解與 log 名稱把「標記舊留言過時」稱為「步驟 2」，但實際執行點被延後到流程後段。這種非時間順序的步驟編號會讓維護者追 log 或對照 README 流程圖時產生認知落差：看到「步驟 2」不再代表第二個發生的動作，而是某個被延後的歷史步驟。",
|
||||||
|
"reason": "Paladin：可排除（重複）。與 F003 及歷史 findings 指涉同一個延後執行的「步驟 2」仍以線性步驟編號呈現所造成的認知落差。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/21 16:00:33",
|
||||||
|
"prNumber": 6,
|
||||||
|
"reviewer": "Leo",
|
||||||
|
"severity": "警告",
|
||||||
|
"file": "readme.md",
|
||||||
|
"startLine": 76,
|
||||||
|
"endLine": 131,
|
||||||
|
"problem": "README 內大量手動維護到 `src/branch/develop/...#Lxx` 的精確行號連結。這次變更已經因程式碼位移而更新一整片連結，未來每次插入函式或註解都會造成文件 churn；更糟的是漏改時文件會指到錯誤行，讀者以為文件可信，實際上卻被帶到過期位置。",
|
||||||
|
"reason": "Paladin：可排除（重複）。README 大量手動維護 develop 分支與 #Lxx 行號連結，歷史 findings 已多次記錄相同維護成本與連結漂移風險。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/21 16:00:33",
|
||||||
|
"prNumber": 6,
|
||||||
|
"reviewer": "Mage",
|
||||||
|
"severity": "嚴重",
|
||||||
|
"file": "src/index.js",
|
||||||
|
"startLine": 117,
|
||||||
|
"endLine": 120,
|
||||||
|
"problem": "當 PR 審查出嚴重問題，但結果 commit/push 失敗時，`commitFindings` 只回傳 `false`。新版主流程又改成「本輪審查不因嚴重問題直接 exit 1，而是依賴下一輪讀到 `[failure]` commit 才失敗」。最小情境：`severe.length > 0`、token 權限不足或 push 競態導致 `commitAndPushFindings` 丟錯；此時沒有 `[failure]` commit、也不會有下一輪快速回報，但本輪仍可能以 0 結束，PR 檢查會在存在嚴重問題時通過。",
|
||||||
|
"reason": "Paladin：可排除（重複）。此條與 F001 指涉同一風險：嚴重 finding 存在時 failure 結果 commit/push 失敗，可能使本輪檢查仍以成功結束。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/21 16:00:33",
|
||||||
|
"prNumber": 6,
|
||||||
|
"reviewer": "Maya",
|
||||||
|
"severity": "警告",
|
||||||
|
"file": "src/index.js",
|
||||||
|
"startLine": 163,
|
||||||
|
"endLine": 437,
|
||||||
|
"problem": "建問題模式被大幅改寫：情境留言先暫存、只有 kept finding 才建 issue、建立失敗會 fallback 回 PR、嚴重／非嚴重 finding 會改發到 issue、最後還要回貼追蹤 issue 連結與設定相依關係。但目前新增測試只覆蓋了少數 helper，沒有驗證 `main()` 在這些分支下的實際副作用。這些行為沒經過試煉，等於還不知道留言會不會發錯地方、fallback 後會不會漏清舊留言、或無 finding 時是否真的靜默通過。",
|
||||||
|
"reason": "Paladin：可排除（重複）。歷史 findings 已涵蓋建問題模式的暫存留言、只在有 finding 時建 issue、fallback、嚴重／非嚴重分流、PR 回貼與靜默通過等核心分支缺少流程測試。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/21 16:00:33",
|
||||||
|
"prNumber": 6,
|
||||||
|
"reviewer": "Maya",
|
||||||
|
"severity": "警告",
|
||||||
|
"file": "src/lib/gitrepo.js",
|
||||||
|
"startLine": 298,
|
||||||
|
"endLine": 355,
|
||||||
|
"problem": "`commitAndPushFindings` 的推送行為改成一律走 `pushWithCredential`，並宣稱 token 不進 argv、會清掉 checkout 的 extraheader、只接受同一 Gitea origin 的 `.git` URL。這是安全與 CI 觸發都很關鍵的失敗路徑，但目前 `test/gitrepo.test.js` 只測了分支名稱檢查，沒有驗證推送時的 argv/env，也沒有驗證遠端 URL 不符時會停止。這段若改壞，測試不會提醒我們 token 可能出現在命令列或推送根本沒用 PAT 身分。",
|
||||||
|
"reason": "Paladin：可排除（重複）。歷史 findings 已記錄 commitAndPushFindings／pushWithCredential 的認證推送路徑、argv/env、遠端目標檢查與失敗訊息遮蔽缺少測試。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/21 16:00:33",
|
||||||
|
"prNumber": 6,
|
||||||
|
"reviewer": "Maya",
|
||||||
|
"severity": "警告",
|
||||||
|
"file": "src/lib/gitrepo.js",
|
||||||
|
"startLine": 130,
|
||||||
|
"endLine": 188,
|
||||||
|
"problem": "`resolveMergeBase` 新增了多階段 fetch 補歷史流程：先 fetch base、首次 merge-base、再 deepen base、deepen PR HEAD、必要時 unshallow，且每個策略成功後要立即重試並短路返回。現有測試只驗證不安全 `baseRef` 會在 fetch 前被拒絕，沒有測到淺層 checkout、首次失敗後補抓成功、策略失敗繼續下一個、全部失敗時診斷訊息等邊界。這正是容易 off-by-one 或順序錯的流程，現在還沒有測試保護。",
|
||||||
|
"reason": "Paladin：可排除（重複）。resolveMergeBase 多階段 fetch、淺層與非淺層路徑、策略停止條件、全部失敗診斷與 cause 缺少測試，已由歷史 findings 涵蓋。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/21 16:26:12",
|
||||||
|
"prNumber": 6,
|
||||||
|
"reviewer": "Assassin",
|
||||||
|
"severity": "嚴重",
|
||||||
|
"file": "src/index.js",
|
||||||
|
"startLine": 105,
|
||||||
|
"endLine": 116,
|
||||||
|
"problem": "這裡把審查結果 commit/push 失敗吞掉並回傳 `false`，而本次變更又把主流程改成「本輪審查不因嚴重問題直接 exit 1，靠下一輪讀到 `[failure]` commit 才失敗」。攻擊者只要讓結果 commit 推不上去，例如在 PR head 競態推送、讓 token 沒有 push 權限、或讓來源分支拒絕 bot push，就能讓嚴重安全 finding 已產生但沒有 failure commit、也沒有下一輪失敗檢查，等同把必要檢查繞過。",
|
||||||
|
"reason": "人工裁示排除：主流程已在 result === failure 且 commitFindings 回傳 false 時直接回傳 1；本 finding 針對舊位置的描述已由現有收尾防線涵蓋。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/21 16:30:12",
|
||||||
|
"prNumber": 6,
|
||||||
|
"reviewer": "Bard",
|
||||||
|
"severity": "建議",
|
||||||
|
"file": "readme.md",
|
||||||
|
"startLine": 48,
|
||||||
|
"endLine": 48,
|
||||||
|
"problem": "Mermaid 節點代號從 `N8` 跳回 `N2`，雖然流程語意是「步驟 2 延後」，但原始碼讀起來像旋律突然倒帶；維護者在對照圖與步驟時容易被代號順序絆住。",
|
||||||
|
"reason": "Paladin：可排除（重複）。歷史 findings 已指出流程步驟編號與實際順序、README 流程圖及文件對照會產生認知落差；本條 Mermaid 節點代號問題屬同一類指控。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/21 16:30:12",
|
||||||
|
"prNumber": 6,
|
||||||
|
"reviewer": "Bard",
|
||||||
|
"severity": "警告",
|
||||||
|
"file": "src/index.js",
|
||||||
|
"startLine": 167,
|
||||||
|
"endLine": 235,
|
||||||
|
"problem": "`main()` 內新增了建 issue 模式狀態、暫存佇列與三個帶長篇 JSDoc 的閉包，讓主流程的旋律被大量伴奏蓋過。這段同時管理 `issueModeActive`、`trackingIssue`、`pendingIssueCommentBodies` 與 PR 留言 id，可讀性負擔明顯升高。",
|
||||||
|
"reason": "Paladin：可排除（重複）。已知排除事項與歷史 findings 已涵蓋 main() 內留言路由、issue 狀態、暫存佇列與發布職責耦合造成可讀性與維護負擔。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/21 16:30:12",
|
||||||
|
"prNumber": 6,
|
||||||
|
"reviewer": "Bard",
|
||||||
|
"severity": "建議",
|
||||||
|
"file": "src/lib/gitrepo.js",
|
||||||
|
"startLine": 121,
|
||||||
|
"endLine": 128,
|
||||||
|
"problem": "`strategies` 以陣列位置承載語意，`[label, ...args]` 雖簡短，卻讓每個元素的第二欄之後全靠讀者猜是 git argv；這裡的可讀性像沒有小節線的樂譜。",
|
||||||
|
"reason": "Paladin：可排除（重複）。歷史 finding 已針對 resolveMergeBase 內 strategies 與補救策略編排使閱讀節奏偏密提出問題；本條 tuple 可讀性屬同一段策略結構的細項。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/21 16:30:12",
|
||||||
|
"prNumber": 6,
|
||||||
|
"reviewer": "Leo",
|
||||||
|
"severity": "警告",
|
||||||
|
"file": "src/index.js",
|
||||||
|
"startLine": 163,
|
||||||
|
"endLine": 231,
|
||||||
|
"problem": "`main()` 這次把一般模式／建問題模式／降級模式的留言去向都塞進閉包狀態：`issueModeActive`、`trackingIssue`、`pendingIssueCommentBodies`、`currentRunCommentIds` 彼此耦合。半年後要新增一種落地方式或調整「何時清舊留言」時，維護者必須同時追多個可變狀態與後續多個 `if (issueModeActive)` 分支，很容易漏掉 flush、清空、登錄留言 id 或 fallback 後的收尾行為。",
|
||||||
|
"reason": "Paladin：可排除（重複）。與 F003 及既有排除事項相同，均指向 main() 以可變閉包狀態承擔留言目的地、issue 生命週期與 fallback 狀態機。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/21 16:30:12",
|
||||||
|
"prNumber": 6,
|
||||||
|
"reviewer": "Leo",
|
||||||
|
"severity": "警告",
|
||||||
|
"file": "src/index.js",
|
||||||
|
"startLine": 232,
|
||||||
|
"endLine": 241,
|
||||||
|
"problem": "流程註解把「將舊留言標記為解決」稱為「步驟 2（延後執行）」，但實際執行點在審查結果產生後、接近原本步驟 9 前。這種「編號是 2、時間點是 8 後」的設計已經擴散到多個檔案的 JSDoc 與 log 描述，未來查 CI log 或維護流程圖時會產生認知落差：看到 `步驟2` 不代表它真的發生在第二步。",
|
||||||
|
"reason": "Paladin：可排除（重複）。歷史 findings 已明確記錄步驟編號散落於 log、JSDoc、README 且實際順序變成 1、3 到 8、2、9 到 10 的維護風險。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/21 16:30:12",
|
||||||
|
"prNumber": 6,
|
||||||
|
"reviewer": "Leo",
|
||||||
|
"severity": "建議",
|
||||||
|
"file": "src/lib/gitrepo.js",
|
||||||
|
"startLine": 103,
|
||||||
|
"endLine": 160,
|
||||||
|
"problem": "`resolveMergeBase()` 內同時負責驗證 base ref、fetch base、重試 merge-base、補抓淺層歷史、累積診斷與組錯誤訊息。這些都和「取得 merge-base」有關，但現在全部攤在同一個函式裡，策略陣列、診斷格式與 git 操作細節混在一起；未來要新增 fetch 策略或改診斷文字時，容易不小心改壞主流程判斷。",
|
||||||
|
"reason": "Paladin：可排除（重複）。歷史 finding 已指出 resolveMergeBase 同時負責驗證、fetch 策略編排、診斷與錯誤包裝，難以分辨主流程與補救策略。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/21 16:30:12",
|
||||||
|
"prNumber": 6,
|
||||||
|
"reviewer": "Maya",
|
||||||
|
"severity": "警告",
|
||||||
|
"file": "src/index.js",
|
||||||
|
"startLine": 164,
|
||||||
|
"endLine": 232,
|
||||||
|
"problem": "建問題模式新增了「先暫存情境留言、確定有保留 finding 才建 issue、建 issue 失敗時降級回 PR 留言」這一整段流程，但目前測試只覆蓋了部分 helper，沒有驗證主流程在 create-issue=true 下的分流行為。這代表像「無保留問題時不應建 issue／不應留言」、「建立 issue 失敗時應把 pending 留言補回 PR」、「trackingIssue 建立後後續留言應改送 issue」這些行為都還沒通過試煉。",
|
||||||
|
"reason": "Paladin：可排除（重複）。歷史 findings 已涵蓋建問題模式核心流程、暫存留言、issue 建立條件、發布分流、外部 API 狀態切換與降級路徑缺少測試。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/21 16:30:12",
|
||||||
|
"prNumber": 6,
|
||||||
|
"reviewer": "Maya",
|
||||||
|
"severity": "警告",
|
||||||
|
"file": "src/lib/gitrepo.js",
|
||||||
|
"startLine": 104,
|
||||||
|
"endLine": 150,
|
||||||
|
"problem": "resolveMergeBase 新增了多階段 fetch/deepen/unshallow fallback 與診斷錯誤，但測試只驗證不安全 baseRef 會被拒絕，沒有驗證任何成功或失敗 fallback 路徑。這段是 diff 基準的核心邏輯，若 shallow checkout 下 deepen PR HEAD 用錯 ref、策略順序跑錯，或全部失敗時診斷不正確，現有測試都抓不到。",
|
||||||
|
"reason": "Paladin：可排除（重複）。歷史 findings 已針對 resolveMergeBase 多階段 fetch、淺層與非淺層分支、策略停止條件、降級與最終診斷缺少測試提出相同問題。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/21 16:30:12",
|
||||||
|
"prNumber": 6,
|
||||||
|
"reviewer": "Maya",
|
||||||
|
"severity": "警告",
|
||||||
|
"file": "src/lib/gitrepo.js",
|
||||||
|
"startLine": 272,
|
||||||
|
"endLine": 322,
|
||||||
|
"problem": "commitAndPushFindings 改成一律透過 pushWithCredential 用 PAT extraheader 推送，且新增 headRef 安全檢查與固定錯誤遮蔽；但目前 gitrepo 測試沒有覆蓋 commitAndPushFindings/pushWithCredential 的推送行為。這讓「token 不進 argv」、「清掉 checkout 既有 extraheader」、「遠端 URL 不符時拒絕」、「push 失敗不洩漏 URL/token」這些失敗與安全邊界都沒有被驗證。",
|
||||||
|
"reason": "Paladin：可排除（重複）。歷史 findings 已涵蓋 commitAndPushFindings 與 pushWithCredential 的推送策略、認證遮蔽、失敗路徑與 token 不外洩等測試缺口。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/21 17:25:38",
|
||||||
|
"prNumber": 6,
|
||||||
|
"reviewer": "Assassin",
|
||||||
|
"severity": "警告",
|
||||||
|
"file": "src/lib/diagnostics.js",
|
||||||
|
"startLine": 68,
|
||||||
|
"endLine": 71,
|
||||||
|
"problem": "攻擊者只要讓 AI CLI 失敗，並碰上 runner 開了 `ACTIONS_STEP_DEBUG=true`，就能把 CLI 的 stderr/stdout 片段推進長期保存的 CI log。這裡的遮罩是黑名單式，會漏掉不少常見秘密格式或個資，例如短 token、AWS access key、JWT 片段、email、電話、內部路徑與提示中夾帶的 diff 內容。安全邊界不能寄望「debug log 只有自己看」；repo 協作者或 CI log 讀者都可能取得這些輸出。",
|
||||||
|
"reason": "Paladin：可排除（重複）。既有紀錄已多次涵蓋 debug 模式輸出 AI CLI stderr／stdout、黑名單遮罩可繞過，以及機密或個資外洩風險；本條只是改到 diagnostics.js 後的同型指控。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/21 17:25:38",
|
||||||
|
"prNumber": 6,
|
||||||
|
"reviewer": "Bard",
|
||||||
|
"severity": "建議",
|
||||||
|
"file": "readme.md",
|
||||||
|
"startLine": 41,
|
||||||
|
"endLine": 51,
|
||||||
|
"problem": "Mermaid 流程圖的節點 ID 從 `N3`、`N4` 一路走到 `N8`，中途又接回 `N2`。顯示文字雖然表達「步驟 2 延後」，但原始碼層面的節點命名逆行，讓文件維護者讀圖時節奏斷裂。",
|
||||||
|
"reason": "Paladin：可排除（重複）。歷史 finding 已指出流程步驟編號被當成跨模組識別值、README 流程圖出現 1、3～8、2、9～10 的逆序維護問題；本條屬同一文件編號耦合問題。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/21 17:25:38",
|
||||||
|
"prNumber": 6,
|
||||||
|
"reviewer": "Leo",
|
||||||
|
"severity": "警告",
|
||||||
|
"file": "src/index.js",
|
||||||
|
"startLine": 162,
|
||||||
|
"endLine": 392,
|
||||||
|
"problem": "`main()` 這次把建問題模式的狀態機、留言緩衝、issue 建立、fallback、舊留言清理、結果 commit 判定都塞進同一個流程函式與多個閉包裡。半年後要改其中一條路徑時，很難確認 `issueModeActive`、`trackingIssue`、`pendingIssueCommentBodies`、`currentRunCommentIds` 在各分支是否仍一致；尤其建 issue 失敗後降級回 PR 留言，後面又要決定清舊留言、發嚴重問題、提交 findings，維護者需要整段流程一起讀才敢動。",
|
||||||
|
"reason": "Paladin：可排除（命中已知排除事項且重複）。已知排除與歷史 findings 已涵蓋 main() 內建問題模式、留言路由、issue 狀態、緩衝佇列與發布職責耦合的問題。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/21 17:25:38",
|
||||||
|
"prNumber": 6,
|
||||||
|
"reviewer": "Leo",
|
||||||
|
"severity": "建議",
|
||||||
|
"file": "src/lib/gitea.js",
|
||||||
|
"startLine": 156,
|
||||||
|
"endLine": 160,
|
||||||
|
"problem": "文件註解提到 `main()` 的 `createIssueAndFlushBufferedComments`，但這次新增的實際閉包名稱是 `openTrackingIssue`。這類失準的內部函式名引用會讓未來維護者循線找不到程式碼，久了文件會變成負債。",
|
||||||
|
"reason": "Paladin：可排除（列表內重複）。與 F002 指涉 src/lib/gitea.js 同一段 JSDoc 引用不存在的 createIssueAndFlushBufferedComments 問題。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/21 17:25:38",
|
||||||
|
"prNumber": 6,
|
||||||
|
"reviewer": "Leo",
|
||||||
|
"severity": "建議",
|
||||||
|
"file": "src/lib/templates.js",
|
||||||
|
"startLine": 302,
|
||||||
|
"endLine": 305,
|
||||||
|
"problem": "`issueBody()` 的 JSDoc 同樣引用不存在的 `createIssueAndFlushBufferedComments`。模板模組本來應該只說明模板用途；引用外層流程的私有閉包名稱，會讓文件跟主流程重構強耦合。",
|
||||||
|
"reason": "Paladin：可排除（列表內重複）。與 F003 指涉 src/lib/templates.js 的 issueBody JSDoc 引用不存在內部閉包名稱，屬同一問題。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/21 17:25:38",
|
||||||
|
"prNumber": 6,
|
||||||
|
"reviewer": "Maya",
|
||||||
|
"severity": "警告",
|
||||||
|
"file": "src/index.js",
|
||||||
|
"startLine": 162,
|
||||||
|
"endLine": 239,
|
||||||
|
"problem": "建問題模式新增了 `queueOrPostComment`、`openTrackingIssue`、`fallbackToPrComments` 這組分流行為，但目前測試只覆蓋了部分 `review` helper，沒有驗證主流程在 issue 尚未建立時會暫存留言、建立成功後會依序 flush、建立或寫入失敗時會回退到 PR 留言。這些都是本次新增的失敗路徑，沒測到時很容易出現審查內容被靜默丟掉或留言落錯地方。",
|
||||||
|
"reason": "Paladin：可排除（重複）。歷史 findings 已涵蓋建問題模式暫存留言、建立後依序 flush、建立或 API 失敗時降級，以及無 finding 靜默通過等核心流程缺少測試。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/21 17:25:38",
|
||||||
|
"prNumber": 6,
|
||||||
|
"reviewer": "Maya",
|
||||||
|
"severity": "警告",
|
||||||
|
"file": "src/lib/gitrepo.js",
|
||||||
|
"startLine": 103,
|
||||||
|
"endLine": 158,
|
||||||
|
"problem": "`resolveMergeBase` 新增了多段 fetch 補抓策略、淺層 repo 判斷、每次 fetch 後重試 merge-base，以及全部失敗時附診斷的錯誤；目前測試只驗證不安全 `baseRef` 會在 fetch 前被拒絕，沒有測到這些新增分支。這些邊界正是 shallow checkout 最容易壞的地方。",
|
||||||
|
"reason": "Paladin：可排除（重複）。歷史 findings 已針對 resolveMergeBase 的多階段 fetch、淺層與非淺層分支、停止條件、降級與最終診斷缺少測試提出相同問題。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/21 17:25:38",
|
||||||
|
"prNumber": 6,
|
||||||
|
"reviewer": "Maya",
|
||||||
|
"severity": "警告",
|
||||||
|
"file": "src/lib/gitrepo.js",
|
||||||
|
"startLine": 287,
|
||||||
|
"endLine": 326,
|
||||||
|
"problem": "`pushWithCredential` 是新增的認證推送核心路徑，包含清掉 checkout 既有 extraheader、用 PAT extraheader 推送、遠端 URL origin 檢查，以及失敗時隱藏 URL／token；但目前沒有任何測試驗證這些行為。這裡的失敗路徑沒測到，容易在 runner 上才發現結果 commit 推不上去或錯誤訊息洩漏敏感資訊。",
|
||||||
|
"reason": "Paladin：可排除（重複）。歷史 findings 已涵蓋 pushToken／pushWithCredential、origin 與一般 token 推送策略、認證遮蔽及失敗路徑缺少測試。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/28 13:57:24",
|
||||||
|
"prNumber": 6,
|
||||||
|
"reviewer": "Maya",
|
||||||
|
"severity": "警告",
|
||||||
|
"file": "src/index.js",
|
||||||
|
"startLine": 306,
|
||||||
|
"endLine": 359,
|
||||||
|
"problem": "建問題模式的核心流程已大幅改變，但 diff 中沒有對應測試驗證各分支：有保留問題時才建立 issue、暫存留言依序送出、無問題時靜默通過、嚴重與非嚴重問題送往正確位置，以及標籤失敗後仍須回貼 PR 連結。這些分支牽涉多次外部 API 呼叫與狀態切換，未測試時很容易出現漏留言、留言送錯 PR／issue，或在 `issue` 尚未建立時解參考的回歸。",
|
||||||
|
"reason": "建問題模式現行已有追蹤 issue 建立失敗降級、嚴重問題才設 dependency、無 finding 靜默通過與結果檔 fail-closed 測試；其餘屬設計重構建議，非本次 findings 修復的可安全最小改動。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/28 13:57:24",
|
||||||
|
"prNumber": 6,
|
||||||
|
"reviewer": "Maya",
|
||||||
|
"severity": "警告",
|
||||||
|
"file": "src/index.js",
|
||||||
|
"startLine": 184,
|
||||||
|
"endLine": 245,
|
||||||
|
"problem": "建問題模式新增「issue 建立前暫存留言、建立後依序沖刷」的狀態流程，但沒有對應測試。尚未驗證 createIssue 或沖刷途中拋錯、空 buffer、重複呼叫、以及一般／建問題模式留言目的地是否正確；失敗路徑可能造成 issue 已建立但內容不完整或留言誤發到 PR。",
|
||||||
|
"reason": "此 finding 屬主流程重構建議，牽涉建問題模式設計切分；現行行為已有降級與結果檔 fail-closed 防護，本次不做高風險重構。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/28 13:57:24",
|
||||||
|
"prNumber": 6,
|
||||||
|
"reviewer": "Maya",
|
||||||
|
"severity": "警告",
|
||||||
|
"file": "src/index.js",
|
||||||
|
"startLine": 309,
|
||||||
|
"endLine": 395,
|
||||||
|
"problem": "建問題模式核心分支被大幅改寫，但沒有測試驗證各種 findings 組合與 API 失敗行為。kept.length===0、只有嚴重、只有警告／建議、兩者皆有，以及標籤挑選／issue 建立／PR 回貼連結／相依 API 失敗等路徑尚未試煉，無法確認「無問題完全靜默」「有問題才建 issue」及相依失敗僅降級等契約成立。",
|
||||||
|
"reason": "此 finding 屬主流程重構建議，牽涉建問題模式設計切分；現行行為已有降級與結果檔 fail-closed 防護，本次不做高風險重構。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/28 13:57:24",
|
||||||
|
"prNumber": 6,
|
||||||
|
"reviewer": "Maya",
|
||||||
|
"severity": "警告",
|
||||||
|
"file": "src/lib/gitrepo.js",
|
||||||
|
"startLine": 249,
|
||||||
|
"endLine": 289,
|
||||||
|
"problem": "推送流程新增 pushToken 分支，但沒有測試驗證兩套認證策略：有 PAT 時略過 origin、PAT 推送失敗不退回其他 token、無 PAT 時 origin 成功不重試、origin 失敗才用一般 token；也沒有案例保護含憑證資訊不出現在錯誤或測試輸出中。（本次已將認證改經 env 傳入並遮蔽 push 錯誤，測試仍待補。）",
|
||||||
|
"reason": "現行推送路徑已統一走 `pushWithCredential`，token 只經環境變數 extraheader 注入且錯誤不帶 URL/憑證；finding 中的 pushToken/origin 雙軌描述已非現行程式。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/28 13:57:24",
|
||||||
|
"prNumber": 6,
|
||||||
|
"reviewer": "Leo",
|
||||||
|
"severity": "警告",
|
||||||
|
"file": "src/index.js",
|
||||||
|
"startLine": 121,
|
||||||
|
"endLine": 145,
|
||||||
|
"problem": "流程步驟編號硬編碼在主流程註解、日誌字串、README 與多個函式 JSDoc 中；插入一個步驟就要同步修改大量檔案，文件與實作高耦合，日後調整流程易漏改而互相矛盾。",
|
||||||
|
"reason": "此 finding 屬主流程重構建議，牽涉建問題模式設計切分；現行行為已有降級與結果檔 fail-closed 防護，本次不做高風險重構。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/28 13:57:24",
|
||||||
|
"prNumber": 6,
|
||||||
|
"reviewer": "Leo",
|
||||||
|
"severity": "警告",
|
||||||
|
"file": "src/lib/gitrepo.js",
|
||||||
|
"startLine": 47,
|
||||||
|
"endLine": 65,
|
||||||
|
"problem": "tryGit 將所有 git 失敗壓成布林值，resolveMergeBase 的診斷只知策略成敗、無法區分認證／refspec／網路／版本問題；CI 出錯時維護者只能重跑或自行重現，診斷成本高。",
|
||||||
|
"reason": "現行推送路徑已統一走 `pushWithCredential`，token 只經環境變數 extraheader 注入且錯誤不帶 URL/憑證；finding 中的 pushToken/origin 雙軌描述已非現行程式。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/28 13:57:24",
|
||||||
|
"prNumber": 6,
|
||||||
|
"reviewer": "Maya",
|
||||||
|
"severity": "警告",
|
||||||
|
"file": "src/lib/gitrepo.js",
|
||||||
|
"startLine": 270,
|
||||||
|
"endLine": 291,
|
||||||
|
"problem": "findings 推送的認證路徑沒有測試。註：原「PAT 直接推送 vs origin 失敗重試」雙路徑已於先前 commit 合併為「一律以 token 明確認證推送」，測試仍待補：空 token 邊界、推送目標正確、錯誤與輸出不含 token 原文。",
|
||||||
|
"reason": "現行推送路徑已統一走 `pushWithCredential`，token 只經環境變數 extraheader 注入且錯誤不帶 URL/憑證；finding 中的 pushToken/origin 雙軌描述已非現行程式。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/28 13:57:24",
|
||||||
|
"prNumber": 6,
|
||||||
|
"reviewer": "Bard",
|
||||||
|
"severity": "建議",
|
||||||
|
"file": "src/index.js",
|
||||||
|
"startLine": 179,
|
||||||
|
"endLine": 231,
|
||||||
|
"problem": "main() 內新增兩個帶完整 JSDoc 的閉包函式與一大段「步驟 2：延後執行」說明，使主流程在進入步驟 3 前被近六十行細節打斷，留言路由、issue 建立與流程說明混在同一層，閱讀節奏沉重。",
|
||||||
|
"reason": "此 finding 屬主流程重構建議，牽涉建問題模式設計切分；現行行為已有降級與結果檔 fail-closed 防護，本次不做高風險重構。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/28 13:57:24",
|
||||||
|
"prNumber": null,
|
||||||
|
"reviewer": "🧰 Leo",
|
||||||
|
"severity": "警告",
|
||||||
|
"file": "src/index.js",
|
||||||
|
"startLine": 257,
|
||||||
|
"endLine": 307,
|
||||||
|
"problem": "流程步驟編號同時硬編碼在 log 字串、區段註解、JSDoc、README 與多個函式庫中。插入或調整一個步驟就必須跨大量檔案全面改號，容易讓文件與實際紀錄不一致。",
|
||||||
|
"reason": "此 finding 屬流程註解與文件呈現的維護性建議；現行延後清理步驟已有明確註解，不影響執行行為，後續可由文件化流程統一整理。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/28 13:57:24",
|
||||||
|
"prNumber": null,
|
||||||
|
"reviewer": "🧪 Maya",
|
||||||
|
"severity": "警告",
|
||||||
|
"file": "src/lib/gitrepo.js",
|
||||||
|
"startLine": 252,
|
||||||
|
"endLine": 289,
|
||||||
|
"problem": "commitAndPushFindings 的推送行為（有無變更、認證方式、空 commit 防護、是否觸發 CI）缺少測試證明。此為本次變更的核心行為，卻沒有任何測試覆蓋。",
|
||||||
|
"reason": "現行推送路徑已統一走 `pushWithCredential`，token 只經環境變數 extraheader 注入且錯誤不帶 URL/憑證；finding 中的 pushToken/origin 雙軌描述已非現行程式。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/28 13:57:24",
|
||||||
|
"prNumber": null,
|
||||||
|
"reviewer": "Leo",
|
||||||
|
"severity": "警告",
|
||||||
|
"file": "src/index.js",
|
||||||
|
"startLine": 119,
|
||||||
|
"endLine": 139,
|
||||||
|
"problem": "流程步驟編號被當成跨模組識別值，散落在 `index.js`、各 library 的日誌與 JSDoc、README 流程圖及功能表。這次僅因插入並延後一步，就必須同步修改大量 `步驟2`～`步驟8` 字串，而且實際執行順序已變成 1、3～8、2、9～10；未來再調整流程時非常容易讓文件、日誌與程式碼脫節。",
|
||||||
|
"reason": "此 finding 屬流程註解與文件呈現的維護性建議；現行延後清理步驟已有明確註解，不影響執行行為，後續可由文件化流程統一整理。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/28 13:57:24",
|
||||||
|
"prNumber": null,
|
||||||
|
"reviewer": "Leo",
|
||||||
|
"severity": "警告",
|
||||||
|
"file": "src/lib/gitrepo.js",
|
||||||
|
"startLine": 293,
|
||||||
|
"endLine": 305,
|
||||||
|
"problem": "為了防止 Git 推送失敗時在例外訊息中回顯包含 Token 與遠端 URL 的命令列參數，pushWithCredential 的 catch 區塊直接拋出一個固定的 Error('推送審查結果 commit 失敗...')。但這樣一來，它完全吞掉了原始的錯誤（例如 non-fast-forward 非快轉、分支保護規則阻擋、或連線逾時），六個月後的維護者在 CI log 中看到此錯誤時，完全無從判斷失敗的原因。",
|
||||||
|
"reason": "現行推送路徑已統一走 `pushWithCredential`，token 只經環境變數 extraheader 注入且錯誤不帶 URL/憑證；finding 中的 pushToken/origin 雙軌描述已非現行程式。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/28 13:57:24",
|
||||||
|
"prNumber": null,
|
||||||
|
"reviewer": "Bard",
|
||||||
|
"severity": "建議",
|
||||||
|
"file": "src/index.js",
|
||||||
|
"startLine": 308,
|
||||||
|
"endLine": 368,
|
||||||
|
"problem": "新增或修改的步驟分隔註解（如步驟 8 分組、步驟 2 延後、步驟 9、步驟 10、及建問題模式收束）其尾隨的水平分隔線（─）長度不一或僅存單一字元，破壞了專案既有程式碼中整齊劃一的長分隔線視覺排版，視覺上顯得雜亂、走調。",
|
||||||
|
"reason": "此 finding 屬流程註解與文件呈現的維護性建議；現行延後清理步驟已有明確註解，不影響執行行為，後續可由文件化流程統一整理。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/28 13:57:24",
|
||||||
|
"prNumber": null,
|
||||||
|
"reviewer": "Rogue",
|
||||||
|
"severity": "建議",
|
||||||
|
"file": "src/index.js",
|
||||||
|
"startLine": 366,
|
||||||
|
"endLine": 382,
|
||||||
|
"problem": "在建問題模式收束時，先 `await gitea.createIssueComment` 再 `await gitea.addIssueDependency`，這兩個 Gitea API 呼叫是獨立且無資料相依性的，卻以序列（Sequential）方式執行，白白浪費了一次網路往返（RTT）的等待時間。",
|
||||||
|
"reason": "建問題模式現行已有追蹤 issue 建立失敗降級、嚴重問題才設 dependency、無 finding 靜默通過與結果檔 fail-closed 測試；其餘屬設計重構建議，非本次 findings 修復的可安全最小改動。"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"addedAt": "2026/07/28 13:57:24",
|
||||||
|
"prNumber": 6,
|
||||||
|
"reviewer": "Bard",
|
||||||
|
"severity": "建議",
|
||||||
|
"file": "src/lib/gitrepo.js",
|
||||||
|
"startLine": 139,
|
||||||
|
"endLine": 160,
|
||||||
|
"problem": "`runFetch`、`tryMergeBase`、`firstError`、`strategies` 夾在 `resolveMergeBase` 主旋律中，使這個函式同時負責驗證、fetch 策略編排、診斷文字組裝與錯誤包裝。即使邏輯可行，閱讀節奏已偏密，維護者很難一眼分辨「主要流程」與「補救策略」。",
|
||||||
|
"reason": "現行 `resolveMergeBase` 已保留策略診斷與首次錯誤 cause，並先拒絕不安全 baseRef；較大規模的可測性重構屬後續設計工作，本次僅套用可安全的淺層判斷效能修正。"
|
||||||
}
|
}
|
||||||
]
|
]
|
||||||
|
|||||||
@@ -7,33 +7,6 @@
|
|||||||
"version": "0.0.8",
|
"version": "0.0.8",
|
||||||
"model": "（工具預設）"
|
"model": "（工具預設）"
|
||||||
},
|
},
|
||||||
"findings": [
|
"findings": [],
|
||||||
{
|
|
||||||
"id": "F002",
|
|
||||||
"reviewer": "Maya",
|
|
||||||
"focus": "testing",
|
|
||||||
"badge": "🧪",
|
|
||||||
"severity": "警告",
|
|
||||||
"file": "src/index.js",
|
|
||||||
"startLine": 306,
|
|
||||||
"endLine": 359,
|
|
||||||
"problem": "建問題模式的核心流程已大幅改變，但 diff 中沒有對應測試驗證各分支：有保留問題時才建立 issue、暫存留言依序送出、無問題時靜默通過、嚴重與非嚴重問題送往正確位置，以及標籤失敗後仍須回貼 PR 連結。這些分支牽涉多次外部 API 呼叫與狀態切換，未測試時很容易出現漏留言、留言送錯 PR／issue，或在 `issue` 尚未建立時解參考的回歸。",
|
|
||||||
"suggestion": "新增主流程測試並 mock Gitea、agent 與 git 操作，至少涵蓋：`kept=[]` 時不建立 issue 且不留言；僅嚴重問題；僅警告／建議；混合問題；建立 issue 或寫入暫存留言失敗；標籤查詢、AI 選標籤及補掛標籤失敗時仍回貼 issue 連結。除了呼叫次數，也應斷言 API 呼叫順序、目標 issue 編號及留言內容。",
|
|
||||||
"suggestedCode": ""
|
|
||||||
},
|
|
||||||
{
|
|
||||||
"id": "F004",
|
|
||||||
"reviewer": "Maya",
|
|
||||||
"focus": "testing",
|
|
||||||
"badge": "🧪",
|
|
||||||
"severity": "警告",
|
|
||||||
"file": "src/lib/gitrepo.js",
|
|
||||||
"startLine": 100,
|
|
||||||
"endLine": 122,
|
|
||||||
"problem": "`resolveMergeBase` 新增多階段 fetch 與淺層 checkout 修復邏輯，但沒有看到測試驗證成功、降級與最終失敗路徑。尤其初次 merge-base 失敗後，淺層與非淺層 repository 會走不同路徑，且多個 `tryGit` 失敗會被刻意吞掉；若參數、refspec 或重試順序有誤，只會在實際 CI checkout 深度不足時才暴露。",
|
|
||||||
"suggestion": "以 stub 的 git 執行器或暫存 repository 補齊案例：首次 merge-base 成功；淺層 repository 經 `--unshallow` 後成功；`--unshallow` 失敗但 `--deepen=1000` 後成功；非淺層首次失敗後重試成功；所有策略失敗時拋出含 `baseRef` 且保留原始 `cause` 的錯誤。並斷言 base/head fetch 的 refspec 與執行順序。",
|
|
||||||
"suggestedCode": ""
|
|
||||||
}
|
|
||||||
],
|
|
||||||
"excluded": []
|
"excluded": []
|
||||||
}
|
}
|
||||||
|
|||||||
@@ -7,59 +7,6 @@
|
|||||||
"version": "0.0.8",
|
"version": "0.0.8",
|
||||||
"model": "（工具預設）"
|
"model": "（工具預設）"
|
||||||
},
|
},
|
||||||
"findings": [
|
"findings": [],
|
||||||
{
|
|
||||||
"id": "F003",
|
|
||||||
"reviewer": "Maya",
|
|
||||||
"focus": "testing",
|
|
||||||
"badge": "🧪",
|
|
||||||
"severity": "警告",
|
|
||||||
"file": "src/index.js",
|
|
||||||
"startLine": 184,
|
|
||||||
"endLine": 245,
|
|
||||||
"problem": "建問題模式新增「issue 建立前暫存留言、建立後依序沖刷」的狀態流程，但沒有對應測試。尚未驗證 createIssue 或沖刷途中拋錯、空 buffer、重複呼叫、以及一般／建問題模式留言目的地是否正確；失敗路徑可能造成 issue 已建立但內容不完整或留言誤發到 PR。",
|
|
||||||
"suggestion": "補主流程整合測試並 mock Gitea API，驗證：一般模式直接發 PR 且記錄留言 id；issue 未建立時只暫存；建立後依序沖刷並清空 buffer；createIssue 與第 N 則沖刷留言失敗時以失敗結束且不再發布後續內容。屬測試架構決策（專案目前無測試框架）。",
|
|
||||||
"suggestedCode": ""
|
|
||||||
},
|
|
||||||
{
|
|
||||||
"id": "F004",
|
|
||||||
"reviewer": "Maya",
|
|
||||||
"focus": "testing",
|
|
||||||
"badge": "🧪",
|
|
||||||
"severity": "警告",
|
|
||||||
"file": "src/index.js",
|
|
||||||
"startLine": 309,
|
|
||||||
"endLine": 395,
|
|
||||||
"problem": "建問題模式核心分支被大幅改寫，但沒有測試驗證各種 findings 組合與 API 失敗行為。kept.length===0、只有嚴重、只有警告／建議、兩者皆有，以及標籤挑選／issue 建立／PR 回貼連結／相依 API 失敗等路徑尚未試煉，無法確認「無問題完全靜默」「有問題才建 issue」及相依失敗僅降級等契約成立。",
|
|
||||||
"suggestion": "以參數化測試覆蓋 findings 四種組合，斷言 API 呼叫順序／次數／issue number／統計；並分別讓 listLabels／selectLabels／createIssue／問題留言／PR 連結留言／addIssueDependency 拋錯，驗證哪些中止、哪些僅記警告續行；零 findings 時斷言所有寫入 API 皆不呼叫。屬測試架構決策。",
|
|
||||||
"suggestedCode": ""
|
|
||||||
},
|
|
||||||
{
|
|
||||||
"id": "F006",
|
|
||||||
"reviewer": "Maya",
|
|
||||||
"focus": "testing",
|
|
||||||
"badge": "🧪",
|
|
||||||
"severity": "警告",
|
|
||||||
"file": "src/lib/gitrepo.js",
|
|
||||||
"startLine": 103,
|
|
||||||
"endLine": 157,
|
|
||||||
"problem": "resolveMergeBase 新增多階段 fetch／重試策略，卻沒有測試鎖定淺層與失敗路徑：首次成功提早返回、非 shallow 不 unshallow、某次 fetch 失敗後仍嘗試下一策略、補抓成功立即停止、全部失敗時診斷與 cause 是否完整；易因呼叫順序或 off-by-one 在 runner 上才暴露。",
|
|
||||||
"suggestion": "將 git 執行器注入或 stub，建立表格化案例覆蓋首次成功／unshallow 後成功／deepen base 後成功／deepen HEAD 後成功／各 fetch 個別失敗／全部失敗；逐案斷言 git 參數與順序、成功後不再額外 fetch，並檢查最終錯誤含各策略成敗摘要且保留首次錯誤為 cause。屬可測性重構＋測試架構決策。",
|
|
||||||
"suggestedCode": ""
|
|
||||||
},
|
|
||||||
{
|
|
||||||
"id": "F007",
|
|
||||||
"reviewer": "Maya",
|
|
||||||
"focus": "testing",
|
|
||||||
"badge": "🧪",
|
|
||||||
"severity": "警告",
|
|
||||||
"file": "src/lib/gitrepo.js",
|
|
||||||
"startLine": 249,
|
|
||||||
"endLine": 289,
|
|
||||||
"problem": "推送流程新增 pushToken 分支，但沒有測試驗證兩套認證策略：有 PAT 時略過 origin、PAT 推送失敗不退回其他 token、無 PAT 時 origin 成功不重試、origin 失敗才用一般 token；也沒有案例保護含憑證資訊不出現在錯誤或測試輸出中。（本次已將認證改經 env 傳入並遮蔽 push 錯誤，測試仍待補。）",
|
|
||||||
"suggestion": "mock git 執行器與 URL／env 組裝，補測 pushToken 有值／空、origin 成功／失敗、PAT 推送失敗及含特殊字元等案例；斷言 push 目標與呼叫次數，並確保任何拋出的錯誤、log 或快照都不含原始 token。屬測試架構決策。",
|
|
||||||
"suggestedCode": ""
|
|
||||||
}
|
|
||||||
],
|
|
||||||
"excluded": []
|
"excluded": []
|
||||||
}
|
}
|
||||||
|
|||||||
@@ -7,98 +7,6 @@
|
|||||||
"version": "0.0.8",
|
"version": "0.0.8",
|
||||||
"model": "（工具預設）"
|
"model": "（工具預設）"
|
||||||
},
|
},
|
||||||
"findings": [
|
"findings": [],
|
||||||
{
|
|
||||||
"id": "F001",
|
|
||||||
"reviewer": "Leo",
|
|
||||||
"focus": "maintainability",
|
|
||||||
"badge": "🧰",
|
|
||||||
"severity": "警告",
|
|
||||||
"file": "src/index.js",
|
|
||||||
"startLine": 121,
|
|
||||||
"endLine": 145,
|
|
||||||
"problem": "流程步驟編號硬編碼在主流程註解、日誌字串、README 與多個函式 JSDoc 中；插入一個步驟就要同步修改大量檔案，文件與實作高耦合，日後調整流程易漏改而互相矛盾。",
|
|
||||||
"suggestion": "共用函式 JSDoc 改以語意階段名稱描述、不引用易變動的數字；日誌集中定義階段名稱或由單一流程描述產生編號；README 流程圖也以語意名稱為主。屬跨檔重構＋設計取捨。",
|
|
||||||
"suggestedCode": "const STAGE = Object.freeze({\n TOOL_DETECTION: '偵測工具',\n DIFF_COLLECTION: '整理差異',\n ATTACK_REVIEW: '攻擊方審查',\n DEFENSE_REVIEW: '防守方裁決',\n});\nlog(STAGE.DIFF_COLLECTION, 'INF', message);"
|
|
||||||
},
|
|
||||||
{
|
|
||||||
"id": "F003",
|
|
||||||
"reviewer": "Leo",
|
|
||||||
"focus": "maintainability",
|
|
||||||
"badge": "🧰",
|
|
||||||
"severity": "警告",
|
|
||||||
"file": "src/lib/gitrepo.js",
|
|
||||||
"startLine": 47,
|
|
||||||
"endLine": 65,
|
|
||||||
"problem": "tryGit 將所有 git 失敗壓成布林值，resolveMergeBase 的診斷只知策略成敗、無法區分認證／refspec／網路／版本問題；CI 出錯時維護者只能重跑或自行重現，診斷成本高。",
|
|
||||||
"suggestion": "讓嘗試結果保留結構化且已清理的錯誤分類（exit code、git 子命令、安全化後短訊息），仍避免記錄遠端 URL 或憑證；最終錯誤彙整足以行動的原因，並可對各失敗類型做單元測試。屬診斷重構＋需測試。",
|
|
||||||
"suggestedCode": "function tryGit(cwd, ...args) {\n try {\n git(cwd, ...args);\n return { ok: true };\n } catch (error) {\n return { ok: false, code: error.status ?? error.code ?? null, reason: sanitizeGitError(error) };\n }\n}"
|
|
||||||
},
|
|
||||||
{
|
|
||||||
"id": "F004",
|
|
||||||
"reviewer": "Maya",
|
|
||||||
"focus": "testing",
|
|
||||||
"badge": "🧪",
|
|
||||||
"severity": "警告",
|
|
||||||
"file": "src/lib/gitrepo.js",
|
|
||||||
"startLine": 270,
|
|
||||||
"endLine": 291,
|
|
||||||
"problem": "findings 推送的認證路徑沒有測試。註：原「PAT 直接推送 vs origin 失敗重試」雙路徑已於先前 commit 合併為「一律以 token 明確認證推送」，測試仍待補：空 token 邊界、推送目標正確、錯誤與輸出不含 token 原文。",
|
|
||||||
"suggestion": "補單元測試攔截 git 參數／env：斷言以 token 認證推送、推送目標 refspec 正確、呼叫次數，並確保任何拋出的錯誤、log 或快照都不含原始 token。屬測試架構決策。",
|
|
||||||
"suggestedCode": ""
|
|
||||||
},
|
|
||||||
{
|
|
||||||
"id": "F005",
|
|
||||||
"reviewer": "Bard",
|
|
||||||
"focus": "style",
|
|
||||||
"badge": "🎼",
|
|
||||||
"severity": "建議",
|
|
||||||
"file": "action.yml",
|
|
||||||
"startLine": 3,
|
|
||||||
"endLine": 3,
|
|
||||||
"problem": "檔頭「更新時間」為手動維護的固定字串，與實際檔案更新時間不一致；散落各檔的手動時間戳容易走調，讀者無法判斷可信度。",
|
|
||||||
"suggestion": "屬 jsc spec-time-log 慣例（各檔頭「更新時間」由 doc-funcs 流程統一產生／同步）。是否移除改用版控紀錄、或如何統一更新，宜由 doc-funcs 流程處理，不在 resolve 逐條硬改。",
|
|
||||||
"suggestedCode": ""
|
|
||||||
},
|
|
||||||
{
|
|
||||||
"id": "F006",
|
|
||||||
"reviewer": "Bard",
|
|
||||||
"focus": "style",
|
|
||||||
"badge": "🎼",
|
|
||||||
"severity": "建議",
|
|
||||||
"file": "readme.md",
|
|
||||||
"startLine": 3,
|
|
||||||
"endLine": 3,
|
|
||||||
"problem": "README 檔頭手動「更新時間」與實際更新時間不符，並與 action.yml、src/index.js 重複保存同類易過期資訊，形成多個不一致的真相來源。",
|
|
||||||
"suggestion": "同 F005：屬 jsc spec-time-log 慣例，交 doc-funcs 流程統一維護（移除或自動注入）。",
|
|
||||||
"suggestedCode": ""
|
|
||||||
},
|
|
||||||
{
|
|
||||||
"id": "F007",
|
|
||||||
"reviewer": "Bard",
|
|
||||||
"focus": "style",
|
|
||||||
"badge": "🎼",
|
|
||||||
"severity": "建議",
|
|
||||||
"file": "src/index.js",
|
|
||||||
"startLine": 7,
|
|
||||||
"endLine": 7,
|
|
||||||
"problem": "啟動橫幅硬編碼的「更新時間」與程式實際更新時間不一致，每次改程式都要人工校準，製造噪音並讓執行日誌呈現失真版本資訊。",
|
|
||||||
"suggestion": "同 F005：屬 jsc spec-time-log 慣例，交 doc-funcs 流程統一維護；若日誌需辨識版本，可改顯示 CI 注入的 commit SHA／版本號（屬慣例調整）。",
|
|
||||||
"suggestedCode": ""
|
|
||||||
},
|
|
||||||
{
|
|
||||||
"id": "F008",
|
|
||||||
"reviewer": "Bard",
|
|
||||||
"focus": "style",
|
|
||||||
"badge": "🎼",
|
|
||||||
"severity": "建議",
|
|
||||||
"file": "src/index.js",
|
|
||||||
"startLine": 179,
|
|
||||||
"endLine": 231,
|
|
||||||
"problem": "main() 內新增兩個帶完整 JSDoc 的閉包函式與一大段「步驟 2：延後執行」說明，使主流程在進入步驟 3 前被近六十行細節打斷，留言路由、issue 建立與流程說明混在同一層，閱讀節奏沉重。",
|
|
||||||
"suggestion": "將留言路由與 issue 建立封裝成具語義名稱的輔助物件／模組（例如 createCommentPublisher），讓 main() 只保留流程級呼叫；延後清理理由縮成貼近呼叫點的簡短註解。與 F001（語意階段名稱）同屬主流程重構，宜一併處理。",
|
|
||||||
"suggestedCode": "const comments = createCommentPublisher({ ctx, gitea });\nawait comments.post(templates.toolComment({ /* ... */ }));"
|
|
||||||
}
|
|
||||||
],
|
|
||||||
"excluded": []
|
"excluded": []
|
||||||
}
|
}
|
||||||
|
|||||||
@@ -7,33 +7,6 @@
|
|||||||
"version": "0.0.8",
|
"version": "0.0.8",
|
||||||
"model": "（工具預設）"
|
"model": "（工具預設）"
|
||||||
},
|
},
|
||||||
"findings": [
|
"findings": [],
|
||||||
{
|
|
||||||
"id": "F001",
|
|
||||||
"reviewer": "🧰 Leo",
|
|
||||||
"focus": "maintainability",
|
|
||||||
"badge": "🧰",
|
|
||||||
"severity": "警告",
|
|
||||||
"file": "src/index.js",
|
|
||||||
"startLine": 257,
|
|
||||||
"endLine": 307,
|
|
||||||
"problem": "流程步驟編號同時硬編碼在 log 字串、區段註解、JSDoc、README 與多個函式庫中。插入或調整一個步驟就必須跨大量檔案全面改號，容易讓文件與實際紀錄不一致。",
|
|
||||||
"suggestion": "程式內改用穩定的語意階段名稱（如 diff、attack、defend、publish），由單一流程定義集中決定顯示順序；JSDoc 以階段名稱互相引用，README 流程圖由同一份階段資料產生或僅在文件層維護展示編號。",
|
|
||||||
"suggestedCode": "const PHASE = Object.freeze({\n RESOLVE_OLD: '清理舊留言',\n DETECT_TOOL: '偵測工具',\n COLLECT_DIFF: '整理差異',\n ATTACK: '攻擊方審查',\n DEFEND: '防守方裁決',\n});\n\nlog(PHASE.COLLECT_DIFF, 'INF', `變更檔案 ${allFiles.length} 個…`);"
|
|
||||||
},
|
|
||||||
{
|
|
||||||
"id": "F002",
|
|
||||||
"reviewer": "🧪 Maya",
|
|
||||||
"focus": "testing",
|
|
||||||
"badge": "🧪",
|
|
||||||
"severity": "警告",
|
|
||||||
"file": "src/lib/gitrepo.js",
|
|
||||||
"startLine": 252,
|
|
||||||
"endLine": 289,
|
|
||||||
"problem": "commitAndPushFindings 的推送行為（有無變更、認證方式、空 commit 防護、是否觸發 CI）缺少測試證明。此為本次變更的核心行為，卻沒有任何測試覆蓋。",
|
|
||||||
"suggestion": "mock git 命令，斷言：無 staged diff 時回傳 false 且不執行 commit／push；有變更時以認證方式推送到正確 refspec 與分支。注意：原 finding 描述的 pushToken 對比 origin 雙軌邏輯已於重構後移除（現行一律以 token 經 pushWithCredential 認證推送），撰寫測試前需依現行程式碼重新界定情境。",
|
|
||||||
"suggestedCode": ""
|
|
||||||
}
|
|
||||||
],
|
|
||||||
"excluded": []
|
"excluded": []
|
||||||
}
|
}
|
||||||
|
|||||||
@@ -7,203 +7,6 @@
|
|||||||
"version": "0.0.9",
|
"version": "0.0.9",
|
||||||
"model": "（工具預設）"
|
"model": "（工具預設）"
|
||||||
},
|
},
|
||||||
"findings": [
|
"findings": [],
|
||||||
{
|
|
||||||
"id": "F001",
|
|
||||||
"reviewer": "Leo",
|
|
||||||
"focus": "",
|
|
||||||
"badge": "🧰",
|
|
||||||
"severity": "警告",
|
|
||||||
"file": "src/index.js",
|
|
||||||
"startLine": 119,
|
|
||||||
"endLine": 139,
|
|
||||||
"problem": "流程步驟編號被當成跨模組識別值，散落在 `index.js`、各 library 的日誌與 JSDoc、README 流程圖及功能表。這次僅因插入並延後一步，就必須同步修改大量 `步驟2`～`步驟8` 字串，而且實際執行順序已變成 1、3～8、2、9～10；未來再調整流程時非常容易讓文件、日誌與程式碼脫節。",
|
|
||||||
"suggestion": "以穩定的語意階段名稱取代硬編碼序號，例如 `TOOL_DETECTION`、`COLLECT_DIFF`、`RESOLVE_OLD_COMMENTS`，由單一常數表集中決定顯示名稱；README 的流程順序則從同一份定義產生，或至少不要在各函式文件重複紀錄易變的數字。",
|
|
||||||
"suggestedCode": "```\nconst PHASE = Object.freeze({\n FAST_RESULT: '快速回報',\n DETECT_TOOL: '偵測 AI 工具',\n COLLECT_DIFF: '整理變更',\n RESOLVE_OLD: '處理舊留言',\n PUBLISH_FINDINGS: '發布審查結果',\n});\n\nlog(PHASE.DETECT_TOOL, 'INF', `選用工具：${tool.name}。`);\n```",
|
|
||||||
"sourceIssue": 11
|
|
||||||
},
|
|
||||||
{
|
|
||||||
"id": "F002",
|
|
||||||
"reviewer": "Leo",
|
|
||||||
"focus": "",
|
|
||||||
"badge": "🧰",
|
|
||||||
"severity": "警告",
|
|
||||||
"file": "readme.md",
|
|
||||||
"startLine": 59,
|
|
||||||
"endLine": 130,
|
|
||||||
"problem": "功能索引把分支名稱與原始碼行號硬編碼在數十個連結中；本次僅因程式碼增行，就必須人工把大量 `#L...` 全面更新，已直接顯示這份文件存在高同步成本。之後任一檔案前段增刪程式碼，都會讓這些連結再次漂移，而且指向會持續變動的 `develop` 分支，使舊版 README 與實際連結內容無法穩定對應。",
|
|
||||||
"suggestion": "不要手動維護原始碼行號。若只需導覽，連到檔案並由右欄既有章節錨點提供函式級定位；若必須精確指向定義，應由 AST／文件產生工具在 CI 自動建立索引，並連到固定 commit SHA 或版本 tag。至少增加連結檢查，避免半年後整張功能表悄悄失準。",
|
|
||||||
"suggestedCode": "```\n| 功能名稱 | 功能描述 |\n| --- | --- |\n| [gitrepo.resolveMergeBase](src/lib/gitrepo.js) | [解析 base 分支與 HEAD 的 merge-base](#gitreporesolvemergebase) |\n```",
|
|
||||||
"sourceIssue": 12
|
|
||||||
},
|
|
||||||
{
|
|
||||||
"id": "F006",
|
|
||||||
"reviewer": "Rogue",
|
|
||||||
"focus": "",
|
|
||||||
"badge": "⚡",
|
|
||||||
"severity": "警告",
|
|
||||||
"file": "src/lib/gitrepo.js",
|
|
||||||
"startLine": 134,
|
|
||||||
"endLine": 134,
|
|
||||||
"problem": "在檢查是否為淺層 repository (shallow repository) 時，呼叫了外部子行程執行 `git rev-parse --is-shallow-repository`。建立與啟動 OS 子行程是非常昂貴的操作，會白白浪費數十毫秒的 CPU 週期與系統資源。",
|
|
||||||
"suggestion": "Git 在淺層 clone 時會在 `.git` 目錄下建立一個 `shallow` 檔案。我們可以使用 Node.js 內建的 `fs.existsSync` 進行本地檔案檢查，不需啟動額外的 Git 子行程，執行速度可快上百倍。",
|
|
||||||
"suggestedCode": "```\nconst fs = require('fs');\n// ...\nif (fs.existsSync(path.join(cwd, '.git', 'shallow'))) {\n strategies.push(['unshallow', 'fetch', '--no-tags', '--unshallow', 'origin']);\n}\n```",
|
|
||||||
"sourceIssue": 14
|
|
||||||
},
|
|
||||||
{
|
|
||||||
"id": "F007",
|
|
||||||
"reviewer": "Leo",
|
|
||||||
"focus": "",
|
|
||||||
"badge": "🧰",
|
|
||||||
"severity": "警告",
|
|
||||||
"file": "src/lib/gitrepo.js",
|
|
||||||
"startLine": 293,
|
|
||||||
"endLine": 305,
|
|
||||||
"problem": "為了防止 Git 推送失敗時在例外訊息中回顯包含 Token 與遠端 URL 的命令列參數，pushWithCredential 的 catch 區塊直接拋出一個固定的 Error('推送審查結果 commit 失敗...')。但這樣一來，它完全吞掉了原始的錯誤（例如 non-fast-forward 非快轉、分支保護規則阻擋、或連線逾時），六個月後的維護者在 CI log 中看到此錯誤時，完全無從判斷失敗的原因。",
|
|
||||||
"suggestion": "建議在保留安全遮罩的前提下，保留原始 exception 的排錯線索。例如可以檢查並安全地過濾 err.message 或 err.stderr 中所有的敏感字串（如 Token/URL），然後將其作為新錯誤的 cause 屬性或附加訊息傳遞下去。",
|
|
||||||
"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": "F009",
|
|
||||||
"reviewer": "Bard",
|
|
||||||
"focus": "",
|
|
||||||
"badge": "🎼",
|
|
||||||
"severity": "建議",
|
|
||||||
"file": "src/index.js",
|
|
||||||
"startLine": 308,
|
|
||||||
"endLine": 368,
|
|
||||||
"problem": "新增或修改的步驟分隔註解（如步驟 8 分組、步驟 2 延後、步驟 9、步驟 10、及建問題模式收束）其尾隨的水平分隔線（─）長度不一或僅存單一字元，破壞了專案既有程式碼中整齊劃一的長分隔線視覺排版，視覺上顯得雜亂、走調。",
|
|
||||||
"suggestion": "補足尾隨的水平線 ─，使其與鄰近步驟分隔註解的長度（約 70~80 字元寬度）與視覺風格保持一致，維持排版的美觀。",
|
|
||||||
"suggestedCode": "```\n// ── 步驟 8（分組）：依嚴重等級分組（嚴重／警告＋建議），組內已依檔案與行數排序 ────────────────\n```",
|
|
||||||
"sourceIssue": 14
|
|
||||||
},
|
|
||||||
{
|
|
||||||
"id": "F010",
|
|
||||||
"reviewer": "Rogue",
|
|
||||||
"focus": "",
|
|
||||||
"badge": "⚡",
|
|
||||||
"severity": "建議",
|
|
||||||
"file": "src/index.js",
|
|
||||||
"startLine": 366,
|
|
||||||
"endLine": 382,
|
|
||||||
"problem": "在建問題模式收束時，先 `await gitea.createIssueComment` 再 `await gitea.addIssueDependency`，這兩個 Gitea API 呼叫是獨立且無資料相依性的，卻以序列（Sequential）方式執行，白白浪費了一次網路往返（RTT）的等待時間。",
|
|
||||||
"suggestion": "使用 `Promise.all` 同時發起這兩個請求，並行處理以減少整體 execution 的等待時間。",
|
|
||||||
"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": "F012",
|
|
||||||
"reviewer": "Rogue",
|
|
||||||
"focus": "",
|
|
||||||
"badge": "⚡",
|
|
||||||
"severity": "建議",
|
|
||||||
"file": "src/lib/review.js",
|
|
||||||
"startLine": 48,
|
|
||||||
"endLine": 53,
|
|
||||||
"problem": "在 `agentFailureDetail` 之中，進行 stderr 與 stdout 的遮罩處理時，是先截斷至 2,000 字元，然後執行多次複雜的 `redactSecrets` 正規表示式替換，最後再截斷至 500 字元輸出。這會造成 1,500 字元的複雜 regex 運算結果在下一步被直接丟棄，白白浪費了 CPU 進行字串比對與取代的週期。",
|
|
||||||
"suggestion": "應在呼叫 `redactSecrets` 之前，就先將字串截斷至目標長度（500 字元），再進行遮罩，可大幅減少 regex 運算負擔。",
|
|
||||||
"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": "F014",
|
|
||||||
"reviewer": "Leo",
|
|
||||||
"focus": "",
|
|
||||||
"badge": "🧰",
|
|
||||||
"severity": "建議",
|
|
||||||
"file": "readme.md",
|
|
||||||
"startLine": 56,
|
|
||||||
"endLine": 132,
|
|
||||||
"problem": "README 的功能表大量手動維護 `src/branch/develop/...#Lxx` 深連結，這次光是分支與行號就改了整排。這類文件會隨任何插入註解、重排函式、換預設分支而失準，未來維護者必須在改程式時同步更新一大段文件，維護成本偏高。",
|
|
||||||
"suggestion": "改成不依賴行號的相對連結，或用文件產生腳本從原始碼 JSDoc 自動產出這張表。若仍要指向 Gitea，建議至少移除 `#Lxx`，或集中定義分支名稱，避免每次改分支都要全表搜尋替換。",
|
|
||||||
"suggestedCode": "",
|
|
||||||
"sourceIssue": 15
|
|
||||||
},
|
|
||||||
{
|
|
||||||
"id": "F022",
|
|
||||||
"reviewer": "Leo",
|
|
||||||
"focus": "",
|
|
||||||
"badge": "🧰",
|
|
||||||
"severity": "警告",
|
|
||||||
"file": "readme.md",
|
|
||||||
"startLine": 76,
|
|
||||||
"endLine": 132,
|
|
||||||
"problem": "README 內大量函式清單同時硬編分支名稱與行號錨點，這次 diff 已經整批從 `master` 改成 `develop` 並同步調整行號。這類文件和原始碼結構高度重複，後續只要插入幾行程式，文件連結就會失準，維護者必須靠人工記得同步整張表。",
|
|
||||||
"suggestion": "改成不含行號的穩定檔案連結，或把這份 API/功能表改由 JSDoc/腳本產生。若一定要保留行號，建議把產生流程寫入 npm script，避免每次程式碼位移都人工批次修改 README。",
|
|
||||||
"suggestedCode": "",
|
|
||||||
"sourceIssue": 18
|
|
||||||
},
|
|
||||||
{
|
|
||||||
"id": "F025",
|
|
||||||
"reviewer": "Assassin",
|
|
||||||
"focus": "",
|
|
||||||
"badge": "🗡️",
|
|
||||||
"severity": "警告",
|
|
||||||
"file": "action.yml",
|
|
||||||
"startLine": 21,
|
|
||||||
"endLine": 24,
|
|
||||||
"problem": "這裡建議呼叫端傳入「能觸發 CI 的 PAT」作為 action token。攻擊者最愛這種長效、可推送、可觸發 workflow 的憑證：只要此 action 在不受信任 PR 上執行，或 PR 能影響 action/workflow 執行內容，惡意變更就可能讀取 `INPUT_TOKEN`、推送結果 commit、再藉由可觸發 CI 的身分製造後續執行鏈。自動 token 原本不觸發 CI 是一道防線，這個建議等於要求使用者把防線拆掉。",
|
|
||||||
"suggestion": "不要泛稱建議使用可觸發 CI 的 PAT。文件與介面應明確要求最小權限、repo 限定、短效或可輪替 token，並禁止在 fork/不受信任 PR context 暴露 PAT。更穩的設計是分離 API 留言 token 與 push token，且只有在明確受信任事件或受保護分支才允許 push token 存在；否則拒絕 commit/push，只做留言或 artifact。",
|
|
||||||
"suggestedCode": "",
|
|
||||||
"sourceIssue": 19
|
|
||||||
},
|
|
||||||
{
|
|
||||||
"id": "F026",
|
|
||||||
"reviewer": "Leo",
|
|
||||||
"focus": "",
|
|
||||||
"badge": "🧰",
|
|
||||||
"severity": "建議",
|
|
||||||
"file": "readme.md",
|
|
||||||
"startLine": 59,
|
|
||||||
"endLine": 132,
|
|
||||||
"problem": "README 的功能列表手動維護了大量 `src/branch/develop/...#Lxx` 深連結與行號。這次 PR 已經一次改動數十個 branch/line anchor，代表文件和原始碼行號高度耦合；下一次只要插入幾行程式，文件就會悄悄過期，維護者很難知道哪些連結還準。",
|
|
||||||
"suggestion": "避免在手寫 README 綁定行號，改連到函式所在檔案或穩定章節錨點；若必須保留行號，請把這段改成產生式文件，讓 CI 或腳本從原始碼/JSDoc 重新生成，減少人工同步成本。",
|
|
||||||
"suggestedCode": "",
|
|
||||||
"sourceIssue": 19
|
|
||||||
},
|
|
||||||
{
|
|
||||||
"id": "F031",
|
|
||||||
"reviewer": "Leo",
|
|
||||||
"focus": "",
|
|
||||||
"badge": "🧰",
|
|
||||||
"severity": "建議",
|
|
||||||
"file": "readme.md",
|
|
||||||
"startLine": 56,
|
|
||||||
"endLine": 132,
|
|
||||||
"problem": "README 的功能表大量硬編遠端分支名稱與行號，這次只是從 `master` 改成 `develop` 並同步行號，但這種文件很容易在下一次函式移動、預設分支更名或重排時再次整批失準。未來維護者會被迫反覆做低價值的連結校正，文件也可能在沒人注意時指到錯誤位置。",
|
|
||||||
"suggestion": "若 README 是 repo 內文件，優先改成相對路徑連結，並避免固定行號；若必須保留行號，建議用產生腳本統一輸出這張表，讓分支名與行號只從單一來源計算。",
|
|
||||||
"suggestedCode": "",
|
|
||||||
"sourceIssue": 21
|
|
||||||
},
|
|
||||||
{
|
|
||||||
"id": "F040",
|
|
||||||
"reviewer": "Assassin",
|
|
||||||
"focus": "",
|
|
||||||
"badge": "🗡️",
|
|
||||||
"severity": "警告",
|
|
||||||
"file": "action.yml",
|
|
||||||
"startLine": 19,
|
|
||||||
"endLine": 22,
|
|
||||||
"problem": "這段新增說明鼓勵呼叫端傳入「能觸發 CI 的 PAT」。攻擊者最喜歡這種長效、高權限、可觸發 workflow 的憑證：若 action 跑在不可信 PR、AI CLI 被 prompt injection 誘導讀環境變數，或同 repo PR 可改動本 action 程式碼，就可能把 PAT 外送或濫用成寫入 repo／觸發 CI 的跳板。",
|
|
||||||
"suggestion": "不要把長效 PAT 當建議預設。改用最小權限、短效的 GitHub App／Gitea App token，並明確禁止在不可信 fork PR 傳入可寫 token。若目標只是回報檢查結果，優先用 status/check API 寫結果，不要靠 PAT push 再觸發下一輪 CI。",
|
|
||||||
"suggestedCode": "```\ndescription: 'Gitea API token（PR/issue 留言與 push findings 用；請使用最小權限、短效 token，勿在不可信 PR 傳入長效 PAT）'\n```",
|
|
||||||
"sourceIssue": 23
|
|
||||||
},
|
|
||||||
{
|
|
||||||
"id": "F041",
|
|
||||||
"reviewer": "Leo",
|
|
||||||
"focus": "",
|
|
||||||
"badge": "🧰",
|
|
||||||
"severity": "建議",
|
|
||||||
"file": "readme.md",
|
|
||||||
"startLine": 58,
|
|
||||||
"endLine": 131,
|
|
||||||
"problem": "README 的功能表把分支名稱與行號大量硬編在外部 URL 裡，這次已經需要整批 `master` 改 `develop` 並同步多個 `#Lxx`。這類文件會隨任何程式碼插行、函式移動或預設分支變更而失準，維護成本會線性累積，最後讀者點到的文件比沒有文件更誤導。",
|
|
||||||
"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
|
|
||||||
}
|
|
||||||
],
|
|
||||||
"excluded": []
|
"excluded": []
|
||||||
}
|
}
|
||||||
|
|||||||
@@ -7,103 +7,7 @@
|
|||||||
"version": "codex-cli 0.144.6",
|
"version": "codex-cli 0.144.6",
|
||||||
"model": "gpt-5.5"
|
"model": "gpt-5.5"
|
||||||
},
|
},
|
||||||
"findings": [
|
"findings": [],
|
||||||
{
|
|
||||||
"reviewer": "Assassin",
|
|
||||||
"focus": "security",
|
|
||||||
"badge": "🗡️",
|
|
||||||
"severity": "嚴重",
|
|
||||||
"file": "src/index.js",
|
|
||||||
"startLine": 344,
|
|
||||||
"endLine": 348,
|
|
||||||
"problem": "建問題模式在 `addIssueDependency` 失敗時只記錄警告，接著本輪仍會回傳 0；若 `commitFindings` 後續因沒有實際 diff 可提交而沒有產生 `[failure]` 結果 commit，攻擊者只要讓嚴重 finding 被搬到追蹤 issue，且目標 Gitea 未啟用 issue dependencies 或 token 權限不足，就會 fail-open：PR 既沒有相依阻擋，也沒有失敗檢查阻擋合併。",
|
|
||||||
"suggestion": "有嚴重問題時，相依關係設定失敗應視為阻擋條件：要嘛直接回傳 1，要嘛確認 failure 結果 commit 已成功產生後才允許本輪回傳 0。不要把阻擋機制失效降級成純警告。",
|
|
||||||
"suggestedCode": "",
|
|
||||||
"id": "F001",
|
|
||||||
"verdicts": {
|
|
||||||
"Paladin": {
|
|
||||||
"exclude": false,
|
|
||||||
"reason": "保留。此條不是單純重複既有「相依 API 失敗降級缺測試」，而是指控嚴重 finding 搬到 issue 後，dependency 失敗可能使阻擋機制失效；已知排除事項未涵蓋此安全語義。"
|
|
||||||
}
|
|
||||||
}
|
|
||||||
},
|
|
||||||
{
|
|
||||||
"reviewer": "Mage",
|
|
||||||
"focus": "logic",
|
|
||||||
"badge": "🔮",
|
|
||||||
"severity": "警告",
|
|
||||||
"file": "src/index.js",
|
|
||||||
"startLine": 330,
|
|
||||||
"endLine": 338,
|
|
||||||
"problem": "在建問題模式下，這段新增的 PR 回貼 issue 連結會在每次審查有保留問題時都新增一則 PR 留言，但同一流程前面明確跳過 `resolveOldComments`（建問題模式不清理 PR 舊留言）。最小重現：PR 第一次審查建立 issue #10 並在 PR 留連結；後續推新 commit 再跑一次，建立 issue #11 並再留一則連結。PR 上會同時存在 #10 與 #11，舊 issue 可能已過時，讀者無法判斷哪個才是目前審查結果。",
|
|
||||||
"suggestion": "建問題模式也應對本 action 先前的 PR 連結留言做過時標記，或在新增連結前查找並更新既有連結留言。若要避免碰觸 issue 內的審查內容，清理範圍可限制在 PR 上含 `MARK` 且標題為「已建立追蹤問題」的留言。",
|
|
||||||
"suggestedCode": "",
|
|
||||||
"id": "F009",
|
|
||||||
"verdicts": {
|
|
||||||
"Paladin": {
|
|
||||||
"exclude": false,
|
|
||||||
"reason": "保留。已知排除事項只裁示舊審查留言在本輪結果前標過時的時機；本條指控建問題模式跳過 PR 舊連結留言清理，導致多個追蹤 issue 連結並存，未被既有排除涵蓋。"
|
|
||||||
}
|
|
||||||
}
|
|
||||||
},
|
|
||||||
{
|
|
||||||
"reviewer": "Bard",
|
|
||||||
"focus": "style",
|
|
||||||
"badge": "🎼",
|
|
||||||
"severity": "建議",
|
|
||||||
"file": "src/lib/diagnostics.js",
|
|
||||||
"startLine": 55,
|
|
||||||
"endLine": 63,
|
|
||||||
"problem": "`agentFailureDetail` 裡的 `stderr` 與 `stdout` 區塊幾乎同譜重奏：取值、slice、redact、判斷、push 只差欄位名。這種重複雖小，卻讓後續若要調整遮罩或長度時容易改一半走調。",
|
|
||||||
"suggestion": "建議抽出小 helper，例如 `appendRedactedOutput(parts, label, value)`，讓 stderr/stdout 共用同一段處理節奏。",
|
|
||||||
"suggestedCode": "",
|
|
||||||
"id": "F005",
|
|
||||||
"verdicts": {
|
|
||||||
"Paladin": {
|
|
||||||
"exclude": false,
|
|
||||||
"reason": "保留。此條針對 diagnostics.js 中 stderr/stdout 處理重複的維護性問題，歷史 findings 主要是安全診斷缺測試與外洩風險，並非同一指控。"
|
|
||||||
}
|
|
||||||
}
|
|
||||||
},
|
|
||||||
{
|
|
||||||
"reviewer": "Bard",
|
|
||||||
"focus": "style",
|
|
||||||
"badge": "🎼",
|
|
||||||
"severity": "建議",
|
|
||||||
"file": "src/lib/gitrepo.js",
|
|
||||||
"startLine": 139,
|
|
||||||
"endLine": 160,
|
|
||||||
"problem": "`runFetch`、`tryMergeBase`、`firstError`、`strategies` 夾在 `resolveMergeBase` 主旋律中，使這個函式同時負責驗證、fetch 策略編排、診斷文字組裝與錯誤包裝。即使邏輯可行，閱讀節奏已偏密，維護者很難一眼分辨「主要流程」與「補救策略」。",
|
|
||||||
"suggestion": "建議將 fetch 策略與診斷收集抽成小函式，例如 `fetchAndRecord`、`resolveMergeBaseWithStrategies`，讓 `resolveMergeBase` 保留高階流程：驗證 baseRef → fetch base → 嘗試 merge-base → 補抓歷史。",
|
|
||||||
"suggestedCode": "",
|
|
||||||
"id": "F003",
|
|
||||||
"verdicts": {
|
|
||||||
"Paladin": {
|
|
||||||
"exclude": false,
|
|
||||||
"reason": "保留。歷史 findings 主要涵蓋 resolveMergeBase 缺測試與診斷不足，本條指向函式內策略編排、診斷組裝與錯誤包裝混雜的可維護性問題，未被既有排除事項完整涵蓋。"
|
|
||||||
}
|
|
||||||
}
|
|
||||||
},
|
|
||||||
{
|
|
||||||
"reviewer": "Bard",
|
|
||||||
"focus": "style",
|
|
||||||
"badge": "🎼",
|
|
||||||
"severity": "建議",
|
|
||||||
"file": "src/lib/gitrepo.js",
|
|
||||||
"startLine": 317,
|
|
||||||
"endLine": 346,
|
|
||||||
"problem": "`pushWithCredential` 的 JSDoc 已經很完整，但正文註解再次長篇解釋 checkout token、PAT、extraheader 清空等細節；文件與程式內註解重複奏同一段旋律，反而稀釋真正需要看的程式碼。",
|
|
||||||
"suggestion": "保留 JSDoc 的背景說明，函式內註解縮成操作提示即可，例如只說明「先清空 checkout extraheader，再注入本次 PAT header」。",
|
|
||||||
"suggestedCode": "",
|
|
||||||
"id": "F004",
|
|
||||||
"verdicts": {
|
|
||||||
"Paladin": {
|
|
||||||
"exclude": false,
|
|
||||||
"reason": "保留。既有排除事項雖有 push-token manifest 說明重複，但未涵蓋 pushWithCredential 函式內 JSDoc 與正文註解重複；證據不足以判定為重複或誤報。"
|
|
||||||
}
|
|
||||||
}
|
|
||||||
}
|
|
||||||
],
|
|
||||||
"excluded": [
|
"excluded": [
|
||||||
{
|
{
|
||||||
"reviewer": "Bard",
|
"reviewer": "Bard",
|
||||||
|
|||||||
@@ -0,0 +1,184 @@
|
|||||||
|
{
|
||||||
|
"generatedAt": "2026/07/21 16:00:33",
|
||||||
|
"commitSha": "216bc39255ec176a0f66f2b257beea5929ef4eb8",
|
||||||
|
"prNumber": 6,
|
||||||
|
"tool": {
|
||||||
|
"name": "codex",
|
||||||
|
"version": "codex-cli 0.144.6",
|
||||||
|
"model": "gpt-5.5"
|
||||||
|
},
|
||||||
|
"findings": [],
|
||||||
|
"excluded": [
|
||||||
|
{
|
||||||
|
"reviewer": "Bard",
|
||||||
|
"focus": "style",
|
||||||
|
"badge": "🎼",
|
||||||
|
"severity": "警告",
|
||||||
|
"file": "src/index.js",
|
||||||
|
"startLine": 166,
|
||||||
|
"endLine": 223,
|
||||||
|
"problem": "`main()` 這段新添的建問題模式狀態、暫存佇列、三個閉包輔助函式，全塞在主流程開頭，讓主旋律還沒開始就先進入一大段插曲。`issueModeActive`、`trackingIssue`、`pendingIssueCommentBodies` 彼此共享可變狀態，讀者必須在腦中追蹤閉包副作用，主流程的步驟節奏因此變得沉重。",
|
||||||
|
"suggestion": "把留言去向抽成小型 helper（例如 `createCommentSink`），讓 `main()` 只看見 `commentSink.post()`、`commentSink.flushToIssue()`、`commentSink.fallbackToPr()` 這類語意清楚的介面。主流程保留編排，狀態管理移到專責函式，樂句會乾淨許多。",
|
||||||
|
"suggestedCode": "",
|
||||||
|
"id": "F002",
|
||||||
|
"verdicts": {
|
||||||
|
"Paladin": {
|
||||||
|
"exclude": true,
|
||||||
|
"reason": "可排除（重複）。此條指涉 main() 內 issue 模式狀態、暫存佇列與閉包職責混雜，已由既有排除事項與歷史 findings 多次涵蓋。"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"reviewer": "Bard",
|
||||||
|
"focus": "style",
|
||||||
|
"badge": "🎼",
|
||||||
|
"severity": "建議",
|
||||||
|
"file": "src/index.js",
|
||||||
|
"startLine": 230,
|
||||||
|
"endLine": 239,
|
||||||
|
"problem": "註解標成「步驟 2：延後執行」，但實際位置夾在快速檢查與步驟 3 之前，後面又在步驟 8 後再次出現「步驟 2（延後執行）」。同一個步驟號在不同位置反覆變奏，雖然註解有解釋，閱讀節拍仍容易打結。",
|
||||||
|
"suggestion": "將流程步驟編號與執行順序拆開命名，例如稱為「舊留言清理（延後）」或「收斂前清理舊留言」，避免用 `步驟 2` 這種線性編號描述一個實際延後執行的階段。",
|
||||||
|
"suggestedCode": "",
|
||||||
|
"id": "F003",
|
||||||
|
"verdicts": {
|
||||||
|
"Paladin": {
|
||||||
|
"exclude": true,
|
||||||
|
"reason": "可排除（重複）。歷史 findings 已指出流程步驟編號散落且實際順序變成 1、3～8、2、9～10，與本條「步驟 2 延後但仍用線性編號」相同。"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"reviewer": "Leo",
|
||||||
|
"focus": "maintainability",
|
||||||
|
"badge": "🧰",
|
||||||
|
"severity": "警告",
|
||||||
|
"file": "src/index.js",
|
||||||
|
"startLine": 166,
|
||||||
|
"endLine": 235,
|
||||||
|
"problem": "`main()` 現在同時負責流程編排、PR 留言、issue 模式暫存、issue 建立、fallback 狀態切換與留言 flush。這段靠 `issueModeActive`、`trackingIssue`、`pendingIssueCommentBodies`、`currentRunCommentIds` 多個閉包變數互相配合，半年後要改「留言要發去哪裡」或「建 issue 失敗怎麼降級」時，很容易漏掉某個狀態轉換，尤其後面收尾 commit、resolve 舊留言、嚴重／其他問題發布都還會讀這些狀態。",
|
||||||
|
"suggestion": "把發布目的地抽成一個小型 publisher 模組或類別，讓 `main()` 只呼叫 `publisher.comment()`、`publisher.ensureIssue()`、`publisher.fallbackToPr()`、`publisher.resolveOldComments()` 這類語意方法。狀態留在 publisher 內部，並補單元測試覆蓋「一般模式、issue 模式有 finding、issue 模式無 finding、建立 issue 失敗降級」四條路徑。",
|
||||||
|
"suggestedCode": "",
|
||||||
|
"id": "F006",
|
||||||
|
"verdicts": {
|
||||||
|
"Paladin": {
|
||||||
|
"exclude": true,
|
||||||
|
"reason": "可排除（命中已知排除事項且重複）。main() 同時承擔留言路由、issue 狀態、fallback 與 flush 的發布狀態管理，已由既有排除事項與歷史 findings 涵蓋。"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"reviewer": "Leo",
|
||||||
|
"focus": "maintainability",
|
||||||
|
"badge": "🧰",
|
||||||
|
"severity": "建議",
|
||||||
|
"file": "src/index.js",
|
||||||
|
"startLine": 222,
|
||||||
|
"endLine": 230,
|
||||||
|
"problem": "註解與 log 名稱把「標記舊留言過時」稱為「步驟 2」，但實際執行點被延後到流程後段。這種非時間順序的步驟編號會讓維護者追 log 或對照 README 流程圖時產生認知落差：看到「步驟 2」不再代表第二個發生的動作，而是某個被延後的歷史步驟。",
|
||||||
|
"suggestion": "改用穩定的階段名稱取代數字，例如 `清理舊留言`、`工具偵測`、`diff 摘要`，或重新編號成實際執行順序。若一定要保留舊編號，建議只放在 README 遷移說明，不要散落在程式碼註解與 log label 中。",
|
||||||
|
"suggestedCode": "",
|
||||||
|
"id": "F007",
|
||||||
|
"verdicts": {
|
||||||
|
"Paladin": {
|
||||||
|
"exclude": true,
|
||||||
|
"reason": "可排除（重複）。與 F003 及歷史 findings 指涉同一個延後執行的「步驟 2」仍以線性步驟編號呈現所造成的認知落差。"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"reviewer": "Leo",
|
||||||
|
"focus": "maintainability",
|
||||||
|
"badge": "🧰",
|
||||||
|
"severity": "警告",
|
||||||
|
"file": "readme.md",
|
||||||
|
"startLine": 76,
|
||||||
|
"endLine": 131,
|
||||||
|
"problem": "README 內大量手動維護到 `src/branch/develop/...#Lxx` 的精確行號連結。這次變更已經因程式碼位移而更新一整片連結，未來每次插入函式或註解都會造成文件 churn；更糟的是漏改時文件會指到錯誤行，讀者以為文件可信，實際上卻被帶到過期位置。",
|
||||||
|
"suggestion": "避免在手寫 README 維護精確行號。可改連到檔案或章節錨點，或把 API 列表改由文件產生器輸出。若需要固定定位，優先使用語意穩定的錨點或函式章節，而不是會隨程式碼行數漂移的 `#Lxx`。",
|
||||||
|
"suggestedCode": "",
|
||||||
|
"id": "F008",
|
||||||
|
"verdicts": {
|
||||||
|
"Paladin": {
|
||||||
|
"exclude": true,
|
||||||
|
"reason": "可排除（重複）。README 大量手動維護 develop 分支與 #Lxx 行號連結，歷史 findings 已多次記錄相同維護成本與連結漂移風險。"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"reviewer": "Mage",
|
||||||
|
"focus": "logic",
|
||||||
|
"badge": "🔮",
|
||||||
|
"severity": "嚴重",
|
||||||
|
"file": "src/index.js",
|
||||||
|
"startLine": 117,
|
||||||
|
"endLine": 120,
|
||||||
|
"problem": "當 PR 審查出嚴重問題，但結果 commit/push 失敗時，`commitFindings` 只回傳 `false`。新版主流程又改成「本輪審查不因嚴重問題直接 exit 1，而是依賴下一輪讀到 `[failure]` commit 才失敗」。最小情境：`severe.length > 0`、token 權限不足或 push 競態導致 `commitAndPushFindings` 丟錯；此時沒有 `[failure]` commit、也不會有下一輪快速回報，但本輪仍可能以 0 結束，PR 檢查會在存在嚴重問題時通過。",
|
||||||
|
"suggestion": "嚴重問題存在時，若 failure 結果 commit 沒有成功產生，必須讓本輪直接回傳 1。可保留「成功 push failure commit 時本輪回傳 0、下一輪失敗」的設計，但 push 失敗不可靜默通過。",
|
||||||
|
"suggestedCode": "const result = severe.length === 0 ? 'success' : 'failure';\nconst committed = commitFindings({ cwd, ctx, files: filesToCommit, result });\nif (result === 'failure' && !committed) {\n log('收尾', 'ERR', '有嚴重問題但無法推送 failure 結果 commit，本輪直接失敗。');\n return 1;\n}\nreturn 0;",
|
||||||
|
"id": "F010",
|
||||||
|
"verdicts": {
|
||||||
|
"Paladin": {
|
||||||
|
"exclude": true,
|
||||||
|
"reason": "可排除（重複）。此條與 F001 指涉同一風險：嚴重 finding 存在時 failure 結果 commit/push 失敗，可能使本輪檢查仍以成功結束。"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"reviewer": "Maya",
|
||||||
|
"focus": "testing",
|
||||||
|
"badge": "🧪",
|
||||||
|
"severity": "警告",
|
||||||
|
"file": "src/index.js",
|
||||||
|
"startLine": 163,
|
||||||
|
"endLine": 437,
|
||||||
|
"problem": "建問題模式被大幅改寫：情境留言先暫存、只有 kept finding 才建 issue、建立失敗會 fallback 回 PR、嚴重／非嚴重 finding 會改發到 issue、最後還要回貼追蹤 issue 連結與設定相依關係。但目前新增測試只覆蓋了少數 helper，沒有驗證 `main()` 在這些分支下的實際副作用。這些行為沒經過試煉，等於還不知道留言會不會發錯地方、fallback 後會不會漏清舊留言、或無 finding 時是否真的靜默通過。",
|
||||||
|
"suggestion": "請補 `src/index.js` 的流程層級測試，mock `gitea`、`review`、`agents`、`gitrepo` 等依賴，至少覆蓋：\n\n| 情境 | 應驗證 |\n| --- | --- |\n| `createIssue=true` 且 `kept.length===0` | 不建 issue、不發 PR 留言、暫存情境留言不外洩 |\n| `createIssue=true` 且有 finding | 先建 issue，再依序 flush 工具／diff／角色留言，finding 發到 issue，PR 只留下追蹤 issue 連結 |\n| 建 issue 或寫入 issue 失敗 | fallback 後情境留言改發 PR，後續使用一般模式留言與舊留言清理 |\n| 嚴重 finding | 結果 commit 標記為 failure，但本輪 `main()` 回傳 0，下一輪才由 bot commit 回報 1 |",
|
||||||
|
"suggestedCode": "",
|
||||||
|
"id": "F011",
|
||||||
|
"verdicts": {
|
||||||
|
"Paladin": {
|
||||||
|
"exclude": true,
|
||||||
|
"reason": "可排除（重複）。歷史 findings 已涵蓋建問題模式的暫存留言、只在有 finding 時建 issue、fallback、嚴重／非嚴重分流、PR 回貼與靜默通過等核心分支缺少流程測試。"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"reviewer": "Maya",
|
||||||
|
"focus": "testing",
|
||||||
|
"badge": "🧪",
|
||||||
|
"severity": "警告",
|
||||||
|
"file": "src/lib/gitrepo.js",
|
||||||
|
"startLine": 298,
|
||||||
|
"endLine": 355,
|
||||||
|
"problem": "`commitAndPushFindings` 的推送行為改成一律走 `pushWithCredential`，並宣稱 token 不進 argv、會清掉 checkout 的 extraheader、只接受同一 Gitea origin 的 `.git` URL。這是安全與 CI 觸發都很關鍵的失敗路徑，但目前 `test/gitrepo.test.js` 只測了分支名稱檢查，沒有驗證推送時的 argv/env，也沒有驗證遠端 URL 不符時會停止。這段若改壞，測試不會提醒我們 token 可能出現在命令列或推送根本沒用 PAT 身分。",
|
||||||
|
"suggestion": "請補針對 `commitAndPushFindings`／`pushWithCredential` 的測試。建議用可替換的 `execFileSync` seam 或測試專用注入方式，斷言：\n\n| 情境 | 斷言方向 |\n| --- | --- |\n| 正常推送 | `git push` argv 只含不帶帳密的 `remoteUrl` 與 refspec |\n| 正常推送 | env 含 `GIT_CONFIG_COUNT=2`，先清空 `http.<origin>/.extraheader`，再注入 `Authorization: Basic ...` |\n| `remoteUrl` origin 不符或非 `.git` | 拋出固定錯誤且不執行 push |\n| push 失敗 | 對外錯誤訊息不含 token、remote URL 或 argv |",
|
||||||
|
"suggestedCode": "",
|
||||||
|
"id": "F012",
|
||||||
|
"verdicts": {
|
||||||
|
"Paladin": {
|
||||||
|
"exclude": true,
|
||||||
|
"reason": "可排除（重複）。歷史 findings 已記錄 commitAndPushFindings／pushWithCredential 的認證推送路徑、argv/env、遠端目標檢查與失敗訊息遮蔽缺少測試。"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"reviewer": "Maya",
|
||||||
|
"focus": "testing",
|
||||||
|
"badge": "🧪",
|
||||||
|
"severity": "警告",
|
||||||
|
"file": "src/lib/gitrepo.js",
|
||||||
|
"startLine": 130,
|
||||||
|
"endLine": 188,
|
||||||
|
"problem": "`resolveMergeBase` 新增了多階段 fetch 補歷史流程：先 fetch base、首次 merge-base、再 deepen base、deepen PR HEAD、必要時 unshallow，且每個策略成功後要立即重試並短路返回。現有測試只驗證不安全 `baseRef` 會在 fetch 前被拒絕，沒有測到淺層 checkout、首次失敗後補抓成功、策略失敗繼續下一個、全部失敗時診斷訊息等邊界。這正是容易 off-by-one 或順序錯的流程，現在還沒有測試保護。",
|
||||||
|
"suggestion": "請補資料驅動的 `resolveMergeBase` 測試，mock git 執行結果來驗證：首次 merge-base 成功時不跑 deepen；deepen base 後成功會立刻回傳；deepen PR HEAD 使用目前 `HEAD` SHA 而不是遠端符號 `HEAD`；非 shallow repo 不呼叫 `--unshallow`；全部策略失敗時錯誤包含各策略診斷且保留 cause。",
|
||||||
|
"suggestedCode": "",
|
||||||
|
"id": "F013",
|
||||||
|
"verdicts": {
|
||||||
|
"Paladin": {
|
||||||
|
"exclude": true,
|
||||||
|
"reason": "可排除（重複）。resolveMergeBase 多階段 fetch、淺層與非淺層路徑、策略停止條件、全部失敗診斷與 cause 缺少測試，已由歷史 findings 涵蓋。"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
@@ -0,0 +1,184 @@
|
|||||||
|
{
|
||||||
|
"generatedAt": "2026/07/21 16:30:12",
|
||||||
|
"commitSha": "43ad2b56d27429aa3c812522dc1d4fedce4a9b76",
|
||||||
|
"prNumber": 6,
|
||||||
|
"tool": {
|
||||||
|
"name": "codex",
|
||||||
|
"version": "codex-cli 0.144.6",
|
||||||
|
"model": "gpt-5.5"
|
||||||
|
},
|
||||||
|
"findings": [],
|
||||||
|
"excluded": [
|
||||||
|
{
|
||||||
|
"reviewer": "Bard",
|
||||||
|
"focus": "style",
|
||||||
|
"badge": "🎼",
|
||||||
|
"severity": "建議",
|
||||||
|
"file": "readme.md",
|
||||||
|
"startLine": 48,
|
||||||
|
"endLine": 48,
|
||||||
|
"problem": "Mermaid 節點代號從 `N8` 跳回 `N2`，雖然流程語意是「步驟 2 延後」，但原始碼讀起來像旋律突然倒帶；維護者在對照圖與步驟時容易被代號順序絆住。",
|
||||||
|
"suggestion": "節點 id 建議改用語意名稱，而把顯示文字保留步驟編號。例如 `ResolveOldComments[2 延後將舊留言標記解決...]`，讓圖的原始碼與顯示內容各自清楚。",
|
||||||
|
"suggestedCode": "",
|
||||||
|
"id": "F002",
|
||||||
|
"verdicts": {
|
||||||
|
"Paladin": {
|
||||||
|
"exclude": true,
|
||||||
|
"reason": "可排除（重複）。歷史 findings 已指出流程步驟編號與實際順序、README 流程圖及文件對照會產生認知落差；本條 Mermaid 節點代號問題屬同一類指控。"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"reviewer": "Bard",
|
||||||
|
"focus": "style",
|
||||||
|
"badge": "🎼",
|
||||||
|
"severity": "警告",
|
||||||
|
"file": "src/index.js",
|
||||||
|
"startLine": 167,
|
||||||
|
"endLine": 235,
|
||||||
|
"problem": "`main()` 內新增了建 issue 模式狀態、暫存佇列與三個帶長篇 JSDoc 的閉包，讓主流程的旋律被大量伴奏蓋過。這段同時管理 `issueModeActive`、`trackingIssue`、`pendingIssueCommentBodies` 與 PR 留言 id，可讀性負擔明顯升高。",
|
||||||
|
"suggestion": "把留言路由與建 issue 暫存邏輯抽成小型 helper（例如 `createCommentRouter`），`main()` 只保留流程編排；JSDoc 也移到 helper 旁，讓主流程步驟重新一眼可讀。",
|
||||||
|
"suggestedCode": "",
|
||||||
|
"id": "F003",
|
||||||
|
"verdicts": {
|
||||||
|
"Paladin": {
|
||||||
|
"exclude": true,
|
||||||
|
"reason": "可排除（重複）。已知排除事項與歷史 findings 已涵蓋 main() 內留言路由、issue 狀態、暫存佇列與發布職責耦合造成可讀性與維護負擔。"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"reviewer": "Bard",
|
||||||
|
"focus": "style",
|
||||||
|
"badge": "🎼",
|
||||||
|
"severity": "建議",
|
||||||
|
"file": "src/lib/gitrepo.js",
|
||||||
|
"startLine": 121,
|
||||||
|
"endLine": 128,
|
||||||
|
"problem": "`strategies` 以陣列位置承載語意，`[label, ...args]` 雖簡短，卻讓每個元素的第二欄之後全靠讀者猜是 git argv；這裡的可讀性像沒有小節線的樂譜。",
|
||||||
|
"suggestion": "改成物件陣列，明確標出 `label` 與 `args`，可降低後續新增 fetch 策略時的閱讀成本。",
|
||||||
|
"suggestedCode": "const strategies = [\n { label: 'deepen base', args: ['fetch', '--no-tags', '--deepen=1000', 'origin', `+refs/heads/${baseRef}:refs/remotes/${remoteBase}`] },\n { label: 'deepen PR HEAD', args: ['fetch', '--no-tags', '--deepen=1000', 'origin', headSha] },\n];",
|
||||||
|
"id": "F005",
|
||||||
|
"verdicts": {
|
||||||
|
"Paladin": {
|
||||||
|
"exclude": true,
|
||||||
|
"reason": "可排除（重複）。歷史 finding 已針對 resolveMergeBase 內 strategies 與補救策略編排使閱讀節奏偏密提出問題；本條 tuple 可讀性屬同一段策略結構的細項。"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"reviewer": "Leo",
|
||||||
|
"focus": "maintainability",
|
||||||
|
"badge": "🧰",
|
||||||
|
"severity": "警告",
|
||||||
|
"file": "src/index.js",
|
||||||
|
"startLine": 163,
|
||||||
|
"endLine": 231,
|
||||||
|
"problem": "`main()` 這次把一般模式／建問題模式／降級模式的留言去向都塞進閉包狀態：`issueModeActive`、`trackingIssue`、`pendingIssueCommentBodies`、`currentRunCommentIds` 彼此耦合。半年後要新增一種落地方式或調整「何時清舊留言」時，維護者必須同時追多個可變狀態與後續多個 `if (issueModeActive)` 分支，很容易漏掉 flush、清空、登錄留言 id 或 fallback 後的收尾行為。",
|
||||||
|
"suggestion": "把留言目的地抽成小型物件，讓主流程只呼叫 `commentSink.postContext()`、`commentSink.finalizeAfterFindings()`、`commentSink.postFinding()` 這類語意方法。一般 PR、issue buffering、fallback 的狀態轉換集中在同一個模組或工廠函式內，`main()` 保持審查流程編排，不承擔留言狀態機。",
|
||||||
|
"suggestedCode": "",
|
||||||
|
"id": "F006",
|
||||||
|
"verdicts": {
|
||||||
|
"Paladin": {
|
||||||
|
"exclude": true,
|
||||||
|
"reason": "可排除（重複）。與 F003 及既有排除事項相同，均指向 main() 以可變閉包狀態承擔留言目的地、issue 生命週期與 fallback 狀態機。"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"reviewer": "Leo",
|
||||||
|
"focus": "maintainability",
|
||||||
|
"badge": "🧰",
|
||||||
|
"severity": "警告",
|
||||||
|
"file": "src/index.js",
|
||||||
|
"startLine": 232,
|
||||||
|
"endLine": 241,
|
||||||
|
"problem": "流程註解把「將舊留言標記為解決」稱為「步驟 2（延後執行）」，但實際執行點在審查結果產生後、接近原本步驟 9 前。這種「編號是 2、時間點是 8 後」的設計已經擴散到多個檔案的 JSDoc 與 log 描述，未來查 CI log 或維護流程圖時會產生認知落差：看到 `步驟2` 不代表它真的發生在第二步。",
|
||||||
|
"suggestion": "不要用固定序號承載流程語意。建議改成穩定階段名稱，例如 `清理舊留言`、`工具偵測`、`diff整理`，或重新編號為實際執行順序並在文件說明「清理舊留言延後到結果產生後」。這樣 log、JSDoc、README 流程圖才不會互相背離。",
|
||||||
|
"suggestedCode": "",
|
||||||
|
"id": "F007",
|
||||||
|
"verdicts": {
|
||||||
|
"Paladin": {
|
||||||
|
"exclude": true,
|
||||||
|
"reason": "可排除（重複）。歷史 findings 已明確記錄步驟編號散落於 log、JSDoc、README 且實際順序變成 1、3 到 8、2、9 到 10 的維護風險。"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"reviewer": "Leo",
|
||||||
|
"focus": "maintainability",
|
||||||
|
"badge": "🧰",
|
||||||
|
"severity": "建議",
|
||||||
|
"file": "src/lib/gitrepo.js",
|
||||||
|
"startLine": 103,
|
||||||
|
"endLine": 160,
|
||||||
|
"problem": "`resolveMergeBase()` 內同時負責驗證 base ref、fetch base、重試 merge-base、補抓淺層歷史、累積診斷與組錯誤訊息。這些都和「取得 merge-base」有關，但現在全部攤在同一個函式裡，策略陣列、診斷格式與 git 操作細節混在一起；未來要新增 fetch 策略或改診斷文字時，容易不小心改壞主流程判斷。",
|
||||||
|
"suggestion": "把補抓策略與重試邏輯拆成私有 helper，例如 `fetchBaseRef()`、`mergeBaseOrNull()`、`shallowFetchStrategies()`。主函式保留高階流程：驗證 ref → 更新 base → 嘗試 merge-base → 逐一套用策略 → 丟出診斷錯誤。",
|
||||||
|
"suggestedCode": "",
|
||||||
|
"id": "F008",
|
||||||
|
"verdicts": {
|
||||||
|
"Paladin": {
|
||||||
|
"exclude": true,
|
||||||
|
"reason": "可排除（重複）。歷史 finding 已指出 resolveMergeBase 同時負責驗證、fetch 策略編排、診斷與錯誤包裝，難以分辨主流程與補救策略。"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"reviewer": "Maya",
|
||||||
|
"focus": "testing",
|
||||||
|
"badge": "🧪",
|
||||||
|
"severity": "警告",
|
||||||
|
"file": "src/index.js",
|
||||||
|
"startLine": 164,
|
||||||
|
"endLine": 232,
|
||||||
|
"problem": "建問題模式新增了「先暫存情境留言、確定有保留 finding 才建 issue、建 issue 失敗時降級回 PR 留言」這一整段流程，但目前測試只覆蓋了部分 helper，沒有驗證主流程在 create-issue=true 下的分流行為。這代表像「無保留問題時不應建 issue／不應留言」、「建立 issue 失敗時應把 pending 留言補回 PR」、「trackingIssue 建立後後續留言應改送 issue」這些行為都還沒通過試煉。",
|
||||||
|
"suggestion": "建議把 main 流程拆出可注入 gitea/review/agents/gitrepo 的 orchestrator，或至少匯出可測的流程函式，補上 create-issue=true 的案例：1. kept=[] 時不呼叫 createIssue/createIssueComment；2. kept>0 時先 flush pending issue comments 再發 finding；3. createIssue 拋錯時 fallbackToPrComments 會發回 PR 並記錄 currentRunCommentIds；4. issueModeActive 降級後會走一般 PR 留言與 resolveOldComments。",
|
||||||
|
"suggestedCode": "",
|
||||||
|
"id": "F011",
|
||||||
|
"verdicts": {
|
||||||
|
"Paladin": {
|
||||||
|
"exclude": true,
|
||||||
|
"reason": "可排除（重複）。歷史 findings 已涵蓋建問題模式核心流程、暫存留言、issue 建立條件、發布分流、外部 API 狀態切換與降級路徑缺少測試。"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"reviewer": "Maya",
|
||||||
|
"focus": "testing",
|
||||||
|
"badge": "🧪",
|
||||||
|
"severity": "警告",
|
||||||
|
"file": "src/lib/gitrepo.js",
|
||||||
|
"startLine": 104,
|
||||||
|
"endLine": 150,
|
||||||
|
"problem": "resolveMergeBase 新增了多階段 fetch/deepen/unshallow fallback 與診斷錯誤，但測試只驗證不安全 baseRef 會被拒絕，沒有驗證任何成功或失敗 fallback 路徑。這段是 diff 基準的核心邏輯，若 shallow checkout 下 deepen PR HEAD 用錯 ref、策略順序跑錯，或全部失敗時診斷不正確，現有測試都抓不到。",
|
||||||
|
"suggestion": "建議用假的 git 執行層或臨時 git repo 補測：首次 merge-base 成功時不跑後續策略；首次失敗但 deepen base 後成功；deepen base 失敗會繼續 deepen PR HEAD；shallow repo 才嘗試 --unshallow；全部失敗時錯誤訊息包含各策略診斷且保留 cause。",
|
||||||
|
"suggestedCode": "",
|
||||||
|
"id": "F012",
|
||||||
|
"verdicts": {
|
||||||
|
"Paladin": {
|
||||||
|
"exclude": true,
|
||||||
|
"reason": "可排除（重複）。歷史 findings 已針對 resolveMergeBase 多階段 fetch、淺層與非淺層分支、策略停止條件、降級與最終診斷缺少測試提出相同問題。"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"reviewer": "Maya",
|
||||||
|
"focus": "testing",
|
||||||
|
"badge": "🧪",
|
||||||
|
"severity": "警告",
|
||||||
|
"file": "src/lib/gitrepo.js",
|
||||||
|
"startLine": 272,
|
||||||
|
"endLine": 322,
|
||||||
|
"problem": "commitAndPushFindings 改成一律透過 pushWithCredential 用 PAT extraheader 推送，且新增 headRef 安全檢查與固定錯誤遮蔽；但目前 gitrepo 測試沒有覆蓋 commitAndPushFindings/pushWithCredential 的推送行為。這讓「token 不進 argv」、「清掉 checkout 既有 extraheader」、「遠端 URL 不符時拒絕」、「push 失敗不洩漏 URL/token」這些失敗與安全邊界都沒有被驗證。",
|
||||||
|
"suggestion": "建議以 stub child_process.execFileSync 或可注入 git runner 的方式補測：commit 後呼叫 git push 的 argv 不含 token；env 內含 GIT_CONFIG_COUNT 與 Authorization extraheader；headRef 不安全時在 git add/commit/push 前拋錯；remote origin 不符與 push 失敗時錯誤訊息不包含 token、repo URL 或 Basic header。",
|
||||||
|
"suggestedCode": "",
|
||||||
|
"id": "F013",
|
||||||
|
"verdicts": {
|
||||||
|
"Paladin": {
|
||||||
|
"exclude": true,
|
||||||
|
"reason": "可排除（重複）。歷史 findings 已涵蓋 commitAndPushFindings 與 pushWithCredential 的推送策略、認證遮蔽、失敗路徑與 token 不外洩等測試缺口。"
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
+4
-4
@@ -1,6 +1,6 @@
|
|||||||
# ============================================================================
|
# ============================================================================
|
||||||
# 用途：定義 AI Code Review Node action 的名稱、輸入參數與 Node.js 24 進入點，供 Gitea / GitHub workflow 以 uses 引用。
|
# 用途：定義 AI Code Review Node action 的名稱、輸入參數與 Node.js 24 進入點，供 Gitea / GitHub workflow 以 uses 引用。
|
||||||
# 更新時間：2026/07/17 18:49:58
|
# 更新時間：2026/07/28 13:57:24
|
||||||
# ============================================================================
|
# ============================================================================
|
||||||
# Gitea / GitHub node action 的 manifest（action.yml）：
|
# Gitea / GitHub node action 的 manifest（action.yml）：
|
||||||
# 定義本 action 的名稱、說明、輸入參數（inputs）與執行方式（runs），
|
# 定義本 action 的名稱、說明、輸入參數（inputs）與執行方式（runs），
|
||||||
@@ -16,11 +16,11 @@ author: 'Jeffery'
|
|||||||
# 輸入參數區塊：呼叫端 workflow 以 `with:` 傳入，
|
# 輸入參數區塊：呼叫端 workflow 以 `with:` 傳入，
|
||||||
# runner 會自動注入為 INPUT_* 環境變數（例如 INPUT_TOKEN、INPUT_MODEL、INPUT_CREATE-ISSUE）供主程式讀取。
|
# runner 會自動注入為 INPUT_* 環境變數（例如 INPUT_TOKEN、INPUT_MODEL、INPUT_CREATE-ISSUE）供主程式讀取。
|
||||||
inputs:
|
inputs:
|
||||||
# Gitea API token：用於對 PR／issue 留言審查結果，以及 push 審查結果檔（findings/exclusions）回 repo。
|
# Gitea API token：用於對 PR／issue 留言審查結果，以及 push 審查結果檔（findings／exclusions）回 repo。
|
||||||
token:
|
token:
|
||||||
# 參數用途說明：secrets/vars context 在 action 內不可用，故由呼叫端 workflow 以 secrets 傳入。
|
# 參數用途說明：secrets/vars context 在 action 內不可用，故由呼叫端 workflow 以 secrets 傳入。
|
||||||
# 建議傳入能觸發 CI 的 PAT；自動 token 推送結果 commit 時可能不會再觸發 workflow。
|
# 建議使用 repo 限定、最小權限且可輪替的 token；不得在不受信任 fork PR 暴露可寫入 token。
|
||||||
description: 'Gitea API token（PR/issue 留言與 push findings 用；建議以能觸發 CI 的 PAT 由 secrets 傳入）'
|
description: 'Gitea API token（PR／issue 留言與 push findings 用；請以 repo 限定、最小權限且可輪替的 secrets 傳入）'
|
||||||
# 必填：缺少 token 無法呼叫 Gitea API，action 無法運作。
|
# 必填：缺少 token 無法呼叫 Gitea API，action 無法運作。
|
||||||
required: true
|
required: true
|
||||||
# 指定 AI 工具使用的模型名稱。
|
# 指定 AI 工具使用的模型名稱。
|
||||||
|
|||||||
@@ -1,6 +1,6 @@
|
|||||||
# AI Code Review
|
# AI Code Review
|
||||||
|
|
||||||
> 更新時間：2026/07/17 18:49:58
|
> 更新時間：2026/07/28 13:57:24
|
||||||
|
|
||||||
AI 多角色 code review 的 Gitea **node action**（`node24`、零外部相依）：以攻擊方六角色（🔮 Mage 邏輯、🗡️ Assassin 安全、⚡ Rogue 效率、🎼 Bard 風格、🧪 Maya 測試、🧰 Leo 可維護性）並行找問題、防守方（🛡️ Paladin）裁決誤報，結果留言到 PR、保存 findings，並以 bot commit 標記審查結果（`[success]`／`[failure]`）供下次觸發快速回報。
|
AI 多角色 code review 的 Gitea **node action**（`node24`、零外部相依）：以攻擊方六角色（🔮 Mage 邏輯、🗡️ Assassin 安全、⚡ Rogue 效率、🎼 Bard 風格、🧪 Maya 測試、🧰 Leo 可維護性）並行找問題、防守方（🛡️ Paladin）裁決誤報，結果留言到 PR、保存 findings，並以 bot commit 標記審查結果（`[success]`／`[failure]`）供下次觸發快速回報。
|
||||||
|
|
||||||
@@ -76,56 +76,56 @@ flowchart TD
|
|||||||
|
|
||||||
| 功能名稱 | 功能描述 |
|
| 功能名稱 | 功能描述 |
|
||||||
| --- | --- |
|
| --- | --- |
|
||||||
| [log.taipeiNow](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/log.js#L20) | [取得台北時區 yyyy/MM/dd HH:mm:ss 時間字串](#logtaipeinow) |
|
| [log.taipeiNow](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/log.js) | [取得台北時區 yyyy/MM/dd HH:mm:ss 時間字串](#logtaipeinow) |
|
||||||
| [log.taipeiFileStamp](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/log.js#L41) | [取得檔名用時間戳 yyyy-MM-dd-HH:mm:ss](#logtaipeifilestamp) |
|
| [log.taipeiFileStamp](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/log.js) | [取得檔名用時間戳 yyyy-MM-dd-HH:mm:ss](#logtaipeifilestamp) |
|
||||||
| [log.taipeiFromIso](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/log.js#L60) | [將 ISO 時間字串轉為台北時區顯示字串](#logtaipeifromiso) |
|
| [log.taipeiFromIso](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/log.js) | [將 ISO 時間字串轉為台北時區顯示字串](#logtaipeifromiso) |
|
||||||
| [log.log](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/log.js#L83) | [以統一格式輸出一行日誌](#loglog) |
|
| [log.log](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/log.js) | [以統一格式輸出一行日誌](#loglog) |
|
||||||
| [context.loadContext](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/context.js#L64) | [彙整 runner 環境變數與事件 payload 為執行上下文](#contextloadcontext) |
|
| [context.loadContext](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/context.js) | [彙整 runner 環境變數與事件 payload 為執行上下文](#contextloadcontext) |
|
||||||
| [gitrepo.latestCommitSubject](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/gitrepo.js#L79) | [取得最新 commit 的訊息標題](#gitrepolatestcommitsubject) |
|
| [gitrepo.latestCommitSubject](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/gitrepo.js) | [取得最新 commit 的訊息標題](#gitrepolatestcommitsubject) |
|
||||||
| [gitrepo.resolveMergeBase](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/gitrepo.js#L100) | [解析 base 分支與 HEAD 的 merge-base](#gitreporesolvemergebase) |
|
| [gitrepo.resolveMergeBase](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/gitrepo.js) | [解析 base 分支與 HEAD 的 merge-base](#gitreporesolvemergebase) |
|
||||||
| [gitrepo.changedFiles](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/gitrepo.js#L136) | [列出 base 與 HEAD 之間有變更的檔案](#gitrepochangedfiles) |
|
| [gitrepo.changedFiles](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/gitrepo.js) | [列出 base 與 HEAD 之間有變更的檔案](#gitrepochangedfiles) |
|
||||||
| [gitrepo.fileDiff](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/gitrepo.js#L157) | [取得單一檔案的 git diff 內容](#gitrepofilediff) |
|
| [gitrepo.fileDiff](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/gitrepo.js) | [取得單一檔案的 git diff 內容](#gitrepofilediff) |
|
||||||
| [gitrepo.fileLastUpdatedIso](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/gitrepo.js#L175) | [取得檔案最後一次 commit 的 ISO 時間](#gitrepofilelastupdatediso) |
|
| [gitrepo.fileLastUpdatedIso](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/gitrepo.js) | [取得檔案最後一次 commit 的 ISO 時間](#gitrepofilelastupdatediso) |
|
||||||
| [gitrepo.commitAndPushFindings](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/gitrepo.js#L213) | [以 bot 身分 commit 結果檔並 push 回 PR 來源分支](#gitrepocommitandpushfindings) |
|
| [gitrepo.commitAndPushFindings](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/gitrepo.js) | [以 bot 身分 commit 結果檔並 push 回 PR 來源分支](#gitrepocommitandpushfindings) |
|
||||||
| [gitea.whoAmI](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/gitea.js#L87) | [取得 token 對應的使用者（bot 身分）](#giteawhoami) |
|
| [gitea.whoAmI](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/gitea.js) | [取得 token 對應的使用者（bot 身分）](#giteawhoami) |
|
||||||
| [gitea.createCommentOnIssue](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/gitea.js#L106) | [對指定編號 issue／PR 新增一般留言](#giteacreatecommentonissue) |
|
| [gitea.createCommentOnIssue](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/gitea.js) | [對指定編號 issue／PR 新增一般留言](#giteacreatecommentonissue) |
|
||||||
| [gitea.createIssueComment](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/gitea.js#L124) | [對本次 PR 新增一般留言](#giteacreateissuecomment) |
|
| [gitea.createIssueComment](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/gitea.js) | [對本次 PR 新增一般留言](#giteacreateissuecomment) |
|
||||||
| [gitea.listLabels](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/gitea.js#L141) | [列出存取庫可用標籤](#gitealistlabels) |
|
| [gitea.listLabels](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/gitea.js) | [列出存取庫可用標籤](#gitealistlabels) |
|
||||||
| [gitea.createIssue](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/gitea.js#L164) | [在存取庫建立 issue（可掛標籤）](#giteacreateissue) |
|
| [gitea.createIssue](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/gitea.js) | [在存取庫建立 issue（可掛標籤）](#giteacreateissue) |
|
||||||
| [gitea.listIssueComments](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/gitea.js#L184) | [列出 PR 全部一般留言（自動分頁）](#gitealistissuecomments) |
|
| [gitea.listIssueComments](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/gitea.js) | [列出 PR 全部一般留言（自動分頁）](#gitealistissuecomments) |
|
||||||
| [gitea.editIssueComment](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/gitea.js#L202) | [編輯既有一般留言](#giteaeditissuecomment) |
|
| [gitea.editIssueComment](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/gitea.js) | [編輯既有一般留言](#giteaeditissuecomment) |
|
||||||
| [gitea.createReview](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/gitea.js#L223) | [建立 code review 並掛行內留言](#giteacreatereview) |
|
| [gitea.createReview](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/gitea.js) | [建立 code review 並掛行內留言](#giteacreatereview) |
|
||||||
| [gitea.listReviews](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/gitea.js#L243) | [列出 PR 全部 review（自動分頁）](#gitealistreviews) |
|
| [gitea.listReviews](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/gitea.js) | [列出 PR 全部 review（自動分頁）](#gitealistreviews) |
|
||||||
| [gitea.listReviewComments](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/gitea.js#L264) | [列出某 review 的全部行內留言](#gitealistreviewcomments) |
|
| [gitea.listReviewComments](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/gitea.js) | [列出某 review 的全部行內留言](#gitealistreviewcomments) |
|
||||||
| [gitea.tryResolveReviewComment](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/gitea.js#L287) | [盡力將行內留言標記為已解決](#giteatryresolvereviewcomment) |
|
| [gitea.tryResolveReviewComment](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/gitea.js) | [盡力將行內留言標記為已解決](#giteatryresolvereviewcomment) |
|
||||||
| [agents.detectTool](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/agents.js#L53) | [依優先序偵測可用的 AI CLI 工具](#agentsdetecttool) |
|
| [agents.detectTool](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/agents.js) | [依優先序偵測可用的 AI CLI 工具](#agentsdetecttool) |
|
||||||
| [agents.runAgent](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/agents.js#L98) | [非互動執行一次 sub agent 並取回回覆](#agentsrunagent) |
|
| [agents.runAgent](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/agents.js) | [非互動執行一次 sub agent 並取回回覆](#agentsrunagent) |
|
||||||
| [agents.extractJson](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/agents.js#L144) | [從 agent 回覆萃取 JSON（容忍雜訊）](#agentsextractjson) |
|
| [agents.extractJson](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/agents.js) | [從 agent 回覆萃取 JSON（容忍雜訊）](#agentsextractjson) |
|
||||||
| [roles.loadRoles](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/roles.js#L32) | [載入角色提示檔並解析 frontmatter](#rolesloadroles) |
|
| [roles.loadRoles](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/roles.js) | [載入角色提示檔並解析 frontmatter](#rolesloadroles) |
|
||||||
| [roles.attackersOf](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/roles.js#L71) | [過濾出攻擊方角色](#rolesattackersof) |
|
| [roles.attackersOf](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/roles.js) | [過濾出攻擊方角色](#rolesattackersof) |
|
||||||
| [roles.defendersOf](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/roles.js#L90) | [過濾出防守方角色](#rolesdefendersof) |
|
| [roles.defendersOf](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/roles.js) | [過濾出防守方角色](#rolesdefendersof) |
|
||||||
| [templates.toolComment](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/templates.js#L88) | [產生步驟 3 審查工具留言](#templatestoolcomment) |
|
| [templates.toolComment](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/templates.js) | [產生步驟 3 審查工具留言](#templatestoolcomment) |
|
||||||
| [templates.diffComment](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/templates.js#L132) | [產生步驟 4 變更摘要留言](#templatesdiffcomment) |
|
| [templates.diffComment](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/templates.js) | [產生步驟 4 變更摘要留言](#templatesdiffcomment) |
|
||||||
| [templates.rolesComment](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/templates.js#L173) | [產生步驟 5／7 角色登場留言](#templatesrolescomment) |
|
| [templates.rolesComment](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/templates.js) | [產生步驟 5／7 角色登場留言](#templatesrolescomment) |
|
||||||
| [templates.severeCommentBody](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/templates.js#L215) | [產生步驟 9 單條嚴重問題留言](#templatesseverecommentbody) |
|
| [templates.severeCommentBody](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/templates.js) | [產生步驟 9 單條嚴重問題留言](#templatesseverecommentbody) |
|
||||||
| [templates.severeReviewBody](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/templates.js#L247) | [產生步驟 9 嚴重問題 review 總覽](#templatesseverereviewbody) |
|
| [templates.severeReviewBody](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/templates.js) | [產生步驟 9 嚴重問題 review 總覽](#templatesseverereviewbody) |
|
||||||
| [templates.othersComment](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/templates.js#L277) | [產生步驟 10 警告＋建議彙整表格留言](#templatesotherscomment) |
|
| [templates.othersComment](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/templates.js) | [產生步驟 10 警告＋建議彙整表格留言](#templatesotherscomment) |
|
||||||
| [templates.issueBody](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/templates.js#L309) | [產生建問題模式的 issue 本文](#templatesissuebody) |
|
| [templates.issueBody](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/templates.js) | [產生建問題模式的 issue 本文](#templatesissuebody) |
|
||||||
| [templates.issueFindingComment](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/templates.js#L341) | [產生建問題模式單條問題的 issue 留言](#templatesissuefindingcomment) |
|
| [templates.issueFindingComment](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/templates.js) | [產生建問題模式單條問題的 issue 留言](#templatesissuefindingcomment) |
|
||||||
| [templates.nothingToReviewComment](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/templates.js#L379) | [產生無可審查變更留言](#templatesnothingtoreviewcomment) |
|
| [templates.nothingToReviewComment](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/templates.js) | [產生無可審查變更留言](#templatesnothingtoreviewcomment) |
|
||||||
| [review.loadReviewIgnore](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/review.js#L29) | [讀取 .reviewignore 忽略前綴清單](#reviewloadreviewignore) |
|
| [review.loadReviewIgnore](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/review.js) | [讀取 .reviewignore 忽略前綴清單](#reviewloadreviewignore) |
|
||||||
| [review.isIgnored](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/review.js#L53) | [判斷檔案是否忽略不送審](#reviewisignored) |
|
| [review.isIgnored](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/review.js) | [判斷檔案是否忽略不送審](#reviewisignored) |
|
||||||
| [review.collectDiffRows](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/review.js#L77) | [整理送審 diff 資料列（含長度上限）](#reviewcollectdiffrows) |
|
| [review.collectDiffRows](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/review.js) | [整理送審 diff 資料列（含長度上限）](#reviewcollectdiffrows) |
|
||||||
| [review.fillPurposes](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/review.js#L127) | [以 AI 補齊每個檔案的一行用途描述](#reviewfillpurposes) |
|
| [review.fillPurposes](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/review.js) | [以 AI 補齊每個檔案的一行用途描述](#reviewfillpurposes) |
|
||||||
| [review.runAttackers](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/review.js#L276) | [攻擊方 sub agent 並行找問題並合併列表](#reviewrunattackers) |
|
| [review.runAttackers](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/review.js) | [攻擊方 sub agent 並行找問題並合併列表](#reviewrunattackers) |
|
||||||
| [review.runDefenders](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/review.js#L448) | [防守方 sub agent 裁決保留或排除](#reviewrundefenders) |
|
| [review.runDefenders](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/review.js) | [防守方 sub agent 裁決保留或排除](#reviewrundefenders) |
|
||||||
| [review.sortFindings](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/review.js#L572) | [依嚴重度→檔案→行號排序 findings](#reviewsortfindings) |
|
| [review.sortFindings](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/review.js) | [依嚴重度→檔案→行號排序 findings](#reviewsortfindings) |
|
||||||
| [review.appendExclusions](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/review.js#L521) | [誤判問題附加到 exclusions.json](#reviewappendexclusions) |
|
| [review.appendExclusions](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/review.js) | [誤判問題附加到 exclusions.json](#reviewappendexclusions) |
|
||||||
| [review.sortFindingsForIssue](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/review.js#L596) | [依檔案→嚴重度→行號排序（建問題模式）](#reviewsortfindingsforissue) |
|
| [review.sortFindingsForIssue](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/review.js) | [依檔案→嚴重度→行號排序（建問題模式）](#reviewsortfindingsforissue) |
|
||||||
| [review.selectLabels](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/review.js#L627) | [以 AI 從可用標籤挑選 issue 標籤](#reviewselectlabels) |
|
| [review.selectLabels](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/review.js) | [以 AI 從可用標籤挑選 issue 標籤](#reviewselectlabels) |
|
||||||
| [review.createIssueWithFindings](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/review.js#L694) | [建 issue 並逐條留言問題明細](#reviewcreateissuewithfindings) |
|
| [review.createIssueWithFindings](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/review.js) | [建 issue 並逐條留言問題明細](#reviewcreateissuewithfindings) |
|
||||||
| [review.resolveOldComments](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/review.js#L778) | [將 PR 舊留言標記為解決／過時](#reviewresolveoldcomments) |
|
| [review.resolveOldComments](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/review.js) | [將 PR 舊留言標記為解決／過時](#reviewresolveoldcomments) |
|
||||||
| [review.postSevereComments](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/review.js#L855) | [嚴重問題逐條掛行留言（含降級）](#reviewpostseverecomments) |
|
| [review.postSevereComments](https://gitea.jsc.idv.tw/node-actions/ai-code-review/src/branch/develop/src/lib/review.js) | [嚴重問題逐條掛行留言（含降級）](#reviewpostseverecomments) |
|
||||||
|
|
||||||
## 使用範例
|
## 使用範例
|
||||||
|
|
||||||
|
|||||||
+56
-28
@@ -4,7 +4,7 @@
|
|||||||
console.log('================================================');
|
console.log('================================================');
|
||||||
console.log('Action : AI Code Review');
|
console.log('Action : AI Code Review');
|
||||||
console.log('用途 : AI 多角色 code review：攻擊方找問題、防守方裁決誤報，結果留言到 PR 並保存 findings');
|
console.log('用途 : AI 多角色 code review：攻擊方找問題、防守方裁決誤報，結果留言到 PR 並保存 findings');
|
||||||
console.log('更新時間: 2026/07/17 18:49:58');
|
console.log('更新時間: 2026/07/21 17:19:15');
|
||||||
console.log('================================================');
|
console.log('================================================');
|
||||||
|
|
||||||
const fs = require('fs');
|
const fs = require('fs');
|
||||||
@@ -72,7 +72,7 @@ function saveFindings({ cwd, ctx, tool, kept, excluded }) {
|
|||||||
* 供下一回合 `main()` 步驟 1 比對辨識、直接回報結果而不重複審查。
|
* 供下一回合 `main()` 步驟 1 比對辨識、直接回報結果而不重複審查。
|
||||||
* 依 `commitAndPushFindings` 的回傳值記錄不同日誌：true＝已 commit/push；
|
* 依 `commitAndPushFindings` 的回傳值記錄不同日誌：true＝已 commit/push；
|
||||||
* false＝檔案無實際變更（空 commit 防護），記「略過 commit/push」。
|
* false＝檔案無實際變更（空 commit 防護），記「略過 commit/push」。
|
||||||
* commit/push 失敗（例如與開發者新 commit 競態）時僅記 WRN log，不拋出例外、不改變審查結果。
|
* commit/push 失敗（例如與開發者新 commit 競態）時僅記 WRN log，不拋出例外；呼叫端可依回傳值決定是否阻擋。
|
||||||
*
|
*
|
||||||
* @param {Object} params - 解構參數。
|
* @param {Object} params - 解構參數。
|
||||||
* @param {string} params.cwd - repo 根目錄（workspace）絕對路徑，git 操作在此目錄執行。
|
* @param {string} params.cwd - repo 根目錄（workspace）絕對路徑，git 操作在此目錄執行。
|
||||||
@@ -84,7 +84,7 @@ function saveFindings({ cwd, ctx, tool, kept, excluded }) {
|
|||||||
* @param {string} params.ctx.repository - `owner/repo` 形式的 repo 名稱。
|
* @param {string} params.ctx.repository - `owner/repo` 形式的 repo 名稱。
|
||||||
* @param {string[]} params.files - 要 commit 的檔案 repo 相對路徑陣列（如 findings 檔、`.gitea/ai-review/exclusions.json`）；全數無變更時只記 INF 略過。
|
* @param {string[]} params.files - 要 commit 的檔案 repo 相對路徑陣列（如 findings 檔、`.gitea/ai-review/exclusions.json`）；全數無變更時只記 INF 略過。
|
||||||
* @param {'success'|'failure'} params.result - 本回合審查結果：success＝無嚴重問題、failure＝有嚴重問題；會拼進 commit 訊息尾端。
|
* @param {'success'|'failure'} params.result - 本回合審查結果：success＝無嚴重問題、failure＝有嚴重問題；會拼進 commit 訊息尾端。
|
||||||
* @returns {void} 無回傳值；成敗僅反映在 log 上。
|
* @returns {boolean} true＝已 commit/push；false＝無變更或 commit/push 失敗。
|
||||||
* @remarks
|
* @remarks
|
||||||
* 使用情境：`main()` 於流程尾端依 `severe.length === 0 ? 'success' : 'failure'` 決定 result、
|
* 使用情境：`main()` 於流程尾端依 `severe.length === 0 ? 'success' : 'failure'` 決定 result、
|
||||||
* 依模式組出 filesToCommit（一般模式：findings 檔＋有變更時的 exclusions.json；
|
* 依模式組出 filesToCommit（一般模式：findings 檔＋有變更時的 exclusions.json；
|
||||||
@@ -107,12 +107,15 @@ function commitFindings({ cwd, ctx, files, result }) {
|
|||||||
});
|
});
|
||||||
if (committed) {
|
if (committed) {
|
||||||
log('收尾', 'INF', `審查結果檔已 commit 並 push 回 ${ctx.headRef}（結果：${result}）。`);
|
log('收尾', 'INF', `審查結果檔已 commit 並 push 回 ${ctx.headRef}（結果：${result}）。`);
|
||||||
|
return true;
|
||||||
} else {
|
} else {
|
||||||
log('收尾', 'INF', '審查結果檔無實際變更，略過 commit/push。');
|
log('收尾', 'INF', '審查結果檔無實際變更，略過 commit/push。');
|
||||||
|
return false;
|
||||||
}
|
}
|
||||||
} catch (err) {
|
} catch (err) {
|
||||||
// push 失敗（例如與開發者新 commit 競態）時只記錄，不改變審查結果。
|
// push 失敗（例如與開發者新 commit 競態）時只記錄，交由呼叫端依嚴重度決定是否阻擋。
|
||||||
log('收尾', 'WRN', `commit/push 審查結果檔失敗：${err.message}。`);
|
log('收尾', 'WRN', `commit/push 審查結果檔失敗：${err.message}。`);
|
||||||
|
return false;
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
@@ -123,15 +126,14 @@ function commitFindings({ cwd, ctx, files, result }) {
|
|||||||
* 建問題模式會把審查情境與每條 finding 發到追蹤 issue；沒有保留 finding 時不建立 issue、PR 也不留言。
|
* 建問題模式會把審查情境與每條 finding 發到追蹤 issue；沒有保留 finding 時不建立 issue、PR 也不留言。
|
||||||
* 嚴重 finding 會寫入 failure 結果 commit，警告與建議只建立追蹤資訊，不直接阻擋合併。
|
* 嚴重 finding 會寫入 failure 結果 commit，警告與建議只建立追蹤資訊，不直接阻擋合併。
|
||||||
*
|
*
|
||||||
* @returns {Promise<number>} process exit code：本輪「審查」一律回傳 0（不因嚴重問題直接讓檢查失敗——
|
* @returns {Promise<number>} process exit code：沒有嚴重問題且結果 commit 已成功推送時回傳 0；
|
||||||
* 失敗改由推出的 `[ai-review-bot][failure]` 結果 commit，於下一輪在步驟 1 讀 commit 訊息時回報）；
|
* 若步驟 1 偵測到 `[ai-review-bot][failure]`、前置條件不足，或需要推送結果檔卻未成功推送，
|
||||||
* 回傳 1 僅發生於：步驟 1 偵測到 `[ai-review-bot][failure]` 結果 commit，或前置條件不足
|
* 則回傳 1，避免 token 權限不足或遠端競態讓 workflow 靜默通過。
|
||||||
* （缺 PR 編號／token、找不到 AI 工具）等無法進行審查的情況。
|
|
||||||
* @remarks
|
* @remarks
|
||||||
* 使用情境：由本檔尾端的頂層呼叫端執行 —— `main().then((code) => process.exit(code))`；
|
* 使用情境：由本檔尾端的頂層呼叫端執行 —— `main().then((code) => process.exit(code))`；
|
||||||
* 非預期例外由頂層 `catch` 記 ERR log 後以 exit code 1 收場，且刻意不 commit 結果標記，
|
* 非預期例外由頂層 `catch` 記 ERR log 後以 exit code 1 收場，且刻意不 commit 結果標記，
|
||||||
* 讓下一次 workflow 觸發時重新完整審查。警告＋建議等級不影響結果標記，只有「嚴重」會使結果 commit
|
* 讓下一次 workflow 觸發時重新完整審查。警告＋建議等級不影響結果標記，只有「嚴重」會使結果 commit
|
||||||
* 標記為 failure；而「失敗檢查（exit 1）」只由步驟 1 讀到該 failure 結果 commit 時產生，審查本輪不直接 exit 1。
|
* 標記為 failure；若結果檔需要 push 卻失敗，本輪直接 exit 1，避免缺權限時無聲放行。
|
||||||
* 建問題模式只改變問題明細的落地方式（issue 留言取代 findings 進版控），不改變上述結果標記判定。
|
* 建問題模式只改變問題明細的落地方式（issue 留言取代 findings 進版控），不改變上述結果標記判定。
|
||||||
*/
|
*/
|
||||||
async function main() {
|
async function main() {
|
||||||
@@ -165,6 +167,7 @@ async function main() {
|
|||||||
// 建問題模式：追蹤 issue 於「確定有保留問題」後才建立；在那之前的情境留言（工具／diff／角色）
|
// 建問題模式：追蹤 issue 於「確定有保留問題」後才建立；在那之前的情境留言（工具／diff／角色）
|
||||||
// 先暫存於 pendingIssueCommentBodies，建立 issue 後一次寫入。
|
// 先暫存於 pendingIssueCommentBodies，建立 issue 後一次寫入。
|
||||||
const pendingIssueCommentBodies = [];
|
const pendingIssueCommentBodies = [];
|
||||||
|
let issueModeActive = ctx.createIssue;
|
||||||
let trackingIssue = null;
|
let trackingIssue = null;
|
||||||
/**
|
/**
|
||||||
* 發布一則審查留言。依模式決定去向：
|
* 發布一則審查留言。依模式決定去向：
|
||||||
@@ -179,7 +182,7 @@ async function main() {
|
|||||||
* 警告／建議彙整等留言。若 Gitea API 失敗，例外會往上拋出並由主流程頂層 catch 收斂。
|
* 警告／建議彙整等留言。若 Gitea API 失敗，例外會往上拋出並由主流程頂層 catch 收斂。
|
||||||
*/
|
*/
|
||||||
const queueOrPostComment = async (body) => {
|
const queueOrPostComment = async (body) => {
|
||||||
if (ctx.createIssue) {
|
if (issueModeActive) {
|
||||||
if (trackingIssue) return gitea.createCommentOnIssue(ctx, trackingIssue.number, body);
|
if (trackingIssue) return gitea.createCommentOnIssue(ctx, trackingIssue.number, body);
|
||||||
pendingIssueCommentBodies.push(body);
|
pendingIssueCommentBodies.push(body);
|
||||||
return null;
|
return null;
|
||||||
@@ -189,7 +192,7 @@ async function main() {
|
|||||||
return created;
|
return created;
|
||||||
};
|
};
|
||||||
/**
|
/**
|
||||||
* 建問題模式：建立追蹤 issue（標題＝PR 標題、本文＝PR 描述＋回溯 PR 的引言，連同挑好的標籤一次建立），
|
* 建問題模式：開啟追蹤 issue（標題＝PR 標題、本文＝PR 描述＋回溯 PR 的引言，連同挑好的標籤一次建立），
|
||||||
* 並把 `pendingIssueCommentBodies` 內暫存的情境留言依流程順序寫入 issue；
|
* 並把 `pendingIssueCommentBodies` 內暫存的情境留言依流程順序寫入 issue；
|
||||||
* 設定閉包變數 `trackingIssue` 供後續留言直接發到 issue。
|
* 設定閉包變數 `trackingIssue` 供後續留言直接發到 issue。
|
||||||
* 僅於「確定有保留問題」時呼叫一次。標籤於建立時一次帶入，省去「先建空標籤 issue 再補掛」的多餘 API 往返。
|
* 僅於「確定有保留問題」時呼叫一次。標籤於建立時一次帶入，省去「先建空標籤 issue 再補掛」的多餘 API 往返。
|
||||||
@@ -198,15 +201,30 @@ async function main() {
|
|||||||
* 空陣列或省略時不掛任何標籤（`gitea.createIssue` 對空陣列不帶 labels 欄位）。
|
* 空陣列或省略時不掛任何標籤（`gitea.createIssue` 對空陣列不帶 labels 欄位）。
|
||||||
* @returns {Promise<void>} 無回傳值；結果反映在閉包變數 `trackingIssue` 與 issue 留言。
|
* @returns {Promise<void>} 無回傳值；結果反映在閉包變數 `trackingIssue` 與 issue 留言。
|
||||||
*/
|
*/
|
||||||
const createIssueAndFlushBufferedComments = async (labelIds = []) => {
|
const openTrackingIssue = async (labelIds = []) => {
|
||||||
trackingIssue = await gitea.createIssue(ctx, {
|
trackingIssue = await gitea.createIssue(ctx, {
|
||||||
title: ctx.prTitle || `AI Code Review：PR #${ctx.prNumber}`,
|
title: ctx.prTitle || `AI Code Review：PR #${ctx.prNumber}`,
|
||||||
body: templates.issueBody({ prNumber: ctx.prNumber, prBody: ctx.prBody }),
|
body: templates.issueBody({ prNumber: ctx.prNumber, prBody: ctx.prBody }),
|
||||||
labels: labelIds,
|
labels: labelIds,
|
||||||
});
|
});
|
||||||
log('建問題', 'INF', `已建立追蹤 issue #${trackingIssue.number}，寫入 ${pendingIssueCommentBodies.length} 則情境留言。`);
|
log('建問題', 'INF', `已建立追蹤 issue #${trackingIssue.number}，寫入 ${pendingIssueCommentBodies.length} 則情境留言。`);
|
||||||
for (const body of pendingIssueCommentBodies) {
|
while (pendingIssueCommentBodies.length > 0) {
|
||||||
|
const body = pendingIssueCommentBodies[0];
|
||||||
await gitea.createCommentOnIssue(ctx, trackingIssue.number, body);
|
await gitea.createCommentOnIssue(ctx, trackingIssue.number, body);
|
||||||
|
pendingIssueCommentBodies.shift();
|
||||||
|
}
|
||||||
|
};
|
||||||
|
/**
|
||||||
|
* 建問題模式降級：追蹤 issue 無法建立或寫入時，改把已暫存的情境留言發回 PR，後續沿用一般模式。
|
||||||
|
*
|
||||||
|
* @returns {Promise<void>} 無回傳值；會關閉建問題模式並把 PR 留言 id 登錄到 `currentRunCommentIds`。
|
||||||
|
*/
|
||||||
|
const fallbackToPrComments = async () => {
|
||||||
|
issueModeActive = false;
|
||||||
|
trackingIssue = null;
|
||||||
|
for (const body of pendingIssueCommentBodies) {
|
||||||
|
const created = await gitea.createIssueComment(ctx, body);
|
||||||
|
currentRunCommentIds.add(created.id);
|
||||||
}
|
}
|
||||||
pendingIssueCommentBodies.length = 0;
|
pendingIssueCommentBodies.length = 0;
|
||||||
};
|
};
|
||||||
@@ -216,7 +234,7 @@ async function main() {
|
|||||||
// 舊結果會先被清掉卻沒有新結果。故延後到「本回合審查已成功產生結果、發布問題留言前」
|
// 舊結果會先被清掉卻沒有新結果。故延後到「本回合審查已成功產生結果、發布問題留言前」
|
||||||
// 才呼叫 review.resolveOldComments（見下方步驟 4 空變更路徑與步驟 9 前）；
|
// 才呼叫 review.resolveOldComments（見下方步驟 4 空變更路徑與步驟 9 前）；
|
||||||
// 屆時本回合的工具／diff／角色留言已登錄於 currentRunCommentIds，不會被誤標為過時。
|
// 屆時本回合的工具／diff／角色留言已登錄於 currentRunCommentIds，不會被誤標為過時。
|
||||||
// 建問題模式全程不觸碰 PR 既有留言（審查內容改發到 issue）。
|
// 建問題模式不清理 PR 既有審查內容，只在收束時標記舊追蹤 issue 連結。
|
||||||
|
|
||||||
// ── 步驟 3：偵測 AI agent 工具並留言 ──────────────────────────────────
|
// ── 步驟 3：偵測 AI agent 工具並留言 ──────────────────────────────────
|
||||||
const tool = agents.detectTool();
|
const tool = agents.detectTool();
|
||||||
@@ -248,7 +266,7 @@ async function main() {
|
|||||||
if (files.length === 0) {
|
if (files.length === 0) {
|
||||||
// 沒有可審查的變更：保存空 findings、以 success 收場。
|
// 沒有可審查的變更：保存空 findings、以 success 收場。
|
||||||
// 一般模式在 PR 留言告知；建問題模式靜默通過（不建 issue、PR 也不留言，暫存的情境留言捨棄）。
|
// 一般模式在 PR 留言告知；建問題模式靜默通過（不建 issue、PR 也不留言，暫存的情境留言捨棄）。
|
||||||
if (ctx.createIssue) {
|
if (issueModeActive) {
|
||||||
log('步驟4', 'INF', '建問題模式且無可審查變更：靜默通過（不建 issue、PR 不留言）。');
|
log('步驟4', 'INF', '建問題模式且無可審查變更：靜默通過（不建 issue、PR 不留言）。');
|
||||||
} else {
|
} else {
|
||||||
await queueOrPostComment(templates.nothingToReviewComment(ignoredCount));
|
await queueOrPostComment(templates.nothingToReviewComment(ignoredCount));
|
||||||
@@ -256,7 +274,7 @@ async function main() {
|
|||||||
await review.resolveOldComments({ ctx, gitea, currentRunCommentIds });
|
await review.resolveOldComments({ ctx, gitea, currentRunCommentIds });
|
||||||
}
|
}
|
||||||
const relativePath = saveFindings({ cwd, ctx, tool, kept: [], excluded: [] });
|
const relativePath = saveFindings({ cwd, ctx, tool, kept: [], excluded: [] });
|
||||||
if (ctx.createIssue) {
|
if (issueModeActive) {
|
||||||
// 建問題模式下 findings 不進版控，且 exclusions.json 無變更 → 沒東西可提交。
|
// 建問題模式下 findings 不進版控，且 exclusions.json 無變更 → 沒東西可提交。
|
||||||
log('收尾', 'INF', '建問題模式且無可審查變更，略過 commit/push。');
|
log('收尾', 'INF', '建問題模式且無可審查變更，略過 commit/push。');
|
||||||
} else {
|
} else {
|
||||||
@@ -299,7 +317,7 @@ async function main() {
|
|||||||
|
|
||||||
// ── 建問題模式：確定有保留問題才建立 issue，並把暫存的情境留言一次寫入；
|
// ── 建問題模式：確定有保留問題才建立 issue，並把暫存的情境留言一次寫入；
|
||||||
// 無保留問題則不建 issue、PR 也完全不留言（靜默通過，暫存的情境留言捨棄）。 ──────
|
// 無保留問題則不建 issue、PR 也完全不留言（靜默通過，暫存的情境留言捨棄）。 ──────
|
||||||
if (ctx.createIssue) {
|
if (issueModeActive) {
|
||||||
if (kept.length > 0) {
|
if (kept.length > 0) {
|
||||||
// 先依保留問題挑好標籤，於建立 issue 時一次帶入（省去「先建空標籤 issue 再補掛」的多餘 API 往返）；
|
// 先依保留問題挑好標籤，於建立 issue 時一次帶入（省去「先建空標籤 issue 再補掛」的多餘 API 往返）；
|
||||||
// 標籤挑選失敗一律降級為不掛標籤，不阻斷建 issue 流程。
|
// 標籤挑選失敗一律降級為不掛標籤，不阻斷建 issue 流程。
|
||||||
@@ -318,7 +336,12 @@ async function main() {
|
|||||||
} catch (err) {
|
} catch (err) {
|
||||||
log('建問題', 'WRN', `標籤挑選失敗（${err.message}），issue 不掛標籤。`);
|
log('建問題', 'WRN', `標籤挑選失敗（${err.message}），issue 不掛標籤。`);
|
||||||
}
|
}
|
||||||
await createIssueAndFlushBufferedComments(labelIds);
|
try {
|
||||||
|
await openTrackingIssue(labelIds);
|
||||||
|
} catch (err) {
|
||||||
|
log('建問題', 'WRN', `建立或寫入追蹤 issue 失敗（${err.message}），改用 PR 留言與 findings 檔流程。`);
|
||||||
|
await fallbackToPrComments();
|
||||||
|
}
|
||||||
} else {
|
} else {
|
||||||
// 無保留問題 → 不建 issue、PR 也不留言（靜默通過，暫存的情境留言捨棄）。
|
// 無保留問題 → 不建 issue、PR 也不留言（靜默通過，暫存的情境留言捨棄）。
|
||||||
log('建問題', 'INF', '沒有保留的問題：靜默通過（不建 issue、PR 不留言）。');
|
log('建問題', 'INF', '沒有保留的問題：靜默通過（不建 issue、PR 不留言）。');
|
||||||
@@ -329,13 +352,13 @@ async function main() {
|
|||||||
// 延後到此可避免工具偵測／diff／攻防裁決任一失敗時舊結果先被清掉卻無新結果；
|
// 延後到此可避免工具偵測／diff／攻防裁決任一失敗時舊結果先被清掉卻無新結果；
|
||||||
// 本回合的工具／diff／角色留言已登錄於 currentRunCommentIds，不會被誤標為過時；
|
// 本回合的工具／diff／角色留言已登錄於 currentRunCommentIds，不會被誤標為過時；
|
||||||
// 嚴重／其他問題留言於本步驟之後才發布，同樣不受影響。
|
// 嚴重／其他問題留言於本步驟之後才發布，同樣不受影響。
|
||||||
if (!ctx.createIssue) {
|
if (!issueModeActive) {
|
||||||
await review.resolveOldComments({ ctx, gitea, currentRunCommentIds });
|
await review.resolveOldComments({ ctx, gitea, currentRunCommentIds });
|
||||||
}
|
}
|
||||||
|
|
||||||
// ── 步驟 9：嚴重問題留言（一般模式掛在 PR 程式碼行上；建問題模式逐條發到 issue）─
|
// ── 步驟 9：嚴重問題留言（一般模式掛在 PR 程式碼行上；建問題模式逐條發到 issue）─
|
||||||
if (severe.length > 0) {
|
if (severe.length > 0) {
|
||||||
if (ctx.createIssue) {
|
if (issueModeActive && trackingIssue) {
|
||||||
await review.postSevereToIssue({ ctx, gitea, issueNumber: trackingIssue.number, severe });
|
await review.postSevereToIssue({ ctx, gitea, issueNumber: trackingIssue.number, severe });
|
||||||
} else {
|
} else {
|
||||||
await review.postSevereComments({ ctx, gitea, severe, cwd });
|
await review.postSevereComments({ ctx, gitea, severe, cwd });
|
||||||
@@ -345,7 +368,7 @@ async function main() {
|
|||||||
// ── 步驟 10：警告＋建議——一般模式彙整為單一表格留言到 PR；
|
// ── 步驟 10：警告＋建議——一般模式彙整為單一表格留言到 PR；
|
||||||
// 建問題模式逐條發到 issue，讓每條問題都能被個別回覆。 ──
|
// 建問題模式逐條發到 issue，讓每條問題都能被個別回覆。 ──
|
||||||
if (others.length > 0) {
|
if (others.length > 0) {
|
||||||
if (ctx.createIssue) {
|
if (issueModeActive && trackingIssue) {
|
||||||
await review.postOthersToIssue({ ctx, gitea, issueNumber: trackingIssue.number, others });
|
await review.postOthersToIssue({ ctx, gitea, issueNumber: trackingIssue.number, others });
|
||||||
} else {
|
} else {
|
||||||
await queueOrPostComment(templates.othersComment(others));
|
await queueOrPostComment(templates.othersComment(others));
|
||||||
@@ -354,8 +377,9 @@ async function main() {
|
|||||||
}
|
}
|
||||||
|
|
||||||
// ── 建問題模式收束：在 PR 回貼 issue 連結（雙向關聯）；僅在有嚴重問題時才讓 PR 相依於該 issue ─
|
// ── 建問題模式收束：在 PR 回貼 issue 連結（雙向關聯）；僅在有嚴重問題時才讓 PR 相依於該 issue ─
|
||||||
// 標籤已於建立 issue 時一次帶入（見上方 selectLabels → createIssueAndFlushBufferedComments），此處不再補掛。
|
// 標籤已於建立 issue 時一次帶入（見上方 selectLabels → openTrackingIssue），此處不再補掛。
|
||||||
if (ctx.createIssue && trackingIssue) {
|
if (issueModeActive && trackingIssue) {
|
||||||
|
await review.resolveOldIssueLinkComments({ ctx, gitea });
|
||||||
await gitea.createIssueComment(
|
await gitea.createIssueComment(
|
||||||
ctx,
|
ctx,
|
||||||
templates.prIssueLinkComment({
|
templates.prIssueLinkComment({
|
||||||
@@ -385,19 +409,23 @@ async function main() {
|
|||||||
// 若有嚴重問題，仍 commit findings 檔產生 [failure] 結果 commit，避免相依 API 不支援時 fail-open。
|
// 若有嚴重問題，仍 commit findings 檔產生 [failure] 結果 commit，避免相依 API 不支援時 fail-open。
|
||||||
const result = severe.length === 0 ? 'success' : 'failure';
|
const result = severe.length === 0 ? 'success' : 'failure';
|
||||||
const filesToCommit = review.resultFilesToCommit({
|
const filesToCommit = review.resultFilesToCommit({
|
||||||
createIssue: ctx.createIssue,
|
createIssue: issueModeActive,
|
||||||
severeCount: severe.length,
|
severeCount: severe.length,
|
||||||
relativePath,
|
relativePath,
|
||||||
exclusionsChanged,
|
exclusionsChanged,
|
||||||
});
|
});
|
||||||
|
let resultCommitted = false;
|
||||||
if (filesToCommit.length > 0) {
|
if (filesToCommit.length > 0) {
|
||||||
commitFindings({ cwd, ctx, files: filesToCommit, result });
|
resultCommitted = commitFindings({ cwd, ctx, files: filesToCommit, result });
|
||||||
} else {
|
} else {
|
||||||
log('收尾', 'INF', '建問題模式且 exclusions.json 無變更，略過 commit/push。');
|
log('收尾', 'INF', '建問題模式且 exclusions.json 無變更，略過 commit/push。');
|
||||||
}
|
}
|
||||||
// 本輪「審查」一律以成功收場、不直接讓檢查失敗；有嚴重問題時已推出 [failure] 結果 commit，
|
// 需要推送結果檔卻沒成功時直接失敗；這通常代表 token 權限不足、非快轉或分支保護阻擋。
|
||||||
// 由它再觸發的下一輪在步驟 1 讀 commit 訊息時才回報失敗（exit 1）。如此失敗檢查落在帶有結果
|
if (review.shouldFailMissingResultCommit({ filesToCommit, resultCommitted })) {
|
||||||
// 標記的最新 head 上，與合併判定一致。（result 僅用於上方 commit 訊息的結果標記。）
|
log('收尾', 'ERR', '審查結果檔需要 push 但未成功產生結果 commit；直接回報失敗避免缺權限時靜默通過。');
|
||||||
|
return 1;
|
||||||
|
}
|
||||||
|
// 嚴重問題已推出 [failure] 結果 commit 時，由它再觸發的下一輪在步驟 1 讀 commit 訊息回報失敗。
|
||||||
if (result === 'failure') {
|
if (result === 'failure') {
|
||||||
log('收尾', 'INF', '本輪有嚴重問題：已標記結果 commit 為 [failure]，失敗檢查由下一輪步驟 1 讀 commit 訊息回報。');
|
log('收尾', 'INF', '本輪有嚴重問題：已標記結果 commit 為 [failure]，失敗檢查由下一輪步驟 1 讀 commit 訊息回報。');
|
||||||
}
|
}
|
||||||
|
|||||||
+1
-1
@@ -38,7 +38,7 @@ const path = require('path');
|
|||||||
* - owner / repo：自 repository 拆出的擁有者與專案名，缺值時為空字串。
|
* - owner / repo：自 repository 拆出的擁有者與專案名，缺值時為空字串。
|
||||||
* - apiBase：Gitea REST API 基底網址（`<serverUrl>/api/v1`）。
|
* - apiBase：Gitea REST API 基底網址（`<serverUrl>/api/v1`）。
|
||||||
* - token：action input `token`（INPUT_TOKEN），用於 Gitea API 認證，以及 push findings/exclusions
|
* - token：action input `token`（INPUT_TOKEN），用於 Gitea API 認證，以及 push findings/exclusions
|
||||||
* commit 回 repo；建議為「能觸發 CI 的 PAT」（自動 token 推送不會再觸發 CI）。缺值時為空字串。
|
* commit 回 repo；建議為 repo 限定、最小權限且可輪替的 token。缺值時為空字串。
|
||||||
* - model：action input `model`（INPUT_MODEL，已 trim），指定 AI 模型，缺值時為空字串。
|
* - model：action input `model`（INPUT_MODEL，已 trim），指定 AI 模型，缺值時為空字串。
|
||||||
* - createIssue：action input `create-issue`（INPUT_CREATE-ISSUE），是否將問題建到
|
* - createIssue：action input `create-issue`（INPUT_CREATE-ISSUE），是否將問題建到
|
||||||
* 存取庫的問題追蹤（建問題模式）；trim + 小寫後與字串 'true' 嚴格比對，預設 false。
|
* 存取庫的問題追蹤（建問題模式）；trim + 小寫後與字串 'true' 嚴格比對，預設 false。
|
||||||
|
|||||||
+18
-7
@@ -2,8 +2,6 @@
|
|||||||
|
|
||||||
// AI CLI 失敗診斷與機密遮罩工具：供 review 流程記錄安全、限長的一行錯誤摘要。
|
// AI CLI 失敗診斷與機密遮罩工具：供 review 流程記錄安全、限長的一行錯誤摘要。
|
||||||
|
|
||||||
// 遮罩前先截去的輸入上限，避免對數 MB 失敗輸出跑整份 O(k*n) 正規掃描。
|
|
||||||
const AGENT_DIAGNOSTIC_INPUT_LIMIT = 2_000;
|
|
||||||
// 每段診斷片段（stderr／stdout）寫入日誌的字元上限。
|
// 每段診斷片段（stderr／stdout）寫入日誌的字元上限。
|
||||||
const AGENT_DIAGNOSTIC_OUTPUT_LIMIT = 500;
|
const AGENT_DIAGNOSTIC_OUTPUT_LIMIT = 500;
|
||||||
|
|
||||||
@@ -24,11 +22,27 @@ function redactSecrets(text) {
|
|||||||
.replace(/(authorization\s*[:=]\s*)(?:bearer\s+)?\S+/gi, '$1***')
|
.replace(/(authorization\s*[:=]\s*)(?:bearer\s+)?\S+/gi, '$1***')
|
||||||
.replace(/((?:api[_-]?key|token|password|secret|bearer)\s*[:=]\s*)\S+/gi, '$1***')
|
.replace(/((?:api[_-]?key|token|password|secret|bearer)\s*[:=]\s*)\S+/gi, '$1***')
|
||||||
.replace(/(https?:\/\/)[^\s/:@]+:[^\s/@]+@/gi, '$1***:***@')
|
.replace(/(https?:\/\/)[^\s/:@]+:[^\s/@]+@/gi, '$1***:***@')
|
||||||
|
.replace(/[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}/g, '***')
|
||||||
|
.replace(/\beyJ[A-Za-z0-9_-]{10,}\.[A-Za-z0-9_-]{10,}\.[A-Za-z0-9_-]{10,}\b/g, '***')
|
||||||
|
.replace(/-----BEGIN [^-]+ PRIVATE KEY-----[\s\S]*?-----END [^-]+ PRIVATE KEY-----/g, '***')
|
||||||
.replace(/\bgh[pousr]_[A-Za-z0-9]{16,}\b/g, '***')
|
.replace(/\bgh[pousr]_[A-Za-z0-9]{16,}\b/g, '***')
|
||||||
.replace(/\b[A-Za-z0-9_-]{40,}\b/g, '***')
|
.replace(/\b[A-Za-z0-9_-]{40,}\b/g, '***')
|
||||||
.trim();
|
.trim();
|
||||||
}
|
}
|
||||||
|
|
||||||
|
/**
|
||||||
|
* 將 AI CLI 失敗輸出整理成單行、遮罩且限長的診斷片段。
|
||||||
|
*
|
||||||
|
* @param {string[]} parts - 要附加診斷片段的陣列。
|
||||||
|
* @param {string} label - 診斷欄位名稱（如 stderr／stdout）。
|
||||||
|
* @param {*} value - 原始診斷輸出。
|
||||||
|
* @returns {void}
|
||||||
|
*/
|
||||||
|
function appendRedactedOutput(parts, label, value) {
|
||||||
|
const redacted = redactSecrets(String(value || '').slice(0, AGENT_DIAGNOSTIC_OUTPUT_LIMIT));
|
||||||
|
if (redacted) parts.push(`${label}：${redacted}`);
|
||||||
|
}
|
||||||
|
|
||||||
/**
|
/**
|
||||||
* 從 `runAgent` 的失敗結果組出可診斷的一行摘要：退出碼／訊號為主，原始輸出預設隱藏。
|
* 從 `runAgent` 的失敗結果組出可診斷的一行摘要：退出碼／訊號為主，原始輸出預設隱藏。
|
||||||
*
|
*
|
||||||
@@ -52,10 +66,8 @@ function agentFailureDetail(agentResult) {
|
|||||||
}
|
}
|
||||||
// 失敗輸出可能含 token 或 PII，預設不寫入長期 CI log；debug 模式才輸出遮罩後片段。
|
// 失敗輸出可能含 token 或 PII，預設不寫入長期 CI log；debug 模式才輸出遮罩後片段。
|
||||||
if (process.env.ACTIONS_STEP_DEBUG === 'true') {
|
if (process.env.ACTIONS_STEP_DEBUG === 'true') {
|
||||||
const stderr = redactSecrets(String((agentResult && agentResult.stderr) || '').slice(0, AGENT_DIAGNOSTIC_INPUT_LIMIT));
|
appendRedactedOutput(parts, 'stderr', agentResult && agentResult.stderr);
|
||||||
if (stderr) parts.push(`stderr：${stderr.slice(0, AGENT_DIAGNOSTIC_OUTPUT_LIMIT)}`);
|
appendRedactedOutput(parts, 'stdout', agentResult && agentResult.output);
|
||||||
const stdout = redactSecrets(String((agentResult && agentResult.output) || '').slice(0, AGENT_DIAGNOSTIC_INPUT_LIMIT));
|
|
||||||
if (stdout) parts.push(`stdout：${stdout.slice(0, AGENT_DIAGNOSTIC_OUTPUT_LIMIT)}`);
|
|
||||||
}
|
}
|
||||||
if (parts.length === 0) {
|
if (parts.length === 0) {
|
||||||
parts.push((err && err.message && redactSecrets(err.message)) || 'AI CLI 執行失敗（無診斷輸出）');
|
parts.push((err && err.message && redactSecrets(err.message)) || 'AI CLI 執行失敗（無診斷輸出）');
|
||||||
@@ -64,7 +76,6 @@ function agentFailureDetail(agentResult) {
|
|||||||
}
|
}
|
||||||
|
|
||||||
module.exports = {
|
module.exports = {
|
||||||
AGENT_DIAGNOSTIC_INPUT_LIMIT,
|
|
||||||
AGENT_DIAGNOSTIC_OUTPUT_LIMIT,
|
AGENT_DIAGNOSTIC_OUTPUT_LIMIT,
|
||||||
redactSecrets,
|
redactSecrets,
|
||||||
agentFailureDetail,
|
agentFailureDetail,
|
||||||
|
|||||||
@@ -0,0 +1,32 @@
|
|||||||
|
'use strict';
|
||||||
|
|
||||||
|
const { execFileSync } = require('child_process');
|
||||||
|
|
||||||
|
/**
|
||||||
|
* 驗證遠端分支名稱可安全用於 refspec 與 refs/remotes/origin/*。
|
||||||
|
*
|
||||||
|
* @param {string} refName - 使用者或事件 payload 提供的分支名稱。
|
||||||
|
* @param {string} fieldName - 錯誤訊息中的欄位名稱。
|
||||||
|
* @returns {string} 原樣回傳通過驗證的分支名稱。
|
||||||
|
* @throws {Error} 分支名稱空白、含路徑穿越，或不符合 git 分支 ref 規則時拋出。
|
||||||
|
*/
|
||||||
|
function assertSafeBranchRef(refName, fieldName) {
|
||||||
|
const value = String(refName || '').trim();
|
||||||
|
if (!value) throw new Error(`${fieldName} 不可為空。`);
|
||||||
|
if (value.includes('..') || value.startsWith('/') || value.endsWith('/') || value.includes('\\')) {
|
||||||
|
throw new Error(`${fieldName} 不是安全的分支名稱：${value}`);
|
||||||
|
}
|
||||||
|
try {
|
||||||
|
execFileSync('git', ['check-ref-format', '--branch', value], {
|
||||||
|
encoding: 'utf8',
|
||||||
|
stdio: ['ignore', 'pipe', 'pipe'],
|
||||||
|
});
|
||||||
|
} catch {
|
||||||
|
throw new Error(`${fieldName} 不是合法的 git 分支名稱：${value}`);
|
||||||
|
}
|
||||||
|
return value;
|
||||||
|
}
|
||||||
|
|
||||||
|
module.exports = {
|
||||||
|
assertSafeBranchRef,
|
||||||
|
};
|
||||||
+18
-48
@@ -1,37 +1,11 @@
|
|||||||
'use strict';
|
'use strict';
|
||||||
|
|
||||||
const { execFileSync } = require('child_process');
|
const { execFileSync } = require('child_process');
|
||||||
|
const fs = require('fs');
|
||||||
|
const { assertSafeBranchRef } = require('./gitref');
|
||||||
|
|
||||||
// git 操作工具：一律以 execFileSync 呼叫 git（不經 shell，避免注入），輸出以 UTF-8 回傳。
|
// git 操作工具：一律以 execFileSync 呼叫 git（不經 shell，避免注入），輸出以 UTF-8 回傳。
|
||||||
|
|
||||||
/**
|
|
||||||
* 驗證遠端分支名稱可安全用於 refspec 與 refs/remotes/origin/*。
|
|
||||||
*
|
|
||||||
* @param {string} refName - 使用者或事件 payload 提供的分支名稱。
|
|
||||||
* @param {string} fieldName - 錯誤訊息中的欄位名稱。
|
|
||||||
* @returns {string} 原樣回傳通過驗證的分支名稱。
|
|
||||||
* @throws {Error} 分支名稱空白、含路徑穿越，或不符合 git 分支 ref 規則時拋出。
|
|
||||||
* @remarks
|
|
||||||
* 使用情境：`resolveMergeBase` 的 `baseRef` 與 `commitAndPushFindings` 的
|
|
||||||
* `headRef` 會被組進 refspec；先驗證可避免惡意 payload 影響本地 refs 路徑。
|
|
||||||
*/
|
|
||||||
function assertSafeBranchRef(refName, fieldName) {
|
|
||||||
const value = String(refName || '').trim();
|
|
||||||
if (!value) throw new Error(`${fieldName} 不可為空。`);
|
|
||||||
if (value.includes('..') || value.startsWith('/') || value.endsWith('/') || value.includes('\\')) {
|
|
||||||
throw new Error(`${fieldName} 不是安全的分支名稱：${value}`);
|
|
||||||
}
|
|
||||||
try {
|
|
||||||
execFileSync('git', ['check-ref-format', '--branch', value], {
|
|
||||||
encoding: 'utf8',
|
|
||||||
stdio: ['ignore', 'pipe', 'pipe'],
|
|
||||||
});
|
|
||||||
} catch {
|
|
||||||
throw new Error(`${fieldName} 不是合法的 git 分支名稱：${value}`);
|
|
||||||
}
|
|
||||||
return value;
|
|
||||||
}
|
|
||||||
|
|
||||||
/**
|
/**
|
||||||
* 同步執行 git 指令並回傳原始 stdout 輸出。
|
* 同步執行 git 指令並回傳原始 stdout 輸出。
|
||||||
*
|
*
|
||||||
@@ -91,6 +65,15 @@ function tryGit(cwd, ...args) {
|
|||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
|
function isShallowRepository(cwd) {
|
||||||
|
try {
|
||||||
|
const shallowPath = gitTrim(cwd, 'rev-parse', '--git-path', 'shallow');
|
||||||
|
return fs.existsSync(shallowPath);
|
||||||
|
} catch {
|
||||||
|
return false;
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
/**
|
/**
|
||||||
* 取得目前 HEAD 最新一筆 commit 的訊息標題（commit message 第一行）。
|
* 取得目前 HEAD 最新一筆 commit 的訊息標題（commit message 第一行）。
|
||||||
*
|
*
|
||||||
@@ -169,7 +152,7 @@ function resolveMergeBase(cwd, baseRef) {
|
|||||||
['deepen base', 'fetch', '--no-tags', '--deepen=1000', 'origin', `+refs/heads/${baseRef}:refs/remotes/${remoteBase}`],
|
['deepen base', 'fetch', '--no-tags', '--deepen=1000', 'origin', `+refs/heads/${baseRef}:refs/remotes/${remoteBase}`],
|
||||||
['deepen PR HEAD', 'fetch', '--no-tags', '--deepen=1000', 'origin', headSha],
|
['deepen PR HEAD', 'fetch', '--no-tags', '--deepen=1000', 'origin', headSha],
|
||||||
];
|
];
|
||||||
if (gitTrim(cwd, 'rev-parse', '--is-shallow-repository') === 'true') {
|
if (isShallowRepository(cwd)) {
|
||||||
strategies.push(['unshallow', 'fetch', '--no-tags', '--unshallow', 'origin']);
|
strategies.push(['unshallow', 'fetch', '--no-tags', '--unshallow', 'origin']);
|
||||||
}
|
}
|
||||||
|
|
||||||
@@ -264,7 +247,7 @@ function fileLastUpdatedIso(cwd, file) {
|
|||||||
* @param {string} [options.headSha] - PR head 的 commit SHA；有提供且與目前 HEAD 不同時會先 detach 到此 commit。可省略（falsy 時不 detach，直接於目前 HEAD 上 commit）。
|
* @param {string} [options.headSha] - PR head 的 commit SHA；有提供且與目前 HEAD 不同時會先 detach 到此 commit。可省略（falsy 時不 detach，直接於目前 HEAD 上 commit）。
|
||||||
* @param {string} options.message - commit 訊息。
|
* @param {string} options.message - commit 訊息。
|
||||||
* @param {string[]} options.files - 要加入 commit 的檔案路徑清單（相對 repo 根目錄）；全數無實際變更時不 commit、回傳 false。
|
* @param {string[]} options.files - 要加入 commit 的檔案路徑清單（相對 repo 根目錄）；全數無實際變更時不 commit、回傳 false。
|
||||||
* @param {string} options.token - 具該 repo push 權限的 Gitea access token（建議為能觸發 CI 的 PAT）；用於 findings commit 的認證推送。
|
* @param {string} options.token - 具該 repo push 權限的 Gitea access token（建議 repo 限定、最小權限且可輪替）；用於 findings commit 的認證推送。
|
||||||
* @param {string} options.serverUrl - Gitea 伺服器根網址（例如 https://gitea.example.com），須為合法 URL。
|
* @param {string} options.serverUrl - Gitea 伺服器根網址（例如 https://gitea.example.com），須為合法 URL。
|
||||||
* @param {string} options.repository - repo 完整名稱（owner/repo 格式），與 serverUrl 組成 clone URL。
|
* @param {string} options.repository - repo 完整名稱（owner/repo 格式），與 serverUrl 組成 clone URL。
|
||||||
* @returns {boolean} true＝有變更且已 commit 並 push 到來源分支；false＝暫存區與 HEAD 無差異，略過 commit/push。
|
* @returns {boolean} true＝有變更且已 commit 並 push 到來源分支；false＝暫存區與 HEAD 無差異，略過 commit/push。
|
||||||
@@ -300,8 +283,7 @@ function commitAndPushFindings(cwd, { headRef, headSha, message, files, token, s
|
|||||||
);
|
);
|
||||||
const refspec = `HEAD:refs/heads/${headRef}`;
|
const refspec = `HEAD:refs/heads/${headRef}`;
|
||||||
const remoteUrl = `${serverUrl}/${repository}.git`;
|
const remoteUrl = `${serverUrl}/${repository}.git`;
|
||||||
// 一律以 token 的身分明確認證推送（不走 origin 的自動 token）——只要 token 是能觸發 CI 的 PAT，
|
// 一律以 token 的身分明確認證推送，不沿用 origin 的自動 token。
|
||||||
// 結果 commit 就會讓 PR 的 synchronize 事件再觸發 CI，由步驟 1 快速回報把結果蓋到新 head。
|
|
||||||
pushWithCredential(cwd, remoteUrl, token, refspec, serverUrl);
|
pushWithCredential(cwd, remoteUrl, token, refspec, serverUrl);
|
||||||
return true;
|
return true;
|
||||||
}
|
}
|
||||||
@@ -309,18 +291,9 @@ function commitAndPushFindings(cwd, { headRef, headSha, message, files, token, s
|
|||||||
/**
|
/**
|
||||||
* 以帶認證的方式推送到指定遠端，認證資訊只經環境變數傳入、不進命令列 argv。
|
* 以帶認證的方式推送到指定遠端，認證資訊只經環境變數傳入、不進命令列 argv。
|
||||||
*
|
*
|
||||||
* 認證方式：等同 `https://ai-review-bot:<secret>@host/...` 的 HTTP Basic（git 會把
|
* 以 `GIT_CONFIG_*` 注入本次 HTTP Basic extraheader，避免憑證出現在 argv；
|
||||||
* URL 帳密轉成相同的 `Authorization: Basic` 標頭送出），但改以 git 的
|
* 同時先清空 checkout 持久化的自動 token extraheader，確保本次 push 使用呼叫端 token。
|
||||||
* `GIT_CONFIG_*` 環境變數注入 `http.<serverUrl>/.extraheader`，使 base64 憑證**不出現在 argv**
|
* 推送失敗時改拋固定訊息，避免原始例外帶出遠端 URL 或認證資訊。
|
||||||
* （避免程序清單／例外回顯洩漏）；推送目標 URL 亦不含帳密。
|
|
||||||
*
|
|
||||||
* 觸發 CI 關鍵：`actions/checkout` 會把「自動 Actions token」持久化在同一個
|
|
||||||
* `http.<serverUrl>/.extraheader` scope；若沿用它推送，Gitea 會視為「自動 token 觸發」而
|
|
||||||
* **不再觸發 workflow**（防遞迴）。故本函式對這次 push 於該 scope**先以空值重置**（清掉自動
|
|
||||||
* token——git 對 extraHeader 給空值即清空既有清單），**再注入 PAT 的 Authorization**，讓推送以
|
|
||||||
* PAT 身分進行、觸發 PR 的 synchronize；作用範圍僅限本次 push 的環境變數，不影響 action 其他
|
|
||||||
* 仰賴 checkout 持久化憑證的 fetch（如 {@link resolveMergeBase}）。
|
|
||||||
* 推送失敗時**不重拋原始例外**（其 message 會含命令列與遠端 URL），改拋固定訊息。
|
|
||||||
*
|
*
|
||||||
* @param {string} cwd - git 工作目錄（repo 的 checkout 路徑）。
|
* @param {string} cwd - git 工作目錄（repo 的 checkout 路徑）。
|
||||||
* @param {string} remoteUrl - 不含帳密的遠端 URL（形如 `https://host/owner/repo.git`）。
|
* @param {string} remoteUrl - 不含帳密的遠端 URL（形如 `https://host/owner/repo.git`）。
|
||||||
@@ -348,7 +321,7 @@ function pushWithCredential(cwd, remoteUrl, token, refspec, serverUrl) {
|
|||||||
env: {
|
env: {
|
||||||
...process.env,
|
...process.env,
|
||||||
GIT_TERMINAL_PROMPT: '0',
|
GIT_TERMINAL_PROMPT: '0',
|
||||||
// 兩筆同 scope 設定：先空值清掉 checkout 的自動 token，再注入 PAT 的 Authorization。
|
// 先清空 checkout extraheader，再注入本次 PAT header。
|
||||||
GIT_CONFIG_COUNT: '2',
|
GIT_CONFIG_COUNT: '2',
|
||||||
GIT_CONFIG_KEY_0: headerScope,
|
GIT_CONFIG_KEY_0: headerScope,
|
||||||
GIT_CONFIG_VALUE_0: '',
|
GIT_CONFIG_VALUE_0: '',
|
||||||
@@ -368,7 +341,4 @@ module.exports = {
|
|||||||
fileDiff,
|
fileDiff,
|
||||||
fileLastUpdatedIso,
|
fileLastUpdatedIso,
|
||||||
commitAndPushFindings,
|
commitAndPushFindings,
|
||||||
__test: {
|
|
||||||
assertSafeBranchRef,
|
|
||||||
},
|
|
||||||
};
|
};
|
||||||
|
|||||||
@@ -579,6 +579,18 @@ function resultFilesToCommit({ createIssue, severeCount, relativePath, exclusion
|
|||||||
return files;
|
return files;
|
||||||
}
|
}
|
||||||
|
|
||||||
|
/**
|
||||||
|
* 判斷本輪是否因結果 commit 未成功推送而必須失敗。
|
||||||
|
*
|
||||||
|
* @param {Object} params - 解構參數。
|
||||||
|
* @param {string[]} params.filesToCommit - 本輪預期寫回遠端分支的結果檔清單。
|
||||||
|
* @param {boolean} params.resultCommitted - 結果檔是否已成功 commit 並 push。
|
||||||
|
* @returns {boolean} 需要寫回結果檔卻沒有成功推送時回傳 true。
|
||||||
|
*/
|
||||||
|
function shouldFailMissingResultCommit({ filesToCommit, resultCommitted }) {
|
||||||
|
return filesToCommit.length > 0 && !resultCommitted;
|
||||||
|
}
|
||||||
|
|
||||||
/**
|
/**
|
||||||
* 就地排序 findings：依 嚴重→警告→建議、再依檔案路徑、再依起始行遞增。
|
* 就地排序 findings：依 嚴重→警告→建議、再依檔案路徑、再依起始行遞增。
|
||||||
*
|
*
|
||||||
@@ -832,6 +844,40 @@ async function resolveOldComments({ ctx, gitea, currentRunCommentIds }) {
|
|||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
|
/**
|
||||||
|
* 建問題模式：只將 PR 上舊的「追蹤問題連結」留言標註為過時，不觸碰 issue 內審查內容。
|
||||||
|
*
|
||||||
|
* @param {Object} params - 解構參數。
|
||||||
|
* @param {Object} params.ctx - 執行環境 context（`loadContext()` 產出）。
|
||||||
|
* @param {Object} params.gitea - Gitea API 模組，需提供 `whoAmI`、`listIssueComments`、`editIssueComment`。
|
||||||
|
* @returns {Promise<void>} 無回傳值；失敗時只記 WRN，不阻斷主流程。
|
||||||
|
*/
|
||||||
|
async function resolveOldIssueLinkComments({ ctx, gitea }) {
|
||||||
|
let botLogin = '';
|
||||||
|
try {
|
||||||
|
botLogin = (await gitea.whoAmI(ctx)).login || '';
|
||||||
|
} catch (err) {
|
||||||
|
log('建問題', 'WRN', `無法取得 bot 身分（${err.message}），略過舊追蹤連結標註。`);
|
||||||
|
return;
|
||||||
|
}
|
||||||
|
|
||||||
|
try {
|
||||||
|
const comments = await gitea.listIssueComments(ctx);
|
||||||
|
let outdatedCount = 0;
|
||||||
|
for (const comment of comments) {
|
||||||
|
const isBot = comment.user && comment.user.login === botLogin;
|
||||||
|
const body = typeof comment.body === 'string' ? comment.body : '';
|
||||||
|
const isIssueLink = body.includes(templates.MARK) && body.includes('## 🔍 AI Code Review｜已建立追蹤問題');
|
||||||
|
if (!isBot || !isIssueLink || body.startsWith(templates.OUTDATED_PREFIX)) continue;
|
||||||
|
await gitea.editIssueComment(ctx, comment.id, `${templates.OUTDATED_PREFIX}${body}`);
|
||||||
|
outdatedCount += 1;
|
||||||
|
}
|
||||||
|
log('建問題', 'INF', `舊追蹤 issue 連結已標註〔已過時〕：${outdatedCount} 則。`);
|
||||||
|
} catch (err) {
|
||||||
|
log('建問題', 'WRN', `標註舊追蹤 issue 連結失敗：${err.message}。`);
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
/**
|
/**
|
||||||
* 步驟 9：嚴重問題逐條掛在 PR 程式碼行上留言（建立 code review）；
|
* 步驟 9：嚴重問題逐條掛在 PR 程式碼行上留言（建立 code review）；
|
||||||
* 建立 review 失敗時降級為一般留言逐條發布（留言內補上檔案與行號位置）。
|
* 建立 review 失敗時降級為一般留言逐條發布（留言內補上檔案與行號位置）。
|
||||||
@@ -880,9 +926,11 @@ module.exports = {
|
|||||||
sortFindings,
|
sortFindings,
|
||||||
appendExclusions,
|
appendExclusions,
|
||||||
resultFilesToCommit,
|
resultFilesToCommit,
|
||||||
|
shouldFailMissingResultCommit,
|
||||||
selectLabels,
|
selectLabels,
|
||||||
postSevereToIssue,
|
postSevereToIssue,
|
||||||
postOthersToIssue,
|
postOthersToIssue,
|
||||||
resolveOldComments,
|
resolveOldComments,
|
||||||
|
resolveOldIssueLinkComments,
|
||||||
postSevereComments,
|
postSevereComments,
|
||||||
};
|
};
|
||||||
|
|||||||
+30
-2
@@ -4,18 +4,46 @@ const assert = require('node:assert/strict');
|
|||||||
const test = require('node:test');
|
const test = require('node:test');
|
||||||
|
|
||||||
const gitrepo = require('../src/lib/gitrepo');
|
const gitrepo = require('../src/lib/gitrepo');
|
||||||
|
const gitref = require('../src/lib/gitref');
|
||||||
|
|
||||||
test('assertSafeBranchRef 接受一般分支名稱', () => {
|
test('assertSafeBranchRef 接受一般分支名稱', () => {
|
||||||
assert.equal(gitrepo.__test.assertSafeBranchRef('feature/review-123', 'baseRef'), 'feature/review-123');
|
assert.equal(gitref.assertSafeBranchRef('feature/review-123', 'baseRef'), 'feature/review-123');
|
||||||
});
|
});
|
||||||
|
|
||||||
test('assertSafeBranchRef 拒絕路徑穿越分支名稱', () => {
|
test('assertSafeBranchRef 拒絕路徑穿越分支名稱', () => {
|
||||||
assert.throws(
|
assert.throws(
|
||||||
() => gitrepo.__test.assertSafeBranchRef('../../hooks/pre-push', 'baseRef'),
|
() => gitref.assertSafeBranchRef('../../hooks/pre-push', 'baseRef'),
|
||||||
/不是安全的分支名稱/,
|
/不是安全的分支名稱/,
|
||||||
);
|
);
|
||||||
});
|
});
|
||||||
|
|
||||||
|
test('assertSafeBranchRef 拒絕空白分支名稱', () => {
|
||||||
|
for (const value of ['', ' ', null, undefined]) {
|
||||||
|
assert.throws(
|
||||||
|
() => gitref.assertSafeBranchRef(value, 'baseRef'),
|
||||||
|
/baseRef 不可為空/,
|
||||||
|
);
|
||||||
|
}
|
||||||
|
});
|
||||||
|
|
||||||
|
test('assertSafeBranchRef 拒絕不安全的 refspec 分支名稱', () => {
|
||||||
|
for (const value of ['/feature', 'feature/', 'feature\\x', 'feature..x']) {
|
||||||
|
assert.throws(
|
||||||
|
() => gitref.assertSafeBranchRef(value, 'baseRef'),
|
||||||
|
/不是安全的分支名稱/,
|
||||||
|
);
|
||||||
|
}
|
||||||
|
});
|
||||||
|
|
||||||
|
test('assertSafeBranchRef 拒絕 git 不合法的分支名稱', () => {
|
||||||
|
for (const value of ['feature.lock', 'feature@{x}', 'feature~x', 'feature^x']) {
|
||||||
|
assert.throws(
|
||||||
|
() => gitref.assertSafeBranchRef(value, 'baseRef'),
|
||||||
|
/不是合法的 git 分支名稱/,
|
||||||
|
);
|
||||||
|
}
|
||||||
|
});
|
||||||
|
|
||||||
test('resolveMergeBase 會在 git fetch 前拒絕不安全 baseRef', () => {
|
test('resolveMergeBase 會在 git fetch 前拒絕不安全 baseRef', () => {
|
||||||
assert.throws(
|
assert.throws(
|
||||||
() => gitrepo.resolveMergeBase(process.cwd(), '../../hooks/pre-push'),
|
() => gitrepo.resolveMergeBase(process.cwd(), '../../hooks/pre-push'),
|
||||||
|
|||||||
@@ -44,6 +44,25 @@ test('agentFailureDetail 在 debug 模式輸出遮罩後片段', () => {
|
|||||||
}
|
}
|
||||||
});
|
});
|
||||||
|
|
||||||
|
test('agentFailureDetail 先限長再遮罩並處理常見 PII', () => {
|
||||||
|
const oldDebug = process.env.ACTIONS_STEP_DEBUG;
|
||||||
|
process.env.ACTIONS_STEP_DEBUG = 'true';
|
||||||
|
try {
|
||||||
|
const detail = diagnostics.agentFailureDetail({
|
||||||
|
ok: false,
|
||||||
|
error: Object.assign(new Error('boom'), { code: 3 }),
|
||||||
|
stderr: `${'x'.repeat(520)} token=should-not-be-scanned`,
|
||||||
|
output: 'user@example.test eyJaaaaaaaaaa.bbbbbbbbbb.cccccccccc',
|
||||||
|
});
|
||||||
|
assert.match(detail, /exit 3/);
|
||||||
|
assert.doesNotMatch(detail, /should-not-be-scanned|user@example.test|eyJaaaaaaaaaa/);
|
||||||
|
assert.match(detail, /stdout：\*\*\* \*\*\*/);
|
||||||
|
} finally {
|
||||||
|
if (oldDebug === undefined) delete process.env.ACTIONS_STEP_DEBUG;
|
||||||
|
else process.env.ACTIONS_STEP_DEBUG = oldDebug;
|
||||||
|
}
|
||||||
|
});
|
||||||
|
|
||||||
test('postOthersToIssue 依序送出 issue 留言以維持排序', async () => {
|
test('postOthersToIssue 依序送出 issue 留言以維持排序', async () => {
|
||||||
const calls = [];
|
const calls = [];
|
||||||
let active = 0;
|
let active = 0;
|
||||||
@@ -97,3 +116,64 @@ test('resultFilesToCommit 在建問題模式無嚴重問題時只提交 exclusio
|
|||||||
['.gitea/ai-review/exclusions.json'],
|
['.gitea/ai-review/exclusions.json'],
|
||||||
);
|
);
|
||||||
});
|
});
|
||||||
|
|
||||||
|
test('shouldFailMissingResultCommit 在結果檔需要 push 但未成功時回報失敗', () => {
|
||||||
|
assert.equal(
|
||||||
|
review.shouldFailMissingResultCommit({
|
||||||
|
filesToCommit: ['.gitea/ai-review/findings/run.json'],
|
||||||
|
resultCommitted: false,
|
||||||
|
}),
|
||||||
|
true,
|
||||||
|
);
|
||||||
|
assert.equal(
|
||||||
|
review.shouldFailMissingResultCommit({
|
||||||
|
filesToCommit: ['.gitea/ai-review/findings/run.json'],
|
||||||
|
resultCommitted: true,
|
||||||
|
}),
|
||||||
|
false,
|
||||||
|
);
|
||||||
|
assert.equal(
|
||||||
|
review.shouldFailMissingResultCommit({
|
||||||
|
filesToCommit: [],
|
||||||
|
resultCommitted: false,
|
||||||
|
}),
|
||||||
|
false,
|
||||||
|
);
|
||||||
|
});
|
||||||
|
|
||||||
|
test('resolveOldIssueLinkComments 只標註舊追蹤 issue 連結', async () => {
|
||||||
|
const edited = [];
|
||||||
|
const fakeGitea = {
|
||||||
|
async whoAmI() {
|
||||||
|
return { login: 'bot' };
|
||||||
|
},
|
||||||
|
async listIssueComments() {
|
||||||
|
return [
|
||||||
|
{
|
||||||
|
id: 1,
|
||||||
|
user: { login: 'bot' },
|
||||||
|
body: '<!-- ai-code-review -->\n## 🔍 AI Code Review｜已建立追蹤問題\nold',
|
||||||
|
},
|
||||||
|
{
|
||||||
|
id: 2,
|
||||||
|
user: { login: 'bot' },
|
||||||
|
body: '<!-- ai-code-review -->\n## 📋 變更摘要（送審 git diff）\nkeep',
|
||||||
|
},
|
||||||
|
{
|
||||||
|
id: 3,
|
||||||
|
user: { login: 'someone' },
|
||||||
|
body: '<!-- ai-code-review -->\n## 🔍 AI Code Review｜已建立追蹤問題\nkeep',
|
||||||
|
},
|
||||||
|
];
|
||||||
|
},
|
||||||
|
async editIssueComment(ctx, commentId, body) {
|
||||||
|
edited.push({ ctx, commentId, body });
|
||||||
|
},
|
||||||
|
};
|
||||||
|
|
||||||
|
await review.resolveOldIssueLinkComments({ ctx: { token: 'hidden' }, gitea: fakeGitea });
|
||||||
|
|
||||||
|
assert.equal(edited.length, 1);
|
||||||
|
assert.equal(edited[0].commentId, 1);
|
||||||
|
assert.match(edited[0].body, /^> 〔已過時〕/);
|
||||||
|
});
|
||||||
|
|||||||
Reference in New Issue
Block a user