Un solo design system, en Web y en Flutter.
El kit de piezas del punto de venta — mismos tokens, mismos componentes, misma marca — vivo en las dos plataformas. Aquí se explica cómo funciona, se recorren los componentes por dominio, y se ven los entregables impresos.
La arquitectura en una ojeada
Todo componente cae en una capa y lleva un prefijo por paquete, así se sabe dónde nace cada pieza y no se duplica entre Web y Flutter.
| Capa | Qué es | Prefijo |
|---|---|---|
| 0 · Tokens | color, tipografía, radio, espacio, motion (fuente única) | Ds* |
| 1 · Primitivas | botón, campo, badge, card, tabla… (marca genérica) | Ds* |
| 2 · Dominio POS | mesa, ticket KDS, recibo, teclado, propina… | Pos* |
| 3 · Shells | andamiaje de navegación (riel ↔ cajón ↔ tabbar) | Ds* / Pos* |
| 4 · Pantallas | una vista concreta de una app | NameScreen |
@dockethub/ui · Flutter gdl_ui@dockethub/ui-restaurant · Flutter pos_uiDetalle completo (capas, tokens, reconciliación de enums) en el plan de paridad y la matriz.
Recórrelos por plataforma
Las dos "áreas" del mismo design system. Cada storybook está vivo: componentes reales, organizados por familia, con ejemplo, propiedades y código.
Web (React)
Flutter
Ds* + 13 de dominio Pos*, con portada, propiedades y código copiable.Los productos impresos
Formatos cerrados y listos: tickets térmicos (80 mm, ESC/POS), factura CFDI 4.0 y corte de caja Z. Generados por gdl_tickets.py + comprobantes en color tamaño carta.
Tickets térmicos · 80 mm · los 5 formatos
Comprobantes en color · carta
Documentos del carril
La fuente viva de los componentes son los storybooks y el repo (feat/design-tokens). Estos documentos explican el plan y el estado.