1LunarVeil/frontend-aesthetics

Esthétique front-end

frontend-design fixe la position : s'engager vers une direction et éviter les valeurs par défaut que personne n'a choisies. Cette compétence fournit les règles de décision, les nombres, les données de précédent et les contrôles qui rendent ces choix vérifiables. Ouvrez la référence des noms d'étapes lorsque vous en avez besoin ; ne les lisez pas toutes à l'avance.

1. Lire d'abord les règles du projet

• Recherchez un brief ou un contrat avant de concevoir : DESIGN.md, PRODUCT.md, un fichier de tokens (tokens.css, theme.*, tailwind.config.*), ou un document contractuel tel que FRONTEND_CONTRACT.md. Ceux-ci priment sur les valeurs par défaut de cette compétence.
• Si le projet achemine les valeurs visuelles via des tokens, une nouvelle valeur brute hex, px ou rgba dans un composant est une découverte, pas un choix de style.
• Conservez ce qui fonctionne déjà : changement de thème, clés i18n, comportement d'accessibilité, composants existants. Restylez le périmètre demandé, pas l'ensemble de l'application.

2. Brief

Rédigez le brief décrit dans references/principles.md : sujet, public et contexte, le travail de l'écran principal, la densité, les langues, et les cinq dimensions (typographie, couleur, mise en page, animation, détails). Ajoutez trois refus : les valeurs par défaut auxquelles cette conception ne doit pas ressembler. Si l'utilisateur n'a pas décrit un goût, proposez une direction et expliquez pourquoi. N'interrogez pas l'utilisateur.

3. Précédents

Exécutez ceci depuis le répertoire de base de la compétence :

python scripts/design_lookup.py "saas dashboard dark" --ux --motion

Utilisez des mots-clés en anglais. La sortie donne le type de produit correspondant, ses styles, une palette avec des paires de texte et d'interface vérifiées pour le contraste, des associations typographiques et des règles de raisonnement. Traitez-la comme une preuve, pas une réponse. Son premier style est souvent un choix tendance (glassmorphisme, néon, bento) qui est erroné pour les outils denses. Les paires de texte échouent dans une seule des 192 lignes de palette, mais la plupart des palettes ont une bordure en dessous de 3:1 par rapport au fond, donc chaque palette doit avoir ses paires d'interface vérifiées avant utilisation.

4. Direction

Choisissez une direction dans references/directions.md, ou définissez la vôtre, et indiquez pourquoi elle correspond à ce brief et pourquoi l'alternative la plus proche ne convient pas. Mettez l'audace à un seul endroit : un élément signature. Tout autour est discipliné.

5. Tokens avant les composants

Définissez d'abord les rôles de couleur, l'échelle typographique, l'espacement, les rayons, l'élévation et les durées d'animation en tant que variables (references/color-and-type.md, references/layout-and-motion.md). Vérifiez chaque paire de texte que vous livrez :

python scripts/wcag.py "#1f2937" "#ffffff" "#556070" "#f6f7f9"

6. Construction

Couvrez tous les états, pas seulement le chemin heureux (references/components-and-states.md). Conservez le texte dans les langues du produit et testez la traduction la plus longue.

7. Vérification avant de rapporter

• Rendez-le et regardez. python scripts/visual_capture.py <url> --out shots --matrix donne les vues par défaut, à 150 %, étroite et mobile, attend un cadre stable et rapporte les erreurs console. Lisez references/visual-review.md ; une revue sans capture n'est pas une revue visuelle.
• Après un changement, capturez à nouveau et exécutez scripts/image_diff.py before.png after.png. Si la région modifiée ne correspond pas à ce que vous prétendez avoir changé, la déclaration est erronée.
• python scripts/slop_scan.py <chemins modifiés>. Le code de sortie 1 signifie des découvertes bloquantes.
• Contraste pour chaque paire de texte et d'interface que vous avez effectivement livrée (wcag.py).
• Un passage clavier uniquement, un passage à mouvement réduit, et le test de rupture avec les pires données.
• Les erreurs console sont des échecs. De même, une capture signalée comme vide est un échec ; traitez une capture signalée comme instable comme suspecte.

Lorsqu'aucun navigateur n'est accessible, écrivez « non vérifié visuellement », nommez les états que vous avez ignorés, et ne revendiquez rien sur l'apparence de l'interface rendue.

8. Rapport

Nommez la direction et la raison de ce choix, donnez le bloc de tokens, et listez chaque vérification avec sa commande et son résultat. Listez ce qui n'a pas été vérifié.

Planchers (ne jamais les échanger pour l'apparence)

• Contraste du texte d'au moins 4,5:1. Le texte large (24px, ou 18,66px en gras) et les limites d'interface ou les indicateurs de focus nécessitent au moins 3:1.
• Chaque élément interactif possède un indicateur de focus clavier visible qui diffère de son état de survol.
• La couleur ne porte jamais de sens à elle seule.
• L'animation respecte prefers-reduced-motion. Rien ne clignote plus de trois fois par seconde.
• Le texte du corps fait au moins 16px sur le web et 14px dans les interfaces desktop denses. Aucun texte en dessous de 12px.
• Chaque état existe : chargement, vide, erreur, désactivé et données partielles.
• Aucun texte fictif n'est livré. Les erreurs disent ce qui s'est passé et quoi faire ensuite.
• Le texte survit à la chaîne réaliste la plus longue : traductions, CJK, chemins longs et noms de modèles.

Règles de goût

• Un neutre dominant fait l'essentiel du travail. Un accent couvre au maximum environ 10 % de l'écran. Les couleurs de succès, d'avertissement et de danger restent fixes d'un thème à l'autre.
• Deux familles de polices au maximum, plus une police mono si nécessaire. Un seul rapport d'échelle. La hiérarchie provient de la taille, du poids, de la couleur et de l'espace avant les boîtes.
• Moins de bordures et moins de cartes imbriquées. Rayon provenant d'une seule petite échelle. Ombres teintées selon la palette, avec au maximum trois niveaux d'élévation.
• Animation : un moment intentionnel par écran, transformation et opacité uniquement, et aucune animation sur les actions répétées plusieurs fois dans une session.
• Texte : casse de phrase, verbes simples, et le même nom pour une action dans le bouton, le message de résultat et le menu.

Le test de choix

Chaque valeur par défaut (police, palette, rayon, ombre, mise en page, jeu d'icônes) doit être choisie pour ce brief. Si vous ne pouvez pas nommer la raison, changez-la. Une valeur par défaut que vous avez choisie n'est pas un marqueur. references/anti-slop.md liste les marqueurs courants et la règle du scanner qui les signale.

Fichiers

• references/principles.md : ordre de décision, modèle de brief, refus.
• references/directions.md : neuf directions avec des tokens de départ vérifiés.
• references/color-and-type.md : palettes, mode sombre, contraste, échelle typographique, chargement de polices, CJK.
• references/layout-and-motion.md : grille, densité, espacement, rayons, élévation, animation.
• references/components-and-states.md : composants, matrice d'états, texte, test de rupture.
• references/desktop-app.md : règles pour les applications WebView et desktop.
• references/anti-slop.md : marqueurs, pourquoi ils sont interprétés comme des valeurs par défaut, questions à poser, identifiants de règle du scanner.
• references/critique.md : procédure de révision, neuf piliers, sévérité, format de sortie.
• references/visual-review.md : comment rendre, capturer, lire et re-différencier l'interface.
• references/sources.md : d'où vient chaque règle et ce qui a été délibérément écarté.
• scripts/wcag.py, scripts/design_lookup.py, scripts/slop_scan.py, scripts/visual_capture.py, scripts/image_diff.py : en lecture seule, sans packages tiers, sans réseau. Utilisez py -3 si python n'est pas dans le PATH.
• data/ : données CSV sous licence MIT provenant de ui-ux-pro-max (voir data/PROVENANCE.md).