chore(ai-review 狀態): 回寫本輪已處理 findings

fix(ai-review): 對齊建問題模式留言順序與命名
chore: update ai-review findings [ai-review-bot][failure]
2026-07-21 14:39:42 +08:00 · 2026-07-21 14:39:42 +08:00 · 2026-07-21 06:27:43 +00:00 · 2026-07-21 14:24:14 +08:00 · 2026-07-21 14:24:10 +08:00 · 2026-07-21 14:24:04 +08:00
21 changed files with 2730 additions and 299 deletions
@@ -8,19 +8,6 @@
    "model": "（工具預設）"
  },
  "findings": [
    {
      "id": "F001",
      "reviewer": "Leo",
      "focus": "maintainability",
      "badge": "🧰",
      "severity": "警告",
      "file": "src/index.js",
      "startLine": 210,
      "endLine": 224,
      "problem": "`ensureIssueCreated` 同時建立 issue、修改外層 `issue` 狀態、逐筆清空 `issueBuffer`，但整段流程沒有可重入或冪等機制。若 issue 建立成功後，寫入其中一則暫存留言時失敗，主流程會中止；重跑後又會建立另一個 issue，留下內容不完整的孤兒 issue。這種依賴閉包可變狀態的半完成狀態，半年後要加入重試、續傳或測試失敗情境都會很痛苦。",
      "suggestion": "把「建立追蹤 issue 並沖刷留言」抽成獨立、可注入 Gitea client 的服務函式，明確回傳 issue 與已寫入進度；建立前以 PR 編號或隱藏識別標記查找既有追蹤 issue，讓重跑能接續而非重複建立。至少也應保留已建立的 issue 編號並在錯誤訊息中回報，避免留下無法追蹤的半成品。",
      "suggestedCode": ""
    },
    {
      "id": "F002",
      "reviewer": "Maya",
@@ -34,19 +21,6 @@
      "suggestion": "新增主流程測試並 mock Gitea、agent 與 git 操作，至少涵蓋：`kept=[]` 時不建立 issue 且不留言；僅嚴重問題；僅警告／建議；混合問題；建立 issue 或寫入暫存留言失敗；標籤查詢、AI 選標籤及補掛標籤失敗時仍回貼 issue 連結。除了呼叫次數，也應斷言 API 呼叫順序、目標 issue 編號及留言內容。",
      "suggestedCode": ""
    },
    {
      "id": "F003",
      "reviewer": "Maya",
      "focus": "testing",
      "badge": "🧪",
      "severity": "警告",
      "file": "src/lib/gitea.js",
      "startLine": 188,
      "endLine": 191,
      "problem": "新增的 `addLabelsToIssue` 沒有對應測試，尚未驗證空值捷徑與實際 API 請求格式。這個函式位於新建問題流程的收尾路徑；若 endpoint、HTTP method 或 `{ labels }` payload 不符預期，追蹤 issue 將無法取得標籤，而空陣列是否真的不發出請求也未被保護。",
      "suggestion": "新增單元測試，分別傳入 `undefined`、`null`、空陣列及多個 label id；斷言前三者回傳 `null` 且完全不呼叫 API，多個 id 時以 POST 呼叫正確的 owner／repo／issue endpoint 並傳送 `{ labels: [...] }`，另驗證 API 拋錯會原樣往上傳遞。",
      "suggestedCode": ""
    },
    {
      "id": "F004",
      "reviewer": "Maya",
@@ -59,19 +33,6 @@
      "problem": "`resolveMergeBase` 新增多階段 fetch 與淺層 checkout 修復邏輯，但沒有看到測試驗證成功、降級與最終失敗路徑。尤其初次 merge-base 失敗後，淺層與非淺層 repository 會走不同路徑，且多個 `tryGit` 失敗會被刻意吞掉；若參數、refspec 或重試順序有誤，只會在實際 CI checkout 深度不足時才暴露。",
      "suggestion": "以 stub 的 git 執行器或暫存 repository 補齊案例：首次 merge-base 成功；淺層 repository 經 `--unshallow` 後成功；`--unshallow` 失敗但 `--deepen=1000` 後成功；非淺層首次失敗後重試成功；所有策略失敗時拋出含 `baseRef` 且保留原始 `cause` 的錯誤。並斷言 base/head fetch 的 refspec 與執行順序。",
      "suggestedCode": ""
    },
    {
      "id": "F005",
      "reviewer": "Maya",
      "focus": "testing",
      "badge": "🧪",
      "severity": "建議",
      "file": "src/lib/review.js",
      "startLine": 17,
      "endLine": 45,
      "problem": "新增的 agent 失敗診斷涵蓋逾時、數字或字串 exit code、signal、空輸出及 500 字截斷等多個邊界，但沒有測試鎖定輸出。這些資訊只在失敗路徑出現，正常審查不會自然覆蓋；日後修改時可能悄悄遺失真正的 CLI 錯誤內容，或破壞單行與截斷約束。",
      "suggestion": "將摘要邏輯匯出供測試，或透過失敗的 `runAttackers`／`runDefenders`／`fillPurposes` 測試間接斷言 log。至少覆蓋 killed、數字 exit code、字串 code、signal、stderr 與 stdout 同時存在、超過 500 字、完全無資訊，以及 `res` 為 null／undefined 的案例。",
      "suggestedCode": ""
    }
  ],
  "excluded": []
@@ -0,0 +1,65 @@
 {
  "generatedAt": "2026/07/20 15:57:46",
  "commitSha": "a6534ee0764fe2363ebbb5525586ad3868dc6720",
  "prNumber": 6,
  "tool": {
    "name": "code-review-resolve",
    "version": "0.0.8",
    "model": "（工具預設）"
  },
  "findings": [
    {
      "id": "F003",
      "reviewer": "Maya",
      "focus": "testing",
      "badge": "🧪",
      "severity": "警告",
      "file": "src/index.js",
      "startLine": 184,
      "endLine": 245,
      "problem": "建問題模式新增「issue 建立前暫存留言、建立後依序沖刷」的狀態流程，但沒有對應測試。尚未驗證 createIssue 或沖刷途中拋錯、空 buffer、重複呼叫、以及一般／建問題模式留言目的地是否正確；失敗路徑可能造成 issue 已建立但內容不完整或留言誤發到 PR。",
      "suggestion": "補主流程整合測試並 mock Gitea API，驗證：一般模式直接發 PR 且記錄留言 id；issue 未建立時只暫存；建立後依序沖刷並清空 buffer；createIssue 與第 N 則沖刷留言失敗時以失敗結束且不再發布後續內容。屬測試架構決策（專案目前無測試框架）。",
      "suggestedCode": ""
    },
    {
      "id": "F004",
      "reviewer": "Maya",
      "focus": "testing",
      "badge": "🧪",
      "severity": "警告",
      "file": "src/index.js",
      "startLine": 309,
      "endLine": 395,
      "problem": "建問題模式核心分支被大幅改寫，但沒有測試驗證各種 findings 組合與 API 失敗行為。kept.length===0、只有嚴重、只有警告／建議、兩者皆有，以及標籤挑選／issue 建立／PR 回貼連結／相依 API 失敗等路徑尚未試煉，無法確認「無問題完全靜默」「有問題才建 issue」及相依失敗僅降級等契約成立。",
      "suggestion": "以參數化測試覆蓋 findings 四種組合，斷言 API 呼叫順序／次數／issue number／統計；並分別讓 listLabels／selectLabels／createIssue／問題留言／PR 連結留言／addIssueDependency 拋錯，驗證哪些中止、哪些僅記警告續行；零 findings 時斷言所有寫入 API 皆不呼叫。屬測試架構決策。",
      "suggestedCode": ""
    },
    {
      "id": "F006",
      "reviewer": "Maya",
      "focus": "testing",
      "badge": "🧪",
      "severity": "警告",
      "file": "src/lib/gitrepo.js",
      "startLine": 103,
      "endLine": 157,
      "problem": "resolveMergeBase 新增多階段 fetch／重試策略，卻沒有測試鎖定淺層與失敗路徑：首次成功提早返回、非 shallow 不 unshallow、某次 fetch 失敗後仍嘗試下一策略、補抓成功立即停止、全部失敗時診斷與 cause 是否完整；易因呼叫順序或 off-by-one 在 runner 上才暴露。",
      "suggestion": "將 git 執行器注入或 stub，建立表格化案例覆蓋首次成功／unshallow 後成功／deepen base 後成功／deepen HEAD 後成功／各 fetch 個別失敗／全部失敗；逐案斷言 git 參數與順序、成功後不再額外 fetch，並檢查最終錯誤含各策略成敗摘要且保留首次錯誤為 cause。屬可測性重構＋測試架構決策。",
      "suggestedCode": ""
    },
    {
      "id": "F007",
      "reviewer": "Maya",
      "focus": "testing",
      "badge": "🧪",
      "severity": "警告",
      "file": "src/lib/gitrepo.js",
      "startLine": 249,
      "endLine": 289,
      "problem": "推送流程新增 pushToken 分支，但沒有測試驗證兩套認證策略：有 PAT 時略過 origin、PAT 推送失敗不退回其他 token、無 PAT 時 origin 成功不重試、origin 失敗才用一般 token；也沒有案例保護含憑證資訊不出現在錯誤或測試輸出中。（本次已將認證改經 env 傳入並遮蔽 push 錯誤，測試仍待補。）",
      "suggestion": "mock git 執行器與 URL／env 組裝，補測 pushToken 有值／空、origin 成功／失敗、PAT 推送失敗及含特殊字元等案例；斷言 push 目標與呼叫次數，並確保任何拋出的錯誤、log 或快照都不含原始 token。屬測試架構決策。",
      "suggestedCode": ""
    }
  ],
  "excluded": []
 }
@@ -0,0 +1,104 @@
 {
  "generatedAt": "2026/07/20 17:37:54",
  "commitSha": "3ef8a302911c60b9f71024e1f4b60e0d4578b8fd",
  "prNumber": 6,
  "tool": {
    "name": "code-review-resolve",
    "version": "0.0.8",
    "model": "（工具預設）"
  },
  "findings": [
    {
      "id": "F001",
      "reviewer": "Leo",
      "focus": "maintainability",
      "badge": "🧰",
      "severity": "警告",
      "file": "src/index.js",
      "startLine": 121,
      "endLine": 145,
      "problem": "流程步驟編號硬編碼在主流程註解、日誌字串、README 與多個函式 JSDoc 中；插入一個步驟就要同步修改大量檔案，文件與實作高耦合，日後調整流程易漏改而互相矛盾。",
      "suggestion": "共用函式 JSDoc 改以語意階段名稱描述、不引用易變動的數字；日誌集中定義階段名稱或由單一流程描述產生編號；README 流程圖也以語意名稱為主。屬跨檔重構＋設計取捨。",
      "suggestedCode": "const STAGE = Object.freeze({\n  TOOL_DETECTION: '偵測工具',\n  DIFF_COLLECTION: '整理差異',\n  ATTACK_REVIEW: '攻擊方審查',\n  DEFENSE_REVIEW: '防守方裁決',\n});\nlog(STAGE.DIFF_COLLECTION, 'INF', message);"
    },
    {
      "id": "F003",
      "reviewer": "Leo",
      "focus": "maintainability",
      "badge": "🧰",
      "severity": "警告",
      "file": "src/lib/gitrepo.js",
      "startLine": 47,
      "endLine": 65,
      "problem": "tryGit 將所有 git 失敗壓成布林值，resolveMergeBase 的診斷只知策略成敗、無法區分認證／refspec／網路／版本問題；CI 出錯時維護者只能重跑或自行重現，診斷成本高。",
      "suggestion": "讓嘗試結果保留結構化且已清理的錯誤分類（exit code、git 子命令、安全化後短訊息），仍避免記錄遠端 URL 或憑證；最終錯誤彙整足以行動的原因，並可對各失敗類型做單元測試。屬診斷重構＋需測試。",
      "suggestedCode": "function tryGit(cwd, ...args) {\n  try {\n    git(cwd, ...args);\n    return { ok: true };\n  } catch (error) {\n    return { ok: false, code: error.status ?? error.code ?? null, reason: sanitizeGitError(error) };\n  }\n}"
    },
    {
      "id": "F004",
      "reviewer": "Maya",
      "focus": "testing",
      "badge": "🧪",
      "severity": "警告",
      "file": "src/lib/gitrepo.js",
      "startLine": 270,
      "endLine": 291,
      "problem": "findings 推送的認證路徑沒有測試。註：原「PAT 直接推送 vs origin 失敗重試」雙路徑已於先前 commit 合併為「一律以 token 明確認證推送」，測試仍待補：空 token 邊界、推送目標正確、錯誤與輸出不含 token 原文。",
      "suggestion": "補單元測試攔截 git 參數／env：斷言以 token 認證推送、推送目標 refspec 正確、呼叫次數，並確保任何拋出的錯誤、log 或快照都不含原始 token。屬測試架構決策。",
      "suggestedCode": ""
    },
    {
      "id": "F005",
      "reviewer": "Bard",
      "focus": "style",
      "badge": "🎼",
      "severity": "建議",
      "file": "action.yml",
      "startLine": 3,
      "endLine": 3,
      "problem": "檔頭「更新時間」為手動維護的固定字串，與實際檔案更新時間不一致；散落各檔的手動時間戳容易走調，讀者無法判斷可信度。",
      "suggestion": "屬 jsc spec-time-log 慣例（各檔頭「更新時間」由 doc-funcs 流程統一產生／同步）。是否移除改用版控紀錄、或如何統一更新，宜由 doc-funcs 流程處理，不在 resolve 逐條硬改。",
      "suggestedCode": ""
    },
    {
      "id": "F006",
      "reviewer": "Bard",
      "focus": "style",
      "badge": "🎼",
      "severity": "建議",
      "file": "readme.md",
      "startLine": 3,
      "endLine": 3,
      "problem": "README 檔頭手動「更新時間」與實際更新時間不符，並與 action.yml、src/index.js 重複保存同類易過期資訊，形成多個不一致的真相來源。",
      "suggestion": "同 F005：屬 jsc spec-time-log 慣例，交 doc-funcs 流程統一維護（移除或自動注入）。",
      "suggestedCode": ""
    },
    {
      "id": "F007",
      "reviewer": "Bard",
      "focus": "style",
      "badge": "🎼",
      "severity": "建議",
      "file": "src/index.js",
      "startLine": 7,
      "endLine": 7,
      "problem": "啟動橫幅硬編碼的「更新時間」與程式實際更新時間不一致，每次改程式都要人工校準，製造噪音並讓執行日誌呈現失真版本資訊。",
      "suggestion": "同 F005：屬 jsc spec-time-log 慣例，交 doc-funcs 流程統一維護；若日誌需辨識版本，可改顯示 CI 注入的 commit SHA／版本號（屬慣例調整）。",
      "suggestedCode": ""
    },
    {
      "id": "F008",
      "reviewer": "Bard",
      "focus": "style",
      "badge": "🎼",
      "severity": "建議",
      "file": "src/index.js",
      "startLine": 179,
      "endLine": 231,
      "problem": "main() 內新增兩個帶完整 JSDoc 的閉包函式與一大段「步驟 2：延後執行」說明，使主流程在進入步驟 3 前被近六十行細節打斷，留言路由、issue 建立與流程說明混在同一層，閱讀節奏沉重。",
      "suggestion": "將留言路由與 issue 建立封裝成具語義名稱的輔助物件／模組（例如 createCommentPublisher），讓 main() 只保留流程級呼叫；延後清理理由縮成貼近呼叫點的簡短註解。與 F001（語意階段名稱）同屬主流程重構，宜一併處理。",
      "suggestedCode": "const comments = createCommentPublisher({ ctx, gitea });\nawait comments.post(templates.toolComment({ /* ... */ }));"
    }
  ],
  "excluded": []
 }
