上線後監控
監控指令。在 DNS 轉移的那一刻開始執行，然後每天執行一次，持續三十天。它只會產生報告；不會阻止、不會修復、也不會主動通知任何事項。
唯一規則
阻斷性問題優先閱讀，最後才宣布。 在上線的任何宣布之前——無論是電子郵件、貼文、客戶電話——必須等到這份報告完全乾淨才能進行。宣布是上線過程中唯一無法收回的步驟，而這裡的兩個阻斷性問題正是上線尚未真正發生的兩種狀態：一個任何人都無法通過的憑證，以及一個告訴搜尋引擎忘記該網站的 noindex。這兩種情況在你已經登入的瀏覽器中看起來都很正常。
如果有人要求你在阻斷性問題仍然存在時宣布，請直接說明阻斷性問題是什麼以及它會造成什麼損失，不要委婉修飾。
唯讀
此技能為唯讀操作。它會擷取正式網站、測試主機、舊主機以及重新導向對應表中的網址，並向四個公開 DNS 解析器查詢網域指向何處。它只會寫入兩項資料，而且都是操作者自己的記錄：報告套件以及其中的 watch.json。它絕不會編輯網站、提交表單、切換設定、呼叫提供者 API 或碰觸 DNS。
以下是三條規則，你在報告時必須重申：
- 每個發現都需要證據。 一個網址、一個狀態碼、一個標頭、一個 DNS 回應、一行 CSV 資料。
- 跳過不等於通過。 你沒有提供的每個輸入都會成為「未涵蓋」中的一個命名行。
- 「未涵蓋」永遠不是通過。 你必須將該區塊原封不動地重複給人類。
兩種模式
| 模式 | 時機 | 回答的問題 |
|---|---|---|
--mode cutover | DNS 轉移的那一刻，以及任何修復之後 | 上線是否真的發生 |
--mode watch | 每天一次，第 1 到 30 天 | 今天到期的項目是什麼，是否有任何偏離 |
先執行 cutover，修復它發現的問題，再次執行直到乾淨為止，然後再宣布。同一天開始監控。
1. 收集輸入
你遺漏的每個輸入都會變成一個無法執行的檢查。請一一詢問，不要猜測。
- 正式環境網址。 必要。
baseline.json— 來自pre-launch套件，或是在轉換前針對測試環境執行launch-audit所產生的。這是用來衡量「是否有任何變動」的基準。沒有它，四個檢查就無從比較，第五個檢查則會回退到--expect-analytics。所有這些檢查都會明確指出缺失。redirects.csv— 來自使用--old-url建置的launch-audit套件。每一行都會以當初寫入時的網址重新請求。- 舊網站的網址（如果要取代的話）。
- 測試環境網址，以便執行確認測試環境副本現在已被封鎖。
- 分析測量 ID，用於沒有基準的情況。
- 預期應設定的 DNS 記錄，以
apex=和www=值提供。
如果你沒有基準或重新導向對應表，請在執行前說明，而不是事後才說：它們來自前兩個階段，而轉換之後就無法再重新建立。
2. 執行轉換檢查
執行腳本；不要閱讀原始碼，也不要重新實作它所做的事情。
node scripts/post-launch.mjs --mode cutover --url <production url> \
--baseline <path to baseline.json> --redirects <path to redirects.csv> \
--old-url <old site url> --staging-url <staging url> \
--expect-analytics <measurement id> --expect-dns apex=<ip>,www=<host> --out <dir>
路徑相對於此技能自己的目錄——請從該目錄執行指令。套件會寫入目前工作目錄：如果沒有 --out，它會落在 ./website-launch/<host>-post-launch-<date>/，這在使用上述指令時意味著此技能自己的目錄內。請使用 --out 將套件寫入你想要的工作位置。
其他旗標：--dev-host <host>（可重複）、--browser auto|on|off、--out <dir>、--config <path>、--json、--help。
結束代碼： 永遠是 0，無論轉換有多糟。2 表示使用錯誤或 I/O 失敗。結束代碼為 0 絕不代表「上線沒問題」——這只是報告，不是把關。請閱讀報告內容。
3. 按此順序閱讀報告
references/reading-the-report.md 包含套件佈局。references/cutover-day.md 說明了當天執行順序的原因——在開始亂序修復之前請先閱讀。
- 阻斷性問題。 以粗體印刷，無論它們來自哪個步驟，都放在最前面。在修復這些問題之前，以及告知任何人網站已上線之前，必須先處理。
- 高優先級發現。 重新導向偏離、遺失的頁面、無效的表單端點、仍在運作的測試環境副本、仍在提供服務的舊主機——這些都是正在導致流量或諮詢流失的問題。這是今天的工作，不是本週的工作。
- 基準差異。
references/baseline-diff.md說明了哪些欄位在上線時本應變動，哪些絕不應變動。不要把整個差異都說成是損害；只報告那些沒有人要求變動的部分。 - 中等與資訊。 閱讀它們。說明它們是什麼。今天不要修復它們。
- 未涵蓋，逐字照錄。 每一行，未經編輯，包括兩個爬蟲無法看到的項目。
然後重新執行，並持續重新執行直到阻斷性問題消失。
4. 處理六項人工項目
它們會在每次執行結束時列出，而且不是可選的：
提交 Sitemap（Search Console 和 Bing） · 為熱門頁面請求索引
確認新的 Search Console 屬性 · 即時驗證分析工具
保持舊主機在線並啟用重新導向 · 僅在此項乾淨後才宣布
絕不要替別人打勾。「端點回傳 200」不等於「有人收到了測試提交」，而「標籤存在於 HTML 中」也不等於「即時出現了點擊」。
5. 每天執行監控
node scripts/post-launch.mjs --mode watch --url <production url> --day <n>
它會列出逾期項目、今天到期的項目以及未來七天即將到期的項目，然後重新執行自動化部分並記錄此次執行。references/thirty-day-watch.md 包含了完整的排程、每天在 Search Console 和分析工具中應查看的內容，以及「健康」的狀態定義，這樣正常的發布後流量下降就不會被報告為災難。
如果省略 --day，它會從第一次執行開始計算天數。如果某天監控從未執行，該天的自動化任務會持續標示為逾期，直到有執行涵蓋該日；人工任務則會持續標示為逾期，直到有人手動清除，因為腳本無法證明有人打開了 Search Console。
6. 第 30 天
有兩件事需要處理，而且都不是自動化的：
- 回顧檢討。 哪些地方退步了、重新導向對應表遺漏了什麼、應該在
pre-launch閘門中加入哪些項目，以免下次上線重蹈覆轍。請記錄下來。 - 舊主機決策。 只有在 Search Console 顯示不再抓取舊網址並且重新導向已生效至少三十天後，才能停用舊主機。在兩項條件都滿足之前，請繼續為它付費。過早關閉它會浪費舊網站所累積的所有連結。
7. 呈現結果
以決策為開頭，而不是數字統計。
- 裁決。「轉換有一個阻斷性問題」或「轉換乾淨順利」。一句話。
- 阻斷性問題，並說明修復方式。
- 正在流失的項目，按原因分組：高優先級發現，用白話說明。
- 與基準相比未被要求的變動。
- 未涵蓋，逐字照錄。
- 人工項目，說明哪些已完成、哪些未完成。
- 是否可以宣布上線。 明確說明可以或不可以。
兩個永遠不會執行的檢查
- 文案與原始文件比對。 沒有人比較正式頁面上的文字與最終確認的文案。必須由人親自閱讀兩者。
- 頁面與約定範圍比對。 沒有人知道哪些頁面本來應該存在。從未被建立的頁面在這裡是完全看不見的。
參考文件
| 檔案 | 涵蓋內容 |
|---|---|
references/cutover-day.md | 當天的有序腳本，以及每個步驟為什麼排在該位置 |
references/thirty-day-watch.md | 排程、在 Search Console 和分析工具中應讀取的內容、健康狀態的定義、舊主機規則 |
references/baseline-diff.md | 每個差異欄位，哪些變動在上線時是預期的、哪些不是 |
references/reading-the-report.md | 套件結構、嚴重性等級、ID、如何分類處理 |
這個技能的位置
pre-launch 在部署前對儲存庫進行閘門檢查和阻斷。launch-audit 爬取測試或正式網址並產出報告。post-launch 就是這個：轉換以及之後的三十天監控。請按順序執行它們——這個技能所需的基準和重新導向對應表只能由前兩個技能產生，而且只能在舊網站仍在線時進行。