production-audit

Production Audit

當使用者詢問應用程式是否已準備好上線（ready to ship）、正式環境可能有哪些潛在問題，或上線前有哪些必須修復的項目時，請使用此 Skill。本 Skill 是對舊版社群 production-audit 概念的維護者安全重寫版本：它保留了實用的正式環境準備度（production-readiness）視角，同時移除了未指定版本的外部程式碼執行以及第三方資料共享。

何時使用

• 使用者詢問「這可以上線了嗎？」、「正式環境會出什麼事？」、「我們漏掉了什麼？」、「幫我診斷這個 repo」或「準備好發布了嗎？」。
• 程式碼已合併，需要進行部署前或合併後的風險評估。
• 即將進行公開發布、展示（demo）、客戶推廣或投資人演示。
• CI 測試顯示綠燈（通過），但使用者想知道正式環境的實際風險，而不僅僅是測試狀態。
• 已有可供收集事證的已部署 URL、發行分支（release branch）、PR 或目前的程式碼庫狀態。

何時不使用

• 處於主動開發階段，此時最適合的視角是行級的安全程式碼編寫（line-level secure coding）；請先使用 security-review。
• 針對純函式庫、範本、僅包含文件的 repo 或專案骨架（scaffold），除非使用者想評估的是套件包裝/發布準備度，而非應用程式準備度。
• 當使用者要求進行正式的合規性審計時。本 Skill 屬於工程排查（triage），並非法律、財務、醫療或法規認證。
• 唯一可用的事證僅為產品概念，缺乏任何 repo、部署、CI 或執行階段界面（runtime surface）。

運作方式

基於本地以及使用者授權的事證來建立診斷。切勿執行未指定版本的遠端程式碼、將 repo 內容上傳至第三方服務，或呼叫外部掃描工具，除非使用者明確批准該特定工具與資料流程。

請依循以下順序：

1. 確認發布界面（release surface）。
2. 檢視近期變更與目前的分支狀態。
3. 檢查 repo 中實際存在的執行階段（runtime）、身分驗證（auth）、資料、支付、背景任務（background-job）、AI 與部署邊界。
4. 檢查 CI、測試、資料庫遷移（migration）、環境變數文件與退回（rollback）機制。
5. 產出簡短的「可上線 / 阻擋」建議，並附上具體的修復項目。

事證檢查清單

從成本低、本地現成的訊號開始：

git status --short --branch
git log --oneline --decorate -20
git diff --stat origin/main...HEAD

接著檢查專案特有的界面：

• Package 腳本、CI 工作流程、發布腳本、Docker 檔案與部署清單（manifests）。
• API 路由、Webhook、身分驗證中間件（auth middleware）、背景 Worker、Cron Job 與資料庫遷移（migrations）。
• 環境變數文件與啟動檢查機制。
• 可觀測性（observability）鉤子、錯誤回報、日誌、健康檢查（health check）與儀表板（dashboard）。
• 退回（rollback）、Seed 資料、遷移與歷史資料補填（backfill）指引。
• 最核心使用者流程的 E2E 測試涵蓋率。

若範圍包含已部署的 URL，僅對該 URL 進行瀏覽器或 HTTP 檢查，並避免執行需要權限的操作，除非使用者提供安全的測試帳號。

風險評估視角

安全性與身分驗證

• 公開路由、API 路由與管理員（admin）路由是否明確分離？
• 身分驗證（auth）與授權（authorization）是否在伺服器端強制執行？
• 敏感資訊（secrets）是否未暴露於前端打包檔案（client bundle）、日誌、範例輸出及已 Commit 的檔案中？
• 速率限制（rate limits）、CSRF 防護、CORS 政策與上傳驗證是否已在必要處配置？
• AI 或 Agent 界面是否能防禦 Prompt Injection、工具濫用以及非受信任內容滲透至高權限操作中？

資料完整性

• 資料庫遷移能否順暢執行，且備有退回或復原計畫？
• 破壞性遷移、歷史資料補填（backfill）與資料匯入是否已安全地分階段進行？
• 資料庫政策、權限授予（grants）與服務角色（service-role）邊界是否符合應用程式的多租戶（tenancy）模型？
• 針對寫入、任務與 Webhook 處理程式，重試機制是否具備等冪性（idempotent）？