@@ -0,0 +1,39 @@
 {
  "generatedAt": "2026/07/20 18:00:02",
  "commitSha": "d354f30c270e99baa9dcfc6aa76510710c0193ca",
  "prNumber": null,
  "tool": {
    "name": "code-review-resolve",
    "version": "0.0.8",
    "model": "（工具預設）"
  },
  "findings": [
    {
      "id": "F001",
      "reviewer": "🧰 Leo",
      "focus": "maintainability",
      "badge": "🧰",
      "severity": "警告",
      "file": "src/index.js",
      "startLine": 257,
      "endLine": 307,
      "problem": "流程步驟編號同時硬編碼在 log 字串、區段註解、JSDoc、README 與多個函式庫中。插入或調整一個步驟就必須跨大量檔案全面改號，容易讓文件與實際紀錄不一致。",
      "suggestion": "程式內改用穩定的語意階段名稱（如 diff、attack、defend、publish），由單一流程定義集中決定顯示順序；JSDoc 以階段名稱互相引用，README 流程圖由同一份階段資料產生或僅在文件層維護展示編號。",
      "suggestedCode": "const PHASE = Object.freeze({\n  RESOLVE_OLD: '清理舊留言',\n  DETECT_TOOL: '偵測工具',\n  COLLECT_DIFF: '整理差異',\n  ATTACK: '攻擊方審查',\n  DEFEND: '防守方裁決',\n});\n\nlog(PHASE.COLLECT_DIFF, 'INF', `變更檔案 ${allFiles.length} 個…`);"
    },
    {
      "id": "F002",
      "reviewer": "🧪 Maya",
      "focus": "testing",
      "badge": "🧪",
      "severity": "警告",
      "file": "src/lib/gitrepo.js",
      "startLine": 252,
      "endLine": 289,
      "problem": "commitAndPushFindings 的推送行為（有無變更、認證方式、空 commit 防護、是否觸發 CI）缺少測試證明。此為本次變更的核心行為，卻沒有任何測試覆蓋。",
      "suggestion": "mock git 命令，斷言：無 staged diff 時回傳 false 且不執行 commit／push；有變更時以認證方式推送到正確 refspec 與分支。注意：原 finding 描述的 pushToken 對比 origin 雙軌邏輯已於重構後移除（現行一律以 token 經 pushWithCredential 認證推送），撰寫測試前需依現行程式碼重新界定情境。",
      "suggestedCode": ""
    }
  ],
  "excluded": []
 }
@@ -0,0 +1,209 @@
 {
  "generatedAt": "2026/07/20 18:31:07",
  "commitSha": "0c29daa01434d6b6fa1b20ce81c513c75b1b1c6a",
  "prNumber": null,
  "tool": {
    "name": "code-review-resolve",
    "version": "0.0.9",
    "model": "（工具預設）"
  },
  "findings": [
    {
      "id": "F001",
      "reviewer": "Leo",
      "focus": "",
      "badge": "🧰",
      "severity": "警告",
      "file": "src/index.js",
      "startLine": 119,
      "endLine": 139,
      "problem": "流程步驟編號被當成跨模組識別值，散落在 `index.js`、各 library 的日誌與 JSDoc、README 流程圖及功能表。這次僅因插入並延後一步，就必須同步修改大量 `步驟2`～`步驟8` 字串，而且實際執行順序已變成 1、3～8、2、9～10；未來再調整流程時非常容易讓文件、日誌與程式碼脫節。",
      "suggestion": "以穩定的語意階段名稱取代硬編碼序號，例如 `TOOL_DETECTION`、`COLLECT_DIFF`、`RESOLVE_OLD_COMMENTS`，由單一常數表集中決定顯示名稱；README 的流程順序則從同一份定義產生，或至少不要在各函式文件重複紀錄易變的數字。",
      "suggestedCode": "```\nconst PHASE = Object.freeze({\n  FAST_RESULT: '快速回報',\n  DETECT_TOOL: '偵測 AI 工具',\n  COLLECT_DIFF: '整理變更',\n  RESOLVE_OLD: '處理舊留言',\n  PUBLISH_FINDINGS: '發布審查結果',\n});\n\nlog(PHASE.DETECT_TOOL, 'INF', `選用工具：${tool.name}。`);\n```",
      "sourceIssue": 11
    },
    {
      "id": "F002",
      "reviewer": "Leo",
      "focus": "",
      "badge": "🧰",
      "severity": "警告",
      "file": "readme.md",
      "startLine": 59,
      "endLine": 130,
      "problem": "功能索引把分支名稱與原始碼行號硬編碼在數十個連結中；本次僅因程式碼增行，就必須人工把大量 `#L...` 全面更新，已直接顯示這份文件存在高同步成本。之後任一檔案前段增刪程式碼，都會讓這些連結再次漂移，而且指向會持續變動的 `develop` 分支，使舊版 README 與實際連結內容無法穩定對應。",
      "suggestion": "不要手動維護原始碼行號。若只需導覽，連到檔案並由右欄既有章節錨點提供函式級定位；若必須精確指向定義，應由 AST／文件產生工具在 CI 自動建立索引，並連到固定 commit SHA 或版本 tag。至少增加連結檢查，避免半年後整張功能表悄悄失準。",
      "suggestedCode": "```\n| 功能名稱 | 功能描述 |\n| --- | --- |\n| [gitrepo.resolveMergeBase](src/lib/gitrepo.js) | [解析 base 分支與 HEAD 的 merge-base](#gitreporesolvemergebase) |\n```",
      "sourceIssue": 12
    },
    {
      "id": "F006",
      "reviewer": "Rogue",
      "focus": "",
      "badge": "⚡",
      "severity": "警告",
      "file": "src/lib/gitrepo.js",
      "startLine": 134,
      "endLine": 134,
      "problem": "在檢查是否為淺層 repository (shallow repository) 時，呼叫了外部子行程執行 `git rev-parse --is-shallow-repository`。建立與啟動 OS 子行程是非常昂貴的操作，會白白浪費數十毫秒的 CPU 週期與系統資源。",
      "suggestion": "Git 在淺層 clone 時會在 `.git` 目錄下建立一個 `shallow` 檔案。我們可以使用 Node.js 內建的 `fs.existsSync` 進行本地檔案檢查，不需啟動額外的 Git 子行程，執行速度可快上百倍。",
      "suggestedCode": "```\nconst fs = require('fs');\n// ...\nif (fs.existsSync(path.join(cwd, '.git', 'shallow'))) {\n  strategies.push(['unshallow', 'fetch', '--no-tags', '--unshallow', 'origin']);\n}\n```",
      "sourceIssue": 14
    },
    {
      "id": "F007",
      "reviewer": "Leo",
      "focus": "",
      "badge": "🧰",
      "severity": "警告",
      "file": "src/lib/gitrepo.js",
      "startLine": 293,
      "endLine": 305,
      "problem": "為了防止 Git 推送失敗時在例外訊息中回顯包含 Token 與遠端 URL 的命令列參數，pushWithCredential 的 catch 區塊直接拋出一個固定的 Error('推送審查結果 commit 失敗...')。但這樣一來，它完全吞掉了原始的錯誤（例如 non-fast-forward 非快轉、分支保護規則阻擋、或連線逾時），六個月後的維護者在 CI log 中看到此錯誤時，完全無從判斷失敗的原因。",
      "suggestion": "建議在保留安全遮罩的前提下，保留原始 exception 的排錯線索。例如可以檢查並安全地過濾 err.message 或 err.stderr 中所有的敏感字串（如 Token/URL），然後將其作為新錯誤的 cause 屬性或附加訊息傳遞下去。",
      "suggestedCode": "```\n} catch (err) {\n    // 過濾敏感資訊後保留錯誤細節\n    const safeMessage = err.message ? redactSecrets(err.message) : '未知錯誤';\n    const error = new Error(`推送審查結果 commit 失敗（${safeMessage}）。`);\n    error.cause = err;\n    throw error;\n  }\n```",
      "sourceIssue": 14
    },
    {
      "id": "F009",
      "reviewer": "Bard",
      "focus": "",
      "badge": "🎼",
      "severity": "建議",
      "file": "src/index.js",
      "startLine": 308,
      "endLine": 368,
      "problem": "新增或修改的步驟分隔註解（如步驟 8 分組、步驟 2 延後、步驟 9、步驟 10、及建問題模式收束）其尾隨的水平分隔線（─）長度不一或僅存單一字元，破壞了專案既有程式碼中整齊劃一的長分隔線視覺排版，視覺上顯得雜亂、走調。",
      "suggestion": "補足尾隨的水平線 ─，使其與鄰近步驟分隔註解的長度（約 70~80 字元寬度）與視覺風格保持一致，維持排版的美觀。",
      "suggestedCode": "```\n// ── 步驟 8（分組）：依嚴重等級分組（嚴重／警告＋建議），組內已依檔案與行數排序 ────────────────\n```",
      "sourceIssue": 14
    },
    {
      "id": "F010",
      "reviewer": "Rogue",
      "focus": "",
      "badge": "⚡",
      "severity": "建議",
      "file": "src/index.js",
      "startLine": 366,
      "endLine": 382,
      "problem": "在建問題模式收束時，先 `await gitea.createIssueComment` 再 `await gitea.addIssueDependency`，這兩個 Gitea API 呼叫是獨立且無資料相依性的，卻以序列（Sequential）方式執行，白白浪費了一次網路往返（RTT）的等待時間。",
      "suggestion": "使用 `Promise.all` 同時發起這兩個請求，並行處理以減少整體 execution 的等待時間。",
      "suggestedCode": "```\nconst commentPromise = gitea.createIssueComment(\n      ctx,\n      templates.issueLinkComment({\n        issueNumber: issue.number,\n        issueUrl: issue.html_url,\n        severeCount: severe.length,\n        otherCount: others.length,\n      })\n    );\n    const dependencyPromise = gitea.addIssueDependency(ctx, ctx.prNumber, issue.number)\n      .then(() => log('建問題', 'INF', `已將 PR #${ctx.prNumber} 設為相依於 issue #${issue.number}。`))\n      .catch((err) => log('建問題', 'WRN', `設定 PR 相依失敗：${err.message}。`));\n    \n    await Promise.all([commentPromise, dependencyPromise]);\n```",
      "sourceIssue": 14
    },
    {
      "id": "F012",
      "reviewer": "Rogue",
      "focus": "",
      "badge": "⚡",
      "severity": "建議",
      "file": "src/lib/review.js",
      "startLine": 48,
      "endLine": 53,
      "problem": "在 `agentFailureDetail` 之中，進行 stderr 與 stdout 的遮罩處理時，是先截斷至 2,000 字元，然後執行多次複雜的 `redactSecrets` 正規表示式替換，最後再截斷至 500 字元輸出。這會造成 1,500 字元的複雜 regex 運算結果在下一步被直接丟棄，白白浪費了 CPU 進行字串比對與取代的週期。",
      "suggestion": "應在呼叫 `redactSecrets` 之前，就先將字串截斷至目標長度（500 字元），再進行遮罩，可大幅減少 regex 運算負擔。",
      "suggestedCode": "```\nconst stderr = redactSecrets(String((res && res.stderr) || '').slice(0, 500));\n  if (stderr) parts.push(`stderr：${stderr}`);\n  const stdout = redactSecrets(String((res && res.output) || '').slice(0, 500));\n  if (stdout) parts.push(`stdout：${stdout}`);\n```",
      "sourceIssue": 14
    },
    {
      "id": "F014",
      "reviewer": "Leo",
      "focus": "",
      "badge": "🧰",
      "severity": "建議",
      "file": "readme.md",
      "startLine": 56,
      "endLine": 132,
      "problem": "README 的功能表大量手動維護 `src/branch/develop/...#Lxx` 深連結，這次光是分支與行號就改了整排。這類文件會隨任何插入註解、重排函式、換預設分支而失準，未來維護者必須在改程式時同步更新一大段文件，維護成本偏高。",
      "suggestion": "改成不依賴行號的相對連結，或用文件產生腳本從原始碼 JSDoc 自動產出這張表。若仍要指向 Gitea，建議至少移除 `#Lxx`，或集中定義分支名稱，避免每次改分支都要全表搜尋替換。",
      "suggestedCode": "",
      "sourceIssue": 15
    },
    {
      "id": "F022",
      "reviewer": "Leo",
      "focus": "",
      "badge": "🧰",
      "severity": "警告",
      "file": "readme.md",
      "startLine": 76,
      "endLine": 132,
      "problem": "README 內大量函式清單同時硬編分支名稱與行號錨點，這次 diff 已經整批從 `master` 改成 `develop` 並同步調整行號。這類文件和原始碼結構高度重複，後續只要插入幾行程式，文件連結就會失準，維護者必須靠人工記得同步整張表。",
      "suggestion": "改成不含行號的穩定檔案連結，或把這份 API/功能表改由 JSDoc/腳本產生。若一定要保留行號，建議把產生流程寫入 npm script，避免每次程式碼位移都人工批次修改 README。",
      "suggestedCode": "",
      "sourceIssue": 18
    },
    {
      "id": "F025",
      "reviewer": "Assassin",
      "focus": "",
      "badge": "🗡️",
      "severity": "警告",
      "file": "action.yml",
      "startLine": 21,
      "endLine": 24,
      "problem": "這裡建議呼叫端傳入「能觸發 CI 的 PAT」作為 action token。攻擊者最愛這種長效、可推送、可觸發 workflow 的憑證：只要此 action 在不受信任 PR 上執行，或 PR 能影響 action/workflow 執行內容，惡意變更就可能讀取 `INPUT_TOKEN`、推送結果 commit、再藉由可觸發 CI 的身分製造後續執行鏈。自動 token 原本不觸發 CI 是一道防線，這個建議等於要求使用者把防線拆掉。",
      "suggestion": "不要泛稱建議使用可觸發 CI 的 PAT。文件與介面應明確要求最小權限、repo 限定、短效或可輪替 token，並禁止在 fork/不受信任 PR context 暴露 PAT。更穩的設計是分離 API 留言 token 與 push token，且只有在明確受信任事件或受保護分支才允許 push token 存在；否則拒絕 commit/push，只做留言或 artifact。",
      "suggestedCode": "",
      "sourceIssue": 19
    },
    {
      "id": "F026",
      "reviewer": "Leo",
      "focus": "",
      "badge": "🧰",
      "severity": "建議",
      "file": "readme.md",
      "startLine": 59,
      "endLine": 132,
      "problem": "README 的功能列表手動維護了大量 `src/branch/develop/...#Lxx` 深連結與行號。這次 PR 已經一次改動數十個 branch/line anchor，代表文件和原始碼行號高度耦合；下一次只要插入幾行程式，文件就會悄悄過期，維護者很難知道哪些連結還準。",
      "suggestion": "避免在手寫 README 綁定行號，改連到函式所在檔案或穩定章節錨點；若必須保留行號，請把這段改成產生式文件，讓 CI 或腳本從原始碼/JSDoc 重新生成，減少人工同步成本。",
      "suggestedCode": "",
      "sourceIssue": 19
    },
    {
      "id": "F031",
      "reviewer": "Leo",
      "focus": "",
      "badge": "🧰",
      "severity": "建議",
      "file": "readme.md",
      "startLine": 56,
      "endLine": 132,
      "problem": "README 的功能表大量硬編遠端分支名稱與行號，這次只是從 `master` 改成 `develop` 並同步行號，但這種文件很容易在下一次函式移動、預設分支更名或重排時再次整批失準。未來維護者會被迫反覆做低價值的連結校正，文件也可能在沒人注意時指到錯誤位置。",
      "suggestion": "若 README 是 repo 內文件，優先改成相對路徑連結，並避免固定行號；若必須保留行號，建議用產生腳本統一輸出這張表，讓分支名與行號只從單一來源計算。",
      "suggestedCode": "",
      "sourceIssue": 21
    },
    {
      "id": "F040",
      "reviewer": "Assassin",
      "focus": "",
      "badge": "🗡️",
      "severity": "警告",
      "file": "action.yml",
      "startLine": 19,
      "endLine": 22,
      "problem": "這段新增說明鼓勵呼叫端傳入「能觸發 CI 的 PAT」。攻擊者最喜歡這種長效、高權限、可觸發 workflow 的憑證：若 action 跑在不可信 PR、AI CLI 被 prompt injection 誘導讀環境變數，或同 repo PR 可改動本 action 程式碼，就可能把 PAT 外送或濫用成寫入 repo／觸發 CI 的跳板。",
      "suggestion": "不要把長效 PAT 當建議預設。改用最小權限、短效的 GitHub App／Gitea App token，並明確禁止在不可信 fork PR 傳入可寫 token。若目標只是回報檢查結果，優先用 status/check API 寫結果，不要靠 PAT push 再觸發下一輪 CI。",
      "suggestedCode": "```\ndescription: 'Gitea API token（PR/issue 留言與 push findings 用；請使用最小權限、短效 token，勿在不可信 PR 傳入長效 PAT）'\n```",
      "sourceIssue": 23
    },
    {
      "id": "F041",
      "reviewer": "Leo",
      "focus": "",
      "badge": "🧰",
      "severity": "建議",
      "file": "readme.md",
      "startLine": 58,
      "endLine": 131,
      "problem": "README 的功能表把分支名稱與行號大量硬編在外部 URL 裡，這次已經需要整批 `master` 改 `develop` 並同步多個 `#Lxx`。這類文件會隨任何程式碼插行、函式移動或預設分支變更而失準，維護成本會線性累積，最後讀者點到的文件比沒有文件更誤導。",
      "suggestion": "改用 repo 相對連結、不固定行號，或把這段功能表改由腳本從 JSDoc 自動產生。若需要連到特定實作，優先連到檔案或錨點，避免每次重排程式碼都要同步更新幾十個行號。",
      "suggestedCode": "```\n| log.taipeiNow | [src/lib/log.js](src/lib/log.js) | 取得台北時區 yyyy/MM/dd HH:mm:ss 時間字串 |\n| review.runAttackers | [src/lib/review.js](src/lib/review.js) | 攻擊方 sub agent 並行找問題並合併列表 |\n```",
      "sourceIssue": 23
    }
  ],
  "excluded": []
 }
