驗證 UI
建構畫面只是第一步。UI 變更尚未完成，直到它已在真實瀏覽器中驅動，且其螢幕截圖已附在 PR 中。乾淨的型別檢查、靜態分析執行與單元測試套件表示程式碼能編譯且邏輯正確。但它們都無法說明面板是否渲染，或頁尾是否位於設計所指定的位置。從未執行該分支的審查者只能依據螢幕截圖來評斷工作，或者根本無法評斷。
1. 在真實瀏覽器中，使用真實資料驅動它
使用一個帶有真實（種子資料）資料庫的執行中應用程式，而不是模擬資料，也不只是快樂路徑的螢幕截圖。遍歷設計中每個命名的狀態，以及那些未命名的狀態：
- 兩種主題。 手寫顏色是深色模式變體容易被忽略的地方。
- 行動裝置與桌面裝置。 佈局會在斷點處重新排列，且頁尾和工具列可能導致一半內容孤立。
- 空狀態、載入狀態、達到限制狀態與失敗狀態， 而不僅僅是有資料的狀態。
- 每個交接點，其中一個對話框或視圖關閉，另一個開啟。
- 開啟你新增的每個選單、彈出面板與下拉選單。 一個你從未開啟的選單，看起來與一個開啟時會導致頁面當機的選單完全一樣。
- 在操作過程中檢查瀏覽器主控台與網路面板是否有錯誤。
2. 執行審查掃描
根據儲存庫所使用的設計與框架準則（設計系統、無障礙性、框架最佳實踐）來審查變更。如果你的代理可以產生子代理，請在較便宜的模型上並行為每個準則執行一個審查者。這是模式比對的工作，而非判斷工作。
- 提供審查者儲存庫自身的規則。 一個未閱讀這些規則的審查者會將已記錄的決策回報為違規。
- 要求他們僅回報。 然後根據真實世界的機率自行判斷每個發現。拒絕那些對於不同產品而言可能為真的發現，例如針對一個最多只有十幾行的清單所提出的虛擬化建議。
3. 為 PR 擷取螢幕截圖
不是螢幕的描述：而是螢幕本身。擷取它們也是捕捉你實際上尚未看過的狀態最便宜的方法。
- 驅動真實的應用程式。 使用一個能到達每個狀態的一次性瀏覽器腳本是可行的。使用 E2E 測試工具組的種子輔助工具來到達 UI 流程無法產生的狀態，然後在圖片產生後刪除該腳本。它不進行任何斷言，也不是測試覆蓋率。
- 在擷取前重新建置。 否則你可能會為你剛剛修復的錯誤拍攝螢幕截圖。
- 在快門前等待動畫完成。 「可見」會在元素被佈局時解析，而不是在其進入轉場結束時，因此一個簡單的擷取會顯示帶有半透明背景的半透明對話框。等待有限動畫完成（過濾掉無限動畫，例如骨架屏的脈衝效果），並設定超時時間。
- 盡可能以使用者會使用的方式到達每個狀態。 強制設定標誌會跳過可能暴露錯誤的競爭條件。
- 將它們提交到
docs/screenshots/<topic>/目錄，如果有的話，放在它們所實作的設計旁邊。 - 使用提交 SHA 而非分支來引用它們， 例如
https://github.com/<org>/<repo>/blob/<sha>/<path>?raw=true。分支 URL 會在分支被合併刪除時失效，並且會使 PR 中充滿損壞的圖片。
無可用的瀏覽器
如果環境確實無法執行 UI（沒有瀏覽器工具、缺少憑證、你無法控制的基礎設施），請在 PR 的「測試」區段中說明。指出是什麼阻止了它，以及你取而代之驗證了什麼。沉默會被理解為「已驗證」。
將審查修正以疊加層的方式出貨
此階段發現的修正應放在一個新的、堆疊在該功能之上的 PR 中，以便建置與審查階段可以分開審查（請參閱 stacked-prs）。
此階段能捕捉到的問題
這些問題都不是來自型別檢查器、靜態分析工具或單元測試套件：
- 一個與其頁面不符的載入骨架屏。 它為該頁面沒有的工具列顯示了骨架屏，因此每次導航都會在兩個佈局之間跳動。逐行鏡像真實佈局，否則就不要出貨骨架屏。
- 在交接時同時繪製了兩個對話框， 因為每個對話框都被掛載了，而只有其
open標誌被切換。隱藏不等於解除掛載。 - 身分錯誤的閃現： 使用者自己的行在一次繪製中提供了移除他們的選項，因為用戶端在首次渲染後才讀取工作階段。伺服器已知的身分應隨頁面一起傳遞。
- 一個錯誤的空狀態： 在查詢解析之前，「未找到結果」被渲染了一幀，因為零行同時代表了「載入中」和「空白」。
- 一個設計 Token 被替換為一個看起來相似但不同的 Token， 在其中一個主題中明顯不同。
- 一個硬編碼的標籤， 而旁邊其他四個呼叫點都從共享目錄中讀取相同的標籤。
- 一個開啟時導致頁面當機的選單， 因為某個子元件需要一個它沒有的父元件。手動點擊檢查錯過了它兩次，因為沒有人開啟該選單。
- 一個規格項目被悄然跳過， 另一個則因正當理由被刪除但未留下記錄。任何偏離設計的地方都需要附帶說明原因。
- 一個自相矛盾的對話框， 透過查看螢幕截圖發現：一則通知顯示「所有座位均已使用」，而旁邊的頁尾仍然顯示「剩餘 2 個座位」。