docs: 規劃 action 啟動前置驗證所有驗證相關設定

在 README 流程新增第 0 點與設計第 11 點，並在 TODO 新增階段十二，
說明 action 啟動時集中驗證 Gitea token、comment token 與 LLM API Key
是否可用，任一失敗即 exit 1。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

README.md

@@ -4,6 +4,11 @@
 
 # 流程(Pull Request opened / synchronize 觸發；若偵測到 AI 助理的自動提交則直接跳過)
 
+0. 前置驗證（action 最開始執行、做任何分析或發 comment 前）：檢查所有驗證相關設定是否都可用，全部通過才繼續；任何一項失敗就印出明確訊息並立即 `exit 1`
+   - 必要環境變數齊全：`GITEA_TOKEN`、`GITEA_REPOSITORY`、`PR_NUMBER`（缺一即失敗）
+   - Gitea API 可連線且 `GITEA_TOKEN` 有權限讀取此 repo（呼叫 `GET /api/v1/repos/{repo}` 驗證 token 與 repo 同時有效）
+   - 若有提供 `GITEA_COMMENT_TOKEN`，額外用它驗證可用（呼叫 `GET /api/v1/user`），確保後續發 comment 不會因 token 失效而中斷
+   - 已選定一個 LLM provider，且其 API Key 至少有一把通過驗證：實際送出一個最小請求確認認證可用；逗號分隔的多把 Key 只要一把成功即可，逐把記錄成敗；Ollama 無 Key，改為檢查 `OLLAMA_BASE_URL` 可連線
 1. 服務名稱、模型名稱、角色資訊(個性、符合個性的英文名稱、工作內容)，Comment 到 Pull Request
 2. 每個角色個別分析 Git Diff 的內容產生新問題表格(問題等級、角色名稱、問題位置或行數、修改建議)
 3. 讀取來源分支中的所有未解決舊問題(問題檔案 `.gitea/ai-review/findings.json`)加上新問題後，去除重複產生本次 PR 的問題表格(PR問題表格)覆蓋問題檔案
@@ -26,6 +31,7 @@
 8. 階段七驗證來源分支中的 `findings.json` 與 `exclusions.json` 是否為合法 JSON 格式，格式錯誤時先嘗試透過 AI 修正內容，再重新驗證；修正後仍不合法才 exit 1；之後才檢查檔案是否存在，不存在則建立並寫入 `[]`
 9. 傳給 AI 的 findings 只保留必要欄位（level、role、location、suggestion），排除 `is_new` 等內部欄位；system prompt 精簡為指令核心；exclusions hint 只傳 location 與 suggestion，減少 token 用量
 10. 執行時會額外記錄來源分支狀態、`findings.json` / `exclusions.json` 的檔案路徑、大小、mtime 與 raw/normalized 筆數，方便追查讀檔與分支內容不一致的問題
+11. action 一啟動就先做「前置驗證」（流程第 0 點）：集中檢查 Gitea 與 LLM 的所有驗證相關設定是否可用，全部通過才往下跑。驗證邏輯獨立成 `app/preflight.js` 並由 `main.js` 在 Step1 之後、其餘步驟之前呼叫；任何一項失敗都印出是哪一項、原因為何後 `exit 1`，避免在分析到一半或發 comment 時才因 token / key 無效而中斷
 
 # 使用說明
 

TODO.md

@@ -57,3 +57,13 @@
 - 目標：傳給 AI 的 findings 只保留必要欄位（level、role、location、suggestion）；system prompt 精簡為指令核心；exclusions hint 只傳 location 與 suggestion；AI 回傳後補回原始完整欄位（含 is_new）。
 - 驗收：AI 呼叫的 payload 不含 is_new 等內部欄位，去重與誤報過濾後的 findings 仍保有完整欄位供後續流程使用。
 - 已驗收：`app/findings.js` 已只傳必要欄位給 AI，並在回傳後補回原始 findings 的完整欄位。
+
+## 階段十二：啟動前置驗證所有驗證相關設定
+- 目標：action 一開始（Step1 之後、其餘步驟之前）就集中檢查所有「驗證相關設定」是否可用，全部通過才繼續，任何一項失敗就印出明確原因並 `exit 1`。檢查項目：
+  1. 必要環境變數齊全：`GITEA_TOKEN`、`GITEA_REPOSITORY`、`PR_NUMBER`（缺一即失敗）。
+  2. Gitea API 可連線且 `GITEA_TOKEN` 能讀取此 repo（`GET /api/v1/repos/{repo}`）。
+  3. 若有提供 `GITEA_COMMENT_TOKEN`，另外用它驗證可用（`GET /api/v1/user`）。
+  4. 已選定一個 LLM provider（`getLLMConfig().provider` 非 null）。
+  5. LLM API Key 至少一把通過驗證：送出最小請求確認認證可用，逗號分隔多把只要一把成功即可並逐把記錄成敗；Ollama 改為檢查 `OLLAMA_BASE_URL` 可連線。
+- 驗收：log 中能看到 `Step1.5`（或對等）前置驗證的每一項結果（成功/失敗），任一失敗時 log 指出是哪一項與錯誤訊息，且 workflow 狀態為失敗；全部通過時 log 出「前置驗證通過」後才進入後續流程；驗證邏輯由 `app/preflight.js` 提供並有單元測試覆蓋（成功、缺環境變數、Gitea token 無效、comment token 無效、所有 LLM key 失敗、Ollama base url 等情境）。
+- 補充紀錄：前置驗證不應發布任何 PR comment，只做唯讀的認證/連線確認；LLM 驗證請用最小 payload，避免浪費 token。