La comprobación final

Cada ejercicio del curso terminaba con su comprobación: los modos, la traducción al código, la accesibilidad. Esas comprobaciones miran una parte del sistema. Antes de publicarlo como versión 1.0.0, quedan tres que necesitan el sistema entero. En esta lección verás cuáles son y cómo se hacen.

En esta página

• Lo que ya has comprobado
• Cada token tiene un uso
• Cada valor tiene token
• Cada token está en todos sus sitios
• Lo que DTCG exige a un archivo
• En Figma
• Lo que te llevas

Lo que ya has comprobado

La comprobación final no repite estas listas. Si alguna quedó a medias, termínala antes:

Cada token tiene un uso

Es la comprobación de Un sistema tan grande como lo que resuelve. Mientras construías el sistema pudo quedar algún token que creaste por si acaso, o uno cuyo uso desapareció al cambiar el diseño. Antes de la 1.0.0, borrarlo no cuesta nada; después, es un cambio MAJOR (Versionar el sistema).

Lo que dice la fuente sobre cómo encontrarlos en Figma:

• La ayuda de las variables no describe ninguna forma de ver dónde se usa una variable ni de seleccionar las capas que la usan (Figma: Create and manage variables and collections).
• Library analytics mide el uso de las variables de una biblioteca, pero es de los planes Organization y Enterprise (Figma: View and explore library analytics).

En el plan Professional, la comprobación se hace con tu documentación. Para cada token semántico, busca en tu mapa de alias del módulo 3 y en tus pantallas al menos un sitio donde se use. La descripción del token te dice dónde mirar.

Un token sin uso tiene dos salidas:

• Lo borras. Es lo normal.
• Lo mantienes con un motivo escrito, en su descripción y en el registro de decisiones. DesignToken101 tiene un caso: los tokens de los mensajes de error y el fondo y el borde de los de éxito no los usa ningún componente, y se mantienen porque el juego completo de mensajes se usará más adelante (S31). Su descripción lo dice: "Sin uso todavía (S31)".

Cada valor tiene token

Es la comprobación inversa: que nada del diseño esté fuera del sistema. Un color sin variable o un texto sin estilo no cambian con los modos, y no llegan al código con su nombre (Un texto sin estilo es un valor suelto).

Lo que dice la fuente:

• Al seleccionar varias capas con rellenos distintos, el panel derecho muestra Selection colors, con los colores sólidos y los degradados de los rellenos y trazos de la selección (Figma: View and adjust colors in a mixed selection). Es la misma herramienta del inventario del módulo 1.
• Check designs busca valores sin variable y propone la variable que falta, pero es de los planes Organization y Enterprise (Figma: Check designs in Figma).

En Professional, recorre tus pantallas con Selection colors y con los paneles de propiedades: colores, espacios, radios, bordes y textos. Hazlo en las cuatro combinaciones de modos del módulo 5: un valor suelto puede pasar desapercibido en Light y verse en Dark.

Cada token está en todos sus sitios

Un token es algo más que una variable de Figma. Según su tipo, tiene que estar en varios sitios, y cada uno se crea en un paso distinto del curso:

Las dos últimas filas son del itinerario de código. Lo que dicen las fuentes sobre la capa 2:

• Un token que está en @theme da clases; uno que está en :root no (Tailwind CSS: Theme variables).
• shadcn/ui añade un token nuevo en dos pasos: lo define en :root y en .dark, y después lo expone a Tailwind CSS con @theme inline (shadcn/ui: Theming).

No todos los tokens van a la capa 2. Los primitivos de color, por ejemplo, no se exponen, para que nadie los use en lugar de un semántico (Lo que no se expone). Lo que importa es que esa ausencia sea una decisión, no un olvido.

export default defineConfig({
  tokens: ['./tokens/sistema.resolver.json'],
  outDir: './css/',
  lint: {
    rules: {
      'core/descriptions': ['error', { ignore: ['palette.**', 'spacing.**', 'corner.**'] }],
    },
  },
  // plugins: igual que antes
});

Lo que DTCG exige a un archivo

Lo que dice la fuente: DTCG pide a las herramientas que den error ante ciertos archivos (Format Module 2025.10):

• Una referencia mal escrita o que apunta a un token que no existe (Error conditions).
• Referencias circulares: un token que, de alias en alias, acaba apuntando a sí mismo (Circular references; Cadenas y referencias circulares).
• Un token cuyo tipo no se puede determinar (Type).
• Un objeto que es a la vez token y grupo (Group structure).

Estos errores se ven al pasar los archivos por una herramienta, así que son parte del itinerario de código. Si generas tu código con la normalización y Terrazzo, revisa los avisos que den y el CSS resultante, como en el ejercicio del módulo 6. En Figma, el último caso es el que más se escapa: Figma acepta a la vez …/default y …/default/hover, que en DTCG no es válido (Revisa la lista de nombres).

En Figma

Para la comprobación de usos, ten abiertos a la vez la vista Variables y tu mapa de alias, y recorre una colección grupo a grupo. Para la de valores, trabaja pantalla a pantalla: selecciona todas las capas de una pantalla y revisa Selection colors antes de pasar a la siguiente.

Fuentes

• Figma: Create and manage variables and collections
• Figma: View and explore library analytics
• Figma: Check designs in Figma
• Figma: View and adjust colors in a mixed selection
• Tailwind CSS: Theme variables
• shadcn/ui: Theming
• Design Tokens Format Module 2025.10
• Terrazzo: Lint
• Terrazzo: Getting started