Verify
腳本負責抓出機械性錯誤。截圖則讓你抓出設計錯誤。每次都要做這兩件事。
執行
node ~/.config/opencode/lib/design/verify.mjs "design/Foo.html" --full --out design/.verify/foo.png
常用變化：
| 案例 | 旗標 |
|---|---|
| 投影片組，每張單獨截圖 | --each "section" --step --each-out design/.verify/deck |
| 文件，列印寬度 | --width 900 --height 1200 --full |
| 海報或固定畫布 | --width 1080 --height 1350 --full |
| 窄面板檢查 | --width 900 |
| 緩慢動畫等待穩定 | --settle 2000 |
它會在一個臨時的 localhost 連接埠上提供檔案服務，以無頭模式載入，並輸出 JSON 以及 stderr 上的摘要。Exit code 1 代表有問題。
閱讀輸出
errors— 主控台錯誤和未捕獲的例外。通常是腳本參照了不存在的元素。修正原因，不要直接壓制錯誤。failedRequests— 缺少的字型、圖片、同層檔案。缺少字型會默默 fallback，導致整個字型決策失效，所以這個項目的重要性比看起來更高。horizontalScroll— 頁面比視窗寬。在螢幕上表示出現了沒人想要的捲軸；在列印中表示內容被右邊緣切掉。從overflowing清單找出超出的元素。metrics.fontFamilies— 實際呈現的字型。如果顯示字型不在清單中，表示字型未載入，你正在審查的是 fallback 字型。images[].loaded: false— 損壞的資源或錯誤的相對路徑。metrics.nodeCount— 合理性檢查，非目標數值。
檢查 Token 使用紀律
在評斷設計之前，先檢查它是否確實使用了系統。當 tokens.css 與設計成品放在同一目錄時，驗證器會自動為你處理 tokens 部分：它會警告頁面未連結該檔案，並列出頁面自身 CSS 以及其他本地樣式表（例如 components.css）中出現的每個顏色字面值——包含 hex、oklch()、rgb() 等。
每一個命中要不是一個應該存在的 token，就是一個繞過檔案的數值。結構性 CSS（如投影片組的 scale transform、海報的 grid）合理包含 px 數值；顏色字面值幾乎從來不該出現。中性的檢視器 chrome（如投影片組的 letterbox 或文件頁面周圍的桌面）會使用命名的顏色，例如 black 和 white。
然後查看截圖
開啟檔案。依序評斷：
- 層級 — 視線是否先落在標題，再落在支援細節？瞇著眼看：如果所有元素權重相同，就沒有層級。
- 間距 — 一致的節奏，且充足。各群組之間不均等的間隙是最常見的未經考慮佈局跡象。
- 對齊 — 任何應該共用左邊緣但卻沒有的項目。
- 剪裁與重疊 — 文字觸碰到或越過邊界，元素超出其容器。
- 對比度 — 淺灰上的低灰是預設的失敗。檢查實際數值，不要相信截圖的呈現。
- 內容 — 沒有填充文字、沒有遺留的佔位文字、沒有你發明的數字。
修正並重新執行
直接從錯誤文字修正，不要重新讀取整個檔案來尋找行號。每次實質變更後重新執行。最多三輪——之後請附上誠實的備註說明仍有什麼問題，再交付。
匯出
當成品要放到不含資料夾的地方時：
node ~/.config/opencode/lib/design/inline.mjs "design/Foo.html"
這會寫出 Foo.standalone.html，並將本地樣式表複製到檔案中。也請在獨立版本上執行驗證器——因為內嵌時相對路徑和 url() 參照容易出錯。
永遠不要因為腳本 exit code 為 0 就說設計完成了。腳本不知道它看起來好不好。