@@ -0,0 +1,184 @@
 {
  "generatedAt": "2026/07/21 14:27:42",
  "commitSha": "9e7f8a2a0a807c26e12e9bf0381e7decfb9e5568",
  "prNumber": 6,
  "tool": {
    "name": "codex",
    "version": "codex-cli 0.144.6",
    "model": "gpt-5.5"
  },
  "findings": [],
  "excluded": [
    {
      "reviewer": "Assassin",
      "focus": "security",
      "badge": "🗡️",
      "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 的人。",
      "suggestion": "把整個 Authorization header value 視為機密，不要只特判 Bearer。應遮掉 scheme 與 credential 全段；若要保留 scheme，也只能保留固定白名單字樣，不能留下後面的 token。",
      "suggestedCode": ".replace(/(authorization\\s*[:=]\\s*)(?:\\S+\\s+)?\\S+/gi, '$1***')",
      "id": "F001",
      "verdicts": {
        "Paladin": {
          "exclude": true,
          "reason": "可排除（重複）。歷史 finding 已指出除錯診斷輸出中 Authorization 遮罩規則可能只遮到 scheme、留下後方憑證，並造成 CI log 洩漏，與本條同一問題。"
        }
      }
    },
    {
      "reviewer": "Leo",
      "focus": "maintainability",
      "badge": "🧰",
      "severity": "警告",
      "file": "src/index.js",
      "startLine": 181,
      "endLine": 239,
      "problem": "`main()` 這次把「PR 留言」、「issue 暫存」、「issue 建立後 flush」三種狀態直接塞進閉包變數 `currentRunCommentIds`、`issueBuffer`、`issue` 與 `queueOrPostComment()`。未來只要再新增一種落地方式或調整留言順序，維護者必須同時理解整個主流程的時序，否則很容易出現留言漏發、舊留言誤標、或 issue 尚未建立卻被使用的狀態錯誤。這段已經不是單純編排，而是隱含一個留言發布狀態機。",
      "suggestion": "把留言目的地抽成小型模組，例如 `CommentSink` / `ReviewPublisher`，讓 `main()` 只負責流程編排：`publisher.postContext()`、`publisher.flushIssue()`、`publisher.resolveOldPrComments()`。建問題模式的暫存與 flush 可獨立測試，半年後改流程時不用在 `main()` 裡追閉包狀態。",
      "suggestedCode": "",
      "id": "F007",
      "verdicts": {
        "Paladin": {
          "exclude": true,
          "reason": "可排除（命中已知排除事項且重複）。既有紀錄已涵蓋 main() 內留言路由、issue 狀態、緩衝佇列與發布狀態機耦合的同一問題。"
        }
      }
    },
    {
      "reviewer": "Leo",
      "focus": "maintainability",
      "badge": "🧰",
      "severity": "警告",
      "file": "readme.md",
      "startLine": 56,
      "endLine": 132,
      "problem": "README 這次把大量連結從 `branch/master` 改成 `branch/develop`，同時保留許多硬編碼行號。這種文件會隨分支名稱、預設分支、或任一檔案插入幾行就整批失準；未來維護者每次調整程式都得同步修幾十個 URL，否則文件看起來精準、實際上卻導到錯誤位置。",
      "suggestion": "改用 repo 相對連結並盡量避免行號，例如 `src/lib/log.js` 或 `src/lib/log.js#L20` 只保留少數真正需要精準定位的 API。若這段是產生文件，請把分支名稱與連結格式集中在產生器設定，不要把同一個 branch 字串散落在 README 表格裡。",
      "suggestedCode": "",
      "id": "F008",
      "verdicts": {
        "Paladin": {
          "exclude": true,
          "reason": "可排除（重複）。歷史 findings 已多次指出 README 大量硬編 branch 與行號深連結，造成文件與原始碼高同步成本；本條為同一問題。"
        }
      }
    },
    {
      "reviewer": "Mage",
      "focus": "logic",
      "badge": "🔮",
      "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 與狀態不一致。",
      "suggestion": "建立 issue 後立即寫入可重試識別資訊，重跑前先搜尋/復用既有本 PR 的 AI review issue；或在 flush 失敗時捕捉錯誤，將已建立 issue 補上失敗狀態與 PR 回連，再讓流程以可診斷方式收束。",
      "suggestedCode": "",
      "id": "F010",
      "verdicts": {
        "Paladin": {
          "exclude": true,
          "reason": "可排除（命中已知排除事項且重複）。issue 建立後 flush 暫存留言失敗、重跑又建立重複 issue，正是已知排除事項與多筆歷史 findings 已記錄的問題。"
        }
      }
    },
    {
      "reviewer": "Maya",
      "focus": "testing",
      "badge": "🧪",
      "severity": "警告",
      "file": "src/index.js",
      "startLine": 180,
      "endLine": 241,
      "problem": "建問題模式新增了「先暫存留言、確定有保留問題才建立 issue、再 flush 暫存留言」的流程，但目前新增測試只驗到低階 helper，沒有驗證主流程在 create-issue=true 時的留言去向與靜默通過行為。這裡若順序錯了，可能會把原本應該留在 issue 的工具／diff／角色留言發到 PR，或在無保留問題時留下不該出現的 PR 留言。",
      "suggestion": "請補主流程層級測試，stub `gitea`、`review.runAttackers`、`review.runDefenders`、`agents.detectTool`，至少驗證：\n\n| 情境 | 應斷言 |\n| --- | --- |\n| `createIssue=true` 且 `kept.length > 0` | 建 issue 前的情境留言先暫存，issue 建立後依序寫入該 issue |\n| `createIssue=true` 且 `kept.length === 0` | 不建立 issue、不對 PR 留言、不呼叫 `resolveOldComments` |\n| 一般模式 | 情境留言仍發到 PR，且 id 被加入 `currentRunCommentIds` |",
      "suggestedCode": "",
      "id": "F012",
      "verdicts": {
        "Paladin": {
          "exclude": true,
          "reason": "可排除（重複）。歷史 findings 已涵蓋 create-issue 模式中留言先暫存、issue 建立後依序寫入、無 finding 靜默通過與一般模式留言目的地缺少主流程測試。"
        }
      }
    },
    {
      "reviewer": "Maya",
      "focus": "testing",
      "badge": "🧪",
      "severity": "警告",
      "file": "src/index.js",
      "startLine": 354,
      "endLine": 395,
      "problem": "新增的建問題模式會依嚴重度分流：嚴重問題改發到 issue、PR 回貼 issue 連結，且只有嚴重問題才呼叫 `addIssueDependency`。目前測試沒有覆蓋這個決策矩陣，等於沒有驗證「警告／建議不阻擋合併」與「嚴重問題要建立相依」這兩個關鍵行為。",
      "suggestion": "請補 create-issue 模式的結果分流測試，至少涵蓋：\n\n| findings | 應斷言 |\n| --- | --- |\n| 只有警告／建議 | 建 issue、逐條留言、PR 回貼連結，但不呼叫 `addIssueDependency` |\n| 有嚴重問題 | 呼叫 `postSevereToIssue`、PR 回貼連結，並呼叫 `addIssueDependency(ctx, ctx.prNumber, issue.number)` |\n| `addIssueDependency` 拋錯 | 流程降級完成，不中斷收尾 commit |",
      "suggestedCode": "",
      "id": "F013",
      "verdicts": {
        "Paladin": {
          "exclude": true,
          "reason": "可排除（重複）。歷史 findings 已涵蓋建問題模式的嚴重／非嚴重分流、PR 回貼、相依 API 降級與核心分支缺少測試；本條屬同一測試缺口。"
        }
      }
    },
    {
      "reviewer": "Maya",
      "focus": "testing",
      "badge": "🧪",
      "severity": "警告",
      "file": "src/lib/gitrepo.js",
      "startLine": 130,
      "endLine": 188,
      "problem": "`resolveMergeBase` 新增了多段 fetch 補歷史策略、每次補抓後重試 merge-base、以及淺層 repo 才執行 `--unshallow` 的行為，但測試只驗證不安全 baseRef 會被拒絕，沒有驗證這些成功／失敗路徑。這段是 diff 基準的核心，一旦 fallback 順序或條件壞掉，review 可能拿錯範圍或在 shallow checkout 直接失敗。",
      "suggestion": "請把 git 執行層抽成可注入或以臨時 repo 測試，補齊：首次 merge-base 成功不跑 fallback、deepen base 後成功即停止、deepen PR HEAD 用目前 HEAD SHA、只有 shallow repo 才嘗試 `--unshallow`、全部策略失敗時錯誤訊息含診斷且保留 cause。",
      "suggestedCode": "",
      "id": "F014",
      "verdicts": {
        "Paladin": {
          "exclude": true,
          "reason": "可排除（重複）。歷史 findings 已針對 resolveMergeBase 多階段 fetch、shallow 與非 shallow 分支、停止條件、降級與最終失敗診斷缺少測試提出相同問題。"
        }
      }
    },
    {
      "reviewer": "Maya",
      "focus": "testing",
      "badge": "🧪",
      "severity": "警告",
      "file": "src/lib/gitrepo.js",
      "startLine": 331,
      "endLine": 366,
      "problem": "`pushWithCredential` 是這次結果 commit 能否用 PAT 觸發下一輪 CI 的關鍵，但目前沒有測試驗證它真的清掉 checkout 的自動 token、再注入 PAT Authorization，也沒有測失敗時不外洩 remote URL／token。這條失敗路徑沒被試煉過，可能讓 `[failure]` 結果 commit 無法觸發快速回報，或在錯誤訊息裡洩漏認證資訊。",
      "suggestion": "請補 `commitAndPushFindings`／`pushWithCredential` 的測試，stub `execFileSync` 驗證：`git push` 使用不含帳密的 remote URL、`GIT_CONFIG_COUNT=2`、第 0 筆 extraheader 為空值、第 1 筆為 Basic Authorization、remote origin 不符時拒絕、push 失敗時拋出的錯誤不包含 token 或 remote URL。",
      "suggestedCode": "",
      "id": "F015",
      "verdicts": {
        "Paladin": {
          "exclude": true,
          "reason": "可排除（重複）。歷史 findings 已涵蓋 pushWithCredential／commitAndPushFindings 的認證推送策略、token 注入、推送目標與失敗時不外洩 token 或 URL 的測試缺口。"
        }
      }
    },
    {
      "reviewer": "Maya",
      "focus": "testing",
      "badge": "🧪",
      "severity": "建議",
      "file": "src/lib/diagnostics.js",
      "startLine": 21,
      "endLine": 32,
      "problem": "`redactSecrets` 新增多個遮罩規則與控制字元單行化，但測試只透過 `agentFailureDetail` 間接覆蓋 Authorization 與 token 兩種格式。URL 內嵌帳密、長 token、GitHub token 樣式、控制字元注入與 null/undefined 邊界都還沒被直接驗證。",
      "suggestion": "請補 `redactSecrets` 的直接單元測試，包含：`https://user:pass@host`、`ghp_...`、40 字以上 token、含換行／tab 的假日誌注入、`null`／`undefined`。斷言重點是輸出為單行、敏感片段被 `***` 取代，且一般錯誤文字仍保留可診斷性。",
      "suggestedCode": "",
      "id": "F016",
      "verdicts": {
        "Paladin": {
          "exclude": true,
          "reason": "可排除（重複）。歷史 findings 已記錄失敗診斷與 redactSecrets 對 Authorization、URL 帳密、token 格式、控制字元、截斷與空值邊界缺少測試；本條為同一測試缺口。"
        }
      }
    }
  ]
 }
@@ -42,13 +42,12 @@ jobs:
      uses: ./
      # 傳入 action inputs。
      with:
-        # Gitea Actions 自動注入的 repo 範圍 token，用於 PR 留言與 findings 寫回。
+        # PR 留言與 findings 寫回用的 token（呼叫端以 secrets 傳入）。
-        token: ${{ gitea.token }}
+        token: ${{ secrets.TOKEN }}
        # 啟用建問題模式：審查內容改發到追蹤 issue，並在 PR 回貼 issue 連結。
        create-issue: 'true'
-        # 推送 findings/exclusions commit 用的 PAT：以 PAT 身分推送才會讓結果 commit 再觸發 CI，
+        # 指定 AI 模型：CI 測試固定用 Antigravity 最省模型以降低消耗。
-        # 由步驟 1 快速回報把結果蓋到新 head，避免自動 token 推送不觸發而卡合併。
+        model: gemini-3.5-flash
        push-token: ${{ secrets.TOKEN }}
  # Codex 工具環境測試 job。
  test-codex:
    # Job 在 workflow UI 顯示的名稱。
@@ -73,13 +72,12 @@ jobs:
      uses: ./
      # 傳入 action inputs。
      with:
-        # Gitea Actions 自動注入的 repo 範圍 token，用於 PR 留言與 findings 寫回。
+        # PR 留言與 findings 寫回用的 token（呼叫端以 secrets 傳入）。
-        token: ${{ gitea.token }}
+        token: ${{ secrets.TOKEN }}
        # 啟用建問題模式：審查內容改發到追蹤 issue，並在 PR 回貼 issue 連結。
        create-issue: 'true'
-        # 推送 findings/exclusions commit 用的 PAT：以 PAT 身分推送才會讓結果 commit 再觸發 CI，
+        # 指定 AI 模型：CI 測試固定用 Codex 最省模型以降低消耗。
-        # 由步驟 1 快速回報把結果蓋到新 head，避免自動 token 推送不觸發而卡合併。
+        model: gpt-5.5
        push-token: ${{ secrets.TOKEN }}
  # Claude 工具環境測試 job。
  test-claude:
    # Job 在 workflow UI 顯示的名稱。
@@ -104,10 +102,9 @@ jobs:
      uses: ./
      # 傳入 action inputs。
      with:
-        # Gitea Actions 自動注入的 repo 範圍 token，用於 PR 留言與 findings 寫回。
+        # PR 留言與 findings 寫回用的 token（呼叫端以 secrets 傳入）。
-        token: ${{ gitea.token }}
+        token: ${{ secrets.TOKEN }}
        # 啟用建問題模式：審查內容改發到追蹤 issue，並在 PR 回貼 issue 連結。
        create-issue: 'true'
-        # 推送 findings/exclusions commit 用的 PAT：以 PAT 身分推送才會讓結果 commit 再觸發 CI，
+        # 指定 AI 模型：Claude job 使用 Opus 4.8。
-        # 由步驟 1 快速回報把結果蓋到新 head，避免自動 token 推送不觸發而卡合併。
+        model: claude-opus-4-8
        push-token: ${{ secrets.TOKEN }}
@@ -16,11 +16,11 @@ author: 'Jeffery'
 # 輸入參數區塊：呼叫端 workflow 以 `with:` 傳入，
 # runner 會自動注入為 INPUT_* 環境變數（例如 INPUT_TOKEN、INPUT_MODEL、INPUT_CREATE-ISSUE）供主程式讀取。
 inputs:
-  # Gitea API token：用於對 PR 留言審查結果、以及 push 審查結果檔回 repo。
+  # Gitea API token：用於對 PR／issue 留言審查結果，以及 push 審查結果檔（findings/exclusions）回 repo。
  token:
-    # 參數用途說明：secrets/vars context 在 action 內不可用，
+    # 參數用途說明：secrets/vars context 在 action 內不可用，故由呼叫端 workflow 以 secrets 傳入。
-    # 故由呼叫端 workflow 以 secrets.GITHUB_TOKEN 傳入。
+    # 建議傳入能觸發 CI 的 PAT；自動 token 推送結果 commit 時可能不會再觸發 workflow。
-    description: 'Gitea API token（PR 留言與 push findings 用；呼叫端以 secrets.GITHUB_TOKEN 傳入）'
+    description: 'Gitea API token（PR/issue 留言與 push findings 用；建議以能觸發 CI 的 PAT 由 secrets 傳入）'
    # 必填：缺少 token 無法呼叫 Gitea API，action 無法運作。
    required: true
  # 指定 AI 工具使用的模型名稱。
