docs(README): 說明單一 Pull Review 發布流程

README.md

@@ -10,13 +10,13 @@
    - 若有提供 `GITEA_COMMENT_TOKEN`，額外用它驗證可用（呼叫 `GET /api/v1/user`），確保後續發 comment 不會因 token 失效而中斷
    - git push 認證可用：用與第 8 點 commit/push 完全相同的 askpass + remote URL 機制跑一次唯讀的 `git ls-remote`，提前抓出 askpass 無法執行或 HTTP 認證失敗（例如 `could not read Username`）的問題。此路徑與上面的 REST API 不同，API token 有效不代表 git push 一定能用，故獨立驗證
    - 已選定一個 LLM provider，且其 API Key 至少有一把通過驗證：實際送出一個最小請求確認認證可用；逗號分隔的多把 Key 只要一把成功即可，逐把記錄成敗；Ollama 無 Key，改為檢查 `OLLAMA_BASE_URL` 可連線
-1. 服務名稱、模型名稱、角色資訊(個性、符合個性的英文名稱、工作內容)，Comment 到 Pull Request
+1. 準備服務名稱、模型名稱、角色資訊(個性、符合個性的英文名稱、工作內容)作為本次 Pull Review 的主內容開頭；後續問題彙整完成後，會將角色介紹與所有問題一起發布在同一筆 Pull Review 底下
 2. 每個角色個別分析 Git Diff 的內容產生新問題表格(問題等級、角色名稱、問題位置或行數、修改建議)
 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 問題表格中取出所有新問題，將每個嚴重等級的問題以 Gitea 行內 review comment 標註在問題所在的檔案與行數上，留言內容為等級／審查員／建議；若問題位置無法解析出行號（例如未標行號或一次列出多個檔案），或該行不在本次 diff 範圍內導致行內留言失敗，則降級為一般 PR Comment
+5. 從 PR 問題表格中取出所有舊問題；若問題位置可解析出單一檔案行號，則放入同一筆 Pull Review 底下的 Gitea 行內 review comment，否則放入 Pull Review 主內容
+6. 從 PR 問題表格中取出所有新問題（包含非嚴重與嚴重）；若問題位置可解析出單一檔案行號，則放入同一筆 Pull Review 底下的 Gitea 行內 review comment，否則放入 Pull Review 主內容
+7. 每個行內 review comment 內容包含分類、等級、審查員、建議；若批次行內留言因行號不在本次 diff 範圍等原因失敗，則將所有問題降級放入同一筆 Pull Review 主內容，避免散落成多筆 PR Comment
 8. Commit 問題檔案，只將 workspace 中實際存在的 `.gitea/ai-review/findings.json` 與 `.gitea/ai-review/exclusions.json` 覆蓋到記憶區；workspace 沒有的問題檔就略過。自動提交的 commit message 會帶上 `[ai-review-bot]`，供 workflow 判斷是否要跳過重跑
 9. 如果 PR 問題表格中有嚴重問題，則不要讓 workflow 執行成功(exit 1)