feat(ai-review 對話收斂): 讀 PR review 留言判斷解決狀態並收斂 findings #45
@@ -35,7 +35,7 @@
|
||||
11. action 一啟動就先做「前置驗證」(流程第 2 點):集中檢查 Gitea REST API token、comment token、git push 認證與 LLM 的所有驗證相關設定是否可用,全部通過才往下跑。驗證邏輯獨立成 `app/preflight.js`(git push 驗證委派給 `app/git.js` 的 `verifyRemoteAccess`),由 `main.js` 在 Step1 之後、其餘步驟之前呼叫;任何一項失敗都印出是哪一項、原因為何後 `exit 1`,避免在分析到一半、發 comment 或最後 push 時才因 token / key / 認證無效而中斷
|
||||
12. PR 對話收斂(流程第 2.5 點)邏輯獨立成 `app/resolve.js`,由 `main.js` 在前置驗證與自動提交檢查之後以 `Step2` 呼叫:
|
||||
- 透過 `app/gitea.js` 的 `listAllReviewComments` 取得所有行內 review comment,`groupConversations` 以「path+line」收斂並偵測 `resolver`(已解決);`reconcileConversations` 取 PR head 最新檔案內容(`getFileContentAtRef`,contents API base64 解碼)取目標行附近視窗,交 `judgeConversations` 由 AI 批次判為 `resolved` / `false_positive` / `open`
|
||||
- `reconcileConversations` 對所有未解決對話一律呼叫 `resolvePullReviewComment`(`POST /pulls/comments/{id}/resolve`)關閉,再依 AI 判斷把對應 finding 分流:`resolved`→`resolvedFindings`(供移除)、`false_positive`→`excludedFindings`(供寫入 exclusions 並移除)、`open`→`carriedFindings`(加回舊問題)
|
||||
- `reconcileConversations` 先把**每一個未解決的 comment**(有 id 且無 `resolver`,依 comment id 去重;不依賴 `path|line` 分組,故含無 path/position 變 null 者)一律呼叫 `resolvePullReviewComment`(`POST /pulls/comments/{id}/resolve`)關閉,確保每個獨立 thread 都關到;再依 AI 判斷把對應 finding 分流:`resolved`→`resolvedFindings`(供移除)、`false_positive`→`excludedFindings`(供寫入 exclusions 並移除)、`open`→`carriedFindings`(加回舊問題)
|
||||
- 與既有 findings 流程的銜接:`main.js` 在 Step4 以 `dropResolvedFindings` 移除(已修復+誤報)、`addCarriedFindings` 加回仍成立者(以「檔案路徑+正規化建議內容」為簽章比對,對行號漂移與標點差異穩定);Step5 以 `findings.js` 的 `appendExclusions` 把誤報寫入 `exclusions.json`(workspace 與 cloned repo 各一份,供本次過濾與後續 commit)
|
||||
- 為降低 token 用量只送目標行附近視窗;任一外部呼叫失敗都降級為「視為 open」並繼續流程
|
||||
13. AI 助理使用量統計獨立成 `app/usage.js`,於 `Step6` 發布 Review 前蒐集,同時寫入 action log 與 Review 本文,核心是呈現「剩餘可用百分比」:
|
||||
|
||||
Reference in New Issue
Block a user