@@ -41,17 +41,6 @@ inputs:
    required: false
    # 預設為字串 'false'，代表不啟用建問題模式（主程式只認字串 'true' 才啟用）。
    default: 'false'
  # 推送用 PAT：推送 findings/exclusions commit 時改以此 token 進行。
  push-token:
    # 參數用途說明：以自動 token（gitea.token / GITHUB_TOKEN）推送的 commit 不會再觸發 CI，
    # 導致新 head 缺檢查而卡合併；改用 PAT 推送會讓 PR 的 synchronize 事件再觸發 CI，
    # 由主程式步驟 1 快速回報（[success]/[failure]）廉價地把結果蓋到新 head。
    # 呼叫端以 secrets 傳入（例如 secrets.TOKEN）。留空＝退回以 token 走 origin 推送（不會再觸發）。
    description: '推送 findings/exclusions commit 用的 PAT（讓 CI 再觸發；呼叫端以 secrets 傳入；留空＝退回 token 推送、不再觸發）'
    # 選填：未指定時退回以 token 推送。
    required: false
    # 預設為空字串，代表不使用專用推送 PAT。
    default: ''
 # 執行方式區塊：宣告本 action 為 node action 及其進入點。
 runs:
  # 以 Node.js 24 runtime 直接在 runner 上執行（非 Docker 容器、非 composite）。
@@ -4,7 +4,8 @@
  "description": "AI 多角色 code review：攻擊方找問題、防守方裁決誤報，結果留言到 PR 並保存 findings",
  "main": "src/index.js",
  "scripts": {
-    "build": "ncc build src/index.js -o dist"
+    "build": "ncc build src/index.js -o dist",
    "test": "node --test"
  },
  "author": "Jeffery",
  "license": "MIT"
@@ -38,16 +38,16 @@ jobs:
 ```mermaid
 flowchart TD
    S1[1 判斷 bot commit 標記] -->|命中| E0[直接回報 success/failure]
-    S1 -->|未命中| S2[2 舊留言標記解決]
+    S1 -->|未命中| N3[3 偵測 AI 工具並留言]
-    S2 --> S3[3 偵測 AI 工具並留言]
+    N3 --> N4[4 讀 .reviewignore 整理 diff 並留言]
-    S3 --> S4[4 讀 .reviewignore 整理 diff 並留言]
+    N4 --> N5[5 攻擊方登場留言]
-    S4 --> S5[5 攻擊方登場留言]
+    N5 --> N6[6 攻擊方 sub agent 並行找問題]
-    S5 --> S6[6 攻擊方 sub agent 並行找問題]
+    N6 --> N7[7 防守方登場留言]
-    S6 --> S7[7 防守方登場留言]
+    N7 --> N8[8 防守方裁決 → 保存 findings ＋ 誤判回寫 exclusions.json]
-    S7 --> S8[8 防守方裁決 → 保存 findings ＋ 誤判回寫 exclusions.json]
+    N8 --> N2[2 延後將舊留言標記解決（成功產生結果後才執行）]
-    S8 --> S9[9 嚴重問題逐條掛行留言]
+    N2 --> N9[9 嚴重問題逐條掛行留言]
-    S9 --> S10[10 警告＋建議彙整表格留言]
+    N9 --> N10[10 警告＋建議彙整表格留言]
-    S10 --> E1[收尾 commit/push ＋ exit code]
+    N10 --> E1[收尾 commit/push ＋ exit code]
 ```
 ## 專案列表
