pre-merge-validation-gatelisted

# Pre-merge validation gate "The build passed and the unit tests are green" is not the same claim as "this works." Treating them as equivalent is the single most common way agentic work ships a real bug that automated checks structurally cannot see: a UI regression that a type-checker and a passing test suite both miss because neither one looks at a rendered screen. ## Core rule: a UI-touching change is not done until it has been driven live Build passing plus unit tests passing is necessary, never sufficient, for anything that changes what a user sees or interacts with. If there's no CI safety net on the branch you're targeting, treat your local gate as the only one that exists. Don't assume a downstream check will catch what you skipped. ## Scale the gate to the change Not every change needs the full gate. Match the check to the blast radius: | Change | Minimum required | |---|---| | Docs/config only | None of the below | | Backend-only, no client-visible behavior change | Backend test suite | | Backend change to an endpoint a client calls | Backend suite + integration/e2e suite | | Anything in the UI layer | Full suite + a live, driven check of the changed screen | | Shared/high-traffic UI chrome | All of the above + any byte-identical or snapshot fixtures that depend on it | | New or changed user-facing strings | Land in every locale in the same commit, then run the test suite (a locale-parity check, if you have one, is the only thing that catches a string landing i