Thariq Skills #9 — Infrastructure Operations：有護欄的例行維護自動化
Infra 維護工作有個特點：重複性高、風險不對稱。
清理孤兒資源、更新依賴、查成本——這些工作每週都要做，但每一個都有可能因為一個錯誤的 delete 指令造成嚴重問題。Infrastructure Operations skills 的設計目標：讓 agent 做例行工作，但在危險操作上永遠停下來等人確認。
類別定義
“Routine maintenance with guardrails for destructive actions.”
兩個核心詞：
- Routine：這些是預期會定期執行的工作，不是一次性任務
- Guardrails for destructive actions：agent 可以做診斷和分析，但刪除、停機、重配置這類操作需要人工確認
Thariq 的範例
resource-orphans — 掃描並標記孤兒資源（沒有對應 owner 的 S3 bucket、EC2 instance、DNS record 等）。agent 生成「待刪除清單」，但不自動刪除——等人確認後才執行。
dependency-management — 自動掃描過時的依賴、評估更新風險、生成更新建議。可以自動執行低風險更新（patch version），高風險更新（major version）需要人工確認。
cost-investigation — 雲端成本異常調查。自動抓取本月 vs 上月的費用對比、識別突增的資源、追蹤到具體的 service 或工單。生成優化建議，但不自動刪除高成本資源。
護欄設計的原則
Infrastructure Operations skills 的護欄不是「保護 agent 不會出錯」，而是「確保人類有機會在不可逆操作前介入」。
三個層次的護欄：
層次 1 — On-demand hooks（技術護欄）
/careful hook：阻擋 rm -rf, kubectl delete, DROP TABLE, force-push
在 skill 啟動時自動掛載，整個 session 有效
層次 2 — Workflow 設計（程序護欄）
「分析」和「執行」分成兩個明確步驟
agent 完成分析後輸出清單，等待人工「確認執行」指令
層次 3 — Report-first 模式（認知護欄）
所有 Infra skills 的輸出格式都是「先報告、後行動」
人工讀完報告確認沒問題，才給 agent 執行許可有些工程師會覺得需要人工確認是 agent 能力不足的表現。但在 Infrastructure Operations 這個類別，HITL 是正確的架構設計——它確保了「agent 效率」和「人類控制」的平衡，而不是犧牲其中一個。
SuperPortia 實戰觀點
SP 在這個類別有部分覆蓋，主要來自 SRE 腳本和兩個相關 skills：
| 工具 | 功能 | 評估 |
|---|---|---|
site-audit skill | 網站健康檢查 | 有，但偏向前端診斷 |
deploy-checklist skill | 部署前的 infra 確認 | 有，但非例行維護用途 |
| SRE patrol scripts | 定期健康監控 | 有，但不是 agent-callable |
| CF Workers / D1 監控 | 無 skill | Agent 無法主動查資源狀態 |
成本調查（cost-investigation 對應物）完全缺失。Cloudflare 帳單只有人工查看，沒有 agent 可以觸發的調查流程。
cf-health — Cloudflare 資源健康掃描：
（1）列出所有 active Workers + D1 databases + Pages 專案
（2）比對 registry.json 中的預期資源，識別孤兒或遺失的資源
（3）抓取本月 CF 費用並對比上月
（4）生成報告，等待人工確認是否需要清理
這個 skill 對 ADR-0010 之後的 11-repo 架構特別有價值——確保沒有「已分拆但忘記清理」的舊資源在持續產生費用。
依賴管理的實務設計
dependency-management/
├── SKILL.md ← 觸發：「更新依賴」「檢查過時的 package」
├── scripts/
│ ├── audit.sh ← npm audit / pip-audit / cargo audit
│ ├── check-updates.sh ← 列出有更新的 package
│ └── safe-update.sh ← 只執行 patch version 更新（低風險）
├── risk-matrix.md ← 哪些 package 是高風險（Thariq 的 PK Danger Zone 對應）
└── gotchas.md ← 已知的 breaking change 記錄這和 SP 的 tech-freshness.md rule 有直接對應：Cloudflare SDK、Astro、AI SDK 是高風險依賴，需要手動確認後才能更新。把這個風險矩陣放進 dependency-management skill 的 risk-matrix.md，agent 就知道哪些可以自動更新，哪些要暫停等確認。
九大類別的最終觀察
這是 Thariq 九大類別的最後一篇。從這個視角回看整個框架，一個模式清晰出現：
Skills 的複雜度和 HITL 需求是正相關的。
- Library & API Reference → 低 HITL（純知識提供）
- Product Verification → 中 HITL（驗證結果需要人判斷）
- Infrastructure Operations → 高 HITL（破壞性操作必須人確認）
設計 skill 時，提前決定「這個 skill 在哪些點需要停下來等人」，是最重要的架構決策之一。
回到總文
本文是九大類別系列的第九篇，也是最後一篇。完整框架與 SuperPortia 對照請見：
...— 部署 pipeline 的 skill 封裝 8. [[Thariq Skills — Runbooks]] — 症狀到報告的結構化調查流程 9. [[Thariq Skills — Infrastructure Operations]] — 有護欄的例行維護自動化 我們的觀點：Skills 是 Action Space 設計 Thariq...