@@ -90,7 +90,8 @@ function saveFindings({ cwd, ctx, tool, kept, excluded }) {
 * 依模式組出 filesToCommit（一般模式：findings 檔＋有變更時的 exclusions.json；
 * 建問題模式：只有 exclusions.json）後呼叫本函式；另在步驟 4 判定無可審查變更且非建問題模式時，
 * 也會以 result: 'success' 提交空 findings。
- * 推送以 `ctx.pushToken`（PAT）優先，使結果 commit 再觸發 CI、由步驟 1 快速回報；
+ * 推送一律以 `ctx.token` 的身分進行（不走 runner 的 origin 自動 token）；只要 token 是能觸發 CI 的
 * PAT，結果 commit 就會再觸發 CI、由步驟 1 快速回報；
 * 注意 commit 訊息與模組常數 `BOT_COMMIT_PREFIX` 耦合，修改前綴會使步驟 1 的快速回報失效。
 */
 function commitFindings({ cwd, ctx, files, result }) {
@@ -101,7 +102,6 @@ function commitFindings({ cwd, ctx, files, result }) {
      message: `${BOT_COMMIT_PREFIX}[${result}]`,
      files,
      token: ctx.token,
      pushToken: ctx.pushToken,
      serverUrl: ctx.serverUrl,
      repository: ctx.repository,
    });
@@ -117,38 +117,22 @@ function commitFindings({ cwd, ctx, files, result }) {
 }
 /**
- * AI code review 主流程：依固定 10 步驟執行多角色審查，回傳 process exit code。
+ * AI code review 主流程：編排多角色審查、發布審查結果，並回傳 process exit code。
 *
- * 流程概要（步驟 2～10 描述一般模式；建問題模式差異見末段）：
+ * 一般模式會把審查情境、嚴重問題與警告／建議發布到 PR，並在成功產生本回合結果後才把舊留言標為過時。
- * 1. 快速回報 — 最新 commit 若為 ai-review-bot 的結果 commit（[success]/[failure]），直接回報 0/1 不重審；
+ * 建問題模式會把審查情境與每條 finding 發到追蹤 issue；沒有保留 finding 時不建立 issue、PR 也不留言。
- * 2. 將 PR 既有舊留言標記為解決（跳過本回合留言；建問題模式不執行此步）——
+ * 嚴重 finding 會寫入 failure 結果 commit，警告與建議只建立追蹤資訊，不直接阻擋合併。
 *    此步延後到「本回合審查已成功產生結果、即將發布問題留言前」才執行，避免工具偵測／diff／
 *    攻防裁決任一失敗時舊結果先被清掉卻沒有新結果（一般模式）；
 * 3. 偵測 AI 工具（antigravity／codex／claude）並留言；
 * 4. 讀 .reviewignore、整理 git diff 並留言（無可審查變更時：留言＋保存空 findings，
 *    一般模式 commit success、建問題模式略過 commit，回傳 0）；
 * 5–6. 攻擊方登場留言、每位攻擊方一個 sub agent 並行找問題；
 * 7–8. 防守方登場留言、裁決誤報後排序並保存 findings JSON，
 *    並以 appendExclusions 把誤判／重複問題回寫 .gitea/ai-review/exclusions.json；
 * 9. 嚴重問題逐條掛在程式碼行上留言；
 * 10. 警告＋建議彙整為單一表格留言；
 * 建問題模式（input: create-issue）：不執行步驟 2、不觸碰 PR 既有留言；步驟 3～10 的所有留言
 *    改發到追蹤 issue（工具／diff／角色留言先暫存，確定有保留問題後先挑好標籤、連同標籤一次建立 issue
 *    並寫入暫存留言，嚴重問題與警告＋建議再逐條發到該 issue，讓每條問題都能被個別回覆）；
 *    無保留問題或無可審查變更則不建 issue、PR 也完全不留言（靜默通過）；
 *    收束時在 PR 回貼 issue 連結形成雙向關聯，
 *    並讓 PR 相依於該 issue（addIssueDependency，issue 完成／關閉前 PR 無法合併；需 repo 啟用問題相依功能）；
 * 收尾：組 filesToCommit —— 一般模式 commit findings 檔（＋有變更的 exclusions.json）、
 * 建問題模式只 commit exclusions.json、無檔案可 commit 時略過；
 * commit 訊息帶結果標記（success＝無嚴重問題、failure＝有嚴重問題）。
 *
- * @returns {Promise<number>} process exit code：0＝成功（無嚴重問題或無可審查變更、或偵測到 success 標記）；
+ * @returns {Promise<number>} process exit code：本輪「審查」一律回傳 0（不因嚴重問題直接讓檢查失敗——
- *   1＝失敗（有嚴重問題、缺 PR 編號／token、找不到 AI 工具、或偵測到 failure 標記）。
+ *   失敗改由推出的 `[ai-review-bot][failure]` 結果 commit，於下一輪在步驟 1 讀 commit 訊息時回報）；
 *   回傳 1 僅發生於：步驟 1 偵測到 `[ai-review-bot][failure]` 結果 commit，或前置條件不足
 *   （缺 PR 編號／token、找不到 AI 工具）等無法進行審查的情況。
 * @remarks
 * 使用情境：由本檔尾端的頂層呼叫端執行 —— `main().then((code) => process.exit(code))`；
 * 非預期例外由頂層 `catch` 記 ERR log 後以 exit code 1 收場，且刻意不 commit 結果標記，
- * 讓下一次 workflow 觸發時重新完整審查。警告＋建議等級的問題不影響成敗，只有「嚴重」會使結果為 failure；
+ * 讓下一次 workflow 觸發時重新完整審查。警告＋建議等級不影響結果標記，只有「嚴重」會使結果 commit
- * 建問題模式只改變問題明細的落地方式（issue 留言取代 findings 進版控），不改變成敗判定。
+ * 標記為 failure；而「失敗檢查（exit 1）」只由步驟 1 讀到該 failure 結果 commit 時產生，審查本輪不直接 exit 1。
 * 建問題模式只改變問題明細的落地方式（issue 留言取代 findings 進版控），不改變上述結果標記判定。
 */
 async function main() {
  const ctx = loadContext();
@@ -178,14 +162,14 @@ async function main() {
  // 本回合（一般模式）發出的 PR 留言 id：resolveOldComments 標註過時時要跳過這些。
  const currentRunCommentIds = new Set();
-  // 建問題模式：issue 於「確定有保留問題」後才建立；在那之前的情境留言（工具／diff／角色）
+  // 建問題模式：追蹤 issue 於「確定有保留問題」後才建立；在那之前的情境留言（工具／diff／角色）
-  // 先暫存於 issueBuffer，建立 issue 後一次寫入。
+  // 先暫存於 pendingIssueCommentBodies，建立 issue 後一次寫入。
-  const issueBuffer = [];
+  const pendingIssueCommentBodies = [];
-  let issue = null;
+  let trackingIssue = null;
  /**
   * 發布一則審查留言。依模式決定去向：
   * - 一般模式：發到 PR，並記錄留言 id 供 `resolveOldComments` 排除。
-   * - 建問題模式：issue 已建立時發到 issue；尚未建立時先暫存到 `issueBuffer`。
+   * - 建問題模式：追蹤 issue 已建立時發到 issue；尚未建立時先暫存到 `pendingIssueCommentBodies`。
   *
   * @param {string} body 要發布的 Markdown 留言內容。
   * @returns {Promise<Object|null>} 一般模式、或建問題模式且 issue 已建立時回傳 Gitea 留言物件；
@@ -194,10 +178,10 @@ async function main() {
   * 使用情境：只在 `main()` 內部使用，處理工具資訊、diff 摘要、角色登場與
   * 警告／建議彙整等留言。若 Gitea API 失敗，例外會往上拋出並由主流程頂層 catch 收斂。
   */
-  const postComment = async (body) => {
+  const queueOrPostComment = async (body) => {
    if (ctx.createIssue) {
-      if (issue) return gitea.createCommentOnIssue(ctx, issue.number, body);
+      if (trackingIssue) return gitea.createCommentOnIssue(ctx, trackingIssue.number, body);
-      issueBuffer.push(body);
+      pendingIssueCommentBodies.push(body);
      return null;
    }
    const created = await gitea.createIssueComment(ctx, body);
@@ -206,24 +190,25 @@ async function main() {
  };
  /**
   * 建問題模式：建立追蹤 issue（標題＝PR 標題、本文＝PR 描述＋回溯 PR 的引言，連同挑好的標籤一次建立），
-   * 並把 `issueBuffer` 內暫存的情境留言依序寫入 issue；設定閉包變數 `issue` 供後續留言直接發到 issue。
+   * 並把 `pendingIssueCommentBodies` 內暫存的情境留言依流程順序寫入 issue；
   * 設定閉包變數 `trackingIssue` 供後續留言直接發到 issue。
   * 僅於「確定有保留問題」時呼叫一次。標籤於建立時一次帶入，省去「先建空標籤 issue 再補掛」的多餘 API 往返。
   *
   * @param {number[]} [labelIds] - 建立 issue 時要一併掛上的標籤 id 陣列（由 `review.selectLabels` 事先挑選）；
   *   空陣列或省略時不掛任何標籤（`gitea.createIssue` 對空陣列不帶 labels 欄位）。
-   * @returns {Promise<void>} 無回傳值；結果反映在閉包變數 `issue` 與 issue 留言。
+   * @returns {Promise<void>} 無回傳值；結果反映在閉包變數 `trackingIssue` 與 issue 留言。
   */
-  const ensureIssueCreated = async (labelIds = []) => {
+  const createIssueAndFlushBufferedComments = async (labelIds = []) => {
-    issue = await gitea.createIssue(ctx, {
+    trackingIssue = await gitea.createIssue(ctx, {
      title: ctx.prTitle || `AI Code Review：PR #${ctx.prNumber}`,
      body: templates.issueBody({ prNumber: ctx.prNumber, prBody: ctx.prBody }),
      labels: labelIds,
    });
-    log('建問題', 'INF', `已建立追蹤 issue #${issue.number}，寫入 ${issueBuffer.length} 則情境留言。`);
+    log('建問題', 'INF', `已建立追蹤 issue #${trackingIssue.number}，寫入 ${pendingIssueCommentBodies.length} 則情境留言。`);
-    for (const body of issueBuffer) {
+    for (const body of pendingIssueCommentBodies) {
-      await gitea.createCommentOnIssue(ctx, issue.number, body);
+      await gitea.createCommentOnIssue(ctx, trackingIssue.number, body);
    }
-    issueBuffer.length = 0;
+    pendingIssueCommentBodies.length = 0;
  };
  // ── 步驟 2：延後執行 ───────────────────────────────────────────────────
@@ -241,7 +226,7 @@ async function main() {
  }
  log('步驟3', 'INF', `選用工具：${tool.name}（${tool.version}）。`);
  const runLink = `${ctx.serverUrl}/${ctx.repository}/actions/runs/${ctx.runId}`;
-  await postComment(
+  await queueOrPostComment(
    templates.toolComment({
      toolName: tool.name,
      version: tool.version,
@@ -266,7 +251,7 @@ async function main() {
    if (ctx.createIssue) {
      log('步驟4', 'INF', '建問題模式且無可審查變更：靜默通過（不建 issue、PR 不留言）。');
    } else {
-      await postComment(templates.nothingToReviewComment(ignoredCount));
+      await queueOrPostComment(templates.nothingToReviewComment(ignoredCount));
      // 已成功產生本回合結果留言（無可審查變更），此時才把舊留言標為過時（本回合留言已排除）。
      await review.resolveOldComments({ ctx, gitea, currentRunCommentIds });
    }
@@ -282,23 +267,25 @@ async function main() {
  const diffRows = review.collectDiffRows({ cwd, files, base, gitrepo });
  await review.fillPurposes({ tool, model: ctx.model, cwd, diffRows });
-  await postComment(templates.diffComment(diffRows, ignoredCount));
+  await queueOrPostComment(templates.diffComment(diffRows, ignoredCount));
  // ── 步驟 5：攻擊方角色登場留言 ─────────────────────────────────────────
  const roles = loadRoles(path.join(ctx.actionPath, 'src', 'prompts', 'roles'));
  const attackers = attackersOf(roles);
  const defenders = defendersOf(roles);
  log('步驟5', 'INF', `攻擊方 ${attackers.length} 位、防守方 ${defenders.length} 位。`);
-  await postComment(templates.rolesComment({ title: '⚔️ 攻擊方登場', roles: attackers }));
+  await queueOrPostComment(templates.rolesComment({ title: '⚔️ 攻擊方登場', roles: attackers }));
  // ── 步驟 6：每個攻擊方一個 sub agent 並行分析，合併問題列表 ────────────
  const findings = await review.runAttackers({ tool, model: ctx.model, cwd, attackers, diffRows });
  // ── 步驟 7：防守方角色登場留言 ─────────────────────────────────────────
-  await postComment(templates.rolesComment({ title: '🛡️ 防守方登場', roles: defenders }));
+  await queueOrPostComment(templates.rolesComment({ title: '🛡️ 防守方登場', roles: defenders }));
  // ── 步驟 8：防守方裁決 → 排除 → 排序 → 保存 findings ──────────────────
-  const { kept, excluded } = await review.runDefenders({ tool, model: ctx.model, cwd, defenders, findings });
+  const { kept, excluded } = findings.length === 0
    ? { kept: [], excluded: [] }
    : await review.runDefenders({ tool, model: ctx.model, cwd, defenders, findings });
  review.sortFindings(kept);
  const relativePath = saveFindings({ cwd, ctx, tool, kept, excluded });
@@ -331,7 +318,7 @@ async function main() {
      } catch (err) {
        log('建問題', 'WRN', `標籤挑選失敗（${err.message}），issue 不掛標籤。`);
      }
-      await ensureIssueCreated(labelIds);
+      await createIssueAndFlushBufferedComments(labelIds);
    } else {
      // 無保留問題 → 不建 issue、PR 也不留言（靜默通過，暫存的情境留言捨棄）。
      log('建問題', 'INF', '沒有保留的問題：靜默通過（不建 issue、PR 不留言）。');
@@ -349,7 +336,7 @@ async function main() {
  // ── 步驟 9：嚴重問題留言（一般模式掛在 PR 程式碼行上；建問題模式逐條發到 issue）─
  if (severe.length > 0) {
    if (ctx.createIssue) {
-      await review.postSevereToIssue({ ctx, gitea, issueNumber: issue.number, severe });
+      await review.postSevereToIssue({ ctx, gitea, issueNumber: trackingIssue.number, severe });
    } else {
      await review.postSevereComments({ ctx, gitea, severe, cwd });
    }
@@ -359,48 +346,62 @@ async function main() {
  //    建問題模式逐條發到 issue，讓每條問題都能被個別回覆。 ──
  if (others.length > 0) {
    if (ctx.createIssue) {
-      await review.postOthersToIssue({ ctx, gitea, issueNumber: issue.number, others });
+      await review.postOthersToIssue({ ctx, gitea, issueNumber: trackingIssue.number, others });
    } else {
-      await postComment(templates.othersComment(others));
+      await queueOrPostComment(templates.othersComment(others));
      log('步驟10', 'INF', `警告＋建議表格留言已發布（${others.length} 條）。`);
    }
  }
-  // ── 建問題模式收束：在 PR 回貼 issue 連結（雙向關聯），並讓 PR 相依於該 issue ─
+  // ── 建問題模式收束：在 PR 回貼 issue 連結（雙向關聯）；僅在有嚴重問題時才讓 PR 相依於該 issue ─
-  //    標籤已於建立 issue 時一次帶入（見上方 selectLabels → ensureIssueCreated），此處不再補掛。
+  //    標籤已於建立 issue 時一次帶入（見上方 selectLabels → createIssueAndFlushBufferedComments），此處不再補掛。
-  if (ctx.createIssue && issue) {
+  if (ctx.createIssue && trackingIssue) {
    await gitea.createIssueComment(
      ctx,
-      templates.issueLinkComment({
+      templates.prIssueLinkComment({
-        issueNumber: issue.number,
+        issueNumber: trackingIssue.number,
-        issueUrl: issue.html_url,
+        issueUrl: trackingIssue.html_url,
        severeCount: severe.length,
        otherCount: others.length,
      }),
    );
-    // 讓 PR 相依於此追蹤 issue：issue 完成／關閉前 PR 無法合併（需 repo 啟用「問題相依」功能）。
+    // 只有「嚴重」問題才讓 PR 相依於追蹤 issue（issue 關閉前無法合併，需 repo 啟用「問題相依」功能）；
-    try {
+    // 僅有警告／建議時，issue 仍建立供追蹤，但不掛相依、不阻擋 PR 合併。
-      await gitea.addIssueDependency(ctx, ctx.prNumber, issue.number);
+    if (severe.length > 0) {
-      log('建問題', 'INF', `已將 PR #${ctx.prNumber} 設為相依於 issue #${issue.number}：issue 關閉前無法合併。`);
+      try {
-    } catch (err) {
+        await gitea.addIssueDependency(ctx, ctx.prNumber, trackingIssue.number);
-      log('建問題', 'WRN', `設定 PR 相依失敗（可能未啟用「問題相依」功能）：${err.message}。`);
+        log('建問題', 'INF', `有嚴重問題：已將 PR #${ctx.prNumber} 設為相依於 issue #${trackingIssue.number}，issue 關閉前無法合併。`);
      } catch (err) {
        log('建問題', 'WRN', `設定 PR 相依失敗（可能未啟用「問題相依」功能）：${err.message}。`);
      }
    } else {
      log('建問題', 'INF', `無嚴重問題（僅警告／建議）：issue #${trackingIssue.number} 僅供追蹤，不阻擋 PR 合併。`);
    }
-    log('建問題', 'INF', `issue #${issue.number} 已寫入審查內容，並在 PR 回貼連結。`);
+    log('建問題', 'INF', `issue #${trackingIssue.number} 已寫入審查內容，並在 PR 回貼連結。`);
  }
  // ── 收尾：commit 並 push（success＝無嚴重問題、failure＝有嚴重問題）───────
-  // 一般模式：findings＋exclusions.json；建問題模式：問題明細已在 issue 留言，只 commit exclusions.json。
+  // 一般模式：findings＋exclusions.json；建問題模式通常只 commit exclusions.json。
  // 若有嚴重問題，仍 commit findings 檔產生 [failure] 結果 commit，避免相依 API 不支援時 fail-open。
  const result = severe.length === 0 ? 'success' : 'failure';
-  const filesToCommit = ctx.createIssue ? [] : [relativePath];
+  const filesToCommit = review.resultFilesToCommit({
-  if (exclusionsChanged) {
+    createIssue: ctx.createIssue,
-    filesToCommit.push(path.join('.gitea', 'ai-review', 'exclusions.json'));
+    severeCount: severe.length,
-  }
+    relativePath,
    exclusionsChanged,
  });
  if (filesToCommit.length > 0) {
    commitFindings({ cwd, ctx, files: filesToCommit, result });
  } else {
    log('收尾', 'INF', '建問題模式且 exclusions.json 無變更，略過 commit/push。');
  }
-  return result === 'success' ? 0 : 1;
+  // 本輪「審查」一律以成功收場、不直接讓檢查失敗；有嚴重問題時已推出 [failure] 結果 commit，
  // 由它再觸發的下一輪在步驟 1 讀 commit 訊息時才回報失敗（exit 1）。如此失敗檢查落在帶有結果
  // 標記的最新 head 上，與合併判定一致。（result 僅用於上方 commit 訊息的結果標記。）
  if (result === 'failure') {
    log('收尾', 'INF', '本輪有嚴重問題：已標記結果 commit 為 [failure]，失敗檢查由下一輪步驟 1 讀 commit 訊息回報。');
  }
  return 0;
 }
 main()
@@ -20,7 +20,6 @@ const path = require('path');
 *   token: string,
 *   model: string,
 *   createIssue: boolean,
 *   pushToken: string,
 *   event: Object,
 *   pr: (Object|null),
 *   prNumber: (number|null),
@@ -38,12 +37,11 @@ const path = require('path');
 * - repository：`owner/repo` 全名（GITHUB_REPOSITORY）。
 * - owner / repo：自 repository 拆出的擁有者與專案名，缺值時為空字串。
 * - apiBase：Gitea REST API 基底網址（`<serverUrl>/api/v1`）。
- * - token：action input `token`（INPUT_TOKEN），用於 API 認證，缺值時為空字串。
+ * - token：action input `token`（INPUT_TOKEN），用於 Gitea API 認證，以及 push findings/exclusions
 *   commit 回 repo；建議為「能觸發 CI 的 PAT」（自動 token 推送不會再觸發 CI）。缺值時為空字串。
 * - model：action input `model`（INPUT_MODEL，已 trim），指定 AI 模型，缺值時為空字串。
 * - createIssue：action input `create-issue`（INPUT_CREATE-ISSUE），是否將問題建到
 *   存取庫的問題追蹤（建問題模式）；trim + 小寫後與字串 'true' 嚴格比對，預設 false。
 * - pushToken：action input `push-token`（INPUT_PUSH-TOKEN），推送 findings/exclusions commit 用的 PAT；
 *   提供時以 PAT 身分推送使 CI 再觸發（配合步驟 1 快速回報）；留空＝退回以 token 走 origin 推送（不會再觸發）。
 * - event：事件 payload 解析後的完整物件；讀取失敗時為空物件。
 * - pr：payload 內的 pull_request 物件；非 PR 事件時為 null。
 * - prNumber：PR 編號，優先取 payload，退而從 GITHUB_REF（refs/pull/N/...）解析；皆無時為 null。
@@ -95,8 +93,6 @@ function loadContext() {
    model: (process.env.INPUT_MODEL || '').trim(),
    // 是否將問題建到存取庫的問題追蹤（input: create-issue，字串 'true' 才啟用，預設否）。
    createIssue: (process.env['INPUT_CREATE-ISSUE'] || '').trim().toLowerCase() === 'true',
    // 推送 findings/exclusions commit 用的 PAT（input: push-token）；提供時以 PAT 推送讓 CI 再觸發，留空＝退回 token。
    pushToken: (process.env['INPUT_PUSH-TOKEN'] || '').trim(),
    event,
    pr,
    prNumber,
@@ -0,0 +1,71 @@
 'use strict';
 // AI CLI 失敗診斷與機密遮罩工具：供 review 流程記錄安全、限長的一行錯誤摘要。
 // 遮罩前先截去的輸入上限，避免對數 MB 失敗輸出跑整份 O(k*n) 正規掃描。
 const AGENT_DIAGNOSTIC_INPUT_LIMIT = 2_000;
 // 每段診斷片段（stderr／stdout）寫入日誌的字元上限。
 const AGENT_DIAGNOSTIC_OUTPUT_LIMIT = 500;
 /**
 * 遮罩診斷文字中的機密與控制字元，避免寫進 CI log 時外洩。
 *
 * 處理順序：換行與控制字元一律壓成單一空白（避免注入假日誌行）→ 遮蔽
 * `Authorization` 標頭、`token=`／`token:` 型憑證、URL 內嵌帳密、以及常見長金鑰／
 * 長 hex／`ghp_` 等 token 樣式。屬「盡力遮罩」——無法窮舉所有機密格式，作為輸出
 * CLI 診斷片段前的防線使用（見 {@link agentFailureDetail}）。
 *
 * @param {*} text - 待遮罩的原始文字（非字串會先以 `String()` 轉型）。
 * @returns {string} 已去控制字元並遮蔽常見機密樣式的單行文字。
 */
 function redactSecrets(text) {
  return String(text ?? '')
    .replace(/[\r\n\t\v\f\x00-\x1f\x7f]+/g, ' ')
    .replace(/(authorization\s*[:=]\s*)(?:bearer\s+)?\S+/gi, '$1***')
    .replace(/((?:api[_-]?key|token|password|secret|bearer)\s*[:=]\s*)\S+/gi, '$1***')
    .replace(/(https?:\/\/)[^\s/:@]+:[^\s/@]+@/gi, '$1***:***@')
    .replace(/\bgh[pousr]_[A-Za-z0-9]{16,}\b/g, '***')
    .replace(/\b[A-Za-z0-9_-]{40,}\b/g, '***')
    .trim();
 }
 /**
 * 從 `runAgent` 的失敗結果組出可診斷的一行摘要：退出碼／訊號為主，原始輸出預設隱藏。
 *
 * 安全考量：AI CLI 失敗時可能在 stderr／stdout 回顯提示內容、環境資訊、token、PII 或
 * 原始碼祕密，這些會被長期保存並供多人讀取的 CI log 收錄。因此本函式預設只輸出退出碼、
 * 訊號與逾時狀態；只有 `ACTIONS_STEP_DEBUG=true` 時才附上經 {@link redactSecrets}
 * 遮罩且去除控制字元的 stderr/stdout 片段。
 *
 * @param {{error: (Error & {code?: number|string, signal?: string, killed?: boolean})|null, stderr?: string, output?: string}} agentResult
 *   `runAgent` 的回傳物件。
 * @returns {string} 單行診斷摘要（各段以「｜」分隔）；無任何資訊時回傳固定字串。
 */
 function agentFailureDetail(agentResult) {
  const parts = [];
  const err = agentResult && agentResult.error;
  if (err) {
    if (err.killed) parts.push('已逾時終止');
    if (typeof err.code === 'number') parts.push(`exit ${err.code}`);
    else if (err.code) parts.push(`code ${err.code}`);
    else if (err.signal) parts.push(`signal ${err.signal}`);
  }
  // 失敗輸出可能含 token 或 PII，預設不寫入長期 CI log；debug 模式才輸出遮罩後片段。
  if (process.env.ACTIONS_STEP_DEBUG === 'true') {
    const stderr = redactSecrets(String((agentResult && agentResult.stderr) || '').slice(0, AGENT_DIAGNOSTIC_INPUT_LIMIT));
    if (stderr) parts.push(`stderr：${stderr.slice(0, AGENT_DIAGNOSTIC_OUTPUT_LIMIT)}`);
    const stdout = redactSecrets(String((agentResult && agentResult.output) || '').slice(0, AGENT_DIAGNOSTIC_INPUT_LIMIT));
    if (stdout) parts.push(`stdout：${stdout.slice(0, AGENT_DIAGNOSTIC_OUTPUT_LIMIT)}`);
  }
  if (parts.length === 0) {
    parts.push((err && err.message && redactSecrets(err.message)) || 'AI CLI 執行失敗（無診斷輸出）');
  }
  return parts.join('｜');
 }
 module.exports = {
  AGENT_DIAGNOSTIC_INPUT_LIMIT,
  AGENT_DIAGNOSTIC_OUTPUT_LIMIT,
  redactSecrets,
  agentFailureDetail,
 };
@@ -119,7 +119,7 @@ function createCommentOnIssue(ctx, issueNumber, body) {
 *   依 Gitea API 回應而定）。
 * @throws {Error} 請求失敗（非 2xx）由底層 `api` 丟出，錯誤附 `status`、`data`。
 * @remarks 使用情境：AI review 各步驟把審查摘要、角色登場、問題彙整等內容
- *   以一般留言形式張貼到本次 PR 上（`main()` 的 `postComment` 閉包即以本函式實作）。
+ *   以一般留言形式張貼到本次 PR 上（`main()` 的 `queueOrPostComment` 閉包即以本函式實作）。
 */
 function createIssueComment(ctx, body) {
  return createCommentOnIssue(ctx, ctx.prNumber, body);
@@ -156,7 +156,7 @@ function listLabels(ctx) {
 * @returns {Promise<object>} 建立成功的 issue 物件（含 `number`、`title`、
 *   `html_url` 等欄位，依 Gitea API 回應而定）。
 * @throws {Error} 請求失敗（非 2xx）由底層 `api` 丟出，錯誤附 `status`、`data`。
- * @remarks 使用情境：建問題模式（input: create-issue）下，`main()` 的 `ensureIssueCreated`
+ * @remarks 使用情境：建問題模式（input: create-issue）下，`main()` 的 `createIssueAndFlushBufferedComments`
 *   以 PR 標題／描述為 issue 標題與本文，並帶入 `review.selectLabels` 事先挑好的標籤 id
 *   呼叫本函式一次建立追蹤問題的 issue（連同標籤），之後再把審查內容逐條留言到該 issue。
 */
@@ -168,49 +168,28 @@ function createIssue(ctx, { title, body, labels }) {
  });
 }
 /**
 * 為既有 issue 追加標籤（不影響既有標籤）。
 * 對應 endpoint：`POST /repos/{owner}/{repo}/issues/{issueNumber}/labels`。
 * `labels` 為空陣列時不呼叫 API、直接回傳 `null`（省一次無意義請求）。
 *
 * @param {object} ctx - 執行環境 context。必要欄位：`apiBase`、`token`、
 *   `owner`（repo 擁有者）、`repo`（repo 名稱）。
 * @param {number|string} issueNumber - 目標 issue 編號。
 * @param {number[]} labels - 要追加的標籤 id 陣列。
 * @returns {Promise<object[]|null>} 追加後該 issue 的標籤陣列（依 Gitea API 回應而定）；
 *   `labels` 為空時回傳 `null`（未發出請求）。
 * @throws {Error} 請求失敗（非 2xx）由底層 `api` 丟出，錯誤附 `status`、`data`。
 * @remarks 使用情境：為既有 issue 動態追加標籤的通用工具（不影響既有標籤）。
 *   註：建問題模式主流程已改為「建立 issue 時一次帶入標籤」（見 `createIssue`），
 *   不再於事後補掛；本函式保留為 Gitea 客戶端的通用能力，供需要事後追加標籤的情境使用。
 */
 function addLabelsToIssue(ctx, issueNumber, labels) {
  if (!labels || labels.length === 0) return Promise.resolve(null);
  return api(ctx, 'POST', `/repos/${ctx.owner}/${ctx.repo}/issues/${issueNumber}/labels`, { labels });
 }
 /**
 * 建立「問題相依」關係：讓 URL 上的 issue／PR 相依於（被阻擋於）表單指定的 issue。
 * 對應 endpoint：`POST /repos/{owner}/{repo}/issues/{issueNumber}/dependencies`
 * （body 為 IssueMeta：`{index, owner, repo}`）。
 *
- * 語義：URL 的 issue（`issueNumber`）相依於 body 的 issue（`dependency`）——
+ * 語義：URL 的 issue（`blockedIssueNumber`）相依於 body 的 issue（`blockingIssueNumber`）——
- * 在 `dependency` 關閉前，`issueNumber` 無法合併／關閉。本 endpoint 需 repo 啟用
+ * 在 `blockingIssueNumber` 關閉前，`blockedIssueNumber` 無法合併／關閉。本 endpoint 需 repo 啟用
 * 「問題相依（issue dependencies）」功能，屬版本／設定相依；未啟用或不支援時 API 會回非 2xx。
 *
 * @param {object} ctx - 執行環境 context。必要欄位：`apiBase`、`token`、
 *   `owner`（repo 擁有者）、`repo`（repo 名稱）。
- * @param {number|string} issueNumber - 要被阻擋的 issue／PR 編號（相依方）。
+ * @param {number|string} blockedIssueNumber - 要被阻擋的 issue／PR 編號（相依方）。
- * @param {number} dependency - 作為阻擋來源的 issue 編號（同一 repo）。
+ * @param {number} blockingIssueNumber - 作為阻擋來源的 issue 編號（同一 repo）。
 * @returns {Promise<object>} 建立成功的相依關係物件（依 Gitea API 回應而定）。
 * @throws {Error} 請求失敗（非 2xx，例如未啟用問題相依功能）由底層 `api` 丟出，錯誤附 `status`、`data`。
 * @remarks 使用情境：建問題模式（input: create-issue）下，`main()` 建立追蹤 issue 後，
 *   以本函式把「PR（`ctx.prNumber`）相依於追蹤 issue」，讓 issue 完成／關閉前 PR 無法合併；
 *   呼叫端以 try/catch 降級（功能未啟用時記 WRN、不阻斷流程）。
 */
-function addIssueDependency(ctx, issueNumber, dependency) {
+function addIssueDependency(ctx, blockedIssueNumber, blockingIssueNumber) {
-  return api(ctx, 'POST', `/repos/${ctx.owner}/${ctx.repo}/issues/${issueNumber}/dependencies`, {
+  return api(ctx, 'POST', `/repos/${ctx.owner}/${ctx.repo}/issues/${blockedIssueNumber}/dependencies`, {
-    index: dependency,
+    index: blockingIssueNumber,
    owner: ctx.owner,
    repo: ctx.repo,
  });
@@ -350,7 +329,6 @@ module.exports = {
  createCommentOnIssue,
  listLabels,
  createIssue,
  addLabelsToIssue,
  addIssueDependency,
  listIssueComments,
  editIssueComment,
@@ -4,6 +4,34 @@ const { execFileSync } = require('child_process');
 // git 操作工具：一律以 execFileSync 呼叫 git（不經 shell，避免注入），輸出以 UTF-8 回傳。
 /**
 * 驗證遠端分支名稱可安全用於 refspec 與 refs/remotes/origin/*。
 *
 * @param {string} refName - 使用者或事件 payload 提供的分支名稱。
 * @param {string} fieldName - 錯誤訊息中的欄位名稱。
 * @returns {string} 原樣回傳通過驗證的分支名稱。
 * @throws {Error} 分支名稱空白、含路徑穿越，或不符合 git 分支 ref 規則時拋出。
 * @remarks
 * 使用情境：`resolveMergeBase` 的 `baseRef` 與 `commitAndPushFindings` 的
 * `headRef` 會被組進 refspec；先驗證可避免惡意 payload 影響本地 refs 路徑。
 */
 function assertSafeBranchRef(refName, fieldName) {
  const value = String(refName || '').trim();
  if (!value) throw new Error(`${fieldName} 不可為空。`);
  if (value.includes('..') || value.startsWith('/') || value.endsWith('/') || value.includes('\\')) {
    throw new Error(`${fieldName} 不是安全的分支名稱：${value}`);
  }
  try {
    execFileSync('git', ['check-ref-format', '--branch', value], {
      encoding: 'utf8',
      stdio: ['ignore', 'pipe', 'pipe'],
    });
  } catch {
    throw new Error(`${fieldName} 不是合法的 git 分支名稱：${value}`);
  }
  return value;
 }
 /**
 * 同步執行 git 指令並回傳原始 stdout 輸出。
 *
@@ -102,6 +130,7 @@ function latestCommitSubject(cwd) {
 * 避免把 base 分支後續演進誤算進 diff。
 */
 function resolveMergeBase(cwd, baseRef) {
  baseRef = assertSafeBranchRef(baseRef, 'baseRef');
  const remoteBase = `origin/${baseRef}`;
  const diagnostics = [];
  // 執行一個 fetch 策略並記錄成敗（只記策略名與成敗，不含 git 原始輸出，避免洩漏遠端資訊）。
@@ -130,17 +159,19 @@ function resolveMergeBase(cwd, baseRef) {
    diagnostics.push('merge-base（首次）：失敗');
  }
-  // 資料驅動的補抓策略：淺層才 unshallow；其後依序 deepen base 與 HEAD。
+  // 資料驅動的補抓策略：先以固定深度分批加深 base 與 HEAD（每步後重試 merge-base，成功即回傳）；
-  // 每個策略成功後立即重試 merge-base，成功即回傳，避免多餘往返。
+  // 只有仍失敗且為淺層 repo 時，才把成本最高的 --unshallow（下載完整歷史）當最後手段，
-  const strategies = [];
+  // 避免大型／長壽 repo 只為找共同祖先就無謂拉全史。
  // 加深 HEAD 側須以「目前 HEAD 的 commit SHA」補抓——遠端符號 `HEAD` 由伺服器解析為
  // 遠端預設分支（非目前 checkout 的 PR head），只加深它並不會補到 PR head 的歷史。
  const headSha = gitTrim(cwd, 'rev-parse', 'HEAD');
  const strategies = [
    ['deepen base', 'fetch', '--no-tags', '--deepen=1000', 'origin', `+refs/heads/${baseRef}:refs/remotes/${remoteBase}`],
    ['deepen PR HEAD', 'fetch', '--no-tags', '--deepen=1000', 'origin', headSha],
  ];
  if (gitTrim(cwd, 'rev-parse', '--is-shallow-repository') === 'true') {
    strategies.push(['unshallow', 'fetch', '--no-tags', '--unshallow', 'origin']);
  }
  strategies.push([
    'deepen base',
    'fetch', '--no-tags', '--deepen=1000', 'origin', `+refs/heads/${baseRef}:refs/remotes/${remoteBase}`,
  ]);
  strategies.push(['deepen HEAD', 'fetch', '--no-tags', '--deepen=1000', 'origin', 'HEAD']);
  for (const [label, ...args] of strategies) {
    if (!runFetch(label, ...args)) continue; // fetch 失敗就換下一個策略。
@@ -223,9 +254,9 @@ function fileLastUpdatedIso(cwd, file) {
 * 若目前 HEAD 不在 PR head commit（例如 checkout 停在 merge commit），
 * 會先 `git checkout --detach <headSha>` 站上 head，避免把 merge 內容推回來源分支。
 * commit 以 `-c` 臨時覆寫 user.name / user.email，不改動 repo 的 git 設定。
- * push 策略：提供 `pushToken`（PAT）時直接以該 token 的 URL 推送（略過 origin）——因為 origin
+ * push 策略：一律以 `token` 的身分明確認證推送（{@link pushWithCredential}，不走 runner 的
- * 帶的是不會再觸發 CI 的自動 token，改以 PAT 身分推送才會讓 PR 的 synchronize 事件再觸發 CI；
+ * origin 自動 token）——origin 帶的自動 token（gitea.token / GITHUB_TOKEN）推送不會再觸發 CI，
- * 未提供 `pushToken` 時先走 origin，失敗（遠端未帶認證）再改用帶 `token` 的 URL 重試。
+ * 改以呼叫端提供的 `token`（建議為 PAT）身分推送，才會讓 PR 的 synchronize 事件再觸發 CI。
 *
 * @param {string} cwd - git 工作目錄（repo 的 checkout 路徑）。
 * @param {object} options - 提交與推送設定。
@@ -233,8 +264,7 @@ function fileLastUpdatedIso(cwd, file) {
 * @param {string} [options.headSha] - PR head 的 commit SHA；有提供且與目前 HEAD 不同時會先 detach 到此 commit。可省略（falsy 時不 detach，直接於目前 HEAD 上 commit）。
 * @param {string} options.message - commit 訊息。
 * @param {string[]} options.files - 要加入 commit 的檔案路徑清單（相對 repo 根目錄）；全數無實際變更時不 commit、回傳 false。
- * @param {string} options.token - 具該 repo push 權限的 Gitea access token；未提供 pushToken 時，於 origin push 失敗才用於組出帶認證的重試 URL。
+ * @param {string} options.token - 具該 repo push 權限的 Gitea access token（建議為能觸發 CI 的 PAT）；用於 findings commit 的認證推送。
 * @param {string} [options.pushToken] - 專用推送 token（PAT）；提供時直接以此 token 的 URL 推送（略過 origin），使 push 以 PAT 身分進行以再觸發 CI；未提供時走 origin、失敗再退回 `token`。
 * @param {string} options.serverUrl - Gitea 伺服器根網址（例如 https://gitea.example.com），須為合法 URL。
 * @param {string} options.repository - repo 完整名稱（owner/repo 格式），與 serverUrl 組成 clone URL。
 * @returns {boolean} true＝有變更且已 commit 並 push 到來源分支；false＝暫存區與 HEAD 無差異，略過 commit/push。
@@ -244,12 +274,13 @@ function fileLastUpdatedIso(cwd, file) {
 * findings 檔與 `.gitea/ai-review/exclusions.json` 等結果檔提交回 PR 來源分支，
 * 並依回傳值記錄「已 commit/push」或「無實際變更、略過」的不同日誌。
 *
- * 安全注意：push 重試時組出的 URL 內含 token（形如
+ * 安全注意：帶認證的推送一律透過 {@link pushWithCredential} 進行——認證只以
- * `https://ai-review-bot:<token>@host/owner/repo.git`），
+ * 環境變數（`http.<url>.extraheader` 的 base64 Basic）傳入，**不進 argv**，
- * 絕對不得將此 URL 輸出到日誌、錯誤訊息或任何 action 輸出，以免洩漏 token；
+ * 推送目標 URL 本身不含帳密；且 push 失敗時改拋固定訊息，避免 `execFileSync`
- * 若需記錄重試行為，只能記載「改用帶認證 URL 重試」而不得包含 URL 本身。
+ * 例外把命令列（含 token）回顯到 CI log 或程序清單。
 */
-function commitAndPushFindings(cwd, { headRef, headSha, message, files, token, pushToken, serverUrl, repository }) {
+function commitAndPushFindings(cwd, { headRef, headSha, message, files, token, serverUrl, repository }) {
  headRef = assertSafeBranchRef(headRef, 'headRef');
  const current = gitTrim(cwd, 'rev-parse', 'HEAD');
  if (headSha && current !== headSha) {
    git(cwd, 'checkout', '--detach', headSha);
@@ -267,28 +298,69 @@ function commitAndPushFindings(cwd, { headRef, headSha, message, files, token, p
    '-c', 'user.email=ai-review-bot@noreply.gitea',
    'commit', '-m', message,
  );
-  if (pushToken) {
+  const refspec = `HEAD:refs/heads/${headRef}`;
-    // 有專用 PAT → 直接以帶 token 的 URL 推送（略過 origin，因 origin 帶的是不會再觸發 CI 的自動 token）；
+  const remoteUrl = `${serverUrl}/${repository}.git`;
-    // 以 PAT 身分推送才會讓 PR 的 synchronize 事件再觸發 CI。不得把含 token 的 URL 輸出到日誌。
+  // 一律以 token 的身分明確認證推送（不走 origin 的自動 token）——只要 token 是能觸發 CI 的 PAT，
-    const url = new URL(`${serverUrl}/${repository}.git`);
+  // 結果 commit 就會讓 PR 的 synchronize 事件再觸發 CI，由步驟 1 快速回報把結果蓋到新 head。
-    url.username = 'ai-review-bot';
+  pushWithCredential(cwd, remoteUrl, token, refspec, serverUrl);
    url.password = pushToken;
    git(cwd, 'push', url.toString(), `HEAD:refs/heads/${headRef}`);
  } else {
    try {
      git(cwd, 'push', 'origin', `HEAD:refs/heads/${headRef}`);
    } catch {
      // 遠端未帶認證（checkout 未保留 credentials）時，改用帶 token 的 URL 重試。
      // 注意：不得把這個 URL 輸出到日誌，避免洩漏 token。
      const url = new URL(`${serverUrl}/${repository}.git`);
      url.username = 'ai-review-bot';
      url.password = token;
      git(cwd, 'push', url.toString(), `HEAD:refs/heads/${headRef}`);
    }
  }
  return true;
 }
 /**
 * 以帶認證的方式推送到指定遠端，認證資訊只經環境變數傳入、不進命令列 argv。
 *
 * 認證方式：等同 `https://ai-review-bot:<secret>@host/...` 的 HTTP Basic（git 會把
 * URL 帳密轉成相同的 `Authorization: Basic` 標頭送出），但改以 git 的
 * `GIT_CONFIG_*` 環境變數注入 `http.<serverUrl>/.extraheader`，使 base64 憑證**不出現在 argv**
 * （避免程序清單／例外回顯洩漏）；推送目標 URL 亦不含帳密。
 *
 * 觸發 CI 關鍵：`actions/checkout` 會把「自動 Actions token」持久化在同一個
 * `http.<serverUrl>/.extraheader` scope；若沿用它推送，Gitea 會視為「自動 token 觸發」而
 * **不再觸發 workflow**（防遞迴）。故本函式對這次 push 於該 scope**先以空值重置**（清掉自動
 * token——git 對 extraHeader 給空值即清空既有清單），**再注入 PAT 的 Authorization**，讓推送以
 * PAT 身分進行、觸發 PR 的 synchronize；作用範圍僅限本次 push 的環境變數，不影響 action 其他
 * 仰賴 checkout 持久化憑證的 fetch（如 {@link resolveMergeBase}）。
 * 推送失敗時**不重拋原始例外**（其 message 會含命令列與遠端 URL），改拋固定訊息。
 *
 * @param {string} cwd - git 工作目錄（repo 的 checkout 路徑）。
 * @param {string} remoteUrl - 不含帳密的遠端 URL（形如 `https://host/owner/repo.git`）。
 * @param {string} token - 具 push 權限的 token／PAT（作為 Basic 認證的密碼）。
 * @param {string} refspec - push 的 refspec（形如 `HEAD:refs/heads/<branch>`）。
 * @param {string} serverUrl - Gitea 伺服器根網址（用於定位 checkout 持久化 extraheader 的 scope）。
 * @returns {void} 成功即返回；失敗拋出不含 URL／argv／token 的固定錯誤。
 * @throws {Error} 推送失敗時拋出固定訊息（已隱藏遠端 URL 與認證資訊）。
 * @remarks 本函式未匯出，僅供 {@link commitAndPushFindings} 使用。
 */
 function pushWithCredential(cwd, remoteUrl, token, refspec, serverUrl) {
  const server = new URL(serverUrl);
  const remote = new URL(remoteUrl);
  if (remote.origin !== server.origin || !remote.pathname.endsWith('.git')) {
    throw new Error('推送遠端 URL 與 Gitea 伺服器不相符，已停止推送。');
  }
  const basic = Buffer.from(`ai-review-bot:${token}`).toString('base64');
  // checkout 持久化自動 token 的 scope 為 `http.<serverUrl>/.extraheader`（結尾帶斜線）。
  const headerScope = `http.${server.origin}/.extraheader`;
  try {
    execFileSync('git', ['push', remoteUrl, refspec], {
      cwd,
      encoding: 'utf8',
      maxBuffer: 64 * 1024 * 1024,
      env: {
        ...process.env,
        GIT_TERMINAL_PROMPT: '0',
        // 兩筆同 scope 設定：先空值清掉 checkout 的自動 token，再注入 PAT 的 Authorization。
        GIT_CONFIG_COUNT: '2',
        GIT_CONFIG_KEY_0: headerScope,
        GIT_CONFIG_VALUE_0: '',
        GIT_CONFIG_KEY_1: headerScope,
        GIT_CONFIG_VALUE_1: `Authorization: Basic ${basic}`,
      },
    });
  } catch {
    throw new Error('推送審查結果 commit 失敗（已隱藏遠端 URL 與認證資訊）。');
  }
 }
 module.exports = {
  latestCommitSubject,
  resolveMergeBase,
@@ -296,4 +368,7 @@ module.exports = {
  fileDiff,
  fileLastUpdatedIso,
  commitAndPushFindings,
  __test: {
    assertSafeBranchRef,
  },
 };
@@ -5,6 +5,7 @@ const path = require('path');
 const { log, taipeiFromIso, taipeiNow } = require('./log');
 const { runAgent, extractJson } = require('./agents');
 const { agentFailureDetail } = require('./diagnostics');
 const templates = require('./templates');
 // 審查流程核心：.reviewignore 過濾、diff 整理、攻擊方找問題、防守方裁決、排序分組與舊留言處理。
@@ -13,71 +14,6 @@ const templates = require('./templates');
 const PER_FILE_DIFF_LIMIT = 16_000;
 const TOTAL_DIFF_LIMIT = 160_000;
 /**
 * 遮罩單行診斷文字中的機密與控制字元，避免寫進 CI log 時外洩。
 *
 * 處理順序：換行與控制字元一律壓成單一空白（避免注入假日誌行）→ 遮蔽
 * `Authorization` 標頭、`token=`／`token:` 型憑證、URL 內嵌帳密、以及常見長金鑰／
 * 長 hex／`ghp_` 等 token 樣式。屬「盡力遮罩」——無法窮舉所有機密格式，故僅在
 * 明確開啟除錯輸出時作為第二道防線使用（見 {@link agentFailureDetail}）。
 *
 * @param {*} text - 待遮罩的原始文字（非字串會先以 `String()` 轉型）。
 * @returns {string} 已去控制字元並遮蔽常見機密樣式的單行文字。
 * @remarks 本函式未匯出，僅供模組內部使用。
 */
 function redactSecrets(text) {
  return String(text ?? '')
    .replace(/[\r\n\t\v\f\x00-\x1f\x7f]+/g, ' ')
    .replace(/(authorization\s*[:=]\s*)\S+/gi, '$1***')
    .replace(/((?:api[_-]?key|token|password|secret|bearer)\s*[:=]\s*)\S+/gi, '$1***')
    .replace(/(https?:\/\/)[^\s/:@]+:[^\s/@]+@/gi, '$1***:***@')
    .replace(/\bgh[pousr]_[A-Za-z0-9]{16,}\b/g, '***')
    .replace(/\b[A-Za-z0-9_-]{40,}\b/g, '***')
    .trim();
 }
 /**
 * 從 `runAgent` 的失敗結果組出可診斷的一行摘要：退出碼／訊號為主，原始輸出預設隱藏。
 *
 * 安全考量：AI CLI 失敗時可能在 stderr／stdout 回顯提示內容、環境資訊、token、PII 或
 * 原始碼祕密，這些會被長期保存並供多人讀取的 CI log 收錄。故本函式**預設只輸出**
 * exit code／signal／killed 等不含機密的分類資訊；**僅在明確開啟 Actions step debug**
 * （環境變數 `ACTIONS_STEP_DEBUG=true`）時，才附上經 {@link redactSecrets} 遮罩且去除
 * 控制字元的 stderr／stdout 片段（各截前 500 字）作為診斷第二選擇。純函式、不拋例外。
 *
 * @param {{error: (Error & {code?: number|string, signal?: string, killed?: boolean})|null, stderr?: string, output?: string}} res
 *   `runAgent` 的回傳物件。
 * @returns {string} 單行診斷摘要（各段以「｜」分隔）；無任何資訊時回傳固定字串。
 * @remarks
 * 使用情境：{@link runAttackers}／{@link runDefenders}／{@link fillPurposes}／{@link selectLabels}
 * 判定 `!res.ok` 時，以本函式把失敗細節寫進 WRN log，讓 CI 記錄能看出 AI CLI 為何失敗；
 * 需要原始輸出診斷時，於 workflow 設定 secret `ACTIONS_STEP_DEBUG=true` 再重跑。
 * 本函式未匯出，僅供模組內部使用。
 */
 function agentFailureDetail(res) {
  const parts = [];
  const err = res && res.error;
  if (err) {
    if (err.killed) parts.push('已逾時終止');
    if (typeof err.code === 'number') parts.push(`exit ${err.code}`);
    else if (err.code) parts.push(`code ${err.code}`);
    else if (err.signal) parts.push(`signal ${err.signal}`);
  }
  // 預設不輸出 AI CLI 原始 stderr/stdout（可能含 token、PII 或原始碼祕密）；
  // 僅在明確開啟 Actions step debug 時，附上「已遮罩＋去控制字元」的片段作為診斷。
  const verbose = String(process.env.ACTIONS_STEP_DEBUG || '').trim().toLowerCase() === 'true';
  if (verbose) {
    const stderr = redactSecrets((res && res.stderr) || '');
    if (stderr) parts.push(`stderr：${stderr.slice(0, 500)}`);
    const stdout = redactSecrets((res && res.output) || '');
    if (stdout) parts.push(`stdout：${stdout.slice(0, 500)}`);
  }
  if (parts.length === 0) {
    parts.push((err && err.message && redactSecrets(err.message)) || 'AI CLI 執行失敗（詳細輸出已隱藏）');
  }
  return parts.join('｜');
 }
 /**
 * 讀取工作目錄下的 `.reviewignore`，解析為忽略路徑前綴清單。
 *
@@ -621,6 +557,28 @@ function appendExclusions({ cwd, excluded, prNumber }) {
  return true;
 }
 /**
 * 依審查模式與結果決定收尾要提交的結果檔。
 *
 * 一般模式永遠提交本回合 findings 檔；建問題模式通常把問題明細留在 issue，不提交
 * findings。例外是有嚴重問題時仍提交 findings 檔，讓 `[failure]` 結果 commit 一定能產生，
 * 避免問題相依 API 不支援或設定失敗時 PR 缺少失敗檢查。
 *
 * @param {Object} params - 解構參數。
 * @param {boolean} params.createIssue - 是否啟用建問題模式。
 * @param {number} params.severeCount - 嚴重 finding 數量。
 * @param {string} params.relativePath - 本回合保存的 findings 檔 repo 相對路徑。
 * @param {boolean} params.exclusionsChanged - exclusions.json 是否有實際異動。
 * @returns {string[]} 應交給 `commitFindings` 的 repo 相對路徑清單。
 */
 function resultFilesToCommit({ createIssue, severeCount, relativePath, exclusionsChanged }) {
  const files = createIssue ? (severeCount > 0 ? [relativePath] : []) : [relativePath];
  if (exclusionsChanged) {
    files.push(path.join('.gitea', 'ai-review', 'exclusions.json'));
  }
  return files;
 }
 /**
 * 就地排序 findings：依 嚴重→警告→建議、再依檔案路徑、再依起始行遞增。
 *
@@ -921,6 +879,7 @@ module.exports = {
  runDefenders,
  sortFindings,
  appendExclusions,
  resultFilesToCommit,
  selectLabels,
  postSevereToIssue,
  postOthersToIssue,
@@ -302,7 +302,7 @@ function othersComment(findings) {
 * @param {string} [params.prBody] - PR 描述原文；nullish 或 trim 後為空時輸出佔位文字。
 * @returns {string} 完整 issue 本文 Markdown 字串（含 MARK 隱藏標記）。
 * @remarks
- * 使用情境：建問題模式下 `main()`（src/index.js）的 `ensureIssueCreated` 建立 issue 時，
+ * 使用情境：建問題模式下 `main()`（src/index.js）的 `createIssueAndFlushBufferedComments` 建立 issue 時，
 * 以「標題＝PR 標題、本文＝本函式輸出」呼叫 `gitea.createIssue`，
 * 讓 issue 讀者能從本文回溯到觸發審查的 PR，再從下方留言逐條查看問題明細。
 */
@@ -334,9 +334,9 @@ ${body || '（PR 無描述）'}
 * @param {string} [finding.suggestedCode] - 建議寫法程式碼；有值才輸出「建議寫法」區塊。
 * @returns {string} 完整留言 Markdown 字串（含 MARK 隱藏標記）。
 * @remarks
- * 使用情境：建問題模式下 `review.postSevereToIssue`（src/lib/review.js）把每條嚴重 finding
+ * 使用情境：建問題模式下 `review.postSevereToIssue` 與 `review.postOthersToIssue`
- * 以本函式產生留言內容、經 `gitea.createCommentOnIssue` 發布到追蹤 issue 上，
+ * 把每條 finding 以本函式產生留言內容、經 `gitea.createCommentOnIssue`
- * 作為問題明細的追蹤紀錄。
+ * 發布到追蹤 issue 上，作為問題明細的追蹤紀錄。
 */
 function issueFindingComment(finding) {
  const emoji = SEVERITY_EMOJI[finding.severity] || '🔵';
@@ -400,7 +400,7 @@ function nothingToReviewComment(ignoredCount) {
 * 以本函式對 PR 留一則連結留言，達成「問題關聯回 PR」；issue 內文另以
 * {@link issueBody} 反向引用 `PR #N`，形成雙向交叉連結。
 */
-function issueLinkComment({ issueNumber, issueUrl, severeCount, otherCount }) {
+function prIssueLinkComment({ issueNumber, issueUrl, severeCount, otherCount }) {
  return `${MARK}
 ## 🔍 AI Code Review｜已建立追蹤問題
@@ -421,5 +421,5 @@ module.exports = {
  issueBody,
  issueFindingComment,
  nothingToReviewComment,
-  issueLinkComment,
+  prIssueLinkComment,
 };
@@ -0,0 +1,73 @@
 'use strict';
 const assert = require('node:assert/strict');
 const test = require('node:test');
 const gitea = require('../src/lib/gitea');
 function withFetchStub(handler, callback) {
  const originalFetch = global.fetch;
  const calls = [];
  global.fetch = async (url, options = {}) => {
    calls.push({ url, options });
    return handler(url, options);
  };
  return Promise.resolve()
    .then(() => callback(calls))
    .finally(() => {
      global.fetch = originalFetch;
    });
 }
 function jsonResponse(data, ok = true, status = 200) {
  return {
    ok,
    status,
    async text() {
      return JSON.stringify(data);
    },
  };
 }
 test('addIssueDependency 使用正確 endpoint、method 與 IssueMeta body', async () => {
  const ctx = {
    apiBase: 'https://gitea.example.test/api/v1',
    token: 'hidden',
    owner: 'owner',
    repo: 'repo',
  };
  await withFetchStub(() => jsonResponse({ ok: true }), async (calls) => {
    await gitea.addIssueDependency(ctx, 12, 34);
    assert.equal(calls.length, 1);
    assert.equal(calls[0].url, 'https://gitea.example.test/api/v1/repos/owner/repo/issues/12/dependencies');
    assert.equal(calls[0].options.method, 'POST');
    assert.equal(calls[0].options.headers.Authorization, 'token hidden');
    assert.deepEqual(JSON.parse(calls[0].options.body), {
      index: 34,
      owner: 'owner',
      repo: 'repo',
    });
  });
 });
 test('createIssue 空 labels 不送出 labels 欄位', async () => {
  const ctx = {
    apiBase: 'https://gitea.example.test/api/v1',
    token: 'hidden',
    owner: 'owner',
    repo: 'repo',
  };
  await withFetchStub(() => jsonResponse({ number: 5 }), async (calls) => {
    await gitea.createIssue(ctx, { title: 'title', body: 'body', labels: [] });
    assert.equal(calls[0].url, 'https://gitea.example.test/api/v1/repos/owner/repo/issues');
    assert.equal(calls[0].options.method, 'POST');
    assert.deepEqual(JSON.parse(calls[0].options.body), {
      title: 'title',
      body: 'body',
    });
  });
 });
@@ -0,0 +1,24 @@
 'use strict';
 const assert = require('node:assert/strict');
 const test = require('node:test');
 const gitrepo = require('../src/lib/gitrepo');
 test('assertSafeBranchRef 接受一般分支名稱', () => {
  assert.equal(gitrepo.__test.assertSafeBranchRef('feature/review-123', 'baseRef'), 'feature/review-123');
 });
 test('assertSafeBranchRef 拒絕路徑穿越分支名稱', () => {
  assert.throws(
    () => gitrepo.__test.assertSafeBranchRef('../../hooks/pre-push', 'baseRef'),
    /不是安全的分支名稱/,
  );
 });
 test('resolveMergeBase 會在 git fetch 前拒絕不安全 baseRef', () => {
  assert.throws(
    () => gitrepo.resolveMergeBase(process.cwd(), '../../hooks/pre-push'),
    /不是安全的分支名稱/,
  );
 });
@@ -0,0 +1,99 @@
 'use strict';
 const assert = require('node:assert/strict');
 const test = require('node:test');
 const review = require('../src/lib/review');
 const diagnostics = require('../src/lib/diagnostics');
 test('agentFailureDetail 預設不輸出 stderr/stdout 片段', () => {
  const oldDebug = process.env.ACTIONS_STEP_DEBUG;
  delete process.env.ACTIONS_STEP_DEBUG;
  try {
    const detail = diagnostics.agentFailureDetail({
      ok: false,
      error: Object.assign(new Error('boom'), { code: 1 }),
      stderr: 'token=super-secret-value',
      output: 'stdout with password=hidden',
    });
    assert.match(detail, /exit 1/);
    assert.doesNotMatch(detail, /super-secret-value|password|stdout|stderr/);
  } finally {
    if (oldDebug === undefined) delete process.env.ACTIONS_STEP_DEBUG;
    else process.env.ACTIONS_STEP_DEBUG = oldDebug;
  }
 });
 test('agentFailureDetail 在 debug 模式輸出遮罩後片段', () => {
  const oldDebug = process.env.ACTIONS_STEP_DEBUG;
  process.env.ACTIONS_STEP_DEBUG = 'true';
  try {
    const detail = diagnostics.agentFailureDetail({
      ok: false,
      error: Object.assign(new Error('boom'), { code: 2 }),
      stderr: 'Authorization: Bearer abcdefghijklmnopqrstuvwxyz1234567890',
      output: 'token=abcdefghijklmnopqrstuvwxyz1234567890TOKEN',
    });
    assert.match(detail, /exit 2/);
    assert.match(detail, /stderr：Authorization: \*\*\*/);
    assert.match(detail, /stdout：token=\*\*\*/);
    assert.doesNotMatch(detail, /abcdefghijklmnopqrstuvwxyz/);
  } finally {
    if (oldDebug === undefined) delete process.env.ACTIONS_STEP_DEBUG;
    else process.env.ACTIONS_STEP_DEBUG = oldDebug;
  }
 });
 test('postOthersToIssue 依序送出 issue 留言以維持排序', async () => {
  const calls = [];
  let active = 0;
  let maxActive = 0;
  const fakeGitea = {
    async createCommentOnIssue(ctx, issueNumber, body) {
      active += 1;
      maxActive = Math.max(maxActive, active);
      calls.push({ ctx, issueNumber, body });
      await new Promise((resolve) => setTimeout(resolve, 20));
      active -= 1;
      return { id: calls.length };
    },
  };
  await review.postOthersToIssue({
    ctx: { token: 'hidden' },
    gitea: fakeGitea,
    issueNumber: 7,
    others: [
      { severity: '警告', reviewer: 'Maya', file: 'a.js', startLine: 1, endLine: 1, problem: 'p1', suggestion: 's1' },
      { severity: '建議', reviewer: 'Bard', file: 'b.js', startLine: 2, endLine: 2, problem: 'p2', suggestion: 's2' },
    ],
  });
  assert.equal(calls.length, 2);
  assert.equal(calls[0].issueNumber, 7);
  assert.equal(maxActive, 1);
 });
 test('resultFilesToCommit 在建問題模式有嚴重問題時仍提交 findings', () => {
  assert.deepEqual(
    review.resultFilesToCommit({
      createIssue: true,
      severeCount: 1,
      relativePath: '.gitea/ai-review/findings/run.json',
      exclusionsChanged: false,
    }),
    ['.gitea/ai-review/findings/run.json'],
  );
 });
 test('resultFilesToCommit 在建問題模式無嚴重問題時只提交 exclusions 異動', () => {
  assert.deepEqual(
    review.resultFilesToCommit({
      createIssue: true,
      severeCount: 0,
      relativePath: '.gitea/ai-review/findings/run.json',
      exclusionsChanged: true,
    }),
    ['.gitea/ai-review/exclusions.json'],
  );
 });
Author	SHA1	Message	Date
Jeffery	d424447d15	chore(ai-review 狀態): 回寫本輪已處理 findings node-actions/template: CI / BUILD (pull_request) Successful in 4s Details CI / TEST (Antigravity) (pull_request) Successful in 52s Details CI / TEST (Codex) (pull_request) Successful in 2m47s Details CI / TEST (Claude) (pull_request) Successful in 26s Details	2026-07-21 14:39:42 +08:00
Jeffery	9d05af647b	fix(ai-review): 對齊建問題模式留言順序與命名	2026-07-21 14:39:42 +08:00
ai-review-bot	941d763129	chore: update ai-review findings [ai-review-bot][failure] node-actions/template: CI / BUILD (pull_request) Successful in 4s Details CI / TEST (Codex) (pull_request) Failing after 24s Details CI / TEST (Claude) (pull_request) Failing after 28s Details CI / TEST (Antigravity) (pull_request) Failing after 33s Details	2026-07-21 06:27:43 +00:00
Jeffery	9e7f8a2a0a	chore(ai-review 狀態): 回寫本輪已處理 findings node-actions/template: CI / BUILD (pull_request) Successful in 3s Details CI / TEST (Claude) (pull_request) Successful in 27s Details CI / TEST (Antigravity) (pull_request) Successful in 48s Details CI / TEST (Codex) (pull_request) Successful in 3m18s Details	2026-07-21 14:24:14 +08:00
Jeffery	8b50a0d643	test(ai-review): 補上建問題模式結果檔測試	2026-07-21 14:24:10 +08:00
Jeffery	555611db07	fix(ai-review): 避免建問題模式嚴重結果 fail-open	2026-07-21 14:24:04 +08:00
ai-review-bot	24b248884f	chore: update ai-review findings [ai-review-bot][failure] node-actions/template: CI / BUILD (pull_request) Successful in 4s Details CI / TEST (Claude) (pull_request) Failing after 26s Details CI / TEST (Codex) (pull_request) Failing after 32s Details CI / TEST (Antigravity) (pull_request) Failing after 46s Details	2026-07-21 05:50:00 +00:00
Jeffery	e0ae6f886f	chore(ai-review 狀態): 回寫已處理 findings node-actions/template: CI / BUILD (pull_request) Successful in 5s Details CI / TEST (Claude) (pull_request) Successful in 28s Details CI / TEST (Antigravity) (pull_request) Successful in 52s Details CI / TEST (Codex) (pull_request) Successful in 2m58s Details	2026-07-21 13:46:48 +08:00
Jeffery	55b349da07	test(ai-review): 補上安全與 Gitea 契約測試	2026-07-21 13:46:43 +08:00
Jeffery	6a26984bee	fix(ai-review): 強化安全防護與建問題留言處理	2026-07-21 13:46:39 +08:00
ai-review-bot	a8561b4257	chore: update ai-review findings [ai-review-bot][failure] node-actions/template: CI / BUILD (pull_request) Successful in 5s Details CI / TEST (Codex) (pull_request) Failing after 25s Details CI / TEST (Claude) (pull_request) Failing after 26s Details CI / TEST (Antigravity) (pull_request) Failing after 32s Details	2026-07-20 10:45:36 +00:00
JefferyandClaude Opus 4.8	5ac73f290e	refactor(review): 診斷輸出長度常數提升為模組層級 node-actions/template: CI / BUILD (pull_request) Successful in 5s Details CI / TEST (Claude) (pull_request) Successful in 32s Details CI / TEST (Antigravity) (pull_request) Successful in 49s Details CI / TEST (Codex) (pull_request) Successful in 2m22s Details 依議題 #24 Bard 建議，將 agentFailureDetail 內的 INPUT_LIMIT／ AGENT_DIAGNOSTIC_OUTPUT_LIMIT 移至模組頂層，與既有 PER_FILE_DIFF_LIMIT／ TOTAL_DIFF_LIMIT 並列集中管理；值與行為不變。 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-20 18:43:06 +08:00
ai-review-bot	05153bba8e	chore: update ai-review findings [ai-review-bot][failure] node-actions/template: CI / BUILD (pull_request) Successful in 4s Details CI / TEST (Codex) (pull_request) Failing after 25s Details CI / TEST (Claude) (pull_request) Failing after 25s Details CI / TEST (Antigravity) (pull_request) Failing after 32s Details	2026-07-20 10:36:03 +00:00
JefferyandClaude Opus 4.8	d7cecc8fa8	chore(ai-review findings): 寫回議題 #11–#23 只來自議題的待人工 findings node-actions/template: CI / BUILD (pull_request) Successful in 4s Details CI / TEST (Claude) (pull_request) Successful in 24s Details CI / TEST (Antigravity) (pull_request) Successful in 58s Details CI / TEST (Codex) (pull_request) Successful in 2m51s Details 以 --issue all 處理 13 個建問題模式追蹤議題，逐條對照目前程式碼與 exclusions.json 後： ✅ 已解決 18 條（現行程式碼已修）、🚫 誤報 28 條（已列入 exclusions，不重複新增）、 ⏭️ 待人工 44 條（設計／效能／慣例取捨，依主題去重寫回 42 條追蹤）。各議題已留言處理進度並關閉。 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-20 18:33:01 +08:00
ai-review-bot	0c29daa014	chore: update ai-review findings [ai-review-bot][failure] CI / TEST (Antigravity) (pull_request) Failing after 51s Details node-actions/template: CI / BUILD (pull_request) Successful in 28s Details CI / TEST (Claude) (pull_request) Failing after 31s Details CI / TEST (Codex) (pull_request) Failing after 41s Details	2026-07-20 10:07:27 +00:00
JefferyandClaude Opus 4.8	d8dd5ce92e	chore(ai-review 狀態): 記錄 issue #10 誤報排除並回寫待人工 findings node-actions/template: CI / BUILD (pull_request) Successful in 4s Details CI / TEST (Claude) (pull_request) Successful in 27s Details CI / TEST (Antigravity) (pull_request) Successful in 50s Details CI / TEST (Codex) (pull_request) Successful in 3m2s Details - exclusions.json 新增一條誤報（gitrepo.js:276 使用者名稱固定 ai-review-bot，依管理員指示）。 - 新增 findings 檔追蹤 4 條待人工處理問題（步驟編號硬編碼、兩處缺測試、debug 輸出取捨）。 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-20 18:04:23 +08:00
JefferyandClaude Opus 4.8	cc9c8afed7	docs(ai-review): 同步 JSDoc 對 main() 閉包改名的引用配合 postComment／ensureIssueCreated 改名，更新 gitea.js 與 templates.js JSDoc 內對兩個閉包的引用名稱。 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-20 18:04:23 +08:00
JefferyandClaude Opus 4.8	0c108ab7f9	refactor(ai-review): 重新命名留言閉包並抽出診斷輸出長度常數 - postComment → queueOrPostComment：涵蓋建問題模式下可能只暫存不立即發布的語義。 - ensureIssueCreated → createIssueAndFlushBufferedComments：明示建立 issue 並清空暫存留言的完整行為。 - review.js agentFailureDetail 的 500 字上限抽為具名常數 AGENT_DIAGNOSTIC_OUTPUT_LIMIT。純內部命名與可讀性調整，無外部行為變更。 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-20 18:04:23 +08:00
JefferyandClaude Opus 4.8	83dd56f37f	fix(resolveMergeBase): deepen HEAD 改以目前 HEAD 的 SHA 補抓 PR head 歷史原策略 fetch 遠端符號 HEAD，會被伺服器解析為遠端預設分支，只加深預設分支歷史、補不到目前 checkout 的 PR head，淺層時仍可能算不出 merge-base。改先 rev-parse 取得 HEAD 的 commit SHA，以該 SHA 加深 PR head 側歷史。 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-20 18:04:23 +08:00
ai-review-bot	d354f30c27	chore: update ai-review findings [ai-review-bot][failure] node-actions/template: CI / BUILD (pull_request) Successful in 4s Details CI / TEST (Claude) (pull_request) Failing after 20s Details CI / TEST (Codex) (pull_request) Failing after 27s Details CI / TEST (Antigravity) (pull_request) Failing after 33s Details	2026-07-20 09:54:00 +00:00
JefferyandClaude Opus 4.8	b5264141c4	fix(推送觸發 CI): push 前重置 checkout 的自動 token extraheader，改以 PAT 身分推送 node-actions/template: CI / BUILD (pull_request) Successful in 3s Details CI / TEST (Claude) (pull_request) Successful in 32s Details CI / TEST (Antigravity) (pull_request) Successful in 52s Details CI / TEST (Codex) (pull_request) Successful in 2m38s Details checkout 於 http.<serverUrl>/.extraheader 持久化自動 Actions token；沿用它推送會被 Gitea 視為自動 token 觸發而不再觸發 workflow。改為推送前於同 scope 先空值重置、再注入 PAT 的 Authorization，使 findings 結果 commit 以 PAT 身分推送、觸發 PR synchronize。 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-20 17:51:21 +08:00
ai-review-bot	4b779ee00b	chore: update ai-review findings [ai-review-bot][failure]	2026-07-20 09:43:57 +00:00
JefferyandClaude Opus 4.8	deb20bb078	chore(ai-review 狀態): 寫回議題 #9 待人工處理問題至 findings node-actions/template: CI / BUILD (pull_request) Successful in 9s Details CI / TEST (Claude) (pull_request) Successful in 27s Details CI / TEST (Antigravity) (pull_request) Successful in 51s Details CI / TEST (Codex) (pull_request) Successful in 3m4s Details Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-20 17:40:50 +08:00
JefferyandClaude Opus 4.8	c63b1a6da2	perf(resolveMergeBase): 先 deepen base/HEAD，--unshallow 降為最後手段 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-20 17:40:50 +08:00
ai-review-bot	ed883f6f20	chore: update ai-review findings [ai-review-bot][failure]	2026-07-20 09:36:22 +00:00
JefferyandClaude Opus 4.8	3ef8a30291	fix(結果回報): 審查本輪不直接 exit 1，失敗只由步驟 1 讀結果 commit 訊息回報 node-actions/template: CI / BUILD (pull_request) Successful in 5s Details CI / TEST (Claude) (pull_request) Successful in 29s Details CI / TEST (Antigravity) (pull_request) Successful in 56s Details CI / TEST (Codex) (pull_request) Successful in 2m59s Details Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-20 17:33:20 +08:00
ai-review-bot	be72aa0944	chore: update ai-review findings [ai-review-bot][failure]	2026-07-20 09:32:01 +00:00
JefferyandClaude Opus 4.8	b277ff2f7c	fix(建問題模式): 僅在有嚴重問題時讓 PR 相依於 issue，警告／建議不阻擋合併 node-actions/template: CI / BUILD (pull_request) Successful in 4s Details CI / TEST (Claude) (pull_request) Successful in 27s Details CI / TEST (Antigravity) (pull_request) Successful in 1m2s Details CI / TEST (Codex) (pull_request) Failing after 3m16s Details Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-20 17:28:43 +08:00
ai-review-bot	20a2b57998	chore: update ai-review findings [ai-review-bot][success]	2026-07-20 09:27:31 +00:00
JefferyandClaude Opus 4.8	05178be520	fix(推送觸發 CI): 合併 push-token 進 token，findings 一律以 token 認證推送觸發 CI node-actions/template: CI / BUILD (pull_request) Successful in 5s Details CI / TEST (Claude) (pull_request) Successful in 28s Details CI / TEST (Antigravity) (pull_request) Successful in 57s Details CI / TEST (Codex) (pull_request) Successful in 3m10s Details - 移除 push-token input，token 兼作 Gitea API 認證與 findings 推送 - commitAndPushFindings 一律以 token 明確認證推送（不走 origin 自動 token）；只要 token 為能觸發 CI 的 PAT，結果 commit 即再觸發 PR 的 CI，避免新 head 缺檢查卡合併 - ci.yaml 三個 job 移除 push-token，保留 token: ${{ secrets.TOKEN }} Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-20 17:24:18 +08:00
ai-review-bot	9e6e8bb793	chore: update ai-review findings [ai-review-bot][success]	2026-07-20 09:21:17 +00:00
JefferyandClaude Opus 4.8	321a717f91	chore(ci): Claude 測試 job 改用 claude-opus-4-8 node-actions/template: CI / BUILD (pull_request) Successful in 4s Details CI / TEST (Claude) (pull_request) Successful in 26s Details CI / TEST (Antigravity) (pull_request) Failing after 1m24s Details CI / TEST (Codex) (pull_request) Successful in 3m33s Details Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-20 17:17:42 +08:00
JefferyandClaude Opus 4.8	36bf2d8644	chore(ci): 三個測試 job 指定各工具最省 model 以降低消耗 node-actions/template: CI / BUILD (pull_request) Successful in 4s Details CI / TEST (Claude) (pull_request) Successful in 23s Details CI / TEST (Antigravity) (pull_request) Failing after 2m13s Details CI / TEST (Codex) (pull_request) Successful in 2m49s Details Antigravity→gemini-3.5-flash、Codex→gpt-5.5、Claude→claude-haiku-4-5 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-20 17:15:12 +08:00
ai-review-bot	85235e43a4	chore: update ai-review findings [ai-review-bot][success]	2026-07-20 08:39:40 +00:00
JefferyandClaude Opus 4.8	491c170d36	fix(AI 失敗診斷): 失敗時預設併印遮罩後 stdout（claude-code 錯誤寫在 stdout） node-actions/template: CI / BUILD (pull_request) Successful in 4s Details CI / TEST (Codex) (pull_request) Successful in 2m23s Details CI / TEST (Claude) (pull_request) Successful in 17s Details CI / TEST (Antigravity) (pull_request) Successful in 54s Details Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-20 16:37:15 +08:00
ai-review-bot	afed9a3cce	chore: update ai-review findings [ai-review-bot][failure]	2026-07-20 08:20:40 +00:00
JefferyandClaude Opus 4.8	71b93a885a	fix(AI 失敗診斷): CLI 失敗預設輸出經遮罩的 stderr 片段以利除錯 node-actions/template: CI / BUILD (pull_request) Successful in 4s Details CI / TEST (Claude) (pull_request) Successful in 23s Details CI / TEST (Antigravity) (pull_request) Failing after 40s Details CI / TEST (Codex) (pull_request) Failing after 2m39s Details Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-20 16:17:59 +08:00
JefferyandClaude Opus 4.8	7b5c7c3e4f	chore(ci): 審查 job 的 token 改用 secrets.TOKEN Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-20 16:17:59 +08:00
ai-review-bot	7823718ff4	chore: update ai-review findings [ai-review-bot][failure]	2026-07-20 08:03:45 +00:00
JefferyandClaude Opus 4.8	4c2b6d4265	chore(ai-review 狀態): 記入議題 #8 不採納排除並寫回待人工處理 findings node-actions/template: CI / BUILD (pull_request) Successful in 5s Details CI / TEST (Antigravity) (pull_request) Failing after 35s Details CI / TEST (Codex) (pull_request) Failing after 2m27s Details CI / TEST (Claude) (pull_request) Successful in 16s Details Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-20 16:01:05 +08:00
JefferyandClaude Opus 4.8	dcd3e931f4	docs(readme): 流程圖步驟順序反映舊留言標記延後執行 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-20 16:01:05 +08:00
JefferyandClaude Opus 4.8	0a51affa72	refactor(gitea client): 移除無呼叫端的 addLabelsToIssue Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-20 16:01:05 +08:00
JefferyandClaude Opus 4.8	f341dc6e07	perf(AI 失敗診斷): 除錯輸出先截長度上限再遮罩降低掃描成本 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-20 16:01:05 +08:00
JefferyandClaude Opus 4.8	8349fe8b71	fix(推送結果 commit): 帶認證推送改經 env 傳入並遮蔽 push 失敗錯誤 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-20 16:01:05 +08:00