Appearance
Plan Check
對應主管要求 ② 零信任 + ③ DBA SOP 內建。 「不依賴人記得做檢查 — 系統自動做」是 Argus 的設計核心之一。
是什麼
Plan 建立後，Argus 自動啟動 一組檢查（PlanCheckRun），對 SQL 做：
| 類別 | 看什麼 |
|---|---|
| Syntax | SQL 能不能 parse、是否有顯而易見的錯誤 |
| Schema impact | 影響哪些 table / column / index / constraint |
| Naming | 命名是否符合 workspace 規則（snake_case、長度…） |
| Risk | 高風險動作偵測（DROP TABLE、全表 UPDATE 無 WHERE、無索引大表 scan…） |
| Statement advisor | 多項可組合的 lint 規則（依 engine 不同） |
| Statement compatibility | 與目標 schema 的相容性（型別、constraint 衝突） |
| Statement type | 是否符合 task 宣告類型（DDL / DML） |
規則細節：Reference / Advisor 規則 | proto：
argus.v1.PlanCheckRun。
為什麼存在
| 痛點 | Plan Check 怎麼解 |
|---|---|
| Code review 不見得抓得到 DB-specific 問題 | 由懂 DB 的工具自動掃 |
| 不同人對「高風險」標準不同 | 用一致規則 + workspace policy |
| 容易忘記跑 explain | 自動跑 |
| 高風險動作要審批者特別注意 | check 結果作為審批 UI 高亮信號 |
生命週期
text
pending ──> running ──> done
├─ success
├─ warning
└─ error| 結果 | 對 Plan 的影響 |
|---|---|
success | Plan 進 ready，可建 Issue |
warning | Plan 進 ready，但 UI 標警示；審批者會看到 |
error | Plan 進 failed，阻擋 建 Issue |
可以重跑（修改 SQL 後）。
觸發時機
- Plan 建立時 → 全套 check
- Plan SQL 編輯後 → 重跑全套
- 目標 DB 的 schema 改變（外部變更）→ 部分 check 重跑
- Issue 建立時 → 重跑一次（防 schema drift）
客製規則
Settings → SQL Review：
- 啟用 / 停用個別 advisor 規則
- 規則嚴重度（disabled / warning / error）
- 範圍（global / per-environment / per-project）
規則調整會記錄在 audit log（
bb.setting.update，severity =notice）。
Override
error 等級 check 預設阻擋 Issue 建立。但 workspace admin 可開啟「allow override with justification」：
- 開發者建 Issue 時須輸入理由
- 理由與 override 紀錄會寫進 audit log
- 審批者 UI 會強烈高亮
不要把 override 當常態用。每次 override 都是技術債。
在 UI 上
- Plan 詳情頁：看到所有 PlanCheckRun（含歷史）
- 每個 check 可展開：看到具體掃出的問題、行號、修正建議
- Issue 詳情頁：頂部會顯示 PlanCheckRun 摘要（總數 / warning 數 / error 數）
對應 store
- 表：
plan_check_run（複合 PK(project, id, plan)） - proto：
argus.store.PlanCheckRunConfig/PlanCheckRunResult