product-design

# Product Design Decide what the interface should do, then route who builds and verifies it: pick the right interaction, make scope and consequence clear, cover reality beyond the happy path. - **IS:** the decision layer. From a brief, spec, mockup, intent, or existing UI: choose the interaction and control, name the object, scope, and consequence of each action, settle reversibility and the safeguard it implies, enumerate every reachable state, set resilience expectations, and require accessibility as task completion. It decides, then routes build, verification, and wording out. - **IS NOT:** - whether a feature deserves investment or fits the product: out of scope; state it as an open product question. - building or styling UI, visual direction, palettes, type: `ui-design`. - auditing the built result (rendered quality, a11y markup, keyboard, layout, performance, React or Next code-level UX with a ship verdict): `ui-design` Audit mode. - copy wording, persuasion, or AI-ism removal: `ghostwriter`. - motion, gesture physics, or deep typography: `ui-animation`, `typography-audit`. - whether an agentic feature earns trust: `ax-audit`. ## Routing boundary `product-design` owns action semantics, scope, reversibility, and contested state choices. `ui-design` builds and styles those states. `ui-animation` owns timing, gestures, and measured motion. A routine missing loading or error state stays with the UI build; a gesture replacing a control needs a product decisio...