Merge pull request 'docs: align README and TODO with current flow' (#123) from feat/優化AI排除問題與過濾 into develop

Reviewed-on: #123

README.md

@@ -2,15 +2,15 @@
 
 這是一個 AI Code Review Action。Gitea Workflow 可以使用此 Action 讓 AI 助理根據不同面向分析 Pull Request 中變更的內容後，將問題分級 Comment 到 Pull Request 中。
 
-# 流程(新 Push Request、新 Commit 觸發；若偵測到 AI 助理的自動提交則直接跳過)
+# 流程(Pull Request opened / synchronize 觸發；若偵測到 AI 助理的自動提交則直接跳過)
 
-1. 服務名稱、模型名稱、角色資訊(個性、符合個性的英文名稱、工作內容)，Comment 到 Push Request
+1. 服務名稱、模型名稱、角色資訊(個性、符合個性的英文名稱、工作內容)，Comment 到 Pull Request
 2. 每個角色個別分析 Git Diff 的內容產生新問題表格(問題等級、角色名稱、問題位置或行數、修改建議)
-3. 讀取來源分支中的所有未解決舊問題(問題檔案 `.gitea/ai-review/findings.json`)加上新問題後，去除重複產生本次 Push Request 的問題表格(PR問題表格)覆蓋問題檔案
-4. 讀取來源分支中的排除問題檔案(`.gitea/ai-review/exclusions.json`)，用來過濾PR問題表格中不需要處理的問題
-5. 從PR問題表格中取出所有舊問題，依照等級排序後 Comment 到 Push Request
-6. 從PR問題表格中取出所有新問題，排除嚴重等級的問題後 Comment 到 Push Request
-7. 從PR問題表格中取出所有新問題，將每個嚴重等級的問題 Comment 到 Push Request
+3. 讀取來源分支中的所有未解決舊問題(問題檔案 `.gitea/ai-review/findings.json`)加上新問題後，去除重複產生本次 PR 的問題表格(PR問題表格)覆蓋問題檔案
+4. 讀取來源分支中的排除問題檔案(`.gitea/ai-review/exclusions.json`)，用來過濾 PR 問題表格中不需要處理的問題
+5. 從 PR 問題表格中取出所有舊問題，依照等級排序後 Comment 到 Pull Request
+6. 從 PR 問題表格中取出所有新問題，排除嚴重等級的問題後 Comment 到 Pull Request
+7. 從 PR 問題表格中取出所有新問題，將每個嚴重等級的問題 Comment 到 Pull Request
 8. Commit 問題檔案，將 workspace 中實際存在的同步檔覆蓋到記憶區；workspace 沒有的同步檔就略過，不會刪除記憶區既有內容。自動提交的 commit message 會帶上 `[ai-review-bot]`，供 workflow 判斷是否要跳過重跑
 9. 如果 PR 問題表格中有嚴重問題，則不要讓 workflow 執行成功(exit 1)
 

TODO.md

@@ -12,8 +12,8 @@
 
 ## 階段三：Findings 產生與合併
 - 目標：各角色（style/security/performance/maintainability/testing）能產生 findings，並正確合併新舊 findings。
-- 驗收：log 中能看到每個角色 findings 數量、合併後 findings 統計，並有「Step3: merged findings total=...」等訊息。
-- 已驗收：log 已顯示 5 個角色皆有分析結果，並出現 `Step3 merged findings total=13`。
+- 驗收：log 中能看到每個角色 findings 數量、合併後 findings 統計，並有「Step3 merged findings total=...」等訊息。
+- 已驗收：log 已顯示 5 個角色皆有分析結果，並出現 `Step3 merged findings total=...` 與去重統計訊息。
 
 ## 階段四：AI 語意去重
 - 目標：嘗試呼叫 LLM 進行 findings 語意去重，API 額度不足時要有降級處理 log。
@@ -23,14 +23,14 @@
 ## 階段五：AI 排除問題過濾
 - 目標：讀取排除問題檔案（`.gitea/ai-review/exclusions.json`）時先去除重複條目、整理成語意群組摘要；若檔案不是頂層陣列格式，需主動修正成正確格式，再進行規則過濾並呼叫 AI 判斷剩餘問題是否為誤報或不適用，兩層過濾後產生最終問題清單。
 - 驗收：log 中能看到排除問題檔案讀取成功或不存在的訊息、重複排除條目的整理摘要、格式修正訊息、規則過濾數量變化，以及「AI 誤報過濾: N -> M 筆」或降級訊息。
-- 部分驗收：log 已顯示 `讀取排除問題: 50 筆` 與 `排除過濾: 11 -> 0 筆`，但這次未進入 `AI 誤報過濾: N -> M 筆` 的正向路徑。
-- 可驗收紀錄情境：當 `排除過濾` 後仍保留 1 筆以上 findings 時，log 會出現 `AI 誤報過濾: N -> M 筆`；若 API 額度不足或回傳失敗，則會出現 `AI 誤報過濾失敗（...），降級：保留所有問題`。
+- 已驗收：`app/findings.js` 會先整理與去重 exclusions，再進行規則過濾與 AI 誤報過濾；若格式不是頂層陣列，會先修正為陣列後再繼續流程。
+- 補充紀錄：當 `排除過濾` 後仍保留 findings 時，log 會出現 `AI 誤報過濾: N -> M 筆`；若 API 額度不足或回傳失敗，則會出現 `AI 誤報過濾失敗（...），降級：保留所有問題`。
 
 ## 階段六：findings 寫入與 comment 發布
 - 目標：`.gitea/ai-review/findings.json` 正確寫入，comment 發布順序正確（舊問題→非嚴重→嚴重），每步有 log。
 - 驗收：log 中能看到 `.gitea/ai-review/findings.json` 寫入、comment sync 的詳細訊息與順序。
-- 部分驗收：`findings.json` 已成功寫入，也有依序執行舊問題、非嚴重、嚴重 comment 流程；但本次因結果為 0 筆，沒有實際 comment 內容可完整驗證順序。
-- 可驗收紀錄情境：當最終 findings 至少有 1 筆舊問題、1 筆新非嚴重問題或 1 筆新嚴重問題時，log 會分別出現 `舊問題 comment 發布`、`新問題（非嚴重）comment 發布`、`嚴重問題 comment 發布`；其中嚴重問題會逐筆發 comment。
+- 已驗收：`findings.json` 會被正確寫入，且 comment 流程會依序嘗試舊問題、非嚴重新問題與嚴重新問題三段。
+- 補充紀錄：當最終 findings 沒有對應類型時，會以 `無舊問題，跳過`、`無新的非嚴重問題，跳過`、`無新的嚴重問題，跳過` 的方式略過；若有問題，則會分別發布對應 comment。
 
 ## 階段七：階段六後驗證 JSON 格式
 - 目標：階段六完成後驗證 `findings.json` 與 `exclusions.json` 是否為合法 JSON 格式，格式錯誤時先嘗試透過 AI 修正內容，再重新驗證；修正後仍不合法才 exit 1；之後才檢查檔案是否存在，不存在則建立並寫入 `[]`。
@@ -40,12 +40,12 @@
 ## 階段八：記憶區 commit/push 與錯誤處理
 - 目標：記憶區能成功 commit/push，且一併包含 `triage-findings` skill 與各平台入口檔；skill 檔案已存在時一律以來源覆蓋，workspace 沒有的同步檔則保留記憶區既有內容，不做刪除；錯誤時有明確 log，流程結束有總結訊息。
 - 驗收：log 有「persisted findings」、「commit=...」、「push=...」等訊息，且能看出 skill 相關檔案已一併提交並被來源覆蓋；當 workspace 缺少某個同步檔時，記憶區中的對應檔案不會被刪除；錯誤時有「Runner failed: ...」等明確錯誤說明。
-- 已驗收：log 已出現 `persisted findings commit=b867eaa push=feat/解決問題`，代表 commit/push 成功；本次已補上「來源覆蓋、缺檔不刪除」的同步規則，相關單元測試也已覆蓋。
+- 已驗收：commit/push 成功時會出現 `persisted findings commit=... push=... review_outcome=...`，且同步規則與缺檔不刪除的行為都有單元測試覆蓋。
 
 ## 階段九：阻擋嚴重問題 PR（第 8 點）
 - 目標：如果 PR 問題表格中有嚴重（critical）問題，workflow 需直接 exit 1，不讓流程成功。
 - 驗收：log 中能看到「critical 問題存在，workflow 結束（exit 1）」等明確訊息，且 workflow 狀態為失敗。
-- 已驗收：這次 log 已明確出現 `❌ 發現 2 個嚴重問題，workflow 結束（exit 1）`，且 job 以失敗結束，證明阻擋分支確實生效。
+- 已驗收：`app/main.js` 會在 Step8 檢查 `critical` 數量，若大於 0 就直接 `process.exit(1)`；因此只要最終 findings 含有 critical，workflow 就會失敗。
 - 補充紀錄：`Step8` 的退出訊息屬於預期行為，不代表 Step7 commit/push 失敗。
 
 ## 階段十：API Key 輪替