tastecheck-passlisted

# TasteCheck Pass Give finished frontend work an honest **SHIP** or **HOLD** decision. Run the checks on the real artifact, put the verdict first, and turn every failure into a concrete next action. Files, intentions, and checkmarks are not execution evidence. ## The answer the user sees Lead with this compact release brief: ```markdown # HOLD — 2 blockers What passed: <one-line scope> Ship blockers: TC-04 keyboard trap; TC-11 dark-theme contrast Fastest path: fix TC-04 → rerun keyboard path → fix TC-11 → remeasure pair Evidence: <ledger/report links> ``` Use **SHIP** only when every applicable row passes. Use **HOLD** when a required check fails, could not run, lacks a real artifact, or lacks evidence. Never make the user infer the verdict from a table. ## Evidence table Create one authoritative row per applicable check: `skill`, `check_id`, `status`, `reason`, `remediation`, `evidence`, and `provenance`. `n/a` means the named subject is absent; it never means “not tested.” Keep measurements and skip reasons in this table. The release brief links to the rows instead of paraphrasing them into softer claims. ## What to check, in order 1. Direction: `design-system-interview` (new) or `improve-existing-website` (existing). 2. Foundations: `color-system`, `web-typography`, `spacing-system`, `theming`. 3. Structure/behavior: `responsive-layout`; `component-states`, `form-ux`, `empty-states`. 4. Surface: `micro-motion`, `data-viz`, `art-direction` where subject exists. 5.