支付與 Webhook

• 是否在解析受信任的 Payload 欄位前驗證 Webhook 簽名？
• 各項支付、訂閱或履約（fulfillment）Webhook 是否具備等冪性？
• 是否已妥善處理重放（replay）、重複發送與跨序發送（out-of-order delivery）？
• 測試模式與正式模式（live-mode）的憑證是否明確分離？

維運

• 應用程式能否依照文件記載的指令，從乾淨的 Codebase 全新啟動？
• 必要的環境變數是否已命名、驗證，並具備 Fast-Fail 機制？
• 是否設有健康檢查以證明依賴項（dependencies）正常可連通？
• 部署、退回與事故負責人（incident-owner）聯絡管道是否已建立文件？
• 日誌是否具備實用價值，且不會洩漏敏感資訊或個人資料？

使用者體驗

• 關鍵上線流程是否已在桌面端與行動端完成測試？
• 表單在行動端是否易於使用，且無輸入放大（input zoom）、版面重疊或送出按鈕卡死等問題？
• 載入中（loading）、空白（empty）、錯誤（error）與權限不足（permission-denied）狀態是否清楚告知使用者發生了什麼事？
• 當關鍵操作失敗時，是否提供客服支援或復原路徑？

評分機制

使用評分的目的在於強制排定優先順序，而非代表數學上的絕對精準。

級別	分數	含義
阻擋（Blocked）	0-49	在修復最高風險前切勿上線
具風險（Risky）	50-69	僅限灰度發布（small rollout）或內部 Beta 測試
附帶條件可上線（Launchable With Caveats）	70-84	若負責人接受列出的風險，即可上線
良好（Strong）	85-100	依現有事證未發現明顯的上線阻擋因素

若存在以下任一情況，分數上限扣至 69：

• 敏感資料缺少身分驗證或授權機制。
• 支付或履約 Webhook 未具備等冪性。
• 必要的資料庫遷移無法安全執行。
• 敏感資訊（secrets）洩露於前端打包檔案、日誌或 Commit 的檔案中。
• 高影響力的版本發布缺乏退回機制。

若 CI 未通過綠燈，或關鍵上線流程未完成端到端（E2E）測試，分數上限扣至 84。

輸出格式

開頭先用一句話總結：

Production audit: 76/100, launchable with caveats, with webhook idempotency and rollback docs as the two risks to fix before public launch.

接著列出：

• Blockers：部署前必須修復的項目。
• High-value fixes：若使用者希望提高分數，優先處理的修復項目。
• Evidence checked：已檢查的檔案、指令、CI、已部署 URL 或 PR。
• Evidence missing：若能提供，將有助於提升評估信心度的缺失事證。
• Next action：下一步具體的修復或驗證步驟。

優點說明保持簡短。使用者要的是準備度評估，因此最有價值的回答是剩餘的風險與下一步行動。

範例

使用者：

is this ready to ship?

回答：

Production audit: 68/100, risky, because Stripe webhooks are verified but not idempotent and there is no rollback note for the pending migration.

Blockers:
- Add idempotency for `checkout.session.completed` before fulfilling orders.
- Write and test the rollback path for `20260511_add_billing_state.sql`.

High-value fixes:
- Add a health check that verifies database and payment-provider reachability.
- Add one E2E path for upgrade, webhook fulfillment, and billing-page refresh.

Evidence checked:
- `api/stripe/webhook.ts`
- `db/migrations/20260511_add_billing_state.sql`
- GitHub Actions run for the release branch

Next action: Want me to patch webhook idempotency first?

反模式（Anti-Patterns）

• 將執行 npx <package>@latest 或遠端掃描器作為預設的診斷方式。
• 在未獲明確授權的情況下，將原始碼、敏感資訊、客戶資料或私有架構上傳至第三方診斷服務。
• 產出分數卻未列出所檢查的事證。
• 將 CI 綠燈直接視為符合正式環境準備度。
• 以泛泛的「再跟我說你想怎麼做」作為結尾。

參見

• Skill: security-review
• Skill: deployment-patterns
• Skill: e2e-testing
• Skill: tdd-workflow
• Skill: verification-loop