Production Audit
當使用者詢問應用程式是否準備好上線、在生產環境中可能出現什麼問題、或在上線前必須修復哪些問題時，請使用此技能。這是一個維護者安全的改寫版本，取代了舊有的社群 production-audit 想法：它保留了有用的生產就緒度視角，並移除了未固定的外部執行和第三方資料共享。
何時使用
- 使用者詢問「這個準備好上線了嗎」、「在生產環境中會出什麼問題」、「我們漏掉了什麼」、或者「準備好出貨了嗎？」
- 某個功能已合併，需要進行部署前或合併後的風險檢查。
- 公開上線、展示、客戶推出或投資者演示即將到來。
- CI 是綠燈，但使用者想知道的是生產風險，而不僅僅是測試狀態。
- 有已部署的 URL、發布分支、PR 或目前簽出的版本可用於收集證據。
何時不使用
- 在積極實作階段，此時正確的視角是程式碼層級的安全編碼；請先使用
security-review。 - 對於純函式庫、範本、僅文檔的儲存庫或樣板，除非使用者想要的是打包/發布就緒度而非應用程式就緒度。
- 當使用者要求正式的法規遵循審計時。此技能是工程分類，而非法律、財務、醫療或監管認證。
- 當唯一可用的證據是一個產品想法，沒有儲存庫、部署、CI 或執行時表面。
運作方式
從本地和使用者授權的證據建立審計。不要執行未固定的遠端程式碼、不要將儲存庫內容上傳至第三方服務、也不要呼叫外部掃描器，除非使用者明確批准該特定工具和資料流程。
請依序執行：
- 建立發布範圍。
- 讀取最近的變更和目前分支狀態。
- 檢查儲存庫中實際存在的執行時、驗證、資料、付款、背景任務、AI 和部署邊界。
- 檢查 CI、測試、遷移、環境文件以及回滾路徑。
- 產生一個簡短的「可出貨/阻擋」建議，並附上具體修復方式。
證據檢查清單
從低成本的本機訊號開始：
git status --short --branch
git log --oneline --decorate -20
git diff --stat origin/main...HEAD
然後檢查專案特定的表面：
- 套件腳本、CI 工作流程、發布腳本、Docker 檔案和部署清單。
- API 路由、Webhook、驗證中介軟體、背景工作者、Cron 工作和資料庫遷移。
- 環境變數文件和啟動檢查。
- 可觀測性掛鉤、錯誤報告、日誌、健康檢查和儀表板。
- 回滾、種子、遷移和回填說明。
- 最重要的使用者路徑的端到端測試覆蓋率。
如果已部署的 URL 在範圍內，僅對該 URL 使用瀏覽器或 HTTP 檢查，並避免需要憑證的操作，除非使用者提供安全的測試帳戶。
風險透視鏡
安全性與驗證
- 公開路由、API 路由和管理員路由是否明確分離？
- 是否在伺服器端強制執行身分驗證和授權？
- 機密是否保留在用戶端套件、日誌、範例輸出和已簽入的檔案之外？
- 應用程式需要的地方是否具備速率限制、CSRF 防護、CORS 政策和上傳驗證？
- AI 或代理表面是否防範提示注入、工具濫用以及未受信任的內容跨入特權操作？
資料完整性
- 遷移是否能乾淨地向前執行，並且有回滾或復原計畫？
- 破壞性遷移、回填和資料匯入是否安全地分階段進行？
- 資料庫原則、授權和服務角色邊界是否符合應用程式的租戶模型？
- 寫入、任務和 Webhook 處理程序的重試是否具有冪等性？
付款與 Webhook
- 在解析受信任的有效負載欄位之前，是否驗證了 Webhook 簽章？
- 每個付款、訂閱或履行 Webhook 是否具有冪等性？
- 是否處理了重播、重複傳送和亂序傳送？
- 測試模式和即時模式的憑證是否分離？
營運
- 應用程式能否使用文件記錄的命令從乾淨的簽出啟動？
- 所需的環境變數是否已命名、驗證並快速失敗？
- 是否有健康檢查證明相依服務可達？
- 部署、回滾和事件負責人的路徑是否有文件記錄？
- 日誌是否有用，且不會洩漏機密或個人資料？
使用者體驗
- 上線關鍵路徑是否涵蓋桌面和行動裝置？
- 表單在行動裝置上是否可用，不會出現輸入縮放、佈局重疊或提交狀態被封鎖的情況？
- 載入、空白、錯誤和權限拒絕狀態是否告知使用者發生了什麼？
- 關鍵操作失敗時是否有支援或復原路徑？
評分
使用評分來強制設定優先順序，而不是暗示數學上的確定性。
| 等級 | 分數 | 意義 |
|---|---|---|
| 受阻 | 0-49 | 在修復最高風險之前不要出貨 |
| 高風險 | 50-69 | 僅在小型推出或內部測試版後出貨 |
| 可上線但有附帶條件 | 70-84 | 如果擁有者接受所列出的風險，則可出貨 |
| 強健 | 85-100 | 從可用證據來看，沒有明顯的上線阻礙 |
如果以下任一條件成立，則將分數上限設為 69：
- 敏感資料缺少身分驗證或授權。
- 付款或履行 Webhook 不具冪等性。
- 所需的遷移無法安全執行。
- 機密暴露在用戶端套件、日誌或已提交的檔案中。
- 對於高影響力的發布沒有回滾路徑。
如果 CI 不是綠燈，或者上線關鍵路徑未經端到端測試，則將分數上限設為 84。
輸出格式
以一句話開頭：
Production audit: 76/100，可上線但有附帶條件，需要修復 webhook 冪等性和回滾文件這兩個風險後才能公開上線。
然後列出：
Blockers（阻礙因素）：部署前必須修復的項目。High-value fixes（高價值修復）：如果使用者想要提高分數，下一步的修復項目。Evidence checked（已檢查的證據）：已檢查的檔案、命令、CI、已部署的 URL 或 PR。Evidence missing（缺少的證據）：如果提供，會改變信心的項目。Next action（下一步行動）：一個具體的修復或驗證步驟。
保持優點簡短。使用者問的是就緒度，因此有用的答案是剩餘的風險和下一步行動。
範例
使用者：
這個準備好出貨了嗎？
回應：
Production audit: 68/100，高風險，因為 Stripe Webhook 已驗證但不具冪等性，且待執行的遷移沒有回滾說明。
Blockers:
- 在履行訂單之前，為 `checkout.session.completed` 加入冪等性。
- 撰寫並測試 `20260511_add_billing_state.sql` 的回滾路徑。
High-value fixes:
- 加入一個健康檢查，以驗證資料庫和付款提供者的可達性。
- 為升級、Webhook 履行和帳單頁面刷新加入一條端到端路徑。
Evidence checked:
- `api/stripe/webhook.ts`
- `db/migrations/20260511_add_billing_state.sql`
- 發布分支的 GitHub Actions 執行
Next action: 要我優先修補 Webhook 冪等性嗎？
反模式
- 將執行
npx <package>@latest或遠端掃描器作為預設的審計路徑。 - 在未經明確批准的情況下，將原始碼、機密、客戶資料或私有拓撲上傳至外部審計服務。
- 在未指明已檢查的證據下產生評分。
- 將綠燈 CI 視為生產就緒。
- 以泛泛的「告訴我想做什麼」結束。
另請參閱
- 技能：
security-review - 技能：
deployment-patterns - 技能：
e2e-testing - 技能：
tdd-workflow - 技能：
verification-loop