ui-craft

The craft rules for screens. This is not a command anyone types: it attaches itself to any session doing UI work — because a path the repo pinned on its paths floor is being touched, or because the judgment net caught a change a user will see or feel — and it stays attached for the whole task. Waiting to be asked is the failure mode; UI work that starts without these rules running has already gone wrong.

The rules come in two strengths (ADR 0003), and the difference is not politeness:

• Hard gates are pass/fail. A failing gate blocks the work from being called done and fails QA later.
• Advice is a starting point. The repo's design system, or a better-reasoned call on the spot, replaces it without ceremony.

Hard gates

Walk all six before calling UI work done — each one checked, each one passing, unless the repo's config documents a gate exception for it (see Precedence). A failing gate is unfinished work, not a taste disagreement.

• Text contrast meets WCAG AA (normal and large text) against its actual background
• Every interactive element is reachable by keyboard, with visible focus while navigating
• Motion respects the reduced-motion setting: nothing essential is animation-only
• Animations use only compositor-friendly properties (transform and opacity)
• Touch targets are at least 44x44 px, or have that much hit area
• No horizontal overflow at a 320 px viewport width