先確認這張報表能看哪些資料
讀取 blacklist，確保報表不會把受保護表或欄位帶進結果。資料不能用時，回頭和 owner 對齊，不要靠改查詢避開政策。
dbcli blacklist list分析交付
營運問「哪個方案流失最嚴重？」先別回一張截圖。
這種問題通常會變成下一個會議的討論起點。交付物得讓人知道資料從哪來、查了什麼、有哪些限制；不然一段漂亮的 Agent 回覆也無法被驗證。
這次要回答的事：營運想比較本月各方案的流失。分析師先確認可看的資料、
subscriptions 的實際欄位，再重用團隊已審閱的 monthly-churn 查詢，把結果交成可討論的 UI。從提問到交付，少走幾個暗坑
看過 schema，才知道「方案」是哪個欄位
先查看實際資料表，再請 Agent 撰寫限定範圍的查詢。這一步避免用名稱相像的欄位算出一張看似合理、其實答錯問題的圖。
dbcli schema subscriptions --format json用團隊查詢交付互動結果
先找已保存的 snippet；確認後才用互動式 UI 執行。既有權限、黑名單與筆數限制仍保護結果。
dbcli queries search churn
dbcli q @monthly-churn --ui