AyronSantos
12d419de7c
Applied impeccable design critique, audit, harden, layout, distill, and polish across all pages. DESIGN SYSTEM: - Created PRODUCT.md (5 design principles, WCAG 2.1 AA target) - Created DESIGN.md (34 color tokens, 6 radius scale, full component spec) - Created .impeccable/design.json (sidecar with tonal ramps, shadows, motion) ACCESSIBILITY: - 33 aria-labels across 7 pages (was ~13) - 63 <label> elements (was ~30) - 6 <main> landmarks + role=navigation on all sidebars - Esc to close modals on 4 pages - Keyboard shortcuts (Ctrl+J/K, Ctrl+F) on chat THEMING: - 216 hardcoded colors replaced with var() references - 449 !important removed from dark-mode.css - Dark mode script unified (was duplicated 9x inline) - All modals converted to .modal-overlay + .modal design system classes CHAT: - Error states for messages (.msg.erro, .msg.enviando) - Connection status indicator - Confirmation modal before finalizar - Input bar reorganized (3 visible actions, + menu) - Right panel accordions - Send button disabled when empty - Touch targets 44px on mobile CLIENT DETAIL: - Tabs/badges/sub-tabs use CSS classes instead of inline styles - 'Iniciar Conversa' button now primary action - alert() replaced with inline feedback - Modal converted to design system classes CLIENT LIST: - Modal moved inside <body> (was HTML-invalid) - alert() replaced with inline feedback - Modal uses .show pattern SETTINGS: - 4 modals converted to design system classes - 14 alert() calls replaced with inline feedback - fecharModal() uses classList instead of style.display ROUTES: - border-radius normalized, hardcoded colors fixed Score progression: Chat: 23 → 32/40 Client List: 32 → 35/40 Client Detail: 26 → 30/40 Settings: 29 → 35/40 Routes: 37 → 38/40 Audit (project): 14/20 → 17/20
70 lines
3.3 KiB
Markdown
70 lines
3.3 KiB
Markdown
# Extract Flow
|
|
|
|
Identify reusable patterns, components, and design tokens, then extract and consolidate them into the design system for systematic reuse.
|
|
|
|
## Step 1: Discover the Design System
|
|
|
|
Find the design system, component library, or shared UI directory. Understand its structure: component organization, naming conventions, design token structure, import/export conventions.
|
|
|
|
**CRITICAL**: If no design system exists, ask the user directly to clarify what you cannot infer. before creating one. Understand the preferred location and structure first.
|
|
|
|
## Step 2: Identify Patterns
|
|
|
|
Look for extraction opportunities in the target area:
|
|
|
|
- **Repeated components**: Similar UI patterns used 3+ times (buttons, cards, inputs)
|
|
- **Hard-coded values**: Colors, spacing, typography, shadows that should be tokens
|
|
- **Inconsistent variations**: Multiple implementations of the same concept
|
|
- **Composition patterns**: Layout or interaction patterns that repeat (form rows, toolbar groups, empty states)
|
|
- **Type styles**: Repeated font-size + weight + line-height combinations
|
|
- **Animation patterns**: Repeated easing, duration, or keyframe combinations
|
|
|
|
Assess value: only extract things used 3+ times with the same intent. Premature abstraction is worse than duplication.
|
|
|
|
## Step 3: Plan Extraction
|
|
|
|
Create a systematic plan:
|
|
|
|
- **Components to extract**: Which UI elements become reusable components?
|
|
- **Tokens to create**: Which hard-coded values become design tokens?
|
|
- **Variants to support**: What variations does each component need?
|
|
- **Naming conventions**: Component names, token names, prop names that match existing patterns
|
|
- **Migration path**: How to refactor existing uses to consume the new shared versions
|
|
|
|
**IMPORTANT**: Design systems grow incrementally. Extract what is clearly reusable now, not everything that might someday be reusable.
|
|
|
|
## Step 4: Extract & Enrich
|
|
|
|
Build improved, reusable versions:
|
|
|
|
- **Components**: Clear props API with sensible defaults, proper variants for different use cases, accessibility built in (ARIA, keyboard navigation, focus management), documentation and usage examples
|
|
- **Design tokens**: Clear naming (primitive vs semantic), proper hierarchy and organization, documentation of when to use each token
|
|
- **Patterns**: When to use this pattern, code examples, variations and combinations
|
|
|
|
## Step 5: Migrate
|
|
|
|
Replace existing uses with the new shared versions:
|
|
|
|
- **Find all instances**: Search for the patterns you extracted
|
|
- **Replace systematically**: Update each use to consume the shared version
|
|
- **Test thoroughly**: Ensure visual and functional parity
|
|
- **Delete dead code**: Remove the old implementations
|
|
|
|
## Step 6: Document
|
|
|
|
Update design system documentation:
|
|
|
|
- Add new components to the component library
|
|
- Document token usage and values
|
|
- Add examples and guidelines
|
|
- Update any Storybook or component catalog
|
|
|
|
**NEVER**:
|
|
- Extract one-off, context-specific implementations without generalization
|
|
- Create components so generic they are useless
|
|
- Extract without considering existing design system conventions
|
|
- Skip proper TypeScript types or prop documentation
|
|
- Create tokens for every single value (tokens should have semantic meaning)
|
|
- Extract things that differ in intent (two buttons that look similar but serve different purposes should stay separate)
|
|
|