Introduction

La source actuelle des jetons vit dans tokens/core.tokens.json. npm run tokens:build utilise Style Dictionary pour générer assets/css/generated/tokens.css; Hugo regroupe ce fichier généré avant assets/css/site.css, donc le site actif lit ses variables de fondation depuis la sortie des jetons.

Utilisez Architecture des jetons pour le modèle technique canonique : propriété de la source, collections de thèmes, artefacts générés, consommateurs et validation. Cette page demeure l’introduction au niveau des fondations.

Groupes actuels#

Les pages de référence par catégorie sont générées depuis data/brand/tokens.yml, qui est généré depuis les métadonnées des jetons dans tokens/core.tokens.json. Les pages Markdown décident seulement de l’URL, du titre et du contexte environnant.

Source DTCG et alias#

Chaque entrée source utilise $value et $type, les champs du format DTCG. Les métadonnées du site kind et visibility ajoutent la gouvernance : kind classe l’intention d’un jeton sans calculer sa valeur, tandis que visibility définit s’il fait partie de l’API publique de rédaction.

Une valeur comme "{color.palette.signal-orange}" est un alias. Style Dictionary préserve cette chaîne dans le CSS généré parce que outputReferences: true est activé. Les alias sémantiques fournissent les variables que les auteurs doivent utiliser; les primitives de palette restent la couche d’implémentation.

API publique#

Les jetons color.palette.* ont visibility: internal. Ils restent dans le CSS généré afin que les alias sémantiques puissent se résoudre, mais ne paraissent pas dans le tableau de référence public ni dans le thème Tailwind généré. Le tableau affiche la valeur résolue de chaque alias public pour rendre la relation vérifiable.

scripts/token-data.mjs résout les alias avant de calculer les contrastes WCAG. La vérification accepte les valeurs hexadécimales et oklch(), puis les tests bloquent les références inconnues et les cycles.