用 Claude Code 核對預覽部署：版本、頁面同關鍵流程

建置綠燈，只係其中一關

假設網站建置成功，但執行時欠一個環境變數，某頁仍然可以回傳 500。部署核對應該回答三件事：測緊邊個版本、頁面有冇正常回應、用戶係咪做得到重要操作。

呢篇由已經建立嘅預覽部署開始，唔將推送、部署、核對同對外通知綁成一個含糊嘅「一鍵上線」。

1. 鎖定今次部署

記低部署 ID、固定對應今次部署嘅網址、環境、分支同 commit SHA。唔好只揀「最近五個部署入面第一個 READY」，繁忙專案可能有其他分支或者重試。

請唯讀檢查呢個部署：[部署 ID 或網址]。

核對專案、環境、分支、完整 commit SHA 同部署狀態。搵唔到指定版本、狀態失敗、API 未授權或超時，要分開報告，唔好轉去測上一個成功版本。

暫時唔建立部署、唔修改設定、唔發通知。

用 API 輪詢時，檢查 HTTP 狀態、解析錯誤、分頁同團隊範圍，設總等待上限。部署完成後再開始網站測試，避免將「未建好」誤判成程式錯誤。

2. 先做 HTTP 檢查

揀幾條代表性路徑，列明預期狀態碼、內容類型同只會喺正確頁面出現嘅內容。首頁導覽都有「月費」兩字，就唔適合用嚟證明收費頁正常。

curl --fail-with-body --show-error --silent \
  --connect-timeout 10 --max-time 30 \
  'https://YOUR-PREVIEW-HOST/api/health'

將網址換成已核對嘅預覽網址。呢條指令只檢查請求結果；如果健康端點回 JSON，仲要用程式驗證必要欄位同值，唔好只搜尋 ok。

重定向要按預期處理：跳去登入頁未必係測到目標內容。受保護嘅預覽需要按平台支援方式提供自動化憑證，唔好為咗測試方便關閉保護，亦唔好將繞過憑證放喺會被記錄嘅公開網址。

3. 用瀏覽器檢查真正操作

以下假設專案已設定 Playwright，預覽網址由受控環境變數提供：

import { test, expect } from '@playwright/test'

const previewUrl = process.env.PREVIEW_URL
if (!previewUrl) throw new Error('PREVIEW_URL is required')

test('首頁可以開啟註冊頁', async ({ page }) => {
  await page.goto(previewUrl)
  await page.getByRole('link', { name: '開始試用' }).click()
  await expect(page.getByRole('heading', { name: '註冊' })).toBeVisible()
})

呢個測試只證明連結同註冊頁開到，唔代表註冊成功。要測表單提交，就要另設測試帳戶、隔離資料同清理方式，並確認唔會寄出真實通知。

搜尋功能亦一樣：要用固定、已知存在嘅測試內容，再驗證對應結果，唔只係見到任何一行結果就算。測試數量由關鍵流程決定，唔係超過五條就一定不穩定。

4. 保留可追查嘅報告

將結果分成部署狀態、HTTP 檢查同瀏覽器流程。

列出完整 commit SHA、部署網址、執行時間、通過項目、失敗項目、截圖或追蹤檔位置。未執行嘅檢查寫「未驗證」，唔好當通過。

若測試不穩定，保留首次失敗證據；重試成功亦要說明，唔好蓋過第一次結果。

需要 Slack 或其他通知時，先確認接收位置同內容。通知失敗要另外回報，唔可以因為網站測試成功，就假設訊息已送達。Webhook 亦要用正確平台格式，唔同平台唔係只換網址就通用。

正式環境同付款流程要另外安排

預覽通過唔保證正式環境相同。正式環境有不同憑證、資料、網域同快取，仍要做獲授權嘅上線後檢查。

付款測試尤其唔應複製一段測試卡 iframe 程式就直接對正式網站執行。要先確認整條流程使用隔離測試帳戶同測試模式，亦要核對訂單、Webhook 同後端狀態。單一成功畫面唔代表整條收款流程都已驗證。

有用嘅核對報告，唔係得一個綠剔，而係清楚交代綠剔涵蓋咗乜。