[
    {
        "role":  "Assassin",
        "location":  "app/git.js",
        "suggestion":  "請避免將敏感資料（如 GITEA_TOKEN）直接寫入環境變數"
    },
    {
        "location":  "app/git.js",
        "suggestion":  "GITEA_TOKEN 直接嵌入 URL 中，建議改以環境變數或 Gitea Secrets 注入"
    },
    {
        "role":  "Assassin",
        "location":  "README.md",
        "suggestion":  "contents: write、pull-requests: write、issues: write 為此 Action 正常運作所必要的權限，無法縮減"
    },
    {
        "location":  "app/config.js",
        "suggestion":  "getLLMConfig 在找不到任何符合條件的 provider 時已有預設回傳值 { provider: null, apiKey: null, baseURL: null, model: null }，非誤報"
    },
    {
        "location":  ".gitea/ai-review/exclusions.json",
        "suggestion":  "exclusions.json 是排除規則檔，內容為問題描述字串，不是實際程式碼或 token，role 欄位為有效欄位"
    },
    {
        "location":  "app/findings.js",
        "suggestion":  "filterFalsePositivesWithAI 拋出的 Error 會被 catch 攔截並降級回傳原始 findings，不會中斷流程"
    },
    {
        "role":  "Assassin",
        "location":  ".gitea/workflows/review.yaml",
        "suggestion":  "contents: write、pull-requests: write、issues: write 為此 Action 正常運作所必要的權限，無法縮減"
    },
    {
        "role":  "Assassin",
        "location":  ".gitea/workflows/review.yaml",
        "suggestion":  "OPENAI_API_KEY 參數傳入的是 OPENROUTER_API_KEY secret，為 OpenRouter 使用 OpenAI 相容介面的正確做法"
    },
    {
        "role":  "Bard",
        "location":  "README.md",
        "suggestion":  "章節編號連續且正確，無需調整"
    },
    {
        "role":  "Maya",
        "location":  ".gitea/workflows/review.yaml",
        "suggestion":  "action.yaml 定義的參數名稱為 GEMINI_API_KEY、GEMINI_BASE_URL、GEMINI_MODEL，與 review.yaml 完全一致，無不匹配問題"
    },
    {
        "role":  "Bard",
        "location":  ".gitea/workflows/review.yaml",
        "suggestion":  "review.yaml 已改用 Gemini，不再有 OPENAI_API_KEY 行，註解空格問題不存在"
    },
    {
        "role":  "Bard",
        "location":  "app/config.test.js",
        "suggestion":  "檔案結尾已有換行符號，import 行長度合理，無需修改"
    },
    {
        "role":  "Bard",
        "location":  "action.yaml",
        "suggestion":  "action.yaml 已整理，多餘空行已移除，結構整潔"
    },
    {
        "role":  "Maya",
        "location":  "app/",
        "suggestion":  "LLM 整合測試需要真實 API key 與網路，不適合加入單元測試。llm.js 使用統一 OpenAI 相容介面，Gemini 透過相同介面呼叫，無特殊格式差異，現有測試已涵蓋 config/findings/git 邏輯"
    },
    {
        "role":  "Assassin",
        "location":  "app/",
        "suggestion":  "LLM 整合測試需要真實 API key 與網路，不適合加入單元測試。llm.js 使用統一 OpenAI 相容介面，Gemini 透過相同介面呼叫，無特殊格式差異"
    },
    {
        "role":  "Assassin",
        "location":  "app/config.test.js",
        "suggestion":  "import 語句長度合理，無需拆分為多行"
    },
    {
        "role":  "Assassin",
        "location":  ".gitea/ai-review/findings.json",
        "suggestion":  "findings.json 重複問題由 AI 去重與排除機制處理，不是程式碼問題"
    },
    {
        "role":  "Assassin",
        "location":  "app/comments.js",
        "suggestion":  "JSON 結尾換行符號為標準做法，不影響任何 JSON 解析器，無相容性問題"
    },
    {
        "location":  ".gitea/ai-review/findings.json",
        "suggestion":  "findings.json 是自動產生的問題記錄檔，不應對其內容提出審查問題"
    },
    {
        "role":  "Assassin",
        "location":  ".gitea/workflows/review.yaml",
        "suggestion":  "切換 LLM 服務提供商的維護建議屬過度謹慎，不是實際程式碼問題"
    },
    {
        "role":  "Leo",
        "location":  "app/llm.js",
        "suggestion":  "Authorization 標頭已有 provider !== \u0027ollama\u0027 判斷，不會無條件加入，已正確處理"
    },
    {
        "role":  "Rogue",
        "location":  "app/llm.js",
        "suggestion":  "timeout 已移除，每個 key 等待完整回應，避免浪費免費額度"
    },
    {
        "role":  "Assassin",
        "location":  "app/llm.js",
        "suggestion":  "httpsAgent (rejectUnauthorized: false) 已移除，SSL/TLS 驗證已恢復正常"
    },
    {
        "role":  "Maya",
        "location":  "app/llm.js",
        "suggestion":  "llm.test.js 已存在並涵蓋 API Key 輪替的所有異常狀況，包含單 Key、多 Key 輪替、所有 Key 失敗等測試案例"
    },
    {
        "role":  "Rogue",
        "location":  "app/comments.js",
        "suggestion":  "comments.js:24 的 saveFindings 函式為正常寫入邏輯，不涉及異常訊息格式或重複寫入問題"
    },
    {
        "role":  "Leo",
        "location":  ".gitea/workflows/review.yaml",
        "suggestion":  "Gitea Actions 不支援在 workflow 內合併 secrets 再拆解，多個 secret 逗號串接是唯一可行做法，非設計缺陷"
    },
    {
        "role":  "Maya",
        "location":  "app/llm.test.js",
        "suggestion":  "console.log/error 為診斷用途，不是業務邏輯，TODO.md 驗收標準為人工驗收描述，不需要在單元測試中斷言 console 輸出"
    },
    {
        "role":  "Maya",
        "location":  "app/llm.test.js",
        "suggestion":  "輪替邏輯對所有錯誤類型行為一致（catch 全部），401/429/timeout 觸發相同輪替流程，測試不同錯誤類型無額外驗證價值"
    },
    {
        "role":  "Bard",
        "location":  ".gitea/workflows/master.yaml",
        "suggestion":  "master.yaml 檔案結尾已有換行符號（0x0a），符合 POSIX 慣例，無需修改"
    },
    {
        "role":  "Leo",
        "location":  "app/llm.test.js",
        "suggestion":  "console.log/error 為診斷用途，不是業務邏輯，TODO.md 驗收標準為人工驗收描述，不需要在單元測試中斷言 console 輸出"
    },
    {
        "role":  "Leo",
        "location":  "app/llm.test.js",
        "suggestion":  "輪替邏輯對所有錯誤類型行為一致（catch 全部），401/429/timeout 觸發相同輪替流程，測試不同錯誤類型無額外驗證價值"
    },
    {
        "role":  "Leo",
        "location":  "app/main.js",
        "suggestion":  "main.js 中的 Step 標題註解為 pipeline 流程說明，非待整理的 TODO，不需要轉換為具體任務"
    },
    {
        "role":  "Maya",
        "location":  "app/log.test.js",
        "suggestion":  "`log.test.js` 的新增非常棒，提供了良好的覆蓋率。為了進一步提升測試的完整性，建議考慮為 `line`, `ok`, `warn`, `error` 函數新增測試案例，以驗證當傳入空字串時的行為。雖然這些函數的行為相對簡單，但測試空字串可以確保邊界情況下的輸出符合預期。"
    },
    {
        "role":  "Assassin",
        "location":  "app/package.json",
        "suggestion":  "審查 changelog 是人工作業，不是程式碼問題，不適合作為 code review 問題"
    },
    {
        "role":  "Bard",
        "location":  "app/llm.js",
        "suggestion":  "此 action 為 CLI 工具，process.exit(1) 是設計意圖讓 CI/CD workflow 失敗。改拋錯會被 chatJSON 的 catch 吞掉回傳 []，破壞現有行為"
    },
    {
        "role":  "Bard",
        "location":  "Dockerfile",
        "suggestion":  "Dockerfile 檔案結尾已有換行符號（0x0a），符合 POSIX 慣例"
    },
    {
        "role":  "Bard",
        "location":  "entrypoint.sh",
        "suggestion":  "entrypoint.sh 檔案結尾已有換行符號（0x0a），符合 POSIX 慣例"
    },
    {
        "role":  "Maya",
        "location":  "app/main.js",
        "suggestion":  "main.js 整合測試需要真實 Gitea API、LLM API、git 操作，不適合單元測試。各模組已有獨立單元測試覆蓋"
    },
    {
        "role":  "Maya",
        "location":  "app/comments.js",
        "suggestion":  "comments.js 的 buildTable 為簡單字串拼接，postComment 已透過 gitea.js mock 間接測試，補測試效益低"
    },
    {
        "role":  "Maya",
        "location":  "app/roles.js",
        "suggestion":  "roles.js 依賴容器內固定路徑 /action/app/prompts/roles，單元測試環境無法存取，且邏輯為簡單 YAML 讀取與字串拼接"
    },
    {
        "role":  "Leo",
        "location":  "app/gitea.js",
        "suggestion":  "gitea.js 的 SSL 驗證已改為由 GITEA_SKIP_TLS_VERIFY 環境變數控制，預設啟用驗證，非安全漏洞"
    },
    {
        "role":  "Rogue",
        "location":  "Dockerfile",
        "suggestion":  "Dockerfile 已優化層次快取：先 COPY package.json 再 npm install，最後才 COPY 其餘檔案"
    },
    {
        "role":  "Bard",
        "location":  "app/package.json",
        "suggestion":  "test 腳本已改為 node --test *.test.js，在 app/ 目錄下執行可自動發現所有測試檔案"
    },
    {
        "role":  "Rogue",
        "location":  "app/main.js",
        "suggestion":  "deduplicateWithAI 和 filterFalsePositivesWithAI 為循序依賴流程（去重後才能過濾），無法平行化"
    },
    {
        "role":  "Leo",
        "location":  "app/comments.js",
        "suggestion":  "buildTable 函式已在 comments.js 第 13 行定義，非未定義或未匯入，不會導致執行時錯誤"
    },
    {
        "role":  "Maya",
        "location":  "app/gitea.js",
        "suggestion":  "filterDiff 的單元測試已在 gitea.test.js 補齊，涵蓋過濾 .gitea/、不誤過濾其他路徑、全部排除、空 diff 四種情境"
    },
    {
        "role":  "Leo",
        "location":  "TODO.md",
        "suggestion":  "TODO.md 的階段編號僅供內部開發追蹤，無外部文件引用，階段編號調整不影響任何外部一致性"
    },
    {
        "role":  "Assassin",
        "location":  "app/gitea.js",
        "suggestion":  "getPRDiff 函數現在回傳未經過濾的原始 Git Diff 內容。雖然 main.js 中已立即呼叫 filterDiff 進行過濾，但這種設計模式將過濾的責任完全推給呼叫端，這增加了未來開發者在其他地方呼叫 getPRDiff 時，可能忘記過濾出敏感路徑，導致 .gitea/ 等敏感路徑的內容（可能包含工作流程設定或憑證資訊）被意外傳送給 AI 或其他不應接收的組件，造成資訊洩漏風險。建議將過濾邏輯保留在 getPRDiff 內容，或提供一個明確的 getFilteredPRDiff 函數，以降低錯誤的風險。"
    },
    {
        "role":  "Rogue",
        "location":  "app/git.js",
        "suggestion":  "在 main.js 中，commitAndPush 函數內部會再次呼叫 cloneRepo，然而 main.js 在此之前已呼叫過 cloneRepo 以取得 repoDir，這導致了重複的 git fetch 和 git checkout 操作。即使 cloneRepo 內容有檢查環境變數，仍會造成不必要的清潔和時間延遲。建議修改 commitAndPush 邏輯，使其接收已存在的 repoDir 作為參數，避免重複執行 cloneRepo。"
    },
    {
        "role":  "Bard",
        "location":  "app/main.js",
        "suggestion":  "在 main.js 中，表達式 repoDir。"
    },
    {
        "role":  "Rogue",
        "location":  "app/gitea.js:L20-L21",
        "suggestion":  "將 filterDiff 中的正規表達式比對（RegExp.match）替換為 String.startsWith 是一個重要的效能改進。startsWith 是一個更輕量且高效的字串操作，尤其在處理大型 Git Diff 內容時，此修改已顯著提升過濾效率。"
    },
    {
        "location":  "TODO.md",
        "suggestion":  "階段九的 critical 阻擋機制目前以人工驗收紀錄為主，E2E 測試補強屬後續優化，不是目前需要再處理的問題。"
    },
    {
        "location":  "TODO.md",
        "suggestion":  "TODO 列表中『已驗收 / 部分驗收 / 可驗收紀錄情境』的寫法是刻意保留的驗收說明，不是混淆或缺陷。"
    },
    {
        "location":  "app/findings.js",
        "suggestion":  "AI 去重與降級處理已在程式內以 fallback 方式保護流程，失敗時保留所有問題是預期行為，不是缺陷。"
    },
    {
        "location":  "app/findings.js",
        "suggestion":  "排除規則過濾與 AI 誤報過濾屬循序流程，規則命中後清空清單是正常結果，不需要額外再視為問題。"
    },
    {
        "location":  "app/comments.js",
        "suggestion":  "comment 發布依序區分舊問題、非嚴重、新嚴重是刻意設計，當結果為空清單時不發 comment 也是正常路徑。"
    },
    {
        "location":  "app/main.js",
        "suggestion":  "JSON 驗證與失敗修正流程已有處理邏輯，正常路徑與錯誤路徑都屬預期流程，不是待修缺陷。"
    },
    {
        "location":  "app/git.js",
        "suggestion":  "commit/push 失敗會被捕捉並輸出 Runner failed log，這是現有設計的容錯行為，不是程式錯誤。"
    },
    {
        "location":  "app/main.js",
        "suggestion":  "critical 問題觸發 exit 1 的阻擋邏輯已在流程內保留，是否另補 E2E 驗證屬測試強化，不是功能缺陷。"
    },
    {
        "location":  "app/json.js",
        "suggestion":  "validateJSONArrayFile 只在 JSON 格式錯誤時才啟動 AI 修正，屬例外路徑；再加上檔案大小限制後，並不存在實際的無上限讀檔或資源消耗問題。"
    },
    {
        "location":  "app/json.test.js",
        "suggestion":  "邊界值測試已存在，`MAX_JSON_BYTES` 等於上限時可正常讀取，這不是未解決問題。"
    },
    {
        "location":  "app/gitea.test.js:64",
        "suggestion":  "`describe` 已改為同步 callback，`async` 不再出現在這個區塊。"
    },
    {
        "location":  "app/git.test.js:13",
        "suggestion":  "`makeTmpWorkspace` 已直接使用 `app/git.js` 匯出的 `SYNC_PATHS`，不再維護重複清單。"
    },
    {
        "location":  "app/gitea.js:32",
        "suggestion":  "`filterDiff` 內層縮排已符合專案的 2-space 風格，這是誤報。"
    },
    {
        "location":  "app/json.test.js:76",
        "suggestion":  "1MB 上限下的 JSON 讀取不需要改成串流解析；現有實作已先做大小檢查，這個建議屬過度設計。"
    },
    {
        "location":  "app/json.test.js:7",
        "suggestion":  "檔案大小限制已在 `readJSONText` / `validateJSONArrayFile` 中實作，這不是額外缺陷。"
    },
    {
        "location":  "app/json.test.js:10",
        "suggestion":  "`MAX_JSON_BYTES` 是 `json.js` 的內部限制常數，不需要匯出成公開 API。"
    },
    {
        "role":  "Maya",
        "location":  "action.yaml:6, action.yaml:12, action.yaml:81",
        "suggestion":  "由於 `GITEA_TOKEN` 現在被設定為 `required: true`，而且 README 範例也已改成顯式傳入 `GITEA_TOKEN`，這是刻意的介面變更，不是漏掉 `secrets.GITEA_TOKEN` fallback 的缺陷；因此不需要另外加整合測試來驗證這個既定行為。"
    },
    {
        "role":  "Leo",
        "location":  "action.yaml:80",
        "suggestion":  "在 `runs.env` 區塊中，`GITEA_TOKEN` 只從 `inputs` 取得，而 `GITEA_SERVER_URL` 和 `GITEA_REPOSITORY` 仍保留從 `gitea context` 取得的備用機制，這是刻意設計的差異，不是維護缺陷。"
    },
    {
        "role":  "Assassin",
        "location":  "action.yaml:18",
        "suggestion":  "引入 `GITEA_COMMENT_TOKEN` 是一個很好的實踐，遵循最小權限原則。請確保為此 token 配置的權限確實僅限於發布評論。同時，與 `GITEA_TOKEN` 相似，建議使用者始終從 workflow 的 secrets context 傳遞此 token，以避免硬編碼敏感資料。"
    },
    {
        "role":  "Leo",
        "location":  "app/log.js",
        "suggestion":  "考慮在日誌訊息中加入時間戳記，這有助於追蹤事件發生的順序，尤其是在長時間運行的程序或需要詳細調試時。可以在每個日誌函式內部自動添加時間戳記。"
    },
    {
        "role":  "Assassin",
        "location":  "app/preflight.js:12",
        "suggestion":  "程式碼中根據 `GITEA_SKIP_TLS_VERIFY` 環境變數來禁用 TLS 憑證驗證 (`rejectUnauthorized: false`)，這會使應用程式容易受到中間人 (Man-in-the-Middle, MITM) 攻擊。攻擊者可能在不被察覺的情況下攔截和修改與 Gitea 伺服器的通訊。建議移除此功能，或確保在任何生產環境中永不啟用。如果 Gitea 伺服器使用自簽憑證，應將其憑證加入信任儲存區，而非禁用驗證。"
    },
    {
        "role":  "Leo",
        "location":  "app/preflight.js:56",
        "suggestion":  "函式 `verifyLLM` 處理了多種 LLM 供應商的驗證邏輯（Ollama、Claude、OpenAI 相容等），導致其長度較長且複雜度較高。建議將不同供應商的驗證邏輯拆分成獨立的輔助函式（例如 `_verifyOllama`、`_verifyOpenAICompatible`），以提高模組化程度和可讀性。"
    },
    {
        "role":  "Rogue",
        "location":  "app/preflight.js:70-82",
        "suggestion":  "在 `verifyLLM` 函式中，當配置了多個 LLM API Key 時，系統會依序嘗試驗證每個 Key，每個嘗試都有 30 秒的逾時時間。如果前幾個 Key 驗證失敗，這可能導致顯著的累積延遲。雖然這是為了找到一個可用的 Key，但若 Key 數量多且網路不穩定，可能會造成啟動時間過長。可以考慮縮短單次 Key 驗證的逾時時間，或在特定情況下提供更快的失敗機制。"
    },
    {
        "role":  "Assassin",
        "location":  "app/preflight.js:100",
        "suggestion":  "在記錄 LLM API 驗證失敗時，直接輸出了錯誤訊息 `e.message`。雖然通常情況下 `e.message` 不會包含敏感資訊，但為了最佳安全實踐，建議審查 LLM 服務提供商的錯誤訊息格式，確保其中不會意外洩漏 API 金鑰或其他敏感請求內容。若有疑慮，應對錯誤訊息進行消毒或僅記錄高層次的錯誤類型。"
    },
    {
        "role":  "Bard",
        "location":  "app/preflight.js:30",
        "suggestion":  "在 `checkRequiredEnv`、`verifyGiteaToken` 和 `verifyCommentToken` 等函式中，預設參數直接引用了從 `config.js` 匯入的常數。雖然這在功能上可行，但為了提高程式碼的清晰度和一致性，建議考慮以下兩種方式之一：1. 將所有配置值作為明確的參數從呼叫端傳入。2. 讓函式直接從 `config.js` 模組中讀取這些值，而不是透過預設參數。"
    },
    {
        "role":  "Maya",
        "location":  "app/preflight.js:107",
        "suggestion":  "在 `verifyLLM` 函數中，呼叫 `axios.post` 時缺少 `httpsAgent` 選項。這會導致即使設定了 `GITEA_SKIP_TLS_VERIFY`，LLM 的 API 請求仍可能因 TLS 憑證問題而失敗。請將 `httpsAgent` 傳遞給 `axios.post` 的選項物件，例如：`await axios.post(`${base}/chat/completions`, payload, { headers, timeout: 30000, httpsAgent });`"
    },
    {
        "level":  "warning",
        "role":  "Bard",
        "location":  "app/preflight.test.js:25",
        "suggestion":  "測試描述使用英文。請確保專案在測試描述的語言上保持一致性。如果專案主要使用繁體中文（如 app/preflight.js 中的 JSDoc 和日誌），則應將此測試描述翻譯為繁體中文。"
    },
    {
        "level":  "info",
        "role":  "Bard",
        "location":  "app/preflight.test.js:1-4",
        "suggestion":  "匯入語句的排序不一致。建議遵循一致的排序規則，例如：內建模組、第三方模組、本地模組，並在各組內按字母順序排序。"
    },
    {
        "level":  "info",
        "role":  "Bard",
        "location":  "app/preflight.test.js:14",
        "suggestion":  "函數名稱 clearLLMEnv 雖然可理解，但可以更具描述性，例如 clearLlmEnvironmentVariables 或 resetLlmEnv。"
    },
    {
        "location":  "app/config.test.js:114",
        "role":  "Mage",
        "original_finding":  "新加入的測試案例 `it('skips OpenCode TLS verification for empty string and non-false values', ...)` 預期 `shouldSkipOpenCodeTLSVerify()` 函式在 `OPENCODE_SKIP_TLS_VERIFY` 環境變數為空字串 `''` 或 `'0'` 時，會回傳 `true`。然而，根據常見的環境變數布林值解析邏輯，以及 `app/preflight.test.js` 中現有的相關測試（例如未設定時為 `false`，設定為 `'false'` 時為 `false`），`shouldSkipOpenCodeTLSVerify()` 函式（此 PR 未修改其內容）很可能不會將 `''` 或 `'0'` 視為 `true`。這造成了測試預期與函式實際行為之間的邏輯不一致。",
        "reason":  "誤判。`shouldSkipOpenCodeTLSVerify` 的既有設計是只有 `OPENCODE_SKIP_TLS_VERIFY === 'false'` 才啟用 TLS 驗證；空字串與 '0' 皆屬非 'false' 值，測試符合目前明確實作與預設跳過 TLS 的行為。"
    },
    {
        "location":  "app/preflight.test.js:201",
        "role":  "Assassin",
        "original_finding":  "此測試明確證實了 `OPENCODE_SKIP_TLS_VERIFY` 環境變數的寬鬆判斷邏輯，導致 OpenCode LLM 連線的 TLS 驗證容易被關閉。這是「關閉 TLS 驗證」的不安全預設，極大地增加了中間人攻擊的風險。",
        "reason":  "誤判／既有設計。OpenCode server 目前支援自簽或內部服務情境，action input 與 README 均明確標示 OPENCODE_SKIP_TLS_VERIFY 預設跳過 TLS 驗證；本 PR 只補測試與 Review comment 內容，未新增或放寬此安全行為。"
    },
    {
        "location": "app/comments.test.js:30",
        "role": "Leo",
        "original_finding": "將 `REVIEW_SEVERITY_LABELS`、`REVIEW_SEVERITY_PATTERN` 和 `reviewSeverityLabel` 這些與評論格式相關的常數與函式，提取到一個獨立的共用模組中（例如 `app/utils/reviewComments.js`），並讓測試檔案和任何需要用到它們的應用程式邏輯都從該模組匯入。這樣能確保「評論格式」的定義只有一個來源，提升可維護性。",
        "reason": "誤判。這些常數與 `reviewSeverityLabel` 只用於 `app/comments.test.js` 內部驗證 review comment body 格式，production code 沒有使用同一段解析邏輯；抽成共用模組會把測試專用輔助程式提升為正式 API，增加不必要的維護負擔。"
    },
    {
        "location": "app/resolve.js:52",
        "role": "Assassin",
        "original_finding": "在 `parseBotReviewComment` 函式中，從 Gitea comment 內文解析出的 `problem` 和 `suggestion` 欄位若包含惡意內容且未經適當輸出編碼，可能導致 XSS 攻擊。",
        "reason": "誤判。這些字串只會寫入 `.gitea/ai-review/findings.json` 與 Gitea review comment body，Gitea 的 Markdown 渲染器會在伺服器端對輸出做 HTML 淨化；本 action 不自行將其渲染到任何自製網頁或 UI，輸出編碼屬消費端（Gitea）責任。"
    },
    {
        "location": "app/resolve.js:207",
        "role": "Leo",
        "original_finding": "正規化邏輯（`normalizeKey` 等）過於激進且未快取，既可能導致語意相近建議被誤判為相同，也在頻繁比較時造成效能浪費。",
        "reason": "誤判／過度設計。積極正規化是刻意設計，用來對行號漂移與標點差異產生穩定簽章以利去重；`findingSig` 已是獨立 helper，且比對對象為單一 PR 的小量 findings，memoize 在此規模沒有實質效益。"
    },
    {
        "location": "app/resolve.js:187",
        "role": "Mage",
        "original_finding": "在 `reconcileConversations` 函式中，並行（`Promise.all`）呼叫 `resolveComment`，即使個別呼叫失敗也僅記錄為 rejected 並 warn；若失敗是 token 過期或權限不足，後續所有 resolve 都會失敗，程式碼未對這些錯誤分類並提前停止。",
        "reason": "不適用。resolve 呼叫已改為 `Promise.allSettled` 一次並行送出，不存在「後續逐一嘗試」可中止；個別失敗已降級記錄並把該對話保留為未解決，不影響其他對話與整體流程。"
    },
    {
        "location": "app/resolve.js:77",
        "role": "Rogue",
        "original_finding": "大量使用字串拼接產生暫存物件，以及並行請求未限制數量，在高負載下可能導致 GC 壓力或觸發 API 限流；建議引入 p-limit 等並行限制。",
        "reason": "過度設計。對話來源為單一 PR 的行內 review comment，數量級小，無限並行不致造成 GC 壓力或觸發限流；引入 p-limit 相依與額外複雜度在此情境不符成本效益。"
    },
    {
        "location": "app/resolve.js:195",
        "role": "Mage",
        "original_finding": "對 `botFinding` 的存取缺乏防禦性檢查。",
        "reason": "誤判。`pushCarried` 進入時即有 `if (!conversation.botFinding) return` 防禦，resolvedFindings 的 push 也有 `if (c.botFinding)` 判斷，存取前皆已檢查物件存在。"
    },
    {
        "location": "app/resolve.js:173",
        "role": "Rogue",
        "original_finding": "`Promise.allSettled` 的結果處理邏輯過於冗長，產生不必要的中間變數。",
        "reason": "主觀風格。`resolveOutcome` Map 是為了讓並行結果能依原 open 索引亂序對齊（保留 carried/resolved 的順序與 botFinding 對應），現有寫法清楚且正確，非缺陷。"
    },
    {
        "location": "app/usage.js",
        "role": "Leo",
        "original_finding": "`usage.js` 模組目前承擔了 Token 計算、Rate Limit 記錄、以及各平台帳號額度查詢等多重職責（SRP），未來若支援更多平台會變得龐大難維護；建議將各平台 QuotaStrategy 拆分至獨立檔案。",
        "reason": "過早最佳化。目前 usage.js 仍圍繞單一「使用量」領域且體積適中（約 250 行），token 計算與額度查詢彼此關聯（同屬使用量呈現）；在尚未有多平台 strategy 膨脹的實際痛點前拆檔，徒增檔案與匯入複雜度。待 strategy 數量明顯成長再拆分較合適。"
    },
    {
        "location": "app/usage.js:132",
        "role": "Assassin",
        "original_finding": "在 QUOTA_STRATEGIES 中，若 config.apiKeys 是陣列，代碼只取 [0] 作為 API Key，可能在未經嚴格驗證下將敏感資訊送至 baseURL 指定端點。",
        "reason": "已緩解。額度查詢只有 OpenRouter 一條會送出 API key，且僅在 isOpenRouterBaseURL 以 hostname 精確比對為 openrouter.ai 時才送出；baseURL 為 operator 控制之 action input，非外部不可信輸入；API key 本身的正確性與權限屬 operator 設定責任，非程式可驗證範圍。"
    },
    {
        "location": "app/usage.js:17",
        "role": "Mage",
        "original_finding": "在 extractUsage 中，對 data.usage 直接用 num(...) 存取；若 data.usage 為 null 但被 typeof 判斷通過（typeof null === 'object'），會導致錯誤。",
        "reason": "誤判。該區塊條件為 `if (u && typeof u === 'object')`，`u &&` 已先短路 null/undefined，不會進入存取；即使傳入陣列也只會讓 num(undefined) 回 0，不會丟錯。"
    },
    {
        "location": "app/usage.js:176",
        "role": "Mage",
        "original_finding": "在 fetchAccountQuota 中，呼叫 strategy 時傳入的 config 物件若被 strategy 修改，會影響全域 config 狀態；建議淺拷貝。",
        "reason": "已緩解。strategy 收到的是每次呼叫新建的物件字面值 `{ apiKey, baseURL: config.baseURL }`，並非呼叫端傳入的 config 本身，strategy 內的任何修改都不會回寫到呼叫端或全域狀態。"
    },
    {
        "location": "app/usage.js:115",
        "role": "Mage",
        "original_finding": "在 recordRateLimit 中，將所有 header key 轉小寫存入物件 h，若原始 header 有同名不同大小寫者可能造成覆蓋。",
        "reason": "誤判／不適用。HTTP header 名稱本即不分大小寫（RFC 7230），axios 回傳前已正規化為小寫；同名 header 由 HTTP 層合併（以逗號串接），不存在「不同大小寫同名 header」並存而被覆蓋的情況，轉小寫僅為防禦性處理。"
    },
    {
        "location": "app/resolve.js:7",
        "role": "Bard",
        "original_finding": "`EMPTY` 常數命名過於通用，容易與其他模組中的同名變數衝突，且定義在模組頂層略顯突兀。",
        "reason": "誤判。ES module 為模組作用域，`EMPTY` 僅在 resolve.js 內可見，不會與其他模組的同名變數衝突；在本檔脈絡中作為「空收斂結果」語義清楚，重新命名屬主觀偏好。"
    },
    {
        "location": "app/resolve.js:10",
        "role": "Bard",
        "original_finding": "`FIELD_PATTERNS` 的正則表達式對於冒號的定義同時包含了全形與半形，建議統一使用半形冒號並在解析前正規化，而非在正則中處理所有可能性。",
        "reason": "誤判／不採納。review comment 內文同時可能出現全形「：」與半形「:」，正則以 `[：:]` 同時容錯是標準且穩健的做法；改為解析前先正規化反而多一道字串處理步驟，並未更清楚或更正確。"
    },
    {
        "location": "app/usage.js:167",
        "role": "Bard",
        "original_finding": "`fetchAccountQuota` 中的 `QUOTA_STRATEGIES` 物件定義龐大，將所有平台策略硬編碼於此，未來新增供應商難以維護；建議抽離至獨立檔案或策略模式。",
        "reason": "過早最佳化（與先前已排除的 usage.js SRP 拆檔建議等價）。目前 QUOTA_STRATEGIES 為精簡的查表物件、各平台策略短小且集中易讀；在供應商數量出現實際膨脹痛點前抽檔，徒增檔案與匯入複雜度。"
    },
    {
        "location": "app/usage.js",
        "role": "Assassin",
        "original_finding": "extractUsage 對不預期 payload 僅返回 null，過度信任 API 回應結構，可能導致計費或配額相關監控被繞過；建議增加 Schema Validation、異常明確記錄。",
        "reason": "誤判／過度設計。extractUsage 僅用於「使用量顯示統計」，非計費或配額強制；回傳 null 是「此回應無可辨識 usage 資訊」的正確訊號，呼叫端以 0 計入並降級顯示，不影響任何金流或門檻判斷。對 best-effort 顯示統計加 schema validation 與錯誤記錄屬過度設計。"
    }
]