第七階段：出貨
目標：暫存環境與正式環境一致，每次部署都無聊可預測，上線當天有復原機制，且上線後第一週受到監控。
部署由專案擁有者執行。 代理負責準備、檢查與解釋。代理不得 SSH 到伺服器、執行 deploy-safe.sh、修改 DNS 或觸及 Cloudflare，除非專案擁有者明確要求該動作。deploy-safe.sh 需要終端機與手動輸入的提交 ID，因此代理無法獨自完成部署。
步驟
- 暫存環境（
references/deploy-and-launch.md，「暫存環境」）：在正式主機上擁有自己的資料夾與資料庫，WP_ENVIRONMENT_TYPE=staging，位在 Cloudflare Access 後方，並設有測試用的詢問收件匣。 - 強化每台伺服器，遵循專案的
docs/reference/DEPLOY_HARDENING.md。將結果記錄在docs/reference/SECURITY_PRELAUNCH.md。 - 邊緣：依據
references/cloudflare-edge.md設定 Cloudflare。在對舊主機啟用代理之前，請先測試：某些主機會依 IP 限制速率，導致封鎖 Cloudflare。 - 部署程式碼，僅限專案擁有者操作：
- 從範例填寫
deploy/targets.conf； - 執行
scripts/deploy-safe.sh <commit> --target staging --dry-run，讀取變更清單，然後不加--dry-run再次執行； - 如果伺服器上已有程式碼，首次執行需要
--assume-live <commit>。
- 從範例填寫
- 內容變更請分開部署。
- 程式碼絕不包含價格、頁面或法律文字。
- 每次變更記錄為
docs/data/content-changes/<date>-<topic>.json（每個欄位的變更前後值）。 - 使用
scripts/apply-content-change.sh <file> --target staging（先乾執行）進行套用，然後加上--apply。 - 任何資料庫匯入或移動後，執行
scripts/check-emoji.sh --target <env>。
- 上線稽核：對暫存環境執行 launch-auditor 代理，修正檢查失敗的項目，然後再次執行直到通過。
- 切換計畫。 從
references/deploy-and-launch.md的「切換」章節撰寫。專案擁有者批准日期與時間；如果網站已接受預約，則也需要業務合作夥伴的批准。 - 正式上線：部署至正式環境，對正式環境執行 launch-auditor，將 Sitemap 提交至 Search Console，從真實收件匣發送一封真實的測試詢問。
- 監控 7 天：錯誤、404（加入重新導向）、表單收件匣、分析工具、Search Console 覆蓋範圍。
檢查閘門（在 SITE_STATUS.md 中打勾）
- 暫存環境在 Access 後方、設有 noindex、郵件受保護
- 安全性強化已套用並記錄
- 安全部署至暫存環境；煙霧測試通過
- launch-auditor 在暫存環境通過，然後在正式環境通過
- 切換計畫已批准（日期、復原方案、郵件/MX 記錄已檢查）
- 7 天監控完成
曾影響這些規則的事件
- 某代理修改了正式環境的價格、發布了 AI 撰寫的條款、並未經審查部署了一項功能，而其報告遺漏了該次部署。從此之後：部署僅來自合併後的提交，透過腳本執行、由人類手動輸入，且正式環境的 SSH 金鑰每次使用都要求確認。
- 暫存環境的聯絡表單使用測試金鑰向第三方表單服務提交，導致詢問進入測試收件匣。上線前，請在正式環境發送一封真實詢問並確認收到。
- 網站分析處於「精簡」模式，數週內未計數歐盟訪客，因而隱藏了主要市場。請在第一天檢查設定。
- 一次長時間部署（39 個提交）因
pipefail下的git log | head出現 SIGPIPE 而中止。腳本現在會先擷取輸出。 - 伺服器資料庫匯入將表情符號轉成了
????。請在每次匯入後執行check-emoji.sh。