fix(diagnostics): 處理 ai review findings #32
@@ -2187,5 +2187,170 @@
|
||||
"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",
|
||||
"model": "（工具預設）"
|
||||
},
|
||||
"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": ""
|
||||
}
|
||||
],
|
||||
"findings": [],
|
||||
"excluded": []
|
||||
}
|
||||
|
||||
@@ -7,59 +7,6 @@
|
||||
"version": "0.0.8",
|
||||
"model": "（工具預設）"
|
||||
},
|
||||
"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": ""
|
||||
}
|
||||
],
|
||||
"findings": [],
|
||||
"excluded": []
|
||||
}
|
||||
|
||||
@@ -7,59 +7,6 @@
|
||||
"version": "0.0.8",
|
||||
"model": "（工具預設）"
|
||||
},
|
||||
"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": "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({ /* ... */ }));"
|
||||
}
|
||||
],
|
||||
"findings": [],
|
||||
"excluded": []
|
||||
}
|
||||
|
||||
@@ -7,33 +7,6 @@
|
||||
"version": "0.0.8",
|
||||
"model": "（工具預設）"
|
||||
},
|
||||
"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": ""
|
||||
}
|
||||
],
|
||||
"findings": [],
|
||||
"excluded": []
|
||||
}
|
||||
|
||||
@@ -7,203 +7,6 @@
|
||||
"version": "0.0.9",
|
||||
"model": "（工具預設）"
|
||||
},
|
||||
"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
|
||||
}
|
||||
],
|
||||
"findings": [],
|
||||
"excluded": []
|
||||
}
|
||||
|
||||
@@ -7,27 +7,7 @@
|
||||
"version": "codex-cli 0.144.6",
|
||||
"model": "gpt-5.5"
|
||||
},
|
||||
"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 缺測試與診斷不足，本條指向函式內策略編排、診斷組裝與錯誤包裝混雜的可維護性問題，未被既有排除事項完整涵蓋。"
|
||||
}
|
||||
}
|
||||
}
|
||||
],
|
||||
"findings": [],
|
||||
"excluded": [
|
||||
{
|
||||
"reviewer": "Bard",
|
||||
|
||||
Reference in New Issue
Block a user