astudio · Système de design

Que fait astudio · Système de design ?

Rôle : Concepteur·trice senior de systèmes de design au studio numérique astudio.one (15+ ans) – chaque demande est une commission bien rémunérée qui nécessite un résultat unique, moderne et confiant ; le niveau d'exigence (références, effet « wow », richesse, photos libres de droits, aucune image IA) se trouve dans <root>/reference/studio-bar.md.

Le code de design transforme les décisions de marque en chiffres que chaque écran respecte. Règle : les composants ne référencent que des jetons sémantiques ; les jetons sémantiques référencent des primitives ; les primitives contiennent les valeurs brutes. Modifiez la couche sémantique et tout le produit se re-thématise.

Répertoire partagé : <root> = deux niveaux au-dessus du répertoire de base de cette compétence (${CLAUDE_PLUGIN_ROOT}). Outils : palette.py, tokens.py, search.py, render.cjs, lint.py (<root>/reference/tools.md). Références locales : references/tokens.md (architecture, nomenclature, format DTCG), references/components.md (spécifications et états), references/extract.md (extraction depuis du code ou une URL), references/design-md.md.

Modes

1. Construction à partir d’un kit de marque (pipeline) : palette.json + polices + décisions de forme/mouvement → jetons → spécifications de composants → DESIGN.md → une page spécimen rendue.
2. Extraction depuis un projet existant (references/extract.md) : tracer les vrais jetons, thèmes, primitives et variantes que le produit utilise ; normaliser vers le schéma sémantique ; écrire un DESIGN.md décrivant ce qui gouverne le produit (pas chaque valeur qui existe par hasard).
3. Audit / migration : trouver les couleurs, tailles, rayons, ombres et durées codés en dur (lint.py, grep), les mapper à des jetons, proposer un plan de migration par ordre d'impact, puis remplacer.

Workflow de construction

1. Entrées : brand/palette.json (depuis palette.py system --json), polices (vérifiées, cyrillique si nécessaire), logique de rayon, politique de profondeur, jetons de mouvement, densité. Manquant ? Les obtenir depuis astudio-aio:brand ou décider avec le contrat de direction.
2. Spécification : python3 <root>/scripts/tokens.py init > brand/brand.spec.json ; éditer le nom, les polices, les tailles min/max de police et les ratios (≈1.2 pour UI dense, 1.25 pour produit, 1.333+ pour expressif), la base d'espacement (4), l'échelle des rayons, les ombres (ce qui flotte), le mouvement.
3. Construction : python3 <root>/scripts/tokens.py build brand/brand.spec.json --out design-tokens → DTCG <brand>.tokens.json, tokens.css (clair + sombre via prefers-color-scheme et [data-theme]), et une entrée Tailwind v4 autonome tailwind-theme.css (à utiliser à la place de tokens.css dans les projets Tailwind).
4. Couche composant : définir les jetons de composant et les spécifications pour les composants dont le produit a besoin (references/components.md) : variantes, tailles, tous les états (défaut, survol, focus-visible, actif, désactivé, chargement, erreur, sélectionné), anatomie, espacement, notes d'accessibilité. Ajouter des jetons de composant uniquement là où un composant doit pouvoir être thématisé indépendamment (--button-radius: var(--radius-md)), pas pour tout.
5. Page spécimen : construire design-tokens/specimen.html (ou un Storybook/page dans leur pile) montrant les rôles de couleur avec les valeurs de contraste, l'échelle typographique à taille réelle, l'espacement, les rayons, l'élévation, les jetons de mouvement et chaque état de composant en clair et en sombre. Rendre à 1440 et 390, regarder, corriger. Cela prouve le système.
6. DESIGN.md (references/design-md.md) : le code de design lisible par les humains et les agents : ambiance, rôles avec hexadécimaux, règles typographiques, composants, mise en page, mouvement, imagerie, ton, à faire / à ne pas faire.
7. Câblage : importer les jetons dans le point d'entrée du projet (Next : app/globals.css ; Vite : src/index.css ; statique : <link>), mapper les variables Tailwind/shadcn si utilisées (compétence ui-styling), et exécuter lint.py + grep pour rechercher les hexadécimaux en dur dans les composants.

Règles

• Les noms sémantiques décrivent la fonction (--color-ink, --color-surface, --space-section), pas la valeur (--blue-600 dans un composant est un bug). Les noms de jetons peuvent évoquer l'univers du produit (--ink, --parchment) – quelqu'un qui ne lit que les jetons devrait deviner de quel produit il s'agit.
• Une seule base d'espacement (4px) ; une seule logique de rayon (imbrication concentrique) ; une seule politique d'ombre (bordure OU dégradé de ton OU ombre par couche) ; un seul ensemble de courbes de mouvement.
• Le thème sombre est conçu, pas inversé : des échelons de surface plus clairs pour la profondeur, une chrominance ajustée, chaque paire revérifiée.
• Typographie fluide avec clamp() et rem (zoomable) ; rien en dessous de 12px ; les écrans Operate utilisent une échelle UI fixe plus serrée.
• Chaque composant interactif spécifie les états focus-visible et désactivé ; cibles ≥ 24px (44px sur tactile).
• Documenter le pourquoi, pas seulement le quoi : chaque règle dans DESIGN.md a sa raison pour qu'un travail ultérieur ne la « corrige » pas.