Closed Token Layer
Architecture 3 couches de tokens CSS variables conçue pour empêcher les LLM de fabriquer des valeurs hardcodées. Couche 1 (foundation) = primitives (couleurs brutes, échelles spacing). Couche 2 (semantic) = tokens contextuels (color-bg-primary, spacing-md). Couche 3 (component) = tokens scope composant (button-padding-x). Les agents AI lisent UNIQUEMENT la couche semantic, couche 1 et 3 sont fermées à la consommation directe. Cas Atlaskit (Atlassian) : 418 valeurs hardcodées → 0 après migration vers closed token layer. La même fermeture se pose aussi à deux étages plus bas que la convention. Dans le CSS : Tailwind v4 permet d'effacer toute une famille de valeurs par défaut (`--color-*: initial`, ou `--*: initial` pour le thème entier), si bien que seules tes valeurs produisent une classe. Dans les types : StyleX, la bibliothèque de styles de Meta, laisse un composant déclarer les propriétés et les valeurs qu'il accepte (un `marginTop` limité à 0, 4, 8 ou 16), et l'éditeur signale l'écart au lieu de le laisser passer. Aucun des deux n'est étanche : la documentation de StyleX prévient elle-même que TypeScript peut laisser passer des propriétés en trop, d'où le linter en dernier filet.
Forces
- Mesurable : tu comptes les valeurs hardcodées avant/après, chiffre de gain clair pour stakeholders
- Backward-compatible : tu peux migrer composant par composant sans bloquer les équipes
- Réduit aussi la dérive humaine, bénéficiaire au-delà des agents AI
Limites
- Refactor initial coûteux pour un DS mature : 2-4 semaines de migration token par token
- Couche component (layer 3) ajoute du verbeux : `--button-padding-x` au lieu de `--spacing-md`
Pour qui
- Design system mature (≥50 composants) qui voit ses tokens fabriqués par agents AI ou humains
- Équipe qui ouvre Claude Code / Cursor à grande échelle et veut un garde-fou architectural, pas comportemental