refactor(ui): Implementar Atomic Design System para componentes reutilizables

[vgpastor]

Descripcion

Reorganizar los widgets compartidos siguiendo el patron Atomic Design para garantizar coherencia visual, reutilizabilidad y escalabilidad a medida que se anaden nuevas herramientas.

Contexto

La app ya cuenta con widgets compartidos en lib/shared/presentation/widgets/ que funcionan bien, pero no siguen una jerarquia formal. A medida que crece el numero de herramientas (actualmente 27+), conviene formalizar un design system para evitar duplicacion y mantener coherencia.

Propuesta de estructura

lib/shared/presentation/widgets/
├── atoms/              # Componentes minimos e indivisibles
│   ├── severity_badge.dart
│   ├── score_chip.dart
│   ├── zone_indicator.dart
│   └── clinical_label.dart
├── molecules/          # Combinaciones de atoms con una funcion
│   ├── scored_option_tile.dart
│   ├── fluid_data_row.dart
│   ├── zone_selector_card.dart
│   └── clinical_input_field.dart
├── organisms/          # Componentes complejos y autonomos
│   ├── result_banner.dart
│   ├── scored_item_selector.dart
│   ├── tool_info_panel.dart
│   ├── fluid_resuscitation_panel.dart
│   └── body_zone_list.dart
├── templates/          # Layouts de pagina completos
│   └── tool_screen_base.dart

Niveles de Atomic Design

Nivel	Descripcion	Ejemplos actuales
Atoms	Elementos UI minimos, sin logica de negocio	Badges de severidad, chips de puntuacion, iconos de alerta
Molecules	Grupos de atoms que forman una unidad funcional	Filas de datos (label + valor), tiles de seleccion con score
Organisms	Secciones completas con logica propia	ResultBanner, ScoredItemSelector, ToolInfoPanel
Templates	Estructura de pagina que define el layout	ToolScreenBase (scaffold + result + body + info)

Enfoque de implementacion

Este refactor debe ser progresivo, no un big-bang:

1. Fase 1: Auditar widgets existentes y clasificarlos en atoms/molecules/organisms/templates
2. Fase 2: Extraer atoms comunes que se repiten en varios screens (severity colors, score badges, data rows)
3. Fase 3: Refactorizar molecules reutilizables (zone selectors, fluid rows, clinical inputs)
4. Fase 4: Documentar el design system (catalogo de componentes, parametros, uso)

Beneficios esperados

• Consistencia visual entre todas las herramientas
• Menos codigo duplicado en nuevas features
• Facilidad para mantener y actualizar estilos globalmente
• Mejor testabilidad de componentes individuales
• Onboarding mas rapido para nuevos colaboradores

Prioridad

Media - abordar de forma incremental con cada nueva feature.

Origen

Feedback interno del equipo de desarrollo.

---

🤖 Generated with Claude Code