test(ai-review): 補使用量統計 NaN 安全測試並排除微優化誤報 #46
@@ -1,552 +1,8 @@
|
||||
[
|
||||
{
|
||||
"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 與錯誤記錄屬過度設計。"
|
||||
},
|
||||
{
|
||||
"location": "app/comments.test.js:250",
|
||||
"role": "Maya",
|
||||
"original_finding": "新增的 postFindingsReview 使用統計功能，但在測試中完全未驗證輸出內容；應斷言 body 含 usageSection 與統計數據。",
|
||||
"reason": "誤判，測試已存在。`app/comments.test.js` 的 'appends usageSection verbatim after the stats block' 斷言 body.endsWith(usageSection) 與結構，'counts both new and old findings in the summary' 斷言四欄新舊統計列；body 內容已被多個案例驗證。"
|
||||
},
|
||||
{
|
||||
"location": "app/findings.test.js:154",
|
||||
"role": "Maya",
|
||||
"original_finding": "filterFalsePositivesWithAI 測試不足，缺乏對內部函數 judgeFindingIsFalsePositive 的獨立單元測試。",
|
||||
"reason": "誤判／不適用。judgeFindingIsFalsePositive 是 findings.js 的私有函式（未匯出），其 verdict 處理（false_positive／confirmed／異常值／拋錯）已透過公開呼叫端 filterFalsePositivesWithAI 的多個案例完整覆蓋；為測試實作細節而匯出私有函式不符測試原則。"
|
||||
},
|
||||
{
|
||||
"location": "app/findings.test.js:145",
|
||||
"role": "Maya",
|
||||
"original_finding": "filterFalsePositivesWithAI 未測試平行裁決部分成功、部分失敗時的結果一致性（失敗者保守保留）。",
|
||||
"reason": "誤判，測試已存在。'keeps failed and confirmed, drops only confirmed false positives (mixed parallel)' 正是模擬一個拋錯、一個誤報、一個成立，驗證只剔除確認誤報、保留失敗與成立者。"
|
||||
},
|
||||
{
|
||||
"location": "app/findings.test.js:189",
|
||||
"role": "Maya",
|
||||
"original_finding": "未測試 resolveMissingLineNumbers 當 chatFn 回傳無效行號時的處理（fallback）。",
|
||||
"reason": "誤判，測試已存在。'resolveMissingLineNumbers keeps the filename after exhausting retries' 以 chatFn 持續回 {line:0}（無效行號）驗證進入 fallback、保留檔名；另有 'swallows chatFn exceptions' 覆蓋拋錯情境。"
|
||||
},
|
||||
{
|
||||
"location": "app/resolve.test.js:21",
|
||||
"role": "Maya",
|
||||
"original_finding": "parseBotReviewComment 的測試沒有驗證解析失敗時回傳 null 的行為。",
|
||||
"reason": "誤判，測試已存在。'returns null for free-form human comments' 已斷言自由格式留言、空字串、null 皆回傳 null。"
|
||||
},
|
||||
{
|
||||
"location": "app/usage.js:146",
|
||||
"role": "Rogue",
|
||||
"original_finding": "在 recordRateLimit 中頻繁呼叫 lowerCaseKeys，對每個請求的 headers 複製與轉換，增加記憶體分配開銷；建議改用不分大小寫存取避免複製。",
|
||||
"reason": "過度設計／非熱路徑。recordRateLimit 每次 LLM 回應只呼叫一次（一輪審查約 13 次），headers 物件小，複製成本可忽略；改用不分大小寫存取器反而增加複雜度，效益不成比例。"
|
||||
},
|
||||
{
|
||||
"location": "app/usage.test.js:250",
|
||||
"role": "Leo",
|
||||
"original_finding": "測試案例直接引用 describe 外層定義的 `usage` 變數，若被其他測試修改會造成測試間隱性耦合；建議改用區域變數或工廠函式生成測試資料。",
|
||||
"reason": "誤判。該 `const usage` 為不可變的測試夾具，所有測試只讀不寫、未曾被任何案例 mutate，不存在跨測試耦合；新增的邊界測試已各自使用區域 usage 物件。為一個唯讀 fixture 改工廠函式屬過度設計。"
|
||||
},
|
||||
{
|
||||
"location": "app/usage.test.js:254",
|
||||
"role": "Mage",
|
||||
"original_finding": "測試情境雖處理了 NaN，但未涵蓋 limit 為 0 或負數等極端數值，可能輸出 Infinity 或負百分比。",
|
||||
"reason": "誤判，測試已存在。`returns null percent for non-finite or non-positive quota limits` 與 `does not output Infinity/NaN/negative percent for invalid quota numbers` 已涵蓋 limit 為 0／負數／Infinity／NaN／undefined，皆驗證輸出「無法計算」、不含 NaN/Infinity/負百分比。"
|
||||
},
|
||||
{
|
||||
"location": "app/usage.test.js:200",
|
||||
"role": "Bard",
|
||||
"original_finding": "邊界測試迴圈 [0, -5, Infinity, NaN, undefined] 混用不同型別，建議拆成多個測試以提升可讀性。",
|
||||
"reason": "主觀風格／不採納。該迴圈已對每個值帶入 assert 訊息（如 `quota.limit=${limit} 應算不出百分比`），測試失敗時可直接定位是哪個輸入；用單一資料驅動迴圈反而精簡、不易遺漏案例。"
|
||||
},
|
||||
{
|
||||
"location": "app/usage.js:216",
|
||||
"role": "Maya",
|
||||
"original_finding": "isFinitePositive 沒有對 null/undefined 做顯式檢查，未來可能被錯誤複用。",
|
||||
"reason": "誤判。`isFinitePositive` 對 null（Number(null)=0 → 0>0 為 false）與 undefined（Number(undefined)=NaN → Number.isFinite 為 false）皆正確回傳 false，本就涵蓋這些輸入；函式名已表明只接受有限正數，無須再加冗餘檢查。"
|
||||
"original_finding": "建議將測試案例拆分，例如分開測試「非數字類型」、「負數」與「邊界值（Infinity/NaN）」，這樣在測試失敗時能更快速釐清是哪種輸入類型導致的問題。",
|
||||
"reason": "AI 對話收斂判定為誤報（問題在最新程式碼中不成立或不適用）"
|
||||
}
|
||||
]
|
||||
|
||||
@@ -1 +1,39 @@
|
||||
[]
|
||||
[
|
||||
{
|
||||
"level": "critical",
|
||||
"role": "Mage",
|
||||
"location": "app/usage.js:231",
|
||||
"problem": "在計算 `remaining` 時，`remaining = Number(rate.remaining);` 之後直接檢查 `Number.isFinite(remaining)`，但若 `rate.remaining` 是 `undefined` 或 `null`，`Number()` 會轉為 `0`。這意味著如果 `rate.remaining` 缺失，會被錯誤地視為「剩餘 0」而不是「無效值」，進而導致計算出 `0%` 的錯誤結果，而非預期的落到 `{ percent: null }`。",
|
||||
"suggestion": "應先檢查 `rate.remaining` 是否為 null/undefined，或者使用更嚴格的轉換方式，確保只有在確實是有限數字時才進行後續運算。",
|
||||
"is_new": true
|
||||
},
|
||||
{
|
||||
"level": "warning",
|
||||
"role": "Assassin",
|
||||
"location": "app/usage.js:215",
|
||||
"problem": "在 `isFinitePositive` 函數中，使用 `Number(n)` 進行強制轉型。若 `n` 為物件（例如 `{}` 或 `[]`），`Number()` 的行為在某些邊緣情況下可能會產生非預期的數字，雖然當前邏輯有做 `Number.isFinite` 檢查，但對於這種隱式轉型仍需保持警惕，且函數名稱 `isFinitePositive` 雖然清楚，但在這個上下文中，函式內部使用了 `Number(n)` 強制轉型，這在 JavaScript 中可能會隱蔽掉原本資料型態的不一致。",
|
||||
"suggestion": "建議在 `isFinitePositive` 內部補上對 `null` 或 `undefined` 的顯式檢查，並直接在外部嚴格限制輸入類型或使用更明確的檢查（例如 `typeof n === 'number'`）取代隱式轉型，避免隱式轉型帶來的不可控副作用。"
|
||||
},
|
||||
{
|
||||
"level": "warning",
|
||||
"role": "Leo",
|
||||
"location": "app/usage.js:222",
|
||||
"problem": "resolveRemainingPercent 函式同時處理了 quota 和 rate 的邏輯，導致檢查 limit 和 remaining 的計算與驗證邏輯在兩處重複，未來若要調整百分比算法，必須兩處同步修改，增加維護負擔。",
|
||||
"suggestion": "建議將百分比計算邏輯抽象為獨立的輔助函式（如 calculatePercent(remaining, limit)），讓 resolveRemainingPercent 僅負責選擇計算基準，降低重複性並提升封裝度。",
|
||||
"is_new": true
|
||||
},
|
||||
{
|
||||
"level": "warning",
|
||||
"role": "Rogue",
|
||||
"location": "app/usage.js:213",
|
||||
"problem": "在函式內部重複呼叫 `Number(n)`，造成不必要的型別轉換開銷，且在條件式之後又呼叫一次 `Number(quota.limit)`，造成重複轉換。",
|
||||
"suggestion": "建議將 `Number(n)` 的結果暫存起來，或在進入條件式後立即將值賦值給一個變數並重複使用，減少重複轉換的成本。"
|
||||
},
|
||||
{
|
||||
"level": "info",
|
||||
"role": "Bard",
|
||||
"location": "app/usage.js:225",
|
||||
"problem": "註解中提到「落到 { percent: null, reason }」，但程式碼實際邏輯是在 if 判斷式內直接 return，且 `resolveRemainingPercent` 函式中檢查分散在兩個 if 區塊，產生了重複的邏輯結構。",
|
||||
"suggestion": "建議將註解簡化為：「上限或剩餘為無效值時跳過計算」，並將計算百分比的邏輯抽離成一個獨立的輔助函式，統一處理 `isFinite` 的檢查與百分比運算。"
|
||||
}
|
||||
]
|
||||
|
||||
Reference in New Issue
Block a user