Files

T

AyronSantos 12d419de7c feat: comprehensive design system overhaul

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

2026-06-23 16:58:12 +00:00

3.3 KiB

Raw Blame History

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)

3.3 KiB Raw Blame History