Sistema de diseño — fundamentos
El sistema de diseño de TED OS está construido como una base neutral más skins por superficie. Cada superficie conserva su propio matiz e iconos; la base se mantiene neutral y reutilizable.
Base vs. skin
| Paquete | Qué |
|---|---|
@tedos/ui | La base neutral — paleta + escala tipográfica — agnóstica a iconos y acento. No lleva matiz de superficie. |
@tedos/admin-ui | El skin del admin — los tokens del admin (capa @theme), shell, primitivos components/ui, vistas de pantalla compartidas, más el Cian + HugeIcons del admin. |
El matiz de una superficie vive en su skin, nunca en la base — "un núcleo, muchos matices". La consola
añade su propia capa de tokens de tinta sobre @tedos/admin-ui. Ver
Alcance de color.
Solo tokens semánticos
Color, radio, sombra y fuente siempre vienen de tokens — nunca hex crudo en los componentes. La
capa @theme del admin expone superficies (canvas / surface / elevated / sunken), bordes,
texto, acento + tonos de estado, una escala de radio (xs … pill), sombras y los tokens de fuente.
Cuando un skin de superficie (p. ej. un cliente white-label, o la consola) sobrescribe los tokens base de superficie, debe re-declarar también los tokens alias cortos — sobrescribir solo el token subyacente deja las utilidades basadas en alias resolviendo a la base clara, produciendo contenido claro-sobre-claro. (Un incidente real; la regla ahora es parte de las convenciones.)
Sin valores de tamaño arbitrarios
Los valores de píxel arbitrarios (text-[13px], w-[820px], rounded-[10px], …) están prohibidos.
Si un tamaño necesario no existe en la escala o los tokens, eso es una decisión de diseño enrutada
al Diseñador para añadirla como token — nunca inventada en línea.
Iconos
Todos los iconos de UI usan HugeIcons (@hugeicons/react + @hugeicons/core-free-icons). Los SVG
en línea hechos a mano para iconos de UI no están permitidos. Las marcas de marca (el seed mark, el
campo de filotaxis) son la excepción — esas permanecen a medida.
Los cuatro estados obligatorios
Cada superficie interactiva entrega cuatro estados: cargando (esquelético, alineado al layout), vacío, error (en línea) y éxito. Un componente solo-happy-path está incompleto.
Vistas de pantalla compartidas
Los cuerpos de pantalla presentacionales se extraen al paquete del sistema de diseño para que cada consumidor — el admin del operador y las apps white-label de cliente — renderice la misma vista. Las vistas son datos-en-props y puras: sin obtención de datos, sin costuras de app dentro. La app anfitriona lee vía su propia costura y pasa datos + estado + hrefs de enrutamiento como props; el enrutamiento permanece en manos de la app. Esto es lo que abarata el patrón white-label de cliente (ver Comprender).
Dónde vive la fuente de verdad
La referencia exacta al píxel vive en los archivos de diseño de Paper del proyecto; la capa de tokens
y las convenciones escritas viven en el repo (knowledge/ + el paquete del sistema de diseño). En un
conflicto, la última decisión gana. Ver Grid System v2 y
Alcance de color.