2357 lines
161 KiB
JSON
2357 lines
161 KiB
JSON
[
|
||
{
|
||
"addedAt": "2026/07/20 13:53:11",
|
||
"prNumber": 6,
|
||
"reviewer": "Mage",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 205,
|
||
"endLine": 215,
|
||
"problem": "建立 issue 與寫入暫存留言不是可重入操作。最小重現：`createIssue` 成功後，第一則 `createCommentOnIssue` 因暫時性 500 或網路中斷而失敗；主流程退出，但已建立的 issue 不會被記錄或回貼 PR。workflow 重跑時 `issue` 又從 null 開始，因此會再建立一個內容相同的 issue，留下孤兒與重複追蹤項目。後續嚴重問題留言或 PR 回貼失敗也有相同結果。",
|
||
"reason": "Paladin：可排除（重複）。與 F004 指涉同一段 issue 建立及暫存留言沖刷流程，也描述相同的中途失敗後重跑會建立重複 issue 問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 15:03:30",
|
||
"prNumber": 6,
|
||
"reviewer": "Leo",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 205,
|
||
"endLine": 218,
|
||
"problem": "`ensureIssueCreated` 把「建立 issue」與「逐筆沖刷暫存留言」綁成一個不可恢復的流程。若 issue 已成功建立，但其中一則留言失敗，主流程會中止；下次重跑又會建立另一張 issue，留下重複且內容不完整的追蹤單。半年後維護者也很難從現有狀態判斷應重試留言、沿用既有 issue，還是重新建立。",
|
||
"reason": "Paladin：可排除（命中已知排除事項）。其指涉的正是 issue 建立成功、留言沖刷失敗後重跑會產生重複追蹤單的同一問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 15:26:21",
|
||
"prNumber": 6,
|
||
"reviewer": "Leo",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 179,
|
||
"endLine": 234,
|
||
"problem": "`main()` 新增了留言路由、issue 狀態、緩衝佇列、issue 建立與緩衝留言沖刷等職責，後續流程又多次以 `ctx.createIssue` 分支決定發布方式。這使主流程同時負責審查編排與發布狀態機；六個月後若再增加發布管道或重試策略，模式判斷會繼續散落，難以獨立測試各種狀態轉換。",
|
||
"reason": "Paladin：可排除（重複）。與 F006 指涉同一段 main() 內的留言路由、issue 狀態及緩衝佇列職責，亦提出相同的發布器抽離方向。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 15:26:21",
|
||
"prNumber": 6,
|
||
"reviewer": "Leo",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 213,
|
||
"endLine": 233,
|
||
"problem": "`ensureIssueCreated` 在建立 issue 後逐則寫入 `issueBuffer`，但整段沒有可恢復或冪等機制。若寫到一半 API 失敗，主流程會中止；重新執行時無法辨識已建立但內容不完整的 issue，因而可能再建立一張重複 issue。這類部分完成狀態日後會很難人工清理與追查。",
|
||
"reason": "Paladin：可排除（命中已知排除事項且與歷史 finding 重複）。其描述的 issue 建立後沖刷留言失敗、重跑產生重複 issue，正是既有排除事項與歷史 finding 已記錄的問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 15:26:21",
|
||
"prNumber": 6,
|
||
"reviewer": "Leo",
|
||
"severity": "建議",
|
||
"file": "src/lib/gitea.js",
|
||
"startLine": 171,
|
||
"endLine": 194,
|
||
"problem": "新增並匯出的 `addLabelsToIssue` 沒有被本次流程使用，註解也明確表示主流程已不再需要它。保留這個預想中的通用 API 會擴大公開介面與測試範圍；未來 Gitea API 行為改變時，維護者仍得判斷這個無使用者的函式是否需要同步修改。",
|
||
"reason": "Paladin：可排除（重複）。與 F007 指涉相同的未使用 addLabelsToIssue 函式及匯出，問題與移除建議均相同。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 15:26:21",
|
||
"prNumber": 6,
|
||
"reviewer": "Mage",
|
||
"severity": "嚴重",
|
||
"file": "src/index.js",
|
||
"startLine": 331,
|
||
"endLine": 331,
|
||
"problem": "建問題模式在此直接建立新的追蹤 issue，卻沒有任何可重入或去重機制。最小重現：issue 建立成功後，寫入 `issueBuffer`、發布 finding、回貼 PR 連結或最後 push 任一步驟失敗，整個 Action 會以失敗結束；重新執行同一個 commit 時仍會再次呼叫 `ensureIssueCreated`，因此產生內容相同的重複 issue。失敗若持續發生，每次重跑都會再新增一筆。",
|
||
"reason": "Paladin：可排除（命中已知排除事項且與 F009、歷史 finding 重複）。同樣是建立 issue 後任一步驟失敗，重跑無法沿用既有 issue 而重複建立的問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 15:26:21",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 190,
|
||
"endLine": 238,
|
||
"problem": "新增的一般模式／建問題模式留言分流與 `issueBuffer` 清空流程，這次 diff 沒有對應測試。尚未驗證 issue 建立前留言只暫存、建立後依序送出、建立後的新留言直接送往 issue，以及任一 API 寫入失敗時的行為；這是本次建問題模式的核心路徑，沒有測試即無法確認留言不會遺失、重複或誤發到 PR。",
|
||
"reason": "Paladin：可排除（與歷史 finding 重複）。歷史 finding 已明確涵蓋建問題模式核心流程、暫存留言依序送出、發布分流及外部 API 狀態切換缺乏測試。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 15:26:21",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 312,
|
||
"endLine": 389,
|
||
"problem": "建問題模式新增了「無 finding 靜默通過」「有 finding 才建 issue」「標籤失敗降級」「嚴重／其他問題分流」「PR 回貼連結」「相依 API 失敗不阻斷」等多個分支，但本次 diff 沒有測試驗證這些結果。尤其 `kept`、`severe`、`others` 的空集合組合與 API 失敗路徑未經試煉，重構後很容易出現 `issue` 為 null 卻被取用、建立空 issue，或意外在 PR 留言。",
|
||
"reason": "Paladin：可排除（與歷史 finding 重複）。歷史 finding 已列出有問題才建立 issue、無問題靜默通過、嚴重與非嚴重問題分流、標籤失敗及 PR 回貼等相同未測試分支。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 15:26:21",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/lib/gitrepo.js",
|
||
"startLine": 103,
|
||
"endLine": 157,
|
||
"problem": "`resolveMergeBase` 新增多階段 fetch／重試狀態機，卻沒有新增測試驗證策略順序與停止條件。未驗證非 shallow、`--unshallow` 成功、各 fetch 失敗、補抓後仍無共同祖先等邊界，可能讓正常 checkout 多做 fetch，或在仍可恢復時提早拋錯。",
|
||
"reason": "Paladin：可排除（與歷史 finding 重複）。歷史 finding 已針對 resolveMergeBase 的多階段 fetch、淺層與非淺層分支、降級及最終失敗路徑缺少測試提出相同問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 15:26:21",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/lib/review.js",
|
||
"startLine": 16,
|
||
"endLine": 77,
|
||
"problem": "新增的失敗診斷與機密遮罩會處理 CI 日誌中的敏感輸出，但本次 diff 沒有測試其邊界與失敗情境。未驗證 debug 預設關閉、大小寫／空白解析、控制字元單行化、各 token 格式遮罩、500 字截斷，以及 `error`／`stderr`／`output` 缺漏時仍能穩定回傳摘要。",
|
||
"reason": "Paladin：可排除（與歷史 finding 重複）。歷史 finding 已指出 agent 失敗診斷的退出狀態、空輸出、單行化與截斷等邊界缺少測試；本條只是進一步枚舉相同測試缺口。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 15:26:21",
|
||
"prNumber": 6,
|
||
"reviewer": "Rogue",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 226,
|
||
"endLine": 228,
|
||
"problem": "`issueBuffer` 內每則留言以 `await` 串行送出，建立 issue 的等待時間會線性累加為約 `留言數 × API RTT`；若每次往返 200～500 ms，6 則留言便額外卡住約 1.2～3 秒。",
|
||
"reason": "Paladin：可排除（誤判）。此處逐筆 await 用來維持暫存留言的 FIFO 發布順序；留言數量有限，所述短暫延遲不足以證明缺陷，而改成並行反而可能破壞順序並增加 API 限流風險。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 15:44:22",
|
||
"prNumber": 6,
|
||
"reviewer": "Leo",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 179,
|
||
"endLine": 230,
|
||
"problem": "建問題模式的狀態管理、留言路由、issue 建立及緩衝區清空都直接塞進已負責整條審查流程的 `main()`，並透過 `issue`、`issueBuffer` 兩個可變閉包共享狀態。後續若再增加重試、不同發布目的地或補償處理，維護者必須同時追蹤閉包狀態與主流程分支；目前 `ensureIssueCreated` 若在逐則寫入緩衝留言時失敗，issue 已建立但狀態沒有可恢復的進度，重跑也可能再建立重複 issue。",
|
||
"reason": "Paladin：可排除（命中已知排除事項且重複）。已知排除事項已涵蓋 main() 中留言路由、issue 狀態與緩衝佇列職責散落；其中重跑產生重複 issue 的部分也與歷史 finding 相同。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 15:44:22",
|
||
"prNumber": 6,
|
||
"reviewer": "Leo",
|
||
"severity": "建議",
|
||
"file": "src/lib/gitea.js",
|
||
"startLine": 171,
|
||
"endLine": 195,
|
||
"problem": "新增的 `addLabelsToIssue` 沒有任何呼叫端，註解甚至明確說明主流程已不再使用它。現在就保留這個公開匯出會擴大 Gitea client 的 API 表面，未來維護者仍需替它維護文件、測試與版本相容性，卻沒有實際需求驗證其語意。",
|
||
"reason": "Paladin：可排除（命中已知排除事項且重複）。已知排除事項已記錄相同的未使用 addLabelsToIssue 函式、公開匯出及移除建議。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 15:44:22",
|
||
"prNumber": 6,
|
||
"reviewer": "Mage",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 216,
|
||
"endLine": 225,
|
||
"problem": "追蹤 issue 的建立與暫存留言寫入不是可重入操作：`createIssue` 成功後，只要任一 `createCommentOnIssue` 失敗，主流程就直接中止，但已建立的 issue 不會回滾或留下可供重跑辨識的狀態。最小重現為：建立 issue 成功、第一則留言遇到暫時性 5xx；workflow 重跑後會再建立一張相同 issue，產生孤兒或重複追蹤問題。",
|
||
"reason": "Paladin：可排除（命中已知排除事項且重複）。issue 建立成功、留言失敗後重跑會建立重複 issue，正是已知排除事項及歷史 finding 已記錄的同一問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 15:44:22",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 184,
|
||
"endLine": 374,
|
||
"problem": "建問題模式新增了大量分支行為，但本次 diff 沒有對應測試驗證：留言先暫存再依序寫入 issue、無保留問題時靜默通過、標籤挑選失敗時降級、嚴重與非嚴重問題分流、PR 回貼連結，以及建立相依失敗時不中斷流程。這些都是可觀察的核心流程；沒有測試時，任何分支回歸都可能造成漏建 issue、留言送錯位置或流程意外失敗。",
|
||
"reason": "Paladin：可排除（與歷史 finding 重複）。歷史 finding 已涵蓋建問題模式的暫存留言、靜默通過、問題分流、標籤失敗及 PR 回貼等核心分支缺少測試。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 15:44:22",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/lib/gitrepo.js",
|
||
"startLine": 105,
|
||
"endLine": 157,
|
||
"problem": "`resolveMergeBase` 新增多階段 fetch／重試策略，卻沒有測試驗證最容易出錯的淺層歷史與失敗路徑，包括非 shallow repo、`--unshallow` 成功後立即停止、某次 fetch 失敗後繼續下一策略，以及全部失敗時的 diagnostics 與 `cause`。這類命令編排很容易因呼叫順序或 off-by-one 次重試而產生多餘網路請求，甚至在其實可取得 merge-base 時仍失敗。",
|
||
"reason": "Paladin：可排除（與歷史 finding 重複）。歷史 finding 已指出 resolveMergeBase 多階段 fetch 在淺層、非淺層、降級及最終失敗路徑缺少測試。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 15:44:22",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/lib/review.js",
|
||
"startLine": 17,
|
||
"endLine": 81,
|
||
"problem": "新增的 AI CLI 失敗診斷只在失敗與 debug 模式執行，但沒有測試覆蓋其邊界：`res`／`error` 缺值、逾時與 signal、debug 大小寫及空白、控制字元單行化、500 字截斷，以及多種 token／URL 帳密遮罩。這些失敗路徑若回歸，可能使診斷完全缺失或將未遮罩內容寫入 CI log。",
|
||
"reason": "Paladin：可排除（與歷史 finding 重複）。歷史 finding 已記錄 AI CLI 失敗診斷在退出狀態、空輸出、單行化、截斷及相關邊界缺少測試；本條是對同一測試缺口的細項枚舉。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 15:57:46",
|
||
"prNumber": 6,
|
||
"reviewer": "Mage",
|
||
"severity": "嚴重",
|
||
"file": "src/index.js",
|
||
"startLine": 268,
|
||
"endLine": 268,
|
||
"problem": "舊審查留言仍在本回合結果完整發布前就被標記為過時；建議把清理舊留言移到本輪所有必要結果均成功產生之後，避免失敗重跑留下「舊結果已清除、新結果不完整」的中間狀態。",
|
||
"reason": "維護者裁示（議題 #8 留言 #4838，系統管理員）：此功能用途為把前一輪 PR 產生的訊息標記為已解決／過時，讓審查人員辨識舊訊息，因此刻意在本回合結果之前執行，不可延後，否則會誤導審查人員。依維護者決定不採納此修改，記為排除以免後續審查重複提出。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 16:03:44",
|
||
"prNumber": 6,
|
||
"reviewer": "Assassin",
|
||
"severity": "嚴重",
|
||
"file": "src/lib/review.js",
|
||
"startLine": 54,
|
||
"endLine": 75,
|
||
"problem": "開啟 `ACTIONS_STEP_DEBUG=true` 後會把 AI CLI 的原始 stderr/stdout 寫入永久 CI log，但 `redactSecrets` 是可繞過的黑名單，也完全沒有移除 PII。攻擊者可透過惡意 diff／提示注入，要求 CLI 以未涵蓋的格式輸出憑證、電子郵件或其他敏感資料；例如短版金鑰、含標點的 token、JWT 或拆段輸出都可能避開現有正規表示式，造成機密與 PII 外洩。",
|
||
"reason": "Paladin：可排除（重複）。歷史 finding 已針對 debug 模式輸出 AI CLI stderr／stdout、黑名單遮罩可繞過及敏感內容外洩提出相同問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 16:03:44",
|
||
"prNumber": 6,
|
||
"reviewer": "Bard",
|
||
"severity": "建議",
|
||
"file": "src/index.js",
|
||
"startLine": 220,
|
||
"endLine": 231,
|
||
"problem": "`ensureIssueCreated` 之名暗示「若尚未建立才建立」的冪等保證，實作卻會無條件建立新 issue。即使目前只呼叫一次，命名仍會誤導後續維護者，長註解也無法替代準確的動詞。",
|
||
"reason": "Paladin：可排除（重複）。歷史 finding 已明確指出 `ensureIssueCreated` 名稱暗示冪等沿用，實際卻建立新 issue 並修改外層狀態。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 16:03:44",
|
||
"prNumber": 6,
|
||
"reviewer": "Bard",
|
||
"severity": "建議",
|
||
"file": "action.yml",
|
||
"startLine": 45,
|
||
"endLine": 57,
|
||
"problem": "新增的 `push-token` 以區塊註解、欄位描述、選填註解與預設值註解反覆敘述「PAT 觸發 CI、留空退回 token」；同一旋律重奏過多，真正重要的使用方式反而埋在十餘行說明裡，且明顯比鄰近 input 冗長。",
|
||
"reason": "Paladin：可排除（重複）。歷史 finding 已針對 `push-token` 在註解、description、required 與 default 說明中重複敘述相同問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 16:03:44",
|
||
"prNumber": 6,
|
||
"reviewer": "Leo",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 180,
|
||
"endLine": 234,
|
||
"problem": "`main()` 新增 `issueBuffer`、可變的 `issue`、`postComment` 與 `ensureIssueCreated`，把「決定留言目的地、建立 issue、暫存與沖刷留言」等多項職責綁在閉包狀態中。後續流程又必須知道 issue 是否已建立並直接讀取 `issue.number`；半年後若增加留言種類、重試或其他發布目的地，維護者得同時修改多個分支，也很難隔離單元測試發布狀態轉換。",
|
||
"reason": "Paladin：可排除（命中已知排除事項且重複）。已知排除事項與歷史 finding 均已涵蓋 `main()` 內留言路由、issue 狀態、緩衝佇列及發布職責耦合的問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 16:03:44",
|
||
"prNumber": 6,
|
||
"reviewer": "Leo",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 221,
|
||
"endLine": 234,
|
||
"problem": "`ensureIssueCreated` 在所有暫存留言成功寫入前，就先把閉包中的 `issue` 設為已建立；沖刷途中任何一則 API 呼叫失敗，都會留下只寫入部分內容的 issue，且主流程沒有保存進度或可重入機制。重新執行時又會建立另一個 issue。這種部分完成狀態日後很難追查，也會讓重試與錯誤處理持續累積例外分支。",
|
||
"reason": "Paladin：可排除（命中已知排除事項且重複）。issue 建立後沖刷留言失敗、留下部分完成狀態並在重跑時建立重複 issue，正是既有排除事項與歷史 finding 記錄的同一問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 16:03:44",
|
||
"prNumber": 6,
|
||
"reviewer": "Mage",
|
||
"severity": "嚴重",
|
||
"file": "src/index.js",
|
||
"startLine": 342,
|
||
"endLine": 344,
|
||
"problem": "一般模式在發布新的嚴重／警告留言前，就先把舊審查留言標為過時。最小重現：`resolveOldComments` 成功後，步驟 9 的 `createReview` 或步驟 10 的留言 API 暫時失敗；本次 action 以失敗結束，但上一回合完整結果已被清除，新結果也未完整發布，PR 會失去可信的審查結果。這仍違反本次改動宣稱的「沒有新結果時保留舊結果」語義。",
|
||
"reason": "Paladin：可排除（命中已知排除事項）。維護者已明確裁示舊留言必須刻意在本回合結果之前標記為過時，以免舊資訊繼續誤導審查人員。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 16:03:44",
|
||
"prNumber": 6,
|
||
"reviewer": "Mage",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 224,
|
||
"endLine": 233,
|
||
"problem": "追蹤 issue 的建立與暫存留言寫入不是可重入操作。最小重現：`createIssue` 成功，但寫入 `issueBuffer` 第 2 則留言時 API 失敗；action 結束前沒有在 PR 留下連結或保存已建立的 issue 編號。工作流程重跑時會再建立一個新 issue，留下孤立且內容不完整的舊 issue，並可能持續產生重複 issue。",
|
||
"reason": "Paladin：可排除（命中已知排除事項且重複）。建立 issue 後留言寫入失敗、未保存可恢復狀態而使重跑建立重複 issue，已由多筆既有排除事項及歷史 finding 完整涵蓋。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 16:03:44",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 311,
|
||
"endLine": 386,
|
||
"problem": "建問題模式的核心流程已大幅改寫，但本次 diff 沒有對應測試驗證：有保留問題時才建立 issue、標籤失敗時降級、暫存留言依序送出、嚴重與其他問題分流、PR 回貼連結，以及相依 API 失敗不阻斷流程。這些分支牽涉多次外部呼叫與狀態變化，未經測試容易出現 issue 未建立卻存取 `issue.number`、留言遺失或呼叫順序錯誤。",
|
||
"reason": "Paladin：可排除（重複）。歷史 finding 已涵蓋建問題模式的 issue 建立條件、標籤降級、暫存留言、問題分流、PR 回貼及相依 API 失敗等核心分支缺少測試。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 16:03:44",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/lib/gitrepo.js",
|
||
"startLine": 103,
|
||
"endLine": 151,
|
||
"problem": "`resolveMergeBase` 新增多階段 fetch 復原與錯誤診斷，但沒有測試覆蓋淺層與失敗路徑。尚未驗證 unshallow 成功後會立即停止、fetch 失敗會繼續下一策略、非淺層 repo 不會執行 unshallow，以及所有策略失敗時的錯誤與 `cause` 是否正確；這類 git 邊界通常只會在 CI 的 shallow checkout 才暴露。",
|
||
"reason": "Paladin：可排除（重複）。歷史 finding 已針對 `resolveMergeBase` 的淺層與非淺層分支、多階段 fetch、停止條件及最終錯誤資訊缺少測試提出相同問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 16:03:44",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/lib/gitrepo.js",
|
||
"startLine": 270,
|
||
"endLine": 313,
|
||
"problem": "新增的 PAT 推送與憑證注入路徑沒有對應測試。尚未驗證有 `pushToken` 時必須略過 origin、無 `pushToken` 時只有 origin 失敗才使用一般 token、Authorization 僅透過環境變數傳入，以及推送失敗時不會把 token、遠端 URL或原始命令帶入錯誤。這些未驗證行為同時影響 CI 是否重觸發與失敗路徑的機密保護。",
|
||
"reason": "Paladin：可排除（重複）。歷史 finding 已明確記錄 pushToken、origin 與一般 token 的兩套推送策略、認證資訊遮蔽及失敗路徑缺少測試。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 16:03:44",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/lib/review.js",
|
||
"startLine": 16,
|
||
"endLine": 80,
|
||
"problem": "新增的失敗診斷與機密遮罩會處理不可信的 stderr/stdout，但沒有測試驗證邊界與失敗格式。特別是換行控制字元、Authorization、URL 帳密、各種 token 格式、超長輸出截斷，以及 `ACTIONS_STEP_DEBUG` 開關；任何漏測都可能造成除錯模式洩漏機密或產生可偽造的多行 CI 日誌。",
|
||
"reason": "Paladin：可排除（重複）。歷史 finding 已涵蓋 `redactSecrets`／`agentFailureDetail` 對控制字元、各類憑證、URL 帳密、截斷及 debug 開關等邊界缺少測試。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 16:03:44",
|
||
"prNumber": 6,
|
||
"reviewer": "Rogue",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 224,
|
||
"endLine": 226,
|
||
"problem": "`issueBuffer` 內每則留言都逐一 `await` 遠端 API，總耗時為 O(n × API RTT)。目前固定情境留言也會累加多次網路往返；若日後增加階段，等待時間會線性成長。",
|
||
"reason": "Paladin：可排除（命中已知排除事項）。逐筆 `await` 是為維持暫存留言的 FIFO 發布順序，留言數量有限；現有證據不足以證明延遲構成缺陷，而並行發送會增加順序不確定及 API 限流風險。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 16:20:39",
|
||
"prNumber": 6,
|
||
"reviewer": "Assassin",
|
||
"severity": "嚴重",
|
||
"file": "src/lib/review.js",
|
||
"startLine": 73,
|
||
"endLine": 74,
|
||
"problem": "攻擊者可在 PR diff 中植入不符合現有正規表示式的機密或 PII，再誘使 AI CLI 失敗並將提示內容回顯至 stderr；此處預設把前 500 字寫入 CI log。`redactSecrets` 僅是樣式黑名單，無法遮蔽電子郵件、短 token、含特殊符號的憑證或原始碼敏感資料，會形成可長期讀取的資料外洩通道。",
|
||
"reason": "Paladin：可排除（重複）。歷史 finding 已針對除錯模式輸出 AI CLI stderr／stdout、黑名單式遮罩可繞過，以及敏感內容或 PII 外洩提出相同問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 16:20:39",
|
||
"prNumber": 6,
|
||
"reviewer": "Bard",
|
||
"severity": "建議",
|
||
"file": "src/index.js",
|
||
"startLine": 179,
|
||
"endLine": 232,
|
||
"problem": "`main()` 新增了 `issueBuffer`、可變的 `issue`，以及兩個捕捉外部狀態的區域函式，使原本已相當冗長的流程編排同時承擔留言路由、緩衝、issue 建立與緩衝區清空等細節。尤其 `ensureIssueCreated` 這個名稱暗示可重複安全呼叫，實作卻會無條件建立新 issue，名稱與行為並不押韻。",
|
||
"reason": "Paladin：可排除（重複）。歷史 findings 已分別涵蓋 main() 承擔留言路由與 issue 狀態管理，以及 ensureIssueCreated 名稱暗示冪等、實際卻建立新 issue 的問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 16:20:39",
|
||
"prNumber": 6,
|
||
"reviewer": "Bard",
|
||
"severity": "建議",
|
||
"file": "action.yml",
|
||
"startLine": 47,
|
||
"endLine": 58,
|
||
"problem": "`push-token` 周圍的註解重複敘述 PAT、CI 再觸發、步驟 1 快速回報與空值退回行為，且 `description` 又把同一段旋律再奏一次。Action manifest 因實作細節過密而難以快速掃讀，也與其他 input 較精簡的註解密度不一致。",
|
||
"reason": "Paladin：可排除（重複）。歷史 finding 與已知排除事項已記錄 push-token 在註解、description、required 與 default 說明中重複敘述相同資訊。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 16:20:39",
|
||
"prNumber": 6,
|
||
"reviewer": "Leo",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 181,
|
||
"endLine": 231,
|
||
"problem": "`main()` 新增以 `issueBuffer`、`issue` 及兩個閉包管理追蹤 issue，後續又在主流程內負責挑標籤、建立 issue、排空留言、發布各類問題、回貼 PR 與設定相依關係。建問題模式的狀態與發布規則因此散落於整個超長函式；未來新增留言種類或調整建立時機時，維護者必須同步追蹤多處 `ctx.createIssue` 分支與可變閉包狀態，容易漏改，也難以獨立單元測試部分失敗及重試行為。",
|
||
"reason": "Paladin：可排除（命中已知排除事項且重複）。既有紀錄已涵蓋 main() 內留言路由、issue 生命週期、緩衝佇列及發布職責耦合，並提出相同的發布器抽離方向。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 16:20:39",
|
||
"prNumber": 6,
|
||
"reviewer": "Mage",
|
||
"severity": "嚴重",
|
||
"file": "src/index.js",
|
||
"startLine": 345,
|
||
"endLine": 347,
|
||
"problem": "舊留言在新問題留言真正發布成功前就被標記為過時。最小重現：`resolveOldComments` 成功後，步驟 9 的 `postSevereComments` 或步驟 10 的 `postComment` 因暫時性 API 錯誤失敗；本次流程以例外結束，但舊審查結果已被清除，PR 上只剩工具／角色等情境留言，沒有任何有效 finding。這仍違反此次延後清理所宣稱的「成功產生結果後才執行」語義。",
|
||
"reason": "Paladin：可排除（命中已知排除事項）。維護者已明確裁示舊留言應刻意在本回合結果發布前標記為過時，以免舊資訊持續誤導審查人員。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 16:20:39",
|
||
"prNumber": 6,
|
||
"reviewer": "Mage",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 219,
|
||
"endLine": 229,
|
||
"problem": "建立追蹤 issue 與寫入暫存留言不是可恢復的原子流程。最小重現：`createIssue` 成功，但寫入第 2 則 `issueBuffer` 留言時 API 失敗；流程中止後已留下內容不完整且沒有 PR 回鏈的 issue，下次重跑又會建立另一個 issue，造成重複追蹤與狀態分歧。後續 PR 回鏈、相依設定或 commit/push 失敗也有相同的重跑問題。",
|
||
"reason": "Paladin：可排除（命中已知排除事項且重複）。建立 issue 後留言或後續步驟失敗、重跑無法沿用既有 issue 而產生孤兒或重複 issue，已由多筆既有紀錄完整涵蓋。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 16:20:39",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/lib/gitrepo.js",
|
||
"startLine": 105,
|
||
"endLine": 157,
|
||
"problem": "`resolveMergeBase` 新增多階段 fetch／merge-base 復原流程，但本次變更沒有對應測試。淺層與非淺層儲存庫、fetch 失敗後繼續、任一策略成功即停止，以及全部失敗時的診斷與 `cause` 都是新增行為；沒有驗證就可能在 runner 的 shallow checkout 上才暴露錯誤或多餘 fetch。",
|
||
"reason": "Paladin：可排除（重複）。歷史 finding 已記錄 resolveMergeBase 多階段 fetch 在淺層、非淺層、策略停止、降級與最終失敗診斷等路徑缺少測試。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 16:20:39",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/lib/gitrepo.js",
|
||
"startLine": 247,
|
||
"endLine": 311,
|
||
"problem": "新增 `pushToken` 與 `pushWithCredential` 後，推送分支及失敗路徑未見測試覆蓋。尚未驗證有 PAT 時確實略過 origin、無 PAT 時先推 origin 再以 `token` 降級、認證只進環境變數，以及失敗錯誤不帶 token／遠端 URL；這些都是本次新增且直接影響結果 commit 能否推送的行為。",
|
||
"reason": "Paladin：可排除（重複）。歷史 finding 已涵蓋 pushToken、origin 與一般 token 的推送策略、呼叫順序、認證遮蔽及失敗路徑缺少測試。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 16:20:39",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 309,
|
||
"endLine": 386,
|
||
"problem": "建問題模式改成「有保留問題才建 issue」、緩衝留言、逐類發布、回貼 PR 與設定相依關係，但本次沒有流程測試驗證這組新增分支。尤其 `kept` 為空、只有嚴重問題、只有警告／建議、標籤挑選失敗，以及相依 API 失敗降級等路徑，若接線錯誤可能造成漏留言、對 `null` issue 取值，或非預期中斷審查。",
|
||
"reason": "Paladin：可排除（重複）。歷史 findings 已涵蓋建問題模式的 issue 建立條件、暫存留言、問題分流、標籤降級、PR 回貼及相依 API 失敗等核心分支缺少測試。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 16:20:39",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/lib/review.js",
|
||
"startLine": 16,
|
||
"endLine": 85,
|
||
"problem": "新增的失敗診斷與機密遮罩沒有對應測試，尚未驗證空值、控制字元、多種 token 格式、URL 內嵌帳密、500／2000 字截斷邊界，以及 `ACTIONS_STEP_DEBUG` 開關。這段程式會處理失敗路徑中的非可信 CLI 輸出；若正規表示式或截斷順序退化，測試無法及時發現機密殘留或假日誌換行。",
|
||
"reason": "Paladin：可排除（重複）。歷史 finding 已逐項記錄失敗診斷與遮罩對空值、控制字元、各類憑證、URL 帳密、截斷及 ACTIONS_STEP_DEBUG 開關缺少測試。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 16:20:39",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "建議",
|
||
"file": "src/lib/gitea.js",
|
||
"startLine": 171,
|
||
"endLine": 181,
|
||
"problem": "新 API `addIssueDependency` 未見測試驗證 endpoint 與 IssueMeta payload。`issueNumber` 與 `dependency` 的方向一旦顛倒，請求仍可能成功，卻會建立相反的阻擋關係；只靠主流程成功測試不容易察覺。",
|
||
"reason": "Paladin：可排除（重複）。歷史 finding 已指出 addIssueDependency 缺少 endpoint、HTTP method、payload 與相依方向的測試，與本條指控相同。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 16:39:40",
|
||
"prNumber": 6,
|
||
"reviewer": "Assassin",
|
||
"severity": "嚴重",
|
||
"file": "src/lib/review.js",
|
||
"startLine": 74,
|
||
"endLine": 77,
|
||
"problem": "攻擊者可在 PR diff 中植入機密或個資，誘使 AI CLI 在失敗時原樣回顯；此處卻預設把 stderr 與 stdout 寫入長期保存的 CI log。`redactSecrets()` 只是可繞過的黑名單，例如 `Authorization: Bearer <憑證>` 只會遮掉 `Bearer`，後方憑證仍會留下，且電子郵件、姓名、短 token 與未知格式完全不會被遮罩，違反回應不得含 PII 的規範。",
|
||
"reason": "Paladin：可排除（重複）。歷史 finding 已指出除錯模式輸出 AI CLI stderr／stdout、黑名單式遮罩可繞過，以及機密或個資外洩的相同問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 16:39:40",
|
||
"prNumber": 6,
|
||
"reviewer": "Bard",
|
||
"severity": "建議",
|
||
"file": "src/index.js",
|
||
"startLine": 183,
|
||
"endLine": 229,
|
||
"problem": "新增的 `postComment`、`ensureIssueCreated`、`issueBuffer` 與可變的 `issue` 全部嵌在本就冗長的 `main()` 中，且第二個函式透過閉包同時讀寫多個外部狀態。讀者要在主流程、留言路由與 issue 生命週期三條旋律間來回切換，主流程輪廓因此被大量細節淹沒。",
|
||
"reason": "Paladin：可排除（重複）。與 F005 及歷史 finding 指涉相同的 main() 職責膨脹、閉包狀態與 issue 發布流程耦合問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 16:39:40",
|
||
"prNumber": 6,
|
||
"reviewer": "Leo",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 181,
|
||
"endLine": 229,
|
||
"problem": "`main()` 新增了 `issueBuffer`、`issue`、`postComment` 與 `ensureIssueCreated` 等可變狀態及閉包，並在後續流程散落多個 `ctx.createIssue` 分支。留言路由、issue 建立、緩衝區清空與主審查編排因此緊密耦合；半年後新增第三種發布方式或調整 issue 建立時機時，維護者必須同時追蹤整個 `main()` 的狀態轉移，也很難獨立單元測試發布行為。",
|
||
"reason": "Paladin：可排除（命中已知排除事項且重複）。既有紀錄已涵蓋 main() 內留言路由、issue 狀態、緩衝佇列與發布職責耦合的問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 16:39:40",
|
||
"prNumber": 6,
|
||
"reviewer": "Leo",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 344,
|
||
"endLine": 382,
|
||
"problem": "一般模式在嚴重問題與彙整留言發布前就呼叫 `resolveOldComments`。若後續 `postSevereComments` 或 `postComment` 因 API 暫時失敗而中斷，舊的完整審查結果已被標成過時，新回合卻只留下工具、diff、角色等情境留言。這與本次變更宣稱的「成功產生結果後才清舊留言」保證不一致，也讓未來維護者難以判斷何時才算發布完成。",
|
||
"reason": "Paladin：可排除（命中已知排除事項）。維護者已明確裁示舊留言須刻意在本回合結果發布前標記為過時，以免舊資訊繼續誤導審查人員。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 16:39:40",
|
||
"prNumber": 6,
|
||
"reviewer": "Mage",
|
||
"severity": "嚴重",
|
||
"file": "src/index.js",
|
||
"startLine": 213,
|
||
"endLine": 225,
|
||
"problem": "建立追蹤 issue 與寫入暫存留言不是原子操作。最小重現：`gitea.createIssue` 成功後，第 2 則 `createCommentOnIssue` 因暫時性 API 錯誤失敗；主流程會中止，但遠端已留下內容不完整的 issue。工作重跑時沒有查找或續寫既有 issue 的機制，因此會再建立一張重複 issue，且先前已成功寫入的留言也可能重複。",
|
||
"reason": "Paladin：可排除（命中已知排除事項且重複）。建立 issue 後沖刷暫存留言失敗、重跑產生孤兒或重複 issue，已由多筆既有紀錄完整涵蓋。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 16:39:40",
|
||
"prNumber": 6,
|
||
"reviewer": "Mage",
|
||
"severity": "嚴重",
|
||
"file": "src/index.js",
|
||
"startLine": 342,
|
||
"endLine": 344,
|
||
"problem": "舊審查留言仍在新結果完整發布前被標記為過時。最小重現：防守方裁決與 findings 寫檔成功後，`resolveOldComments` 先清除舊結果；接著 `postSevereComments`、`postComment` 或最後的 commit/push 任一步失敗，流程便以失敗結束，PR 上只剩工具／角色等情境留言，既有問題已過時、新問題卻未完整發布。這仍違反本次改動宣稱的「失敗時保留舊結果」語義。",
|
||
"reason": "Paladin：可排除（命中已知排除事項且與 F006 重複）。維護者已裁示不得將舊留言清理延後至新結果完整發布之後。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 16:39:40",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/lib/gitrepo.js",
|
||
"startLine": 105,
|
||
"endLine": 159,
|
||
"problem": "新增的 merge-base 補抓流程沒有對應測試驗證。尚未確認非淺層／淺層 repository、首次 fetch 失敗、unshallow 成功、deepen base 或 HEAD 才成功，以及所有策略失敗時的診斷與 `cause`；這些分支會直接決定送審 diff 的基準，未經試煉仍可能漏審或錯審。",
|
||
"reason": "Paladin：可排除（重複）。歷史 finding 已記錄 resolveMergeBase 多階段 fetch 在淺層、非淺層、停止條件、降級與最終失敗診斷等路徑缺少測試。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 16:39:40",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/lib/gitrepo.js",
|
||
"startLine": 267,
|
||
"endLine": 308,
|
||
"problem": "新增的 `pushToken` 推送分流與 `pushWithCredential` 失敗降級沒有測試覆蓋。尚未驗證有 PAT 時確實略過 origin、無 PAT 時 origin 成功不重試、origin 失敗才使用一般 token，以及認證環境變數與固定錯誤訊息不會帶出 token；這是本次 CI 再觸發機制的核心行為。",
|
||
"reason": "Paladin：可排除（重複）。歷史 finding 已涵蓋 pushToken、origin 與一般 token 的推送策略、呼叫順序、認證遮蔽及失敗路徑缺少測試。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 16:39:40",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 309,
|
||
"endLine": 387,
|
||
"problem": "建問題模式被大幅改寫，但 diff 中沒有測試驗證各分支的外部行為。尤其 `kept` 為空時必須不建 issue、不碰 PR 留言；有問題時必須依序建立 issue、沖出暫存留言、發布各類 finding、回貼 PR 連結；標籤挑選與相依 API 失敗又必須降級而不中斷。這些成功與失敗路徑目前都未被驗證。",
|
||
"reason": "Paladin：可排除（重複）。歷史 findings 已涵蓋建問題模式的 issue 建立條件、暫存留言、問題分流、標籤降級、PR 回貼及相依 API 失敗等核心分支缺少測試。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 16:39:40",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/lib/review.js",
|
||
"startLine": 16,
|
||
"endLine": 82,
|
||
"problem": "新增的失敗診斷與機密遮罩邏輯沒有測試驗證邊界。尚未確認 Authorization、token/password/secret、URL 內嵌帳密、GitHub 樣式 token、長字串、控制字元，以及機密剛好跨越 2,000 字截斷邊界時是否仍會被完整遮蔽；也未驗證 timeout、數字／字串 code、signal 與空輸出的摘要。",
|
||
"reason": "Paladin：可排除（重複）。歷史 finding 已涵蓋失敗診斷與遮罩對空值、控制字元、各類憑證、URL 帳密、截斷及退出狀態等邊界缺少測試。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 16:39:40",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "建議",
|
||
"file": "src/lib/gitea.js",
|
||
"startLine": 171,
|
||
"endLine": 195,
|
||
"problem": "新加入的 `addIssueDependency` API 封裝沒有契約測試，尚未驗證 URL 中使用相依方 PR 編號，而 request body 的 `index` 使用阻擋來源 issue 編號；兩者若對調，請求可能仍是合法格式，卻會建立反向的相依關係。",
|
||
"reason": "Paladin：可排除（重複）。歷史 finding 已指出 addIssueDependency 缺少 endpoint、HTTP method、payload 與相依方向的契約測試。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 17:21:16",
|
||
"prNumber": 6,
|
||
"reviewer": "Assassin",
|
||
"severity": "嚴重",
|
||
"file": "src/lib/review.js",
|
||
"startLine": 70,
|
||
"endLine": 73,
|
||
"problem": "攻擊者可以把惡意內容塞進 PR diff 或 AI 工具輸出，誘使 AI CLI 在失敗時把環境變數、原始碼片段、token、PR 內容或 PII 印到 stdout/stderr；這裡預設把 stdout/stderr 前 500 字寫進 CI log。`redactSecrets` 只是黑名單式遮罩，擋不住 Gitea PAT、JWT、雲端金鑰、短 token、帶標點的密碼或一般 PII。尤其本 PR 又新增 `push-token` PAT，失敗診斷變成一條可被 prompt injection 利用的外洩通道。",
|
||
"reason": "Paladin：可排除（重複）。歷史 finding 已針對 debug/失敗診斷輸出 AI CLI stdout/stderr、黑名單式遮罩可繞過，以及機密或個資外洩提出相同問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 17:21:16",
|
||
"prNumber": 6,
|
||
"reviewer": "Leo",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 180,
|
||
"endLine": 365,
|
||
"problem": "`main()` 這次把「留言目的地切換、issue 暫存與 flush、標籤挑選、PR 回貼、issue dependency、舊留言清理時機」全部塞進同一段流程。半年後要改建問題模式時，維護者必須同時理解 `ctx.createIssue`、`issue`、`issueBuffer`、`currentRunCommentIds` 這幾個閉包狀態的互動，任何一個留言新增在錯誤位置，都可能變成被暫存後丟棄、發錯地方，或被舊留言清理誤處理。這不是單純長度問題，而是 orchestration 和 delivery policy 已經耦合在一起。",
|
||
"reason": "Paladin：可排除（命中已知排除事項且重複）。既有紀錄已涵蓋 main() 內留言路由、issue 狀態、緩衝佇列與發布職責耦合的問題；本條只是擴充描述同一設計負擔。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 17:21:16",
|
||
"prNumber": 6,
|
||
"reviewer": "Leo",
|
||
"severity": "建議",
|
||
"file": "src/lib/review.js",
|
||
"startLine": 30,
|
||
"endLine": 39,
|
||
"problem": "`agentFailureDetail()` 的說明文字前後不一致：開頭說「原始輸出預設隱藏」，下一段又說失敗時預設附上遮罩後的 stderr/stdout 片段。這種註解矛盾會讓未來維護者不確定目前政策到底是偏向保守隱藏，還是偏向可診斷輸出，尤其這段又是多個 AI CLI 失敗路徑共用的行為。",
|
||
"reason": "Paladin：可排除（列表內重複）。與 F002 指涉同一段 agentFailureDetail 註解前後政策描述不一致的問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 17:21:16",
|
||
"prNumber": 6,
|
||
"reviewer": "Mage",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 213,
|
||
"endLine": 224,
|
||
"problem": "`ensureIssueCreated` 先建立追蹤 issue，再逐則寫入 `issueBuffer`。只要 issue 建立成功後任一 buffered comment 發生暫時性 API 失敗，例外會往上拋出，action 以失敗結束，但已建立的 issue 不會回滾，也沒有被記錄成可重用狀態。\n\n最小重現情境：`create-issue=true`、有保留問題；`gitea.createIssue` 成功建立 #10；第一則 `createCommentOnIssue` timeout。這次 run 失敗；下次重跑又建立 #11，造成重複追蹤 issue，且 PR 可能沒有任何連結指向第一次建立的 issue。",
|
||
"reason": "Paladin：可排除（命中已知排除事項且重複）。issue 建立成功後 buffered comment 失敗、重跑產生重複追蹤 issue，正是既有排除事項與歷史 finding 已裁定涵蓋的同一問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 17:21:16",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 309,
|
||
"endLine": 381,
|
||
"problem": "建問題模式這次改了主要行為：有保留問題時才建 issue、先暫存工具/diff/角色留言、之後逐條留言到 issue、再回貼 PR 連結並建立 dependency；但 diff 沒看到對應測試。這條路徑牽涉多個外部 API 呼叫與順序，沒有測試就無法驗證「PR 只留連結、issue 收到完整內容、無保留問題時靜默通過」這些新契約。",
|
||
"reason": "Paladin：可排除（重複）。歷史 findings 已涵蓋建問題模式有 finding 才建 issue、暫存留言 flush、PR 只回貼連結、dependency 失敗降級等核心分支缺少測試。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 17:21:16",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/lib/gitrepo.js",
|
||
"startLine": 102,
|
||
"endLine": 146,
|
||
"problem": "`resolveMergeBase` 新增了多段 fetch fallback（明確更新 base、淺層時 unshallow、deepen base、deepen HEAD）以及失敗診斷，但沒有看到測試覆蓋這些邊界與失敗路徑。這段是 diff 基準來源；只要淺層 checkout 或 fetch 策略順序沒被驗證，審查範圍可能整個錯掉。",
|
||
"reason": "Paladin：可排除（重複）。歷史 findings 已指出 resolveMergeBase 多階段 fetch、淺層與非淺層路徑、停止條件及最終失敗診斷缺少測試。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 17:21:16",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/lib/gitrepo.js",
|
||
"startLine": 267,
|
||
"endLine": 324,
|
||
"problem": "`push-token` 與 `pushWithCredential` 是新的提交推送行為，但 diff 沒有對應測試驗證分支選擇與失敗處理。尤其 `pushToken` 存在時會跳過 origin、未提供時才 fallback，這些都是會影響 CI 是否重新觸發的關鍵行為。",
|
||
"reason": "Paladin：可排除（重複）。歷史 findings 已涵蓋 pushToken、origin fallback、認證傳遞與推送失敗遮蔽等分支缺少測試。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 17:21:16",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "建議",
|
||
"file": "src/lib/review.js",
|
||
"startLine": 13,
|
||
"endLine": 72,
|
||
"problem": "`redactSecrets` / `agentFailureDetail` 新增了輸出 stderr/stdout 診斷的行為，但沒有測試驗證遮罩規則與限長。這不是單純格式調整；一旦正規式或順序被改壞，失敗 log 可能變得不可診斷，或把控制字元與憑證樣式原樣輸出。",
|
||
"reason": "Paladin：可排除（重複）。歷史 findings 已針對 redactSecrets／agentFailureDetail 的控制字元、憑證樣式、URL 帳密、截斷與 debug 開關缺少測試提出相同問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 17:27:30",
|
||
"prNumber": 6,
|
||
"reviewer": "Assassin",
|
||
"severity": "嚴重",
|
||
"file": "src/lib/review.js",
|
||
"startLine": 74,
|
||
"endLine": 77,
|
||
"problem": "攻擊者只要讓 AI CLI 失敗，這裡就會把 stderr/stdout 片段寫進 CI log。那些輸出可能包含 prompt、diff 內容、環境診斷、第三方 CLI 錯誤訊息，甚至 token、API key、JWT、email 或其他 PII；`redactSecrets` 只是樣式比對，漏掉未列舉格式時，秘密會被永久留在多人可讀的建置紀錄裡。",
|
||
"reason": "Paladin：可排除（重複）。歷史 finding 已針對 AI CLI stderr/stdout 寫入 CI log、黑名單式遮罩可繞過，以及 token／PII 外洩風險提出相同問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 17:27:30",
|
||
"prNumber": 6,
|
||
"reviewer": "Bard",
|
||
"severity": "建議",
|
||
"file": "src/index.js",
|
||
"startLine": 206,
|
||
"endLine": 217,
|
||
"problem": "`ensureIssueCreated` 這個名字唱的是「確保存在」，但實作每次呼叫都會直接建立新 issue；名稱與行為不同拍，日後重用時很容易誤讀。",
|
||
"reason": "Paladin：可排除（重複）。歷史 finding 已明確指出 `ensureIssueCreated` 名稱暗示冪等沿用，實作卻會建立新 issue，與本條指控相同。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 17:27:30",
|
||
"prNumber": 6,
|
||
"reviewer": "Leo",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 176,
|
||
"endLine": 363,
|
||
"problem": "建問題模式把「留言目的地切換、issue 延後建立、標籤挑選、嚴重/非嚴重發布、PR 回貼連結、相依設定」全部塞進 `main()`，讓主流程同時承擔流程編排與發布策略。六個月後要改任何一種輸出模式時，很容易漏改其中一個 `ctx.createIssue` 分支，或讓一般模式與建問題模式的行為逐步分岔。",
|
||
"reason": "Paladin：可排除（命中已知排除事項且重複）。既有紀錄已涵蓋 `main()` 內留言路由、issue 生命週期、標籤、相依設定與發布職責耦合的問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 17:27:30",
|
||
"prNumber": 6,
|
||
"reviewer": "Leo",
|
||
"severity": "建議",
|
||
"file": "src/lib/review.js",
|
||
"startLine": 31,
|
||
"endLine": 53,
|
||
"problem": "`agentFailureDetail` 的說明提到「需要原始輸出診斷時，於 workflow 設定 secret `ACTIONS_STEP_DEBUG=true` 再重跑」，但實作其實不看 `ACTIONS_STEP_DEBUG`，預設就會輸出遮罩後的 stderr/stdout 片段。註解與行為不一致會讓未來維護者誤判這段診斷的暴露條件。",
|
||
"reason": "Paladin：可排除（與 F001 重複）。本條同樣指向 `agentFailureDetail` 預設輸出 stderr/stdout 片段、與 debug 暴露條件不一致的同一行為；F001 已保留其核心風險。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 17:27:30",
|
||
"prNumber": 6,
|
||
"reviewer": "Mage",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 219,
|
||
"endLine": 228,
|
||
"problem": "`ensureIssueCreated` 先建立 issue，再逐則寫入暫存留言；任一留言 API 在中途失敗時，流程會直接丟出例外結束，但已建立的 issue 不會回滾，也沒有可重用的識別。最小情境：issue 建立成功，寫入第 2 則 `issueBuffer` 留言時 Gitea 暫時回 500；本次 action 失敗，下一次重跑會再建立一個新 issue，留下重複且內容不完整的追蹤 issue。",
|
||
"reason": "Paladin：可排除（命中已知排除事項且重複）。建立 issue 後沖刷暫存留言失敗、重跑又建立重複 issue，正是既有排除事項與多筆歷史 finding 已涵蓋的問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 17:27:30",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 312,
|
||
"endLine": 383,
|
||
"problem": "建問題模式的核心流程被大幅改寫，但這段新增行為還沒看到對應測試驗證：`kept.length > 0` 才建 issue、標籤挑選失敗要降級、嚴重與非嚴重問題要改發到 issue、最後還要回貼 PR 並嘗試建立 issue dependency。這些都是跨 API 的分支與失敗路徑，沒有測試時很容易只跑到快樂路徑，漏掉「沒有保留問題」「標籤 API 失敗」「dependency API 不支援」這類實際會發生的情境。",
|
||
"reason": "Paladin：可排除（重複）。歷史 findings 已涵蓋建問題模式的 issue 建立條件、標籤降級、問題分流、PR 回貼與 dependency 失敗路徑缺少測試。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 17:27:30",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/lib/gitrepo.js",
|
||
"startLine": 102,
|
||
"endLine": 151,
|
||
"problem": "`resolveMergeBase` 新增了淺層 checkout 修復策略與多段 fallback，但邊界與失敗路徑還沒被驗證：初次 fetch 成功但 merge-base 失敗、`--unshallow` 成功後立即成功、`deepen base` 成功、`deepen HEAD` 成功，以及所有策略都失敗時錯誤訊息要包含診斷。這段是 review diff 的基準點，沒測到 fallback 行為就等於沒有確認淺層 checkout 的修復真的可用。",
|
||
"reason": "Paladin：可排除（重複）。歷史 findings 已針對 `resolveMergeBase` 多階段 fetch、淺層／非淺層分支、停止條件與最終診斷缺少測試提出相同問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 17:27:30",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/lib/gitrepo.js",
|
||
"startLine": 266,
|
||
"endLine": 314,
|
||
"problem": "push 行為從「先 origin、失敗才帶 token URL 重試」改成一律透過 `pushWithCredential` 用環境變數注入 Basic header，但新增的認證與錯誤遮蔽行為沒有測試驗證。這裡的失敗路徑如果沒測，很容易在 push 失敗時回歸成洩漏 argv/token，或 refspec/remoteUrl 組錯卻直到 CI 才發現。",
|
||
"reason": "Paladin：可排除（重複）。歷史 finding 已涵蓋 `pushToken`、origin 與 credential push 策略、認證遮蔽及 push 失敗路徑缺少測試。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 17:27:30",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/lib/review.js",
|
||
"startLine": 14,
|
||
"endLine": 73,
|
||
"problem": "`agentFailureDetail` 現在會把 AI CLI 的 stderr/stdout 片段寫進 log，並依賴 `redactSecrets` 做遮罩與單行化；但這段新增的失敗診斷路徑沒有看到測試覆蓋。這不只是快樂路徑問題，邊界包含空輸出、只有 stdout、逾時 killed、換行控制字元、Authorization/token/URL credentials/長 token 等格式，任何一個漏掉都會讓診斷品質或遮罩行為失真。",
|
||
"reason": "Paladin：可排除（重複）。歷史 finding 已記錄 `agentFailureDetail`／`redactSecrets` 對空輸出、控制字元、憑證格式、URL 帳密、截斷與 debug 開關缺少測試。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 17:32:00",
|
||
"prNumber": 6,
|
||
"reviewer": "Assassin",
|
||
"severity": "警告",
|
||
"file": "src/lib/review.js",
|
||
"startLine": 52,
|
||
"endLine": 69,
|
||
"problem": "AI CLI 失敗時會把 stdout/stderr 片段預設寫進 CI log。攻擊者只要讓 CLI 失敗，並讓錯誤輸出夾帶 prompt、diff、環境診斷、原始碼片段或不符合目前 regex 的 token/PII，就能把本應留在審查沙箱內的內容長期落到多人可讀的 workflow log。`redactSecrets` 是黑名單式遮罩，擋不住未知格式憑證、中文個資、內部 URL、客戶資料或模型/CLI 回顯的任意文字。",
|
||
"reason": "Paladin：可排除（重複）。歷史 finding 已針對 AI CLI 失敗輸出 stdout／stderr、黑名單式遮罩可繞過，以及機密或個資落入 CI log 的風險提出相同問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 17:32:00",
|
||
"prNumber": 6,
|
||
"reviewer": "Bard",
|
||
"severity": "建議",
|
||
"file": "src/index.js",
|
||
"startLine": 178,
|
||
"endLine": 235,
|
||
"problem": "`main()` 裡新加入的兩個閉包與大段 JSDoc 讓主流程開場變得過於厚重。這些說明本身有價值，但它們插在流程步驟之前，讓讀者要先穿過一整段留言派送與建 issue 細節，才聽見真正的 10 步驟主旋律。",
|
||
"reason": "Paladin：可排除（重複）。歷史 finding 已涵蓋 main() 承擔留言路由、issue 狀態、緩衝佇列與發布職責耦合，並提出抽離 helper／發布器的方向。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 17:32:00",
|
||
"prNumber": 6,
|
||
"reviewer": "Leo",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 177,
|
||
"endLine": 378,
|
||
"problem": "`main()` 這次把「一般模式」與「建問題模式」的留言路由、issue 建立、暫存 buffer、標籤挑選、相依關係、舊留言清理全部塞進同一個流程函式。六個月後要改任一個發佈規則時，維護者必須同時理解 `ctx.createIssue`、`issue` 閉包狀態、`issueBuffer`、`currentRunCommentIds` 與步驟順序，控制流已經變成隱含狀態機，測試也很難只針對「留言目的地」或「issue 收束」單獨驗證。",
|
||
"reason": "Paladin：可排除（重複）。此條與歷史 Leo finding 同樣指向 main() 內一般模式／建問題模式發布規則、issueBuffer、issue 閉包狀態與 ctx.createIssue 分支耦合。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 17:32:00",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 177,
|
||
"endLine": 390,
|
||
"problem": "建問題模式這次新增了大量可觀察行為，但 diff 沒看到對應測試：留言先暫存再寫入 issue、無保留問題時靜默通過、有嚴重問題才加 PR 相依、只有警告／建議時不阻擋合併，以及一般模式才延後 resolve 舊留言。這些都是很容易在分支條件中漏掉的流程行為，現在還沒有被試煉過。",
|
||
"reason": "Paladin：可排除（重複）。歷史 Maya findings 已涵蓋建問題模式的暫存留言、靜默通過、嚴重／非嚴重分流、PR 相依與一般模式舊留言清理等核心分支缺少測試。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 17:32:00",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/lib/gitrepo.js",
|
||
"startLine": 102,
|
||
"endLine": 158,
|
||
"problem": "`resolveMergeBase` 新增了多段 fetch 補救策略與錯誤診斷，但沒有看到測試驗證邊界與失敗路徑：首次 merge-base 成功、淺層 repo 走 `--unshallow`、unshallow 失敗後 deepen base/head、所有策略都失敗時要拋出含診斷且保留 `cause` 的錯誤。這段若沒測，很容易在淺層 checkout 才暴露審查整段中斷。",
|
||
"reason": "Paladin：可排除（重複）。歷史 findings 已針對 resolveMergeBase 多階段 fetch、淺層與非淺層分支、停止條件、降級及最終錯誤診斷缺少測試提出相同問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 17:32:00",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/lib/gitrepo.js",
|
||
"startLine": 266,
|
||
"endLine": 306,
|
||
"problem": "`commitAndPushFindings` 改成一律透過 `pushWithCredential` 使用 token 推送，且 `pushWithCredential` 要保證 token 不進 argv、失敗錯誤被固定訊息取代；但 diff 沒有對這些失敗與遮蔽保證新增測試。這條路徑失敗時會直接影響 findings commit，也可能讓敏感資訊出現在測不到的例外訊息中。",
|
||
"reason": "Paladin：可排除（重複）。歷史 finding 已涵蓋 pushToken／pushWithCredential 推送策略、認證遮蔽與失敗路徑缺少測試。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 17:32:00",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/lib/review.js",
|
||
"startLine": 13,
|
||
"endLine": 72,
|
||
"problem": "`agentFailureDetail` 現在會把 stderr/stdout 片段寫進 CI log，雖然有 `redactSecrets`，但沒有看到測試驗證遮罩規則與截斷邊界。這不是快樂路徑；一旦 AI CLI 失敗，未驗證的遮罩就會變成長期保存的 log 風險。",
|
||
"reason": "Paladin：可排除（重複）。歷史 finding 已涵蓋 redactSecrets／agentFailureDetail 對 Authorization、token、URL 帳密、控制字元、截斷與空輸出等邊界缺少測試。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 17:36:21",
|
||
"prNumber": 6,
|
||
"reviewer": "Assassin",
|
||
"severity": "嚴重",
|
||
"file": "src/lib/review.js",
|
||
"startLine": 72,
|
||
"endLine": 75,
|
||
"problem": "這裡把 AI CLI 的 stderr/stdout 片段預設寫進 CI log。攻擊者可以讓 CLI 失敗並把 prompt、diff、環境診斷、token、JWT、內部 URL 或 PR 內容中的敏感資料噴到 stdout/stderr；`redactSecrets` 只是正規表示式盡力遮罩，漏掉格式外的憑證或 PII 時，機密就被長期保存到多人可讀的 CI log。",
|
||
"reason": "Paladin：可排除（重複）。歷史 finding 已針對 debug/失敗診斷輸出 AI CLI stderr/stdout、黑名單式遮罩可繞過，以及機密或個資外洩提出相同問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 17:36:21",
|
||
"prNumber": 6,
|
||
"reviewer": "Bard",
|
||
"severity": "建議",
|
||
"file": "src/index.js",
|
||
"startLine": 180,
|
||
"endLine": 235,
|
||
"problem": "`main()` 裡新增了兩個閉包 helper，再各自搭配整段 JSDoc，像把副歌、橋段與註腳全塞進同一小節。這些註解本身不差，但放在主流程中間會稀釋流程主線，讓讀者在真正開始步驟 3 前先穿過一大段實作細節。",
|
||
"reason": "Paladin：可排除（重複）。歷史 findings 已涵蓋 `main()` 內留言路由、issue 建立、緩衝佇列與閉包 helper 造成主流程職責混雜，並提出抽出發布協作者的相同方向。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 17:36:21",
|
||
"prNumber": 6,
|
||
"reviewer": "Leo",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 180,
|
||
"endLine": 234,
|
||
"problem": "`main()` 這次被塞進建問題模式的留言路由、issue 暫存佇列、issue 建立流程與標籤套用邏輯。未來只要要調整「留言要發到 PR 還是 issue」、「何時 flush 暫存留言」、「哪些模式要靜默通過」，維護者都必須在主流程裡追閉包狀態（`issueBuffer`、`issue`、`currentRunCommentIds`），主流程會越來越像狀態機但沒有清楚邊界。",
|
||
"reason": "Paladin：可排除（命中已知排除事項且重複）。既有紀錄已涵蓋 `main()` 中 issue 狀態、`issueBuffer`、留言路由與發布狀態機職責耦合的同一問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 17:36:21",
|
||
"prNumber": 6,
|
||
"reviewer": "Leo",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 309,
|
||
"endLine": 390,
|
||
"problem": "建問題模式的收束流程散在多段 `if (ctx.createIssue)` 分支中：建立 issue、選標籤、嚴重問題留言、其他問題留言、PR 回貼連結、設定 dependency 都在 `main()` 裡交錯。這讓「建問題模式」沒有單一可讀入口，未來維護者要確認模式行為時必須跨多個區塊拼湊流程，尤其容易漏掉 `issue` 只在 `kept.length > 0` 後才存在的隱含前提。",
|
||
"reason": "Paladin：可排除（重複）。歷史 findings 已指出建問題模式的 issue 建立、留言分流、PR 回貼與 dependency 等流程散落在 `main()`，同屬發布流程邊界不清。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 17:36:21",
|
||
"prNumber": 6,
|
||
"reviewer": "Leo",
|
||
"severity": "建議",
|
||
"file": "src/lib/review.js",
|
||
"startLine": 30,
|
||
"endLine": 44,
|
||
"problem": "`agentFailureDetail` 的文件先說「原始輸出預設隱藏」，後面又說預設附上遮罩後的 stderr/stdout 片段。這種註解與實作語意互相打架，未來維護者很容易誤判 CI log 會不會包含 CLI 輸出，進而在調整遮罩或除錯策略時做錯取捨。",
|
||
"reason": "Paladin：可排除（重複）。與 F003 指涉同一段 `agentFailureDetail` 文件，問題同為「預設隱藏原始輸出」與「預設輸出遮罩片段」語意互相衝突。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 17:36:21",
|
||
"prNumber": 6,
|
||
"reviewer": "Mage",
|
||
"severity": "嚴重",
|
||
"file": "src/index.js",
|
||
"startLine": 397,
|
||
"endLine": 415,
|
||
"problem": "在 `create-issue=true` 且本輪有保留的嚴重問題、但 `excluded` 為空時，`exclusionsChanged` 會是 `false`，建問題模式又不 commit findings，因此收尾會「略過 commit/push」後直接 `return 0`。最小重現：PR 只有 1 條嚴重 finding、沒有任何誤判排除、問題相依 API 未啟用或設定失敗；流程會建立 issue、相依設定被 catch 成 WRN，沒有 `[failure]` 結果 commit，也沒有下一輪步驟 1 可回報失敗，最後 CI 成功通過。",
|
||
"reason": "Paladin：可排除（重複）。與 F001 指涉同一個嚴重 finding gate 依賴後續 commit/push 或 dependency side effect、而本輪可能直接回傳 0 的問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 17:36:21",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 180,
|
||
"endLine": 409,
|
||
"problem": "建問題模式的流程被大幅改寫，但 diff 沒看到對應測試驗證這些新分支：留言先暫存到 `issueBuffer`、`kept.length > 0` 才建立 issue、無保留問題／無可審查變更時靜默通過、PR 回貼 issue 連結，以及只有嚴重問題才呼叫 `addIssueDependency`。這些都是使用者可觀察行為，沒有測試就很容易在之後調整流程時被改壞。",
|
||
"reason": "Paladin：可排除（重複）。歷史 findings 已涵蓋建問題模式的暫存留言、有 finding 才建 issue、靜默通過、PR 回貼、嚴重問題與 dependency 等核心分支缺少測試。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 17:36:21",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/lib/gitrepo.js",
|
||
"startLine": 102,
|
||
"endLine": 159,
|
||
"problem": "`resolveMergeBase` 新增了多段 fetch／unshallow／deepen fallback 與錯誤診斷，但沒有看到針對淺層 checkout、fetch 失敗、merge-base 首次失敗後成功、所有策略失敗等邊界的測試。這段決定送審 diff 的基準，一旦 fallback 順序或錯誤處理壞掉，審查可能漏看或多看變更。",
|
||
"reason": "Paladin：可排除（重複）。歷史 findings 已針對 `resolveMergeBase` 多階段 fetch、淺層 checkout、成功停止條件與全部失敗診斷缺少測試提出相同問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 17:36:21",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/lib/gitrepo.js",
|
||
"startLine": 266,
|
||
"endLine": 297,
|
||
"problem": "push 行為改成一律走 `pushWithCredential`，並宣稱 token 不進 argv、失敗時隱藏 URL／認證資訊，但沒有測試覆蓋成功與失敗路徑。這裡一旦 regression，可能導致結果 commit 推不上去，或失敗訊息洩漏認證材料。",
|
||
"reason": "Paladin：可排除（重複）。歷史 findings 已涵蓋 pushToken／pushWithCredential 的推送策略、認證環境變數、失敗遮蔽與成功失敗路徑缺少測試。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 17:36:21",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/lib/review.js",
|
||
"startLine": 13,
|
||
"endLine": 84,
|
||
"problem": "`agentFailureDetail` 現在會把 AI CLI 的 stderr/stdout 片段寫進 CI log，並依賴 `redactSecrets` 遮罩機密；但新增的遮罩規則與截斷規則沒有測試。這是典型失敗路徑，平常快樂路徑不會跑到，沒測過就無法相信它真的能處理 Authorization、token、URL 帳密、控制字元與長金鑰。",
|
||
"reason": "Paladin：可排除（重複）。歷史 findings 已涵蓋 `redactSecrets`／`agentFailureDetail` 對 Authorization、token、URL 帳密、控制字元、長輸出與空輸出等邊界缺少測試。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 17:43:56",
|
||
"prNumber": 6,
|
||
"reviewer": "Assassin",
|
||
"severity": "警告",
|
||
"file": "src/lib/review.js",
|
||
"startLine": 58,
|
||
"endLine": 72,
|
||
"problem": "`agentFailureDetail` 現在預設把 AI CLI 的 `stderr` 與 `stdout` 片段寫進 CI log。攻擊者可以在 PR diff 或提示注入內容中放入敏感資料形狀的字串，再誘導 CLI 失敗並回顯 prompt；`redactSecrets` 只是盡力遮罩，擋不住短密碼、內部 URL、email、客戶資料或非典型 token。這等於把不可信輸入與可能含機密的工具輸出灌進長期保存、多人可讀的 log。",
|
||
"reason": "Paladin：可排除（重複）。歷史 finding 已針對 AI CLI stderr／stdout 寫入 CI log、黑名單式遮罩可繞過，以及機密或個資外洩風險提出相同問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 17:43:56",
|
||
"prNumber": 6,
|
||
"reviewer": "Bard",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 119,
|
||
"endLine": 151,
|
||
"problem": "流程說明把「步驟 2」描述成延後到步驟 8 之後才執行，後面程式又用 `步驟 2（延後執行）` 回頭標示。這段樂譜的拍號倒著走，讀者必須在時間順序與編號順序之間來回換算，註解、log 與 README 流程圖都因此變得不直覺。",
|
||
"reason": "Paladin：可排除（重複）。歷史 finding 已指出流程步驟編號硬編碼於主流程註解、日誌與 README，調整流程時容易失準；本條是同一類步驟編號與執行順序不直覺問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 17:43:56",
|
||
"prNumber": 6,
|
||
"reviewer": "Bard",
|
||
"severity": "建議",
|
||
"file": "src/index.js",
|
||
"startLine": 186,
|
||
"endLine": 224,
|
||
"problem": "`postComment` 與 `ensureIssueCreated` 是 `main()` 內部閉包，卻各自塞入完整 JSDoc，再加上前後多段長註解，使主流程像在旋律中突然插入大段腳註。這會稀釋真正重要的 10 步驟編排，可讀性變得厚重。",
|
||
"reason": "Paladin：可排除（重複）。歷史 finding 已指出 main() 內新增兩個帶完整 JSDoc 的閉包與長段註解，打斷主流程閱讀節奏。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 17:43:56",
|
||
"prNumber": 6,
|
||
"reviewer": "Leo",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 180,
|
||
"endLine": 390,
|
||
"problem": "`main()` 這次把「一般模式 PR 留言」、「建問題模式暫存留言」、「建立 issue」、「回貼 PR 連結」、「設定 issue dependency」都塞進同一段流程與閉包狀態（`issueBuffer`、`issue`、`postComment`、`ensureIssueCreated`）。半年後要改留言落點或新增第三種輸出模式時，維護者必須同時理解整條 10 步驟流程與這些隱含狀態轉移，出錯點會集中在同一個長函式裡。",
|
||
"reason": "Paladin：可排除（命中已知排除事項且重複）。既有紀錄已涵蓋 main() 內留言路由、issue 生命週期、緩衝佇列與發布職責耦合，並提出相同的發布器抽離方向。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 17:43:56",
|
||
"prNumber": 6,
|
||
"reviewer": "Mage",
|
||
"severity": "嚴重",
|
||
"file": "src/index.js",
|
||
"startLine": 405,
|
||
"endLine": 426,
|
||
"problem": "在 `create-issue: true` 且有嚴重問題、但 `exclusionsChanged === false` 的情境下，流程不會產生任何結果 commit：`filesToCommit` 會是空陣列，接著進入略過 commit/push 的分支，最後仍固定 `return 0`。最小重現：PR 產生 1 條保留的「嚴重」 finding、防守方沒有排除項目，因此 `exclusions.json` 不變；若問題相依 API 未啟用或設定失敗，程式只記 WRN，沒有 failure commit 觸發下一輪步驟 1，也沒有非 0 exit code，CI 會通過。這和註解宣稱「嚴重問題由 `[failure]` 結果 commit 於下一輪回報」的契約衝突。",
|
||
"reason": "Paladin：可排除（重複）。此條與 F001 指涉同一建問題模式 fail-open 問題：嚴重 finding 可能因沒有 failure commit 且 issue dependency 失敗被降級而讓 CI 通過。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 17:43:56",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/lib/gitrepo.js",
|
||
"startLine": 102,
|
||
"endLine": 155,
|
||
"problem": "新增的 `resolveMergeBase` 淺層 checkout 補抓流程沒有看到對應測試驗證。這段現在有多個分支：初次 `merge-base` 成功、`deepen base` 後成功、`deepen HEAD` 後成功、淺層 repo 才跑 `--unshallow`、所有策略失敗時要帶診斷與 `cause`。這些都是會直接影響送審 diff 範圍的核心行為，沒被試煉過我會先當作未完成。",
|
||
"reason": "Paladin：可排除（重複）。歷史 finding 已針對 resolveMergeBase 的多階段 fetch、淺層與非淺層分支、停止條件及最終失敗診斷缺少測試提出相同問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 17:43:56",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/lib/gitrepo.js",
|
||
"startLine": 265,
|
||
"endLine": 298,
|
||
"problem": "push 行為從「先 origin、失敗再帶 token URL」改成「一律透過 `pushWithCredential` 用 `GIT_CONFIG_*` extraheader 推送」，但 diff 沒有新增測試驗證成功路徑、失敗路徑與機密不進 argv。這段一旦組錯環境變數或 refspec，結果 commit 就推不上去；一旦錯誤訊息回顯 argv，也會破壞你想保護 token 的保證。",
|
||
"reason": "Paladin：可排除（重複）。歷史 finding 已涵蓋 findings 推送認證路徑、token push 目標、錯誤不含憑證與相關測試缺口。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 17:43:56",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 184,
|
||
"endLine": 397,
|
||
"problem": "建問題模式新增了大量流程分支，但沒有看到對應測試驗證留言去向與邊界。現在行為包含：issue 建立前先暫存工具/diff/角色留言、沒有保留問題時靜默通過、有保留問題才建 issue、嚴重問題才設定 PR 相依、只有警告/建議時不阻擋合併、最後回貼 issue 連結到 PR。這些不是單純註解調整，是使用者可觀察到的流程改變，若沒測試很容易在重構時漏發或發錯位置。",
|
||
"reason": "Paladin：可排除（重複）。歷史 findings 已涵蓋建問題模式的暫存留言、無 finding 靜默通過、有 finding 才建 issue、嚴重與其他問題分流、PR 回貼及相依 API 分支缺少測試。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 17:43:56",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/lib/review.js",
|
||
"startLine": 16,
|
||
"endLine": 72,
|
||
"problem": "`redactSecrets` / `agentFailureDetail` 新增了把 AI CLI 的 stderr/stdout 寫進 CI log 的行為，但沒有看到測試驗證遮罩規則與截斷邊界。這裡的失敗路徑特別需要測：Authorization、token/password、URL 內嵌帳密、長 token、控制字元與超長輸出都應被處理，否則一個未覆蓋的格式就可能把敏感內容留下來。",
|
||
"reason": "Paladin：可排除（重複）。歷史 finding 已記錄 redactSecrets／agentFailureDetail 對 Authorization、token、URL 帳密、控制字元、截斷與 debug 開關等邊界缺少測試。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 17:43:56",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "建議",
|
||
"file": "src/lib/gitea.js",
|
||
"startLine": 172,
|
||
"endLine": 194,
|
||
"problem": "新增的 `addIssueDependency` API wrapper 沒有看到測試確認 endpoint 與 body。這段雖然薄，但語意很容易寫反：URL 上的是被阻擋的 PR/issue，body 的 `index` 才是 dependency。少了測試，未來調整時很可能把相依方向顛倒而不自知。",
|
||
"reason": "Paladin：可排除（重複）。歷史 finding 已指出 addIssueDependency 缺少 endpoint、HTTP method、payload、錯誤傳遞與相依方向測試，與本條相同。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 17:54:00",
|
||
"prNumber": 6,
|
||
"reviewer": "Assassin",
|
||
"severity": "警告",
|
||
"file": "src/lib/review.js",
|
||
"startLine": 65,
|
||
"endLine": 78,
|
||
"problem": "AI CLI 失敗時預設把 stderr/stdout 片段寫進 CI log。攻擊者可以讓 CLI 失敗並誘使它回顯 prompt、diff、環境診斷或原始碼內容；`redactSecrets` 只是盡力遮罩，擋不住 PII、內部路徑、專案機密格式、JWT/雲端金鑰變體，或模型輸出的敏感片段。CI log 通常被長期保存且可被多人讀取，這條路徑會把不該外洩的內容變成可搜尋的紀錄。",
|
||
"reason": "Paladin：可排除（重複）。歷史 finding 已針對 AI CLI stderr/stdout 寫入 CI log、黑名單式遮罩可繞過，以及敏感內容外洩提出相同問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 17:54:00",
|
||
"prNumber": 6,
|
||
"reviewer": "Bard",
|
||
"severity": "建議",
|
||
"file": "action.yml",
|
||
"startLine": 2,
|
||
"endLine": 3,
|
||
"problem": "檔頭的「更新時間」仍停在 2026/07/17 18:49:58，但本次變更脈絡顯示檔案已在 2026/07/20 更新；這種手動時間戳與實際修改節奏不同拍，會讓讀者懷疑哪一份資訊才可信。",
|
||
"reason": "Paladin：可排除（重複）。歷史 finding 已指出 action.yml 檔頭手動更新時間與實際更新時間不一致，且建議移除或改由 git history 表達。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 17:54:00",
|
||
"prNumber": 6,
|
||
"reviewer": "Bard",
|
||
"severity": "建議",
|
||
"file": "readme.md",
|
||
"startLine": 3,
|
||
"endLine": 3,
|
||
"problem": "README 的更新時間被改成 2026/07/17 18:49:58，卻與本次 2026/07/20 的文件變更不一致；文件首頁第一眼就走調，會削弱後續內容的可信度。",
|
||
"reason": "Paladin：可排除（重複）。歷史 finding 已指出 README 手動更新時間與實際更新時間不符，且與其他檔案重複保存易過期資訊。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 17:54:00",
|
||
"prNumber": 6,
|
||
"reviewer": "Bard",
|
||
"severity": "建議",
|
||
"file": "src/index.js",
|
||
"startLine": 7,
|
||
"endLine": 7,
|
||
"problem": "啟動橫幅的更新時間仍是 2026/07/17 18:49:58，但本檔本次已有大量流程調整；執行 log 會唱出過期的日期，維運者讀 log 時容易被誤導。",
|
||
"reason": "Paladin：可排除（重複）。歷史 finding 已指出 src/index.js 啟動橫幅硬編碼更新時間與程式實際更新時間不一致。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 17:54:00",
|
||
"prNumber": 6,
|
||
"reviewer": "Bard",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 183,
|
||
"endLine": 237,
|
||
"problem": "`main()` 內新增 `postComment`、`ensureIssueCreated` 兩個閉包，還各自塞入完整 JSDoc；主流程本來應像總譜一樣清楚推進，現在在步驟前奏就被大量細節註解打斷，閱讀節奏明顯變重。",
|
||
"reason": "Paladin：可排除（重複）。歷史 finding 已涵蓋 main() 內新增閉包、JSDoc 與建問題模式細節打斷主流程可讀性的問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 17:54:00",
|
||
"prNumber": 6,
|
||
"reviewer": "Leo",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 180,
|
||
"endLine": 407,
|
||
"problem": "`main()` 這次同時吃下「一般模式留言」、「建問題模式暫存／建 issue／貼回 PR／設定相依」、「舊留言延後解決」與「結果 commit」等多條流程。半年後要改其中一種模式時，維護者必須在同一個長函式裡追蹤 `issue`、`issueBuffer`、`currentRunCommentIds`、`kept/severe/others` 的狀態轉換，任何插入步驟都很容易破壞另一個模式。",
|
||
"reason": "Paladin：可排除（重複）。已知排除事項與歷史 findings 已涵蓋 main() 承擔一般模式、建問題模式、issue 狀態、緩衝佇列與發布職責耦合的問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 17:54:00",
|
||
"prNumber": 6,
|
||
"reviewer": "Leo",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 188,
|
||
"endLine": 216,
|
||
"problem": "`postComment` 以同一個函式名稱包了三種行為：PR 直接留言、issue 直接留言、issue 尚未建立時暫存且回傳 `null`。這個回傳型別與副作用都依 `ctx.createIssue`／`issue` 閉包狀態改變，未來新增呼叫點時很容易誤以為一定會真的發出留言或一定會拿到留言物件。",
|
||
"reason": "Paladin：可排除（重複）。此條仍屬 main() 中留言路由、issue 狀態與緩衝語意集中在閉包狀態的同一設計問題，已由歷史 findings 涵蓋。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 17:54:00",
|
||
"prNumber": 6,
|
||
"reviewer": "Mage",
|
||
"severity": "嚴重",
|
||
"file": "src/index.js",
|
||
"startLine": 405,
|
||
"endLine": 419,
|
||
"problem": "在 `create-issue: true` 且本輪有嚴重問題、但 `exclusions.json` 沒有變更時，`filesToCommit` 會是空陣列，因此不會推出帶 `[failure]` 的結果 commit。接著第 419 行仍固定 `return 0`。最小情境：PR 產生 1 條嚴重 finding、沒有任何 excluded finding、Gitea 未啟用 issue dependency 或 `addIssueDependency` 失敗；流程只建立 issue 並記 WRN，CI check 卻成功結束，也沒有下一輪可讀取 `[failure]` commit，嚴重問題不會阻擋合併。",
|
||
"reason": "Paladin：可排除（重複）。與 F001 指涉同一個建問題模式嚴重 finding 在 dependency 失敗且無 failure marker 時 fail-open 的問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 17:54:00",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 321,
|
||
"endLine": 395,
|
||
"problem": "建問題模式的核心流程被大幅改寫，但 diff 沒看到對應測試驗證幾個分支：沒有保留問題時不建 issue、不在 PR 留言；只有警告／建議時建立 issue 但不加 dependency；有嚴重問題時建立 issue、回貼 PR 連結並嘗試加 dependency。這些都是會影響 PR 合併與通知位置的新行為，沒有測試就很容易在後續調整時悄悄退化。",
|
||
"reason": "Paladin：可排除（重複）。歷史 findings 已涵蓋建問題模式核心分支缺少測試，包括無保留問題、嚴重與非嚴重分流、PR 回貼與相依 API 失敗降級。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 17:54:00",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/lib/gitrepo.js",
|
||
"startLine": 104,
|
||
"endLine": 148,
|
||
"problem": "`resolveMergeBase` 新增多段 fetch／deepen／unshallow 補救流程與診斷錯誤，但沒有看到測試驗證淺層 checkout、fetch 失敗後改走下一策略、某策略成功後立即停止，以及全部失敗時錯誤訊息含診斷。這裡直接決定送審 diff 的基準，邊界沒驗證就可能把錯誤檔案送審或漏審。",
|
||
"reason": "Paladin：可排除（重複）。歷史 findings 已針對 resolveMergeBase 多階段 fetch、淺層與非淺層路徑、停止條件及最終診斷缺少測試提出相同問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 17:54:00",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/lib/gitrepo.js",
|
||
"startLine": 307,
|
||
"endLine": 333,
|
||
"problem": "`pushWithCredential` 新增以 `GIT_CONFIG_*` 注入 Basic header、先清空 checkout 自動 token、失敗時隱藏 URL／憑證的行為，但 diff 沒看到測試覆蓋成功與失敗路徑。這段是結果 commit 能否觸發下一輪 CI 的關鍵，也承擔避免 token 出現在 argv／錯誤訊息的保護，沒有測試很難防回歸。",
|
||
"reason": "Paladin：可排除（重複）。歷史 findings 已涵蓋 pushWithCredential／pushToken 推送認證路徑、環境變數注入、成功與失敗路徑及憑證遮蔽缺少測試。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 17:54:00",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/lib/review.js",
|
||
"startLine": 13,
|
||
"endLine": 72,
|
||
"problem": "`redactSecrets`／`agentFailureDetail` 現在會把 AI CLI 的 stderr/stdout 片段寫進 CI log，但遮罩規則與截斷策略沒有測試。這是失敗路徑才會觸發的行為，若正規表示式或輸出拼接被改壞，可能不是漏診斷就是把敏感字串帶進 log。",
|
||
"reason": "Paladin：可排除（重複）。歷史 findings 已涵蓋 redactSecrets／agentFailureDetail 對 stderr/stdout、遮罩、控制字元、截斷與敏感字串缺少測試的問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 17:54:00",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "建議",
|
||
"file": "src/lib/gitea.js",
|
||
"startLine": 169,
|
||
"endLine": 175,
|
||
"problem": "新增 `addIssueDependency` API wrapper，但沒有看到測試固定 endpoint 與 payload。這種薄封裝看似簡單，卻很容易在 issue/PR 編號、`index` 欄位或 repo owner/name 組合上出錯。",
|
||
"reason": "Paladin：可排除（重複）。歷史 findings 已指出 addIssueDependency 缺少 endpoint、HTTP method、payload 與相依方向測試，與本條相同。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 18:00:02",
|
||
"prNumber": 6,
|
||
"reviewer": "🔮 Mage",
|
||
"severity": "嚴重",
|
||
"file": "src/lib/gitrepo.js",
|
||
"startLine": 276,
|
||
"endLine": 276,
|
||
"problem": "提供 pushToken 時仍把 Git HTTP 使用者名稱固定為 ai-review-bot；若 PAT 屬於其他帳號，伺服器會以錯誤的帳號／PAT 組合驗證，導致 push 失敗。",
|
||
"reason": "誤報（管理員於 issue #10 留言明確指示列為誤報）。Gitea 的 HTTP Basic 認證以密碼欄（token／PAT）判定身分，使用者名稱欄不影響認證結果，故固定為 ai-review-bot 不會造成 push 失敗。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 18:07:26",
|
||
"prNumber": 6,
|
||
"reviewer": "Assassin",
|
||
"severity": "嚴重",
|
||
"file": "src/lib/review.js",
|
||
"startLine": 73,
|
||
"endLine": 76,
|
||
"problem": "攻擊者可以把惡意內容塞進 PR diff，誘導 AI CLI 在失敗時把環境資訊、原始提示、程式碼片段或秘密印到 stdout/stderr；這裡預設把 stderr/stdout 片段寫進 CI log。`redactSecrets` 只是盡力遮罩，擋不住短 token、雲端 access key、JWT 片段、email、PR 內容中的 PII，等於把不可信子程序輸出變成長期保存且多人可讀的洩漏面。",
|
||
"reason": "Paladin：可排除（重複）。歷史 finding 已針對 AI CLI 失敗時將 stderr/stdout 寫入 CI log、黑名單式遮罩不足，以及機密或個資外洩風險提出相同問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 18:07:26",
|
||
"prNumber": 6,
|
||
"reviewer": "Bard",
|
||
"severity": "建議",
|
||
"file": "src/index.js",
|
||
"startLine": 199,
|
||
"endLine": 237,
|
||
"problem": "`main()` 內新增兩個帶完整 JSDoc 的閉包，篇幅與抽象程度已不像局部小工具；主流程原本應像總譜一樣清楚推進，現在在步驟開始前先插入大段支線說明，閱讀節奏被拉長。",
|
||
"reason": "Paladin：可排除（重複）。歷史 finding 已指出 `main()` 內新增兩個帶完整 JSDoc 的閉包，讓留言路由與 issue 建立細節打斷主流程閱讀。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 18:07:26",
|
||
"prNumber": 6,
|
||
"reviewer": "Bard",
|
||
"severity": "建議",
|
||
"file": "action.yml",
|
||
"startLine": 3,
|
||
"endLine": 4,
|
||
"problem": "檔頭的用途句過長，且「更新時間」仍停在 `2026/07/17 18:49:58`，與本次檔案變更時間脈絡不一致。文件開場若時間與篇幅都失準，後續讀者很難相信這份註解仍被細心維護。",
|
||
"reason": "Paladin：可排除（重複）。歷史 finding 已針對 `action.yml` 檔頭手寫更新時間過期、易與實際變更不同步提出相同問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 18:07:26",
|
||
"prNumber": 6,
|
||
"reviewer": "Leo",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 180,
|
||
"endLine": 223,
|
||
"problem": "`main()` 現在同時負責審查流程編排、PR 留言、issue 暫存、issue 建立與暫存留言 flush。這些模式差異靠 `ctx.createIssue`、`issueBuffer`、`issue` 這幾個閉包狀態散在後續流程判斷；半年後要新增第三種輸出目的地或調整步驟順序時，很容易漏改某個分支，造成留言發錯位置或暫存內容被丟棄。",
|
||
"reason": "Paladin：可排除（命中已知排除事項且重複）。既有紀錄已涵蓋 `main()` 內留言路由、issue 狀態、緩衝佇列與發布職責耦合的問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 18:07:26",
|
||
"prNumber": 6,
|
||
"reviewer": "Leo",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 309,
|
||
"endLine": 388,
|
||
"problem": "建問題模式的生命週期被拆散在多個區塊：先依 `kept.length` 建 issue、再分別處理 severe/others、最後回貼 PR 連結與設定 dependency。這些區塊都隱含「只要有 severe 或 others，`issue` 一定存在」的前置條件，但前置條件沒有被型別或函式邊界保護，只靠讀者追完整個流程才能確認。後續若有人改了 `kept` 分組、靜默通過規則或 issue 建立條件，這段會很容易產生 null issue 或部分內容漏發。",
|
||
"reason": "Paladin：可排除（重複）。此條仍指向建問題模式的 issue 生命週期與跨區塊可變狀態耦合，與 F007 及歷史 Leo findings 所述同一設計問題重複。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 18:07:26",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 183,
|
||
"endLine": 389,
|
||
"problem": "建問題模式新增了完整分流行為，但這次變更沒有看到對應測試驗證。這裡不只是換留言目的地，而是新增「先暫存留言、確定有保留問題才建 issue、無保留問題靜默通過、嚴重問題才掛 PR 相依、PR 回貼 issue 連結」等多個分支；若其中任一條件判斷錯，可能造成 PR 沒有審查結果、issue 漏留言，或警告問題誤阻擋合併。",
|
||
"reason": "Paladin：可排除（重複）。歷史 Maya findings 已涵蓋建問題模式暫存留言、無保留問題靜默通過、問題分流、PR 回貼 issue 連結與 dependency 等核心分支缺少測試。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 18:07:26",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/lib/gitrepo.js",
|
||
"startLine": 102,
|
||
"endLine": 158,
|
||
"problem": "`resolveMergeBase` 新增多段 fetch fallback 與診斷彙整，但沒有測試覆蓋淺層 checkout、fetch 失敗、每次補抓後立即重試 merge-base、以及最終失敗時錯誤訊息與 `cause` 的行為。這段是 PR diff 基準的核心邏輯，未驗證時很容易在 shallow clone 或 PR head 歷史不足時漏審／誤審。",
|
||
"reason": "Paladin：可排除（重複）。歷史 findings 已針對 `resolveMergeBase` 多階段 fetch、淺層與非淺層路徑、fetch 失敗後降級、停止條件與最終診斷缺少測試提出相同問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 18:07:26",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/lib/gitrepo.js",
|
||
"startLine": 268,
|
||
"endLine": 325,
|
||
"problem": "`commitAndPushFindings` 改成一律透過 `pushWithCredential` 用 PAT extraheader 推送，且宣稱會清掉 checkout 自動 token、避免 token 進 argv、失敗時不外洩 URL／憑證；但這些安全與觸發 CI 的關鍵行為沒有測試驗證。未測的失敗路徑尤其危險，因為一旦環境變數組錯，可能推送失敗或回到自動 token 而不觸發下一輪檢查。",
|
||
"reason": "Paladin：可排除（重複）。歷史 findings 已涵蓋 `commitAndPushFindings`／`pushWithCredential` 的推送認證路徑、token 不進 argv、錯誤不外洩憑證與 CI 觸發相關行為缺少測試。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 18:07:26",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/lib/review.js",
|
||
"startLine": 13,
|
||
"endLine": 74,
|
||
"problem": "`agentFailureDetail` 現在會把 AI CLI 的 stderr/stdout 片段寫進 CI log，並依賴 `redactSecrets` 遮罩機密與控制字元；這是新增的失敗診斷行為，但沒有看到測試驗證邊界與失敗輸出。若遮罩規則漏掉，測試沒守住就可能把 token、Authorization header 或含換行的偽造 log 直接輸出。",
|
||
"reason": "Paladin：可排除（重複）。歷史 findings 已記錄 `agentFailureDetail`／`redactSecrets` 對 Authorization、token、URL 帳密、控制字元、截斷與空輸出等邊界缺少測試。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 18:07:26",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/lib/gitea.js",
|
||
"startLine": 169,
|
||
"endLine": 195,
|
||
"problem": "新增 `addIssueDependency` 封裝 Gitea issue dependency endpoint，但沒有對 endpoint、HTTP method 與 body 語意補測試。這個 API 的方向性很重要：是讓 PR 相依於追蹤 issue；若 body 的 `index` 或 URL 上的 issue number 寫反，測試沒抓到就會變成錯誤的阻擋關係，甚至完全沒有阻擋效果。",
|
||
"reason": "Paladin：可排除（重複）。歷史 findings 已指出 `addIssueDependency` 缺少 endpoint、HTTP method、payload 與相依方向的契約測試，與本條指控相同。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 18:36:02",
|
||
"prNumber": 6,
|
||
"reviewer": "Assassin",
|
||
"severity": "嚴重",
|
||
"file": "src/lib/review.js",
|
||
"startLine": 68,
|
||
"endLine": 75,
|
||
"problem": "AI CLI 失敗時會把 stderr／stdout 片段預設寫進 CI log。攻擊者只要讓工具失敗，且讓 prompt、diff、CLI 錯誤或環境診斷中夾帶未被正規式涵蓋的秘密格式（例如 JWT、雲端憑證、私鑰片段、較短 token、含符號的密碼或 PII），就能把機密永久留在多人可讀的 workflow log。`redactSecrets` 是盡力遮罩，不足以作為洩漏邊界。",
|
||
"reason": "Paladin：可排除（重複）。歷史 findings 已指出 AI CLI 失敗時將 stderr/stdout 寫入 CI log、黑名單式遮罩可繞過，並可能洩漏機密或個資；本條是同一風險。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 18:36:02",
|
||
"prNumber": 6,
|
||
"reviewer": "Assassin",
|
||
"severity": "警告",
|
||
"file": "action.yml",
|
||
"startLine": 22,
|
||
"endLine": 25,
|
||
"problem": "文件改成建議呼叫端傳入可觸發 CI 的 PAT。若 workflow 在 PR head 上執行此 action，或 action 程式碼可被 PR 修改，攻擊者可以把這顆 PAT 當成獵物：改寫 action、讓工具輸出、或藉由執行流程把 token 外送。自動 token 原本的防遞迴限制被 PAT 繞開後，等於把更高權限、更危險的憑證交給不可信變更。",
|
||
"reason": "Paladin：可排除（重複）。歷史 findings 已針對 action.yml 建議使用可觸發 CI 的 PAT，導致不可信 PR 或可修改 action 程式碼時產生憑證外洩與濫用風險提出相同問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 18:36:02",
|
||
"prNumber": 6,
|
||
"reviewer": "Bard",
|
||
"severity": "建議",
|
||
"file": "action.yml",
|
||
"startLine": 3,
|
||
"endLine": 3,
|
||
"problem": "檔案標頭的「更新時間」仍停在 `2026/07/17 18:49:58`，但本次變更內容與提供的檔案最後更新時間已是 `2026/07/20`。這種手寫時間戳像樂譜上的舊拍號，讀者會懷疑文件到底是否同步。",
|
||
"reason": "Paladin：可排除（重複）。歷史 finding 已指出 action.yml 檔頭手寫更新時間與實際版本不一致，屬同一問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 18:36:02",
|
||
"prNumber": 6,
|
||
"reviewer": "Bard",
|
||
"severity": "建議",
|
||
"file": "readme.md",
|
||
"startLine": 3,
|
||
"endLine": 3,
|
||
"problem": "README 的更新時間也停在 `2026/07/17 18:49:58`，與本次文件內容大幅改動不相稱。對讀者而言，這個欄位現在不是資訊，而是噪音。",
|
||
"reason": "Paladin：可排除（重複）。歷史 finding 已指出 README 檔頭手寫更新時間與實際更新不符，屬同一問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 18:36:02",
|
||
"prNumber": 6,
|
||
"reviewer": "Bard",
|
||
"severity": "建議",
|
||
"file": "src/index.js",
|
||
"startLine": 7,
|
||
"endLine": 7,
|
||
"problem": "啟動 banner 的更新時間仍是 `2026/07/17 18:49:58`，但同檔本次新增了大量流程與註解。執行時印出的版本感與實際程式節奏不一致，像開場音還停在舊調。",
|
||
"reason": "Paladin：可排除（重複）。歷史 finding 已指出 src/index.js 啟動橫幅硬編碼更新時間失準，屬同一問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 18:36:02",
|
||
"prNumber": 6,
|
||
"reviewer": "Bard",
|
||
"severity": "建議",
|
||
"file": "readme.md",
|
||
"startLine": 42,
|
||
"endLine": 50,
|
||
"problem": "mermaid 圖用 `S1 -> S3 -> ... -> S8 -> S2 -> S9` 表示延後的步驟 2，節點代號與視覺流程反向交錯。雖然顯示文字能說明「步驟 2 延後」，但閱讀原始 Markdown 時節奏很拗，維護者很容易在後續增修時接錯線。",
|
||
"reason": "Paladin：可排除（重複）。歷史 findings 已涵蓋流程步驟編號硬編碼於 README 與流程圖，造成文件與流程順序高耦合；本條只是針對 Mermaid 節點 ID 的同類表現。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 18:36:02",
|
||
"prNumber": 6,
|
||
"reviewer": "Bard",
|
||
"severity": "建議",
|
||
"file": "src/index.js",
|
||
"startLine": 182,
|
||
"endLine": 238,
|
||
"problem": "`queueOrPostComment` 與 `createIssueAndFlushBufferedComments` 這兩段閉包夾在主流程前奏中，註解、狀態變數與模式分流交織在一起，讓 `main()` 的旋律還沒進入步驟 3 就先變成長篇宣敘。可讀性負擔集中在主流程，後面的步驟編排也因此更難掃描。",
|
||
"reason": "Paladin：可排除（重複）。歷史 finding 已指出 main() 在步驟 3 前被 issueBuffer、issue 與兩個閉包函式打斷，留言路由與 issue 建立細節混入主流程，屬同一可讀性問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 18:36:02",
|
||
"prNumber": 6,
|
||
"reviewer": "Leo",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 180,
|
||
"endLine": 407,
|
||
"problem": "`main()` 這次把留言路由、issue 暫存、標籤挑選、issue 建立、問題發布、PR 回貼、相依設定全部塞進同一個流程函式。半年後要改「建問題模式」其中一段時，維護者必須同時理解 `currentRunCommentIds`、`issueBuffer`、`issue` 閉包狀態與一般模式／建問題模式的分支時序，這會讓錯誤很容易藏在流程順序裡，也很難針對單一行為做單元測試。",
|
||
"reason": "Paladin：可排除（命中已知排除事項且重複）。既有紀錄已涵蓋 main() 內留言路由、issue 狀態、緩衝佇列、標籤、相依關係與發布職責耦合的問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 18:36:02",
|
||
"prNumber": 6,
|
||
"reviewer": "Leo",
|
||
"severity": "警告",
|
||
"file": "src/lib/review.js",
|
||
"startLine": 32,
|
||
"endLine": 48,
|
||
"problem": "`agentFailureDetail` 的文件和實作描述互相打架：前面寫「原始輸出預設隱藏」，下一段又寫預設附上經遮罩的 stderr/stdout，後面還提到 `ACTIONS_STEP_DEBUG=true`，但實作沒有任何 debug 開關。這種註解漂移會讓未來維護者誤判 CI log 會不會輸出 agent 內容，進而在除錯或調整遮罩策略時做錯決策。",
|
||
"reason": "Paladin：可排除（重複）。歷史 findings 已多次指出 agentFailureDetail 文件宣稱預設隱藏原始輸出，卻又描述預設輸出 stderr/stdout 且提到未實作的 ACTIONS_STEP_DEBUG 分支。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 18:36:02",
|
||
"prNumber": 6,
|
||
"reviewer": "Leo",
|
||
"severity": "建議",
|
||
"file": "readme.md",
|
||
"startLine": 76,
|
||
"endLine": 131,
|
||
"problem": "README 的功能列表把分支名稱與原始碼行號硬編在數十個連結裡；這次只是程式碼位移就必須大面積同步改 `#Lxx`。這種文件形態維護成本很高，未來只要函式上方增減幾行，文件就會悄悄指到錯誤位置。",
|
||
"reason": "Paladin：可排除（重複）。歷史 findings 已指出 README 功能列表硬編分支名稱與行號連結，維護成本高且容易漂移。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 18:36:02",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 320,
|
||
"endLine": 386,
|
||
"problem": "建問題模式這次改成「有保留問題才建 issue」、「先暫存工具／diff／角色留言」、「嚴重問題才加相依」、「無保留問題靜默通過」，但 diff 沒看到對應測試。這些是使用者可觀察到的流程分支，尤其 `kept.length === 0`、只有警告／建議、有嚴重問題、`addIssueDependency` 失敗降級，都還沒有被驗證。",
|
||
"reason": "Paladin：可排除（重複）。歷史 findings 已涵蓋建問題模式的 issue 建立條件、暫存留言、嚴重與非嚴重分流、無 finding 靜默通過、標籤或相依 API 失敗等核心分支缺少測試。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 18:36:02",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/lib/gitrepo.js",
|
||
"startLine": 102,
|
||
"endLine": 147,
|
||
"problem": "`resolveMergeBase` 新增多段 fetch／deepen／unshallow 重試策略與診斷錯誤，但沒有看到測試覆蓋淺層 checkout 的失敗路徑。這段邏輯若順序或 refspec 錯，會直接讓審查抓不到正確 diff 基準。",
|
||
"reason": "Paladin：可排除（重複）。歷史 findings 已針對 resolveMergeBase 多階段 fetch、deepen、unshallow、停止條件與最終失敗診斷缺少測試提出相同問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 18:36:02",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/lib/gitrepo.js",
|
||
"startLine": 310,
|
||
"endLine": 340,
|
||
"problem": "`pushWithCredential` 改成用 `GIT_CONFIG_*` 注入 PAT、先清掉 checkout 的 extraheader，且失敗時改丟固定錯誤；這是認證與 CI 觸發的關鍵行為，但缺少測試驗證環境變數、refspec 與錯誤遮蔽。",
|
||
"reason": "Paladin：可排除（重複）。歷史 findings 已涵蓋 pushWithCredential／commitAndPushFindings 的 token 認證推送路徑、refspec、環境變數注入與錯誤遮蔽缺少測試。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 18:36:02",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "建議",
|
||
"file": "src/lib/review.js",
|
||
"startLine": 13,
|
||
"endLine": 73,
|
||
"problem": "新增的 `redactSecrets`／`agentFailureDetail` 會把 AI CLI 的 stderr/stdout 寫進 CI log，雖然有遮罩與限長，但沒有測試驗證常見機密格式、控制字元與長輸出邊界是否真的被處理。",
|
||
"reason": "Paladin：可排除（重複）。歷史 findings 已指出 redactSecrets／agentFailureDetail 對常見憑證格式、URL 帳密、控制字元、截斷與空輸出等邊界缺少測試。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 18:45:35",
|
||
"prNumber": 6,
|
||
"reviewer": "Assassin",
|
||
"severity": "嚴重",
|
||
"file": "src/lib/review.js",
|
||
"startLine": 82,
|
||
"endLine": 85,
|
||
"problem": "攻擊者只要讓 AI CLI 失敗，就有機會把 CLI 的 stderr/stdout 片段寫進 CI log。這些輸出可能回顯送審 diff、prompt、環境診斷、token、JWT、雲端金鑰、私鑰片段或 PII；目前 `redactSecrets` 只是盡力遮罩，漏掉未列舉格式時，秘密會被長期保存在多人可讀的 workflow log。這違反「回應不得含 PII」的邊界，也把失敗路徑變成資料外洩通道。",
|
||
"reason": "Paladin：可排除（重複）。歷史 finding 已針對 AI CLI 失敗時將 stderr/stdout 片段寫入 CI log、黑名單式遮罩不足，以及機密或 PII 外洩風險提出相同問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 18:45:35",
|
||
"prNumber": 6,
|
||
"reviewer": "Assassin",
|
||
"severity": "警告",
|
||
"file": "action.yml",
|
||
"startLine": 17,
|
||
"endLine": 23,
|
||
"problem": "這裡鼓勵呼叫端傳入「能觸發 CI 的 PAT」作為 action token。攻擊者若能提交 PR 並讓 workflow 在不可信程式碼上執行，就會盯上這個高權限 PAT：任何後續工具、腳本、AI CLI 或被 PR 影響的輸出路徑只要有一處外洩，就能拿到可 push、可留言、可觸發 CI 的長效憑證。自動 token 不重觸發 CI 是防遞迴與降權邊界，直接建議 PAT 等於要求使用者拆掉這道邊界。",
|
||
"reason": "Paladin：可排除（重複）。歷史 findings 已指出 action.yml 鼓勵使用可觸發 CI 的 PAT，會在不可信 PR 或受 PR 影響流程中擴大高權限憑證外洩與濫用風險。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 18:45:35",
|
||
"prNumber": 6,
|
||
"reviewer": "Leo",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 180,
|
||
"endLine": 397,
|
||
"problem": "`main()` 這次把留言路由、issue 暫存與建立、標籤挑選、PR 相依設定、舊留言清理、嚴重/非嚴重發布策略全部揉進同一個流程函式。六個月後要調整其中一個落地模式時，維護者必須同時理解 `ctx.createIssue`、`issueBuffer`、`issue`、`currentRunCommentIds` 與步驟順序的隱含關係，很容易在新增一個留言點時漏掉「一般模式要記 id、建問題模式要暫存或發 issue」這類規則。",
|
||
"reason": "Paladin：可排除（命中已知排除事項且重複）。既有紀錄已涵蓋 main() 內留言路由、issue 生命週期、緩衝佇列、發布策略與審查編排耦合，並提出抽離 publisher 類邊界的相同方向。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 18:45:35",
|
||
"prNumber": 6,
|
||
"reviewer": "Leo",
|
||
"severity": "警告",
|
||
"file": "src/lib/review.js",
|
||
"startLine": 21,
|
||
"endLine": 78,
|
||
"problem": "`redactSecrets()` / `agentFailureDetail()` 新增了不少診斷輸出政策與遮罩規則，但目前是未匯出的私有函式。這段邏輯牽涉多種 token 格式、URL 帳密、控制字元與長度截斷，未來一改 regex 就可能讓 CI log 變得難除錯或遮罩失效；若只能透過攻擊方/防守方整段流程間接驗證，測試成本會很高。",
|
||
"reason": "Paladin：可排除（重複）。歷史 findings 已涵蓋 redactSecrets／agentFailureDetail 缺少直接測試、遮罩與截斷邊界難以驗證，以及診斷／遮罩職責放在 review.js 造成模組邊界不清的問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 18:45:35",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 184,
|
||
"endLine": 406,
|
||
"problem": "建問題模式這次新增了多個未驗證的流程分支：留言先暫存到 issueBuffer、確定 kept.length > 0 才建 issue、無保留問題／無可審查變更時靜默通過、嚴重問題才建立 PR 對 issue 的 dependency。這些都是會影響 PR 留言、issue 建立與合併阻擋的核心行為，但 diff 沒看到對應測試；目前如果某個分支漏發、誤發到 PR，或 issue 為 null 時仍呼叫 postSevereToIssue，都不會被試煉攔下來。",
|
||
"reason": "Paladin：可排除（重複）。歷史 findings 已涵蓋建問題模式的暫存留言、kept 為空靜默通過、有問題才建 issue、嚴重與非嚴重分流、dependency 與 PR 回貼等核心分支缺少測試。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 18:45:35",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/lib/gitrepo.js",
|
||
"startLine": 102,
|
||
"endLine": 155,
|
||
"problem": "resolveMergeBase 新增了淺層 checkout 的多段 fetch fallback、每次成功 fetch 後重試 merge-base、以及最終診斷錯誤，但沒有看到測試覆蓋這些邊界與失敗路徑。這段行為依賴 git 指令順序；只要 deepen base 成功後沒有立刻回傳、HEAD 補抓用錯 ref、或全部失敗時沒有保留診斷，PR diff 基準就可能錯或完全中斷，現在沒有測試能驗證。",
|
||
"reason": "Paladin：可排除（重複）。歷史 findings 已針對 resolveMergeBase 的多階段 fetch、shallow／非 shallow 分支、成功停止條件、降級策略與最終診斷缺少測試提出相同問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 18:45:35",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/lib/gitrepo.js",
|
||
"startLine": 270,
|
||
"endLine": 330,
|
||
"problem": "pushWithCredential 改成一律用 GIT_CONFIG_* 注入 Basic extraheader，並刻意清掉 checkout 持久化的自動 token；這是高風險失敗路徑與防洩漏行為，但 diff 沒有測試確認 token 不會出現在 argv、失敗錯誤不含遠端 URL/token、以及 extraheader 的兩筆設定順序正確。",
|
||
"reason": "Paladin：可排除（重複）。歷史 findings 已涵蓋 commitAndPushFindings／pushWithCredential 的認證推送策略、GIT_CONFIG 注入、token 遮蔽與失敗路徑缺少測試。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 18:45:35",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/lib/review.js",
|
||
"startLine": 13,
|
||
"endLine": 75,
|
||
"problem": "agentFailureDetail/redactSecrets 新增了把 AI CLI stderr/stdout 寫入 CI log 的行為，且依賴遮罩、控制字元清理與長度截斷來避免外洩；但沒有看到測試驗證 token、Authorization、URL 內嵌帳密、長字串與換行控制字元都會被處理。這種失敗診斷若測試只看快樂路徑，很容易在某種輸出格式下把秘密寫進 log。",
|
||
"reason": "Paladin：可排除（重複）。歷史 findings 已逐項記錄 agentFailureDetail／redactSecrets 對 Authorization、token、URL 帳密、控制字元、截斷與 debug 開關缺少測試。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 18:45:35",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "建議",
|
||
"file": "src/lib/gitea.js",
|
||
"startLine": 168,
|
||
"endLine": 194,
|
||
"problem": "addIssueDependency 新增了 Gitea endpoint 包裝，但沒有測試確認路徑與 body 的語義：URL 上的 issueNumber 是被阻擋的 PR/issue，body.index 才是 dependency。這個方向如果寫反，流程仍可能收到 2xx 或難以從單次手動測試看出錯誤。",
|
||
"reason": "Paladin：可排除（重複）。歷史 findings 已指出 addIssueDependency 缺少 endpoint、HTTP method、payload 與相依方向測試，與本條指控相同。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 18:45:35",
|
||
"prNumber": 6,
|
||
"reviewer": "Rogue",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 365,
|
||
"endLine": 370,
|
||
"problem": "建問題模式下把 `others` 交給 `review.postOthersToIssue` 逐條發 issue 留言，這是在拿遠端 API latency 燒時間。警告／建議通常可能比嚴重問題多很多，若有 50 條、每次 Gitea API 往返 200ms，光留言就可能多花 10 秒以上，還會增加 rate limit 壓力。",
|
||
"reason": "Paladin：可排除（重複）。歷史 finding 已指出建問題模式將警告／建議逐條發成 issue 留言，會造成 O(n) 遠端 POST、增加 CI 時間與 rate limit 壓力。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/21 13:49:59",
|
||
"prNumber": 6,
|
||
"reviewer": "Assassin",
|
||
"severity": "警告",
|
||
"file": "action.yml",
|
||
"startLine": 19,
|
||
"endLine": 24,
|
||
"problem": "文件鼓勵呼叫端傳入「能觸發 CI 的 PAT」。這把原本自動 token 的防遞迴與範圍限制換成長效、較高權限的秘密。若 workflow 會在不受信任的 PR 程式碼或可被 PR 修改的 action 版本上執行，攻擊者可以在 CI 中讀取或外送 PAT，接著用它 push commit、改 issue、或觸發更多 workflow。",
|
||
"reason": "Paladin：可排除（重複）。歷史 findings 已針對 action.yml 建議使用可觸發 CI 的 PAT 所帶來的長效高權限憑證風險提出相同問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/21 13:49:59",
|
||
"prNumber": 6,
|
||
"reviewer": "Bard",
|
||
"severity": "建議",
|
||
"file": "action.yml",
|
||
"startLine": 2,
|
||
"endLine": 3,
|
||
"problem": "檔頭 `更新時間` 仍寫著 `2026/07/17 18:49:58`，但本次變更描述顯示此檔最後更新為 `2026/07/20 17:24:18`。文件時間戳若成了舊拍子，讀者會開始懷疑整份 manifest 的註解是否也同樣過期。",
|
||
"reason": "Paladin：可排除（重複）。歷史 finding 已指出 action.yml 檔頭手動更新時間容易過期且與實際內容不同。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/21 13:49:59",
|
||
"prNumber": 6,
|
||
"reviewer": "Bard",
|
||
"severity": "建議",
|
||
"file": "src/index.js",
|
||
"startLine": 7,
|
||
"endLine": 7,
|
||
"problem": "啟動 banner 的 `更新時間` 被改成 `2026/07/17 18:49:58`，但這次主流程明顯新增了建 issue、延後解決舊留言等大量段落。這個時間戳像留在舊譜上的小節號，和目前程式內容不再合拍。",
|
||
"reason": "Paladin：可排除（重複）。歷史 finding 已指出 src/index.js 啟動 banner 的手動更新時間與程式實際變更不同，屬同一問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/21 13:49:59",
|
||
"prNumber": 6,
|
||
"reviewer": "Leo",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 180,
|
||
"endLine": 390,
|
||
"problem": "`main()` 這次把建問題模式的暫存留言、issue 建立、標籤挑選、PR 回貼、相依設定、一般模式舊留言清理全部塞進同一個流程函式。半年後要改任何一個輸出通道時，維護者必須重新推演 `ctx.createIssue`、`issue`、`issueBuffer`、`currentRunCommentIds` 與步驟 2 延後執行之間的狀態關係，這會讓主流程變成難以安全修改的編排巨石。",
|
||
"reason": "Paladin：可排除（命中已知排除事項且重複）。main() 內建問題模式狀態、留言路由、issue 建立與發布職責耦合，已由既有排除事項與歷史 findings 涵蓋。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/21 13:49:59",
|
||
"prNumber": 6,
|
||
"reviewer": "Leo",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 199,
|
||
"endLine": 232,
|
||
"problem": "`queueOrPostComment` 透過閉包同時讀寫 `ctx.createIssue`、`issue`、`issueBuffer`、`currentRunCommentIds`，回傳型別也會依狀態變成 `Object|null`。這種隱性狀態機短期能跑，但未來要追「這則留言到底會發到 PR、issue，還是只進 buffer」時，必須靠讀整個 `main()` 的執行順序才能理解。",
|
||
"reason": "Paladin：可排除（重複）。queueOrPostComment 的閉包狀態與留言目的地隱性分流，與既有 main() 留言路由、issue 狀態與緩衝佇列耦合問題相同。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/21 13:49:59",
|
||
"prNumber": 6,
|
||
"reviewer": "Leo",
|
||
"severity": "建議",
|
||
"file": "readme.md",
|
||
"startLine": 76,
|
||
"endLine": 131,
|
||
"problem": "README 的功能列表繼續維護大量硬編碼到 `develop` 分支與精確行號的連結。這次 diff 已經為了行號漂移更新一整片表格；之後任何新增註解、移動函式或插入測試都會讓文件連結過期，維護成本會隨每次重構累積。",
|
||
"reason": "Paladin：可排除（重複）。歷史 findings 已多次指出 README 大量硬編 develop 分支與精確行號連結，會隨程式碼移動失準。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/21 13:49:59",
|
||
"prNumber": 6,
|
||
"reviewer": "Mage",
|
||
"severity": "嚴重",
|
||
"file": "src/index.js",
|
||
"startLine": 409,
|
||
"endLine": 418,
|
||
"problem": "建問題模式下若有嚴重問題但 `exclusions.json` 沒變更，`filesToCommit` 會是空陣列，流程會走到「略過 commit/push」後直接 `return 0`。最小重現：`create-issue=true`、攻擊方保留 1 條 `severity: '嚴重'`、防守方沒有排除任何 finding，因此 `exclusionsChanged=false`。此時本輪檢查成功，且沒有推出 `[ai-review-bot][failure]` commit 觸發下一輪步驟 1 回報失敗；若 issue dependency API 未啟用或設定失敗，嚴重問題不會阻擋合併。",
|
||
"reason": "Paladin：可排除（重複）。與 F001 指涉同一個建問題模式下嚴重 finding 可能未產生可阻擋失敗訊號、最後回傳成功的問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/21 13:49:59",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 323,
|
||
"endLine": 390,
|
||
"problem": "建問題模式的核心流程新增了多個可觀察行為，但目前測試沒有驗證：有保留問題才建立 issue、無保留問題靜默通過、暫存的工具／diff／角色留言會 flush 到 issue、PR 只回貼 issue 連結、且只有嚴重問題才呼叫 `addIssueDependency`。這些都是本次 PR 新增／改動的主要行為，沒有試煉過就等於還沒完成。",
|
||
"reason": "Paladin：可排除（重複）。歷史 findings 已涵蓋建問題模式有問題才建 issue、無問題靜默通過、暫存留言 flush、PR 回貼與嚴重問題相依設定等核心分支缺少測試。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/21 13:49:59",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/lib/gitrepo.js",
|
||
"startLine": 130,
|
||
"endLine": 190,
|
||
"problem": "`resolveMergeBase` 新增了多段 fetch 補歷史策略、每步後重試 merge-base、淺層 repo 才 `--unshallow`、以及失敗診斷彙整，但新增測試只驗證不安全 `baseRef` 會被拒絕，沒有覆蓋這些成功與失敗路徑。這裡最怕的是淺層 checkout 或 PR head 歷史不足時，實際 CI 才發現 fetch 順序或 refspec 錯了。",
|
||
"reason": "Paladin：可排除（重複）。歷史 findings 已針對 resolveMergeBase 的多階段 fetch、淺層／非淺層分支、停止條件、降級與最終失敗診斷缺少測試提出相同問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/21 13:49:59",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/lib/gitrepo.js",
|
||
"startLine": 303,
|
||
"endLine": 358,
|
||
"problem": "推送結果 commit 的認證方式改成 `pushWithCredential`：不走 origin、自訂 `GIT_CONFIG_*` extraheader、先清掉 checkout token、URL origin 必須相符、失敗時隱藏遠端與 token。這些安全與 CI 觸發相關行為目前完全沒有測試；現有 `gitrepo.test.js` 只測分支名稱驗證。",
|
||
"reason": "Paladin：可排除（重複）。歷史 findings 已記錄 commitAndPushFindings／pushWithCredential 的 token 認證推送路徑、推送目標、錯誤遮蔽與安全行為缺少測試。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/21 14:27:42",
|
||
"prNumber": 6,
|
||
"reviewer": "Assassin",
|
||
"severity": "嚴重",
|
||
"file": "src/lib/diagnostics.js",
|
||
"startLine": 23,
|
||
"endLine": 23,
|
||
"problem": "攻擊者只要讓 AI CLI 在 debug 模式下把 `Authorization: token <secret>` 或 `Authorization: Basic <base64>` 印到 stderr/stdout，這條遮罩規則只會遮掉 `token`／`Basic` 這個 scheme，後面的真正憑證仍會進 CI log。這正好打穿本檔宣稱的「安全診斷」防線，PAT 或 API token 會被長期保存並暴露給可讀 log 的人。",
|
||
"reason": "Paladin：可排除（重複）。歷史 finding 已指出除錯診斷輸出中 Authorization 遮罩規則可能只遮到 scheme、留下後方憑證，並造成 CI log 洩漏，與本條同一問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/21 14:27:42",
|
||
"prNumber": 6,
|
||
"reviewer": "Leo",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 181,
|
||
"endLine": 239,
|
||
"problem": "`main()` 這次把「PR 留言」、「issue 暫存」、「issue 建立後 flush」三種狀態直接塞進閉包變數 `currentRunCommentIds`、`issueBuffer`、`issue` 與 `queueOrPostComment()`。未來只要再新增一種落地方式或調整留言順序，維護者必須同時理解整個主流程的時序，否則很容易出現留言漏發、舊留言誤標、或 issue 尚未建立卻被使用的狀態錯誤。這段已經不是單純編排，而是隱含一個留言發布狀態機。",
|
||
"reason": "Paladin：可排除（命中已知排除事項且重複）。既有紀錄已涵蓋 main() 內留言路由、issue 狀態、緩衝佇列與發布狀態機耦合的同一問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/21 14:27:42",
|
||
"prNumber": 6,
|
||
"reviewer": "Leo",
|
||
"severity": "警告",
|
||
"file": "readme.md",
|
||
"startLine": 56,
|
||
"endLine": 132,
|
||
"problem": "README 這次把大量連結從 `branch/master` 改成 `branch/develop`，同時保留許多硬編碼行號。這種文件會隨分支名稱、預設分支、或任一檔案插入幾行就整批失準；未來維護者每次調整程式都得同步修幾十個 URL，否則文件看起來精準、實際上卻導到錯誤位置。",
|
||
"reason": "Paladin：可排除（重複）。歷史 findings 已多次指出 README 大量硬編 branch 與行號深連結，造成文件與原始碼高同步成本；本條為同一問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/21 14:27:42",
|
||
"prNumber": 6,
|
||
"reviewer": "Mage",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 217,
|
||
"endLine": 225,
|
||
"problem": "建問題模式先建立 issue，再逐則 flush `issueBuffer`，但中途任一留言 API 失敗會直接拋出，沒有回滾或冪等處理。最小重現：`gitea.createIssue` 成功建立 #10，第一則 buffered comment 成功，第二則因 500/timeout 失敗 → 主流程 exit 1，PR 沒有 issue 連結、也沒有結果 commit；重跑時又建立 #11，留下半成品 issue #10。這會在暫時性 API 錯誤下造成重複追蹤 issue 與狀態不一致。",
|
||
"reason": "Paladin：可排除（命中已知排除事項且重複）。issue 建立後 flush 暫存留言失敗、重跑又建立重複 issue，正是已知排除事項與多筆歷史 findings 已記錄的問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/21 14:27:42",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 180,
|
||
"endLine": 241,
|
||
"problem": "建問題模式新增了「先暫存留言、確定有保留問題才建立 issue、再 flush 暫存留言」的流程，但目前新增測試只驗到低階 helper，沒有驗證主流程在 create-issue=true 時的留言去向與靜默通過行為。這裡若順序錯了，可能會把原本應該留在 issue 的工具／diff／角色留言發到 PR，或在無保留問題時留下不該出現的 PR 留言。",
|
||
"reason": "Paladin：可排除（重複）。歷史 findings 已涵蓋 create-issue 模式中留言先暫存、issue 建立後依序寫入、無 finding 靜默通過與一般模式留言目的地缺少主流程測試。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/21 14:27:42",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 354,
|
||
"endLine": 395,
|
||
"problem": "新增的建問題模式會依嚴重度分流：嚴重問題改發到 issue、PR 回貼 issue 連結，且只有嚴重問題才呼叫 `addIssueDependency`。目前測試沒有覆蓋這個決策矩陣，等於沒有驗證「警告／建議不阻擋合併」與「嚴重問題要建立相依」這兩個關鍵行為。",
|
||
"reason": "Paladin：可排除（重複）。歷史 findings 已涵蓋建問題模式的嚴重／非嚴重分流、PR 回貼、相依 API 降級與核心分支缺少測試；本條屬同一測試缺口。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/21 14:27:42",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/lib/gitrepo.js",
|
||
"startLine": 130,
|
||
"endLine": 188,
|
||
"problem": "`resolveMergeBase` 新增了多段 fetch 補歷史策略、每次補抓後重試 merge-base、以及淺層 repo 才執行 `--unshallow` 的行為，但測試只驗證不安全 baseRef 會被拒絕，沒有驗證這些成功／失敗路徑。這段是 diff 基準的核心，一旦 fallback 順序或條件壞掉，review 可能拿錯範圍或在 shallow checkout 直接失敗。",
|
||
"reason": "Paladin：可排除（重複）。歷史 findings 已針對 resolveMergeBase 多階段 fetch、shallow 與非 shallow 分支、停止條件、降級與最終失敗診斷缺少測試提出相同問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/21 14:27:42",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/lib/gitrepo.js",
|
||
"startLine": 331,
|
||
"endLine": 366,
|
||
"problem": "`pushWithCredential` 是這次結果 commit 能否用 PAT 觸發下一輪 CI 的關鍵，但目前沒有測試驗證它真的清掉 checkout 的自動 token、再注入 PAT Authorization，也沒有測失敗時不外洩 remote URL／token。這條失敗路徑沒被試煉過，可能讓 `[failure]` 結果 commit 無法觸發快速回報，或在錯誤訊息裡洩漏認證資訊。",
|
||
"reason": "Paladin：可排除（重複）。歷史 findings 已涵蓋 pushWithCredential／commitAndPushFindings 的認證推送策略、token 注入、推送目標與失敗時不外洩 token 或 URL 的測試缺口。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/21 14:27:42",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "建議",
|
||
"file": "src/lib/diagnostics.js",
|
||
"startLine": 21,
|
||
"endLine": 32,
|
||
"problem": "`redactSecrets` 新增多個遮罩規則與控制字元單行化，但測試只透過 `agentFailureDetail` 間接覆蓋 Authorization 與 token 兩種格式。URL 內嵌帳密、長 token、GitHub token 樣式、控制字元注入與 null/undefined 邊界都還沒被直接驗證。",
|
||
"reason": "Paladin：可排除（重複）。歷史 findings 已記錄失敗診斷與 redactSecrets 對 Authorization、URL 帳密、token 格式、控制字元、截斷與空值邊界缺少測試；本條為同一測試缺口。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/21 14:42:39",
|
||
"prNumber": 6,
|
||
"reviewer": "Bard",
|
||
"severity": "建議",
|
||
"file": "src/index.js",
|
||
"startLine": 179,
|
||
"endLine": 212,
|
||
"problem": "`queueOrPostComment` 與 `createIssueAndFlushBufferedComments` 這兩個閉包名稱像兩段不同旋律：一個強調「排隊或發布」，另一個卻把「建立 issue、flush 暫存留言、設定狀態」全塞進名稱與實作。讀者要來回追 `trackingIssue`、`pendingIssueCommentBodies`，節奏偏長且語意負擔重。",
|
||
"reason": "Paladin：可排除（重複）。歷史 finding 已指出 main() 內新增閉包與 issue/comment 路由細節讓主流程閱讀負擔加重；本條只是改以目前函式名稱描述同一維護性問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/21 14:42:39",
|
||
"prNumber": 6,
|
||
"reviewer": "Leo",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 165,
|
||
"endLine": 213,
|
||
"problem": "`main()` 這次把「留言目的地切換、issue 建立、暫存留言 flush、標籤挑選前置狀態」都塞進閉包與可變狀態（`pendingIssueCommentBodies`、`trackingIssue`、`currentRunCommentIds`）。半年後要改建問題模式時，維護者得同時追蹤主流程步驟、閉包副作用與留言落點，任何新增留言點都可能忘記處理 queue/flush 或 PR 排除清單，長期會讓流程編排變得很脆弱。",
|
||
"reason": "Paladin：可排除（命中已知排除事項且重複）。已知與歷史 findings 已涵蓋 main() 內留言目的地、issue 狀態、緩衝佇列與可變閉包耦合，及應抽出發布器／sink 的方向。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/21 14:42:39",
|
||
"prNumber": 6,
|
||
"reviewer": "Leo",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 302,
|
||
"endLine": 353,
|
||
"problem": "建問題模式的收束邏輯把「挑標籤、建立 issue、發 finding、回貼 PR、設定 issue dependency、決定是否阻擋合併」全部展開在 `main()`。這段和前面的 `createIssueAndFlushBufferedComments` 共同組成一條隱性的 issue workflow，但邊界沒有被封裝；未來要新增 issue 模板、改排序、改阻擋條件或重試策略時，會在主流程裡到處補條件，維護成本會快速上升。",
|
||
"reason": "Paladin：可排除（重複）。此條與 F006 及歷史 findings 同樣指向建問題模式在 main() 中承擔 issue workflow、發布分流與狀態管理，屬同一維護性問題的延伸描述。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/21 14:42:39",
|
||
"prNumber": 6,
|
||
"reviewer": "Leo",
|
||
"severity": "建議",
|
||
"file": "readme.md",
|
||
"startLine": 56,
|
||
"endLine": 132,
|
||
"problem": "README 內大量維護到原始碼行號的連結，這次 diff 只是分支與行號位移就需要同步改一整片表格。這種文件和程式碼行號的硬耦合很容易在後續修改時過期，讀者點到錯誤位置，維護者也要花時間做機械式同步。",
|
||
"reason": "Paladin：可排除（重複）。歷史 findings 已多次指出 README 功能表硬編分支與行號連結，導致文件與原始碼高度耦合且容易失準。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/21 14:42:39",
|
||
"prNumber": 6,
|
||
"reviewer": "Mage",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 251,
|
||
"endLine": 253,
|
||
"problem": "無可審查變更的分支在一般模式下會先把舊留言標為過時，之後才保存 findings 與 commit/push 結果。最小重現：`files.length === 0`、`nothingToReviewComment` 成功、`resolveOldComments` 成功，但接著 `saveFindings` 因檔案系統錯誤或 `commitFindings` 因 push 失敗拋例外。此時舊審查結果已被標過時，但沒有成功落地本回合的 success 結果 commit，狀態會停在半更新。",
|
||
"reason": "Paladin：可排除（命中已知排除事項）。維護者已裁示舊留言應刻意在本回合結果發布前標為過時；本條要求延後清理，落在同一已排除範圍。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/21 14:42:39",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 160,
|
||
"endLine": 353,
|
||
"problem": "建問題模式的主流程被大幅改寫，但目前測試只驗證了少數 helper，沒有驗證「留言先暫存、確定有 kept finding 才建 issue、無保留問題時靜默通過、嚴重問題才加 issue dependency、最後回貼 PR 連結」這些新增流程。這些行為一旦順序或條件寫錯，測試不會擋下來。",
|
||
"reason": "Paladin：可排除（重複）。歷史 findings 已涵蓋建問題模式 main() 層級流程缺測試，包括暫存留言、有 finding 才建 issue、無 finding 靜默、PR 回貼、嚴重與非嚴重分流及 dependency 失敗降級。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/21 14:42:39",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/lib/gitrepo.js",
|
||
"startLine": 307,
|
||
"endLine": 361,
|
||
"problem": "`pushWithCredential` 新增了關鍵認證行為，但沒有測試驗證它真的用 `GIT_CONFIG_*` 清掉 checkout 的 extraheader、再注入 PAT Authorization，也沒有測試遠端 URL 不符與 push 失敗時不洩漏 URL/token 的失敗路徑。這段是結果 commit 能否觸發下一輪 CI 的核心，沒有測試等於這個新契約還沒通過試煉。",
|
||
"reason": "Paladin：可排除（重複）。歷史 findings 已記錄 pushWithCredential／pushToken 認證推送路徑缺少測試，包含 token 不進 argv、認證遮蔽、推送目標與失敗訊息不洩漏敏感資訊。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/21 14:42:39",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"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、成功後會短路，也沒有覆蓋所有策略失敗時的診斷錯誤。",
|
||
"reason": "Paladin：可排除（重複）。歷史 findings 已針對 resolveMergeBase 多階段 fetch、淺層與非淺層分支、成功短路、降級順序與最終失敗診斷缺測試提出相同問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/21 14:42:39",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "建議",
|
||
"file": "src/lib/diagnostics.js",
|
||
"startLine": 18,
|
||
"endLine": 69,
|
||
"problem": "`redactSecrets` 與 `agentFailureDetail` 是新加入的安全診斷防線，但測試只覆蓋 Authorization/token 的基本遮罩。控制字元單行化、URL 內嵌帳密、長 token/hex、輸入與輸出長度截斷、以及沒有 error code 時的 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；較大規模的可測性重構屬後續設計工作，本次僅套用可安全的淺層判斷效能修正。"
|
||
}
|
||
]
|