Iron rule: Do not pile up interface code directly before confirming the information structure, design constraints, and text internationalization strategy.
Workflow
- Step 1: Confirm the interface goal ⚠️ REQUIRED
- 1.1 Clarify whether this is a page, component, form, or interaction detail fix.
- 1.2 Inventory the existing design language, component patterns, and state sources.
- Step 2: Do structure first, then styles ⚠️ REQUIRED
- 2.1 First clarify component responsibilities, props, events, and state boundaries.
- 2.2 Then orchestrate layout, hierarchy, and accessibility semantics.
- Step 3: Handle implementation constraints
- 3.1 Text goes through i18n by default; do not hardcode final copy.
- 3.2 Styles should prioritize design tokens, semantic class names, and maintainable structure.
- 3.3 Page-level changes should consider SEO, loading states, and empty states.
- Step 4: Do visual and interaction validation
- 4.1 Check responsiveness, keyboard accessibility, disabled states, and error states.
- 4.2 Whenever there are visual changes, it is recommended to coordinate with ui-validator for real-device verification.
Focus points
- Whether components have a single responsibility, are easy to reuse, and are easy to compose.
- Whether text, icons, colors, and contrast adapt to multiple languages and light/dark themes.
- Whether form interactions cover loading, error, empty, and success states.
- Whether style naming is stable rather than temporary patches.
Project-specific tips
- Component implementation should prioritize following , Composition API, and the existing UI component library, rather than introducing another parallel style.
- Styles should prioritize preserving the constraints of BEM, design tokens, global variables, and mixins; do not patch with !important.
- Page-level components should consider SEO metadata entry points such as useHead or definePageMeta.
- Text should go through useI18n or $t() by default; do not fall back to hardcoded copy because of schedule pressure.
Anti-patterns
- Piling complex business logic directly into templates.
- Quickly muddling through with hardcoded text, sizes, or colors.
- Only looking at desktop, not mobile or dark mode.
- Adding large areas of !important to fix a single style issue.
Pre-delivery checklist
- Structure, state, and visual responsibilities have been clearly separated.
- Text has considered i18n, and styles have considered tokens and maintainability.
- Key states and responsive scenarios have been covered.
- When there are visual changes, ui-validator verification has been planned or executed.