frontend-ttdlisted

# Frontend TTD Use test-driven design (TTD) to make a frontend change observable before calling it complete. TTD here means: define the design intent and user-visible acceptance criteria, exercise the UI in a real browser, inspect screenshots, and turn discovered regressions into durable automated coverage. Browser automation is evidence, not a substitute for judgment. A passing DOM assertion does not prove that the layout is usable or visually correct; a screenshot does not prove that the interaction works. Use both where applicable. ## Start with a design contract Before changing UI, locate existing design principles in the brief, design system, product documentation, component library, CSS tokens, or nearby screens. Summarize only the principles that govern the requested change. If no usable principles exist, tell the user and offer these choices: 1. provide principles or a design reference; 2. let the agent propose a concise, project-specific set for approval; or 3. allow the agent to infer provisional principles from the codebase and label them as assumptions. Do not silently invent a brand identity, visual direction, or product requirement. When an urgent implementation must proceed, infer the smallest defensible contract from existing UI and record what needs confirmation. A useful contract covers hierarchy, spacing and alignment, typography, color and states, responsive behavior, accessibility, and any relevant content rules. Convert it into observable criteri