281 lines
17 KiB
JSON
281 lines
17 KiB
JSON
{
|
||
"generatedAt": "2026/07/21 14:42:39",
|
||
"commitSha": "d424447d1502f49538fcb3093d23b5ac7bfa16c5",
|
||
"prNumber": 6,
|
||
"tool": {
|
||
"name": "codex",
|
||
"version": "codex-cli 0.144.6",
|
||
"model": "gpt-5.5"
|
||
},
|
||
"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": [
|
||
{
|
||
"reviewer": "Bard",
|
||
"focus": "style",
|
||
"badge": "🎼",
|
||
"severity": "建議",
|
||
"file": "src/index.js",
|
||
"startLine": 179,
|
||
"endLine": 212,
|
||
"problem": "`queueOrPostComment` 與 `createIssueAndFlushBufferedComments` 這兩個閉包名稱像兩段不同旋律：一個強調「排隊或發布」，另一個卻把「建立 issue、flush 暫存留言、設定狀態」全塞進名稱與實作。讀者要來回追 `trackingIssue`、`pendingIssueCommentBodies`，節奏偏長且語意負擔重。",
|
||
"suggestion": "建議統一命名語彙，例如把「暫存／發布」集中成 `postReviewComment`、`flushPendingIssueComments`，讓函式名稱只描述一件事；建立 issue 與 flush 留言也可拆成兩段，讀起來會更像樂句而不是長句。",
|
||
"suggestedCode": "",
|
||
"id": "F002",
|
||
"verdicts": {
|
||
"Paladin": {
|
||
"exclude": true,
|
||
"reason": "可排除（重複）。歷史 finding 已指出 main() 內新增閉包與 issue/comment 路由細節讓主流程閱讀負擔加重；本條只是改以目前函式名稱描述同一維護性問題。"
|
||
}
|
||
}
|
||
},
|
||
{
|
||
"reviewer": "Leo",
|
||
"focus": "maintainability",
|
||
"badge": "🧰",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 165,
|
||
"endLine": 213,
|
||
"problem": "`main()` 這次把「留言目的地切換、issue 建立、暫存留言 flush、標籤挑選前置狀態」都塞進閉包與可變狀態（`pendingIssueCommentBodies`、`trackingIssue`、`currentRunCommentIds`）。半年後要改建問題模式時，維護者得同時追蹤主流程步驟、閉包副作用與留言落點，任何新增留言點都可能忘記處理 queue/flush 或 PR 排除清單，長期會讓流程編排變得很脆弱。",
|
||
"suggestion": "把留言目的地抽成明確的小型物件或模組，例如 `ReviewCommentSink` / `IssueCommentSink`，由它負責 `post()`、`flush()`、`currentRunCommentIds`。`main()` 只保留流程順序，不直接管理留言暫存與 issue 狀態。",
|
||
"suggestedCode": "",
|
||
"id": "F006",
|
||
"verdicts": {
|
||
"Paladin": {
|
||
"exclude": true,
|
||
"reason": "可排除（命中已知排除事項且重複）。已知與歷史 findings 已涵蓋 main() 內留言目的地、issue 狀態、緩衝佇列與可變閉包耦合，及應抽出發布器／sink 的方向。"
|
||
}
|
||
}
|
||
},
|
||
{
|
||
"reviewer": "Leo",
|
||
"focus": "maintainability",
|
||
"badge": "🧰",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 302,
|
||
"endLine": 353,
|
||
"problem": "建問題模式的收束邏輯把「挑標籤、建立 issue、發 finding、回貼 PR、設定 issue dependency、決定是否阻擋合併」全部展開在 `main()`。這段和前面的 `createIssueAndFlushBufferedComments` 共同組成一條隱性的 issue workflow，但邊界沒有被封裝；未來要新增 issue 模板、改排序、改阻擋條件或重試策略時，會在主流程裡到處補條件，維護成本會快速上升。",
|
||
"suggestion": "把建問題模式整理成單一高階函式，例如 `review.publishIssueModeResults({ ctx, gitea, tool, model, cwd, kept, severe, others, bufferedComments })`，主流程只接收 `trackingIssue` / `filesToCommit` 等結果。這樣 PR 模式與 issue 模式的責任邊界會清楚很多。",
|
||
"suggestedCode": "",
|
||
"id": "F007",
|
||
"verdicts": {
|
||
"Paladin": {
|
||
"exclude": true,
|
||
"reason": "可排除（重複）。此條與 F006 及歷史 findings 同樣指向建問題模式在 main() 中承擔 issue workflow、發布分流與狀態管理，屬同一維護性問題的延伸描述。"
|
||
}
|
||
}
|
||
},
|
||
{
|
||
"reviewer": "Leo",
|
||
"focus": "maintainability",
|
||
"badge": "🧰",
|
||
"severity": "建議",
|
||
"file": "readme.md",
|
||
"startLine": 56,
|
||
"endLine": 132,
|
||
"problem": "README 內大量維護到原始碼行號的連結，這次 diff 只是分支與行號位移就需要同步改一整片表格。這種文件和程式碼行號的硬耦合很容易在後續修改時過期，讀者點到錯誤位置，維護者也要花時間做機械式同步。",
|
||
"suggestion": "若這份表格是 API 索引，建議改成自動產生，或至少移除 `#Lxx` 行號錨點，改連到檔案或穩定章節錨點。讓文件描述 API，而不是跟著每次程式碼行號漂移。",
|
||
"suggestedCode": "",
|
||
"id": "F008",
|
||
"verdicts": {
|
||
"Paladin": {
|
||
"exclude": true,
|
||
"reason": "可排除（重複）。歷史 findings 已多次指出 README 功能表硬編分支與行號連結，導致文件與原始碼高度耦合且容易失準。"
|
||
}
|
||
}
|
||
},
|
||
{
|
||
"reviewer": "Mage",
|
||
"focus": "logic",
|
||
"badge": "🔮",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 251,
|
||
"endLine": 253,
|
||
"problem": "無可審查變更的分支在一般模式下會先把舊留言標為過時，之後才保存 findings 與 commit/push 結果。最小重現：`files.length === 0`、`nothingToReviewComment` 成功、`resolveOldComments` 成功，但接著 `saveFindings` 因檔案系統錯誤或 `commitFindings` 因 push 失敗拋例外。此時舊審查結果已被標過時，但沒有成功落地本回合的 success 結果 commit，狀態會停在半更新。",
|
||
"suggestion": "把 `review.resolveOldComments` 延後到 `saveFindings` 與必要的 `commitFindings` 成功之後；或至少在空變更路徑也遵守同一個交易順序：先產生並提交本回合結果，再清理舊留言。",
|
||
"suggestedCode": "",
|
||
"id": "F010",
|
||
"verdicts": {
|
||
"Paladin": {
|
||
"exclude": true,
|
||
"reason": "可排除（命中已知排除事項）。維護者已裁示舊留言應刻意在本回合結果發布前標為過時；本條要求延後清理，落在同一已排除範圍。"
|
||
}
|
||
}
|
||
},
|
||
{
|
||
"reviewer": "Maya",
|
||
"focus": "testing",
|
||
"badge": "🧪",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 160,
|
||
"endLine": 353,
|
||
"problem": "建問題模式的主流程被大幅改寫，但目前測試只驗證了少數 helper，沒有驗證「留言先暫存、確定有 kept finding 才建 issue、無保留問題時靜默通過、嚴重問題才加 issue dependency、最後回貼 PR 連結」這些新增流程。這些行為一旦順序或條件寫錯，測試不會擋下來。",
|
||
"suggestion": "請補 `main()` 層級的流程測試，stub `agents`、`review`、`gitea`、`gitrepo`，至少覆蓋：`createIssue=true && kept=[]` 不建立 issue/不貼 PR 留言；`kept` 只有警告/建議時建立 issue、flush 暫存留言、回貼 PR 連結但不呼叫 `addIssueDependency`；`kept` 含嚴重時呼叫 `addIssueDependency`，且 dependency 失敗時流程仍完成並 commit failure findings。",
|
||
"suggestedCode": "",
|
||
"id": "F011",
|
||
"verdicts": {
|
||
"Paladin": {
|
||
"exclude": true,
|
||
"reason": "可排除（重複）。歷史 findings 已涵蓋建問題模式 main() 層級流程缺測試，包括暫存留言、有 finding 才建 issue、無 finding 靜默、PR 回貼、嚴重與非嚴重分流及 dependency 失敗降級。"
|
||
}
|
||
}
|
||
},
|
||
{
|
||
"reviewer": "Maya",
|
||
"focus": "testing",
|
||
"badge": "🧪",
|
||
"severity": "警告",
|
||
"file": "src/lib/gitrepo.js",
|
||
"startLine": 307,
|
||
"endLine": 361,
|
||
"problem": "`pushWithCredential` 新增了關鍵認證行為，但沒有測試驗證它真的用 `GIT_CONFIG_*` 清掉 checkout 的 extraheader、再注入 PAT Authorization，也沒有測試遠端 URL 不符與 push 失敗時不洩漏 URL/token 的失敗路徑。這段是結果 commit 能否觸發下一輪 CI 的核心，沒有測試等於這個新契約還沒通過試煉。",
|
||
"suggestion": "請補推送行為測試。可用可注入的 exec wrapper 或子程序測試方式驗證：`git push` argv 不含 token、env 包含兩筆同 scope extraheader、`GIT_CONFIG_VALUE_0` 為空值、`GIT_CONFIG_VALUE_1` 為 Basic header；再補 `remote.origin !== server.origin` 與 exec 失敗時錯誤訊息不含 token/remoteUrl 的案例。",
|
||
"suggestedCode": "",
|
||
"id": "F012",
|
||
"verdicts": {
|
||
"Paladin": {
|
||
"exclude": true,
|
||
"reason": "可排除（重複）。歷史 findings 已記錄 pushWithCredential／pushToken 認證推送路徑缺少測試，包含 token 不進 argv、認證遮蔽、推送目標與失敗訊息不洩漏敏感資訊。"
|
||
}
|
||
}
|
||
},
|
||
{
|
||
"reviewer": "Maya",
|
||
"focus": "testing",
|
||
"badge": "🧪",
|
||
"severity": "警告",
|
||
"file": "src/lib/gitrepo.js",
|
||
"startLine": 130,
|
||
"endLine": 192,
|
||
"problem": "`resolveMergeBase` 新增多段 fetch fallback：先抓 base、再 deepen base、deepen PR HEAD、最後 shallow repo 才 unshallow，但現有測試只驗證不安全 baseRef 會被拒絕，沒有驗證淺層歷史補抓順序、每次 fetch 後會重試 merge-base、成功後會短路，也沒有覆蓋所有策略失敗時的診斷錯誤。",
|
||
"suggestion": "請補針對 `resolveMergeBase` 的失敗與邊界測試。建議把 git 執行函式抽成可替換依賴，或用臨時 git repo 模擬 shallow 狀態，斷言：首次 merge-base 成功不走 fallback；deepen base 成功後立即回傳；deepen PR HEAD 使用目前 HEAD SHA 而不是遠端 `HEAD`；非 shallow repo 不呼叫 `--unshallow`；全部失敗時錯誤包含策略診斷。",
|
||
"suggestedCode": "",
|
||
"id": "F013",
|
||
"verdicts": {
|
||
"Paladin": {
|
||
"exclude": true,
|
||
"reason": "可排除（重複）。歷史 findings 已針對 resolveMergeBase 多階段 fetch、淺層與非淺層分支、成功短路、降級順序與最終失敗診斷缺測試提出相同問題。"
|
||
}
|
||
}
|
||
},
|
||
{
|
||
"reviewer": "Maya",
|
||
"focus": "testing",
|
||
"badge": "🧪",
|
||
"severity": "建議",
|
||
"file": "src/lib/diagnostics.js",
|
||
"startLine": 18,
|
||
"endLine": 69,
|
||
"problem": "`redactSecrets` 與 `agentFailureDetail` 是新加入的安全診斷防線，但測試只覆蓋 Authorization/token 的基本遮罩。控制字元單行化、URL 內嵌帳密、長 token/hex、輸入與輸出長度截斷、以及沒有 error code 時的 fallback 訊息都還沒被驗證。",
|
||
"suggestion": "請補診斷邊界測試，至少包含：含換行與 tab 的輸出不會產生多行 log；`https://user:pass@host` 會被遮罩；40 字元以上 token 會被遮罩；debug 模式下 stderr/stdout 只輸出到限制長度；沒有 `error.code`、`signal`、`stderr/stdout` 時仍回傳安全的 fallback 訊息。",
|
||
"suggestedCode": "",
|
||
"id": "F014",
|
||
"verdicts": {
|
||
"Paladin": {
|
||
"exclude": true,
|
||
"reason": "可排除（重複）。歷史 findings 已涵蓋 redactSecrets／agentFailureDetail 對控制字元、URL 帳密、token 格式、截斷與 fallback 診斷等邊界缺少測試。"
|
||
}
|
||
}
|
||
}
|
||
]
|
||
}
|