Taste Engine — routeur de style

Que fait Taste Engine — routeur de style ?

Un processus universel, de nombreux goûts indépendants — avec anti-slop, SEO public conditionnel et animation optionnelle alignée sur le style. Taste Engine contrôle quand demander, quel pack de style sélectionné charger, et comment l'appliquer. Le moteur lui-même n'a pas d'esthétique prédéfinie. Les packs de style dans styles/*.md contiennent les instructions de conception réelles.

Fidélité matérielle (styles sélectionnés) — contrat au niveau de la capture d'écran

Les esthétiques visuelles sélectionnées doivent être reconnaissables depuis l'interface rendue, pas seulement énoncées dans les titres ou les noms de variables CSS. Lorsque glassmorphism est sélectionné, chargez styles/glassmorphism.md et appliquez sa porte de fidélité matérielle Glass obligatoire : de vrais panneaux givrés/teintés visibles filtrant une lumière d'arrière-plan différenciée, des reflets/bords lisibles, et un repli accessible. Un héros bleu plat plus un CTA bleu n'est pas du Glassmorphisme. Utilisez tests/glassmorphism-visual.md pour les vérifications d'acceptation et examples/glassmorphism/frosted-surfaces.css comme recette de départ. N'appliquez pas cette vérification spécifique au verre à d'autres styles ; chaque esthétique conserve ses propres exigences.

Exception de dégradé spécifique au Glassmorphisme

Lorsque le Glassmorphisme est sélectionné, les dégradés CSS intentionnels en arrière-plan, les champs de lumière ambiante et les formes de couleur douces contrôlées sont explicitement autorisés car ils rendent le givrage translucide et la profondeur visibles. Ne les supprimez pas pour satisfaire les avertissements généraux anti-slop sur les dégradés. Lisez styles/glassmorphism.md (« Exception explicite de dégradé d'arrière-plan ») et validez que la première fenêtre d'affichage montre un vrai panneau filtrant son arrière-plan différencié. Cette exemption s'applique uniquement au matériau sélectionné et ne remplace jamais la convivialité, la véracité, l'accessibilité ou les contraintes de l'utilisateur.

Invocation automatique : le contrat sans commande

• Ceci est une compétence déclenchée par tâche, pas un workflow uniquement par commande oblique. Les agents installés qui prennent en charge les compétences d'agent autonomes doivent découvrir les métadonnées ci-dessus pour les demandes de portfolio, site web, application, tableau de bord, page d'atterrissage et refonte UI — même lorsque l'utilisateur ne dit jamais « taste-engine ».
• Une fois invoqué, appliquez le Contrat d'invocation automatique avant tout code UI. La plateforme réelle décide si la compétence est invoquée ; ce fichier ne peut pas créer un hook au niveau du système d'exploitation ni garantir la conformité sur chaque hôte.
• Sélection de style implicite : « construis-moi un site portfolio » → posez UNE question de style concise, puis terminez le tour. Ne demandez jamais à l'utilisateur des détails non liés dans le même tour.
• Sélection de style explicite : « construis un site portfolio dans le style skeumorphsm » → normalisez la faute de frappe en skeuomorphism, lisez styles/skeuomorphism.md, et construisez. N'exécutez pas le menu de questions.
• Projet établi : une configuration de projet approuvée ou une marque/style documenté l'emporte sur les valeurs par défaut génériques pour le travail incrémental ; n'interrompez pas avec un menu.
• Pas de travail frontend : implémentation d'API, débogage de logique métier, migration de base de données, infrastructure, tâches de rédaction uniquement → ne lancez pas le sélecteur de style.

Compagnon d'ingénierie — conditionnel et conscient du framework

Une fois la question de style visuel résolue (ou ignorée pour les systèmes existants/travail non visuel), appliquez le Routeur d'ingénierie. Chaque UI web obtient la porte universelle Qualité d'interface web ; React/Next bénéficie de Performance React et éventuellement Composition React uniquement lorsque la pile et la tâche les justifient. Le travail React Native/Expo bénéficie de Mobile natif, pas du SEO web. La motion de navigation peut utiliser Transitions de vue après vérifications de compatibilité, ou Anime.js optionnel lorsque vraiment utile. Les tâches de rédaction de documentation bénéficient de Rédaction de docs sans sélecteur de style visuel.

Ce sont des intégrations originales locales, pas des plugins Vercel importés. Elles résument les pratiques d'ingénierie apprises de la recherche amont. Ne supposez jamais que les compétences amont sont installées, n'exigez jamais React, ne déployez jamais sans intention de déploiement explicite, et ne laissez pas les conseils techniques écraser l'esthétique de l'utilisateur. Les éléments principaux de prévol, héros plein écran, SEO, anti-slop et motion consciente du style restent inchangés. Voir tests de routage d'ingénierie.

Héros plein écran — obligatoire lorsque pertinent

Après la sélection de style, pour tout nouveau portfolio public, page d'atterrissage ou page d'accueil avec un héros, chargez le Contrat de héros plein écran. Par défaut, une composition en-tête + héros d'un écran visible : utilisez min-height: 100svh (avec repli 100vh) sûr pour mobile et soustrayez la hauteur réelle de l'en-tête en flux normal, ou utilisez un héros pleine hauteur lorsque l'en-tête le recouvre. N'appliquez pas 100vh aveuglément : les hauteurs fixes peuvent couper le texte et les fenêtres d'affichage mobiles modifiées par la barre d'outils. Gardez le contenu et le CTA utilisables sur les écrans étroits/courts ; permettez la croissance naturelle et le défilement en zoom/texte grand. Suivez les directives ## Composition du héros (première fenêtre d'affichage complète) du style sélectionné et les vérifications anti-slop partagées. N'inventez pas d'images, de badges, de statistiques fictives ou de mouvement en boucle juste pour remplir l'écran.

Cette règle n'impose pas un héros marketing dans les tableaux de bord privés, formulaires, espaces de travail d'application ou modifications incrémentales qui ne créent/redessinent pas le héros. Un choix explicite de l'utilisateur pour un héros compact ou pas de héros prévaut. Aucune question de sélection de style supplémentaire n'est nécessaire lorsque le style est déjà établi.

Moteur de mouvement Anime.js v4 — optionnel et conscient du style

Pour les demandes explicites de micro-interactions UI, ou lors de la construction d'un style sélectionné qui bénéficie réellement d'un mouvement supplémentaire, chargez Adaptateur de moteur de mouvement et les directives ## Motion du style choisi. Le mouvement ne devient jamais un nouveau sélecteur esthétique, et n'exige jamais un second entretien. Une demande comme « Tambahkan micro-interaction di dashboard ini » préserve le style de projet existant et fonctionne sans question de style. Si le projet n'a pas de langage de design sélectionné et que l'utilisateur construit une nouvelle UI, la prévol d'une question originale reste obligatoire.

Aucune installation automatique de dépendances. Inspectez d'abord la pile existante. Préférez les capacités CSS/natives du navigateur pour les transitions simples ; ne considérez Anime.js v4 que lorsqu'il simplifie significativement le mouvement coordonné ou a été explicitement demandé. Pour React/Next, utilisez createScope() + nettoyage du cycle de vie ; pour les utilisateurs préférant moins de mouvement, désactivez les effets non essentiels tout en gardant les interactions fonctionnelles. Ne forcez pas les rebonds, boucles ou décalages gratuits. Le mappage de style se trouve dans styles/motion-profiles.json ; la recette React dans examples/react/anime-v4-press.jsx. Les applications non web/natives doivent utiliser leurs API de mouvement de plateforme à la place.

SEO inter-style : automatique et conditionnel

Le SEO n'est pas un choix de style. Pour un site web public nouveau ou substantiellement redessiné (portfolio, page d'atterrissage, blog, site web professionnel public, documentation publique ou pages produit publiques), chargez Intégration SEO et, si nécessaire, Recettes d'implémentation SEO après la sélection de style visuel. Appliquez le SEO technique + le contenu anti-slop à chaque style choisi, sans demander « voulez-vous du SEO ? » comme seconde question. Le SEO ne modifie jamais l'esthétique matérielle sélectionnée.

• Style explicite : « Construis un portfolio Skeuomorphism » → lisez styles/skeuomorphism.md + references/seo.md, pas de question de style, puis implémentez.
• Style manquant : « Construis un site portfolio » → posez exactement une question de style et arrêtez-vous. Après la réponse, chargez le style + SEO et implémentez. Ne contournez pas la prévol simplement pour écrire des métadonnées.
• SEO uniquement : « Audite le SEO de mon site web » / « corrige les URLs canoniques et le sitemap » → lisez immédiatement le module SEO, aucun entretien de style visuel et aucune refonte non sollicitée.
• Application privée/interne : préservez la confidentialité et l'indexabilité existante ; ne générez pas de sitemap public et ne révélez pas de routes privées. Les tâches mobile natif/uniquement backend sont hors du champ SEO web ordinaire.
• Domaine inconnu : ne fabriquez pas d'URLs en direct, de paternité, de données structurées, d'avis ou de contenu de page ; implémentez en toute sécurité la sémantique/titre et rapportez ce qui reste en attente.

SEO et style partagent les portes FLOOR / REFLEX / FINISH ; la confidentialité, le contenu véridique, l'accessibilité et le comportement fonctionnel priment sur l'esthétique et les préférences de recherche. Voir scénarios d'acceptation SEO. La compétence autonome optionnelle taste-seo est pour les installations SEO uniquement ; les utilisateurs du routeur n'ont pas besoin de l'installer séparément.

Exigence stricte : prévol avant toute nouvelle implémentation visuelle

Pour les tâches qui introduisent ou redessinent substantiellement l'UI visuelle, n'écrivez pas de code UI, ne générez pas de maquettes d'interface, et ne modifiez pas les jetons de design jusqu'à ce que la direction visuelle soit résolue.

1. Examinez la demande actuelle de l'utilisateur, la marque/système de design existant du produit, et une configuration de style de projet explicitement approuvée.
2. Si un style est déjà explicitement sélectionné (par exemple, « tableau de bord brutaliste »), ne demandez pas à nouveau. Confirmez-le en une ligne courte si utile et chargez ce pack de style.
3. Si le projet existant a un style clairement établi et que l'utilisateur demande des modifications incrémentales, préservez-le ; n'interrompez pas avec un nouveau choix. Une demande de refonte peut remplacer le style établi.
4. Sinon, posez exactement une question concise de sélection de style et arrêtez-vous. Proposez 6 choix contrastés et « Plus de styles / Personnalisé / Envoyer une référence ». Ne sélectionnez pas silencieusement un style, ne commencez pas à coder en attendant une réponse, et ne posez pas un entretien à questions multiples.
5. Lorsque l'utilisateur répond, résolvez l'ID du style via le registre, lisez uniquement le(s) pack(s) sélectionné(s), dérivez les jetons/décisions spécifiques au projet, puis exécutez. Un adjectif ou une référence fourni par l'utilisateur peut nécessiter l'interprétation des caractéristiques du style au lieu de forcer un préréglage.
6. Si un exécuteur d'outil ne peut pas faire de pause pour une entrée utilisateur, signalez la sélection non résolue et ne fabriquez pas de consentement. Une instruction explicite d'utiliser un meilleur effort autonome par défaut peut autoriser un style provisoire ; marquez-le comme provisoire et réversible.

Première question obligatoire (exemple en indonésien)

Avant de commencer la conception, quel style visuel souhaitez-vous ?

1. Clamorphe — doux, tactile, profondeur subtile
2. Verremorphe — transparent, en couches, moderne
3. Brutalisme — typographie audacieuse, grille brute, contraste élevé
4. Néobrutalisme — couleurs vives, bordures et ombres dures
5. Minimalisme — propre, simple, axé sur le contenu
6. Suisse / Éditorial — grille de précision, typographie dominante Ou tapez autre, personnalisé, ou envoyez une référence.

Adaptez-vous à la langue de l'utilisateur. Gardez une question unique ; décrivez les distinctions sans en déclarer une « meilleure ». Pour les menus longs, présentez d'abord les six plus un moyen de voir les options restantes. Si l'utilisateur veut des exemples, montrez les options avant de sélectionner. Si l'utilisateur demande un sélecteur interactif et que l'agent le prend en charge, présentez les mêmes choix sous forme de contrôles UI.

Packs de style disponibles

Lisez styles/registry.json lors de la correspondance des IDs, alias, fautes d'orthographe courantes, et descriptions. Normalisez la ponctuation, les traits d'union et la casse ; respectez les mentions de style niées (« pas de glassmorphisme ») et le contexte. Lorsque disponible, python3 scripts/style_probe.py --prompt "..." peut fournir une indication de style déterministe ; l'interprétation sémantique et le contexte du projet prévalent toujours. N'appelez pas une compétence de style autonome par son nom : lisez le fichier local styles/<id>.md sélectionné, qui fait partie de ce routeur installé. Packs intégrés :

ID	Direction	Fichier à charger une fois sélectionné
claymorphism	Tactile sculpté	pack de style
glassmorphism	En couches translucide	pack de style
brutalism	Structuré brut	pack de style
neo-brutalism	Audacieux ludique	pack de style
minimalism	Clarté sobre	pack de style
swiss-editorial	Grille typographique	pack de style
bento	Tuiles modulaires	pack de style
skeuomorphism	Métaphore de contrôle physique	pack de style
retro-terminal	Esthétique console	pack de style
enterprise	Workflow/données d'abord	pack de style

Personnalisé est de première classe : si l'esthétique choisie n'est pas dans le registre, rassemblez une courte référence ou des contraintes, puis créez une définition de style provisoire spécifique au projet en utilisant les mêmes dimensions. N'étiquetez jamais le style comme un pack non présent. N'exigez pas d'accès Internet externe pour choisir.

États du routeur

• needs-selection : Nouveau travail visuel ; aucune direction choisie/confirmée. Posez une question de style et arrêtez-vous.
• ready : Style ou marque existante explicitement établi ; chargez le pack pertinent et implémentez.
• refine : Petit changement dans l'UI existante ; préservez le style, modifiez uniquement les jetons/composants nécessaires.
• custom : L'utilisateur choisit un mélange, fournit des captures d'écran ou demande un style non spécifié ; mappez aux mêmes dimensions de design et ne confirmez que l'ambiguïté conséquente.
• non-visual : Backend, tests, docs, corrections de bugs sans décision visuelle ; ignorez complètement la sélection de design.

Règles détaillées de routage, mélanges et conflits : routeur de style. Pour la découverte autonome, les alias de style, les limites de l'hôte et les transcriptions d'exemples exacts, voir invocation automatique.

Application du style après sélection

1. Extrayez les exigences : produit, public, appareil, framework, marque existante, goûts/dégoûts explicites, accessibilité, performance.
2. Chargez uniquement le pack sélectionné (plus les références partagées si nécessaire). Ne mélangez pas de règles aléatoires à partir de packs non sélectionnés.
   • Style ≠ anatomie : dérivez le flux produit et le contenu de la page des objectifs réels de l'utilisateur, tandis que le pack sélectionné détermine le matériau visuel. Avant de coder, assurez-vous que les objectifs de contenu de l'utilisateur sont clairs. Ne remplacez pas le contenu réel par des espaces réservés esthétiques.
   • Respectez les seuils de fidélité du pack : chaque pack de style peut définir des contrôles de qualité spécifiques (par exemple, le Glassmorphisme exige un vrai effet de verre visible). Exécutez les vérifications de fidélité matérielle du pack sélectionné.
3. Appliquez les principes anti-slop : pas de dégradés génériques, pas de héros gonflés, pas de motifs décoratifs sans signification, pas de contenu de remplissage, pas de fausses données. Chaque élément doit avoir un but.
4. Implémentez la composition UI en utilisant la grille de base du style, les traitements de surface, la typographie et les valeurs spatiales.
5. Ajoutez le SEO pour le travail public ; intégrez les métadonnées, la structure sémantique, les données structurées si applicable, sans modifier l'esthétique visuelle.
6. Animez uniquement si cela correspond à la demande et au style ; utilisez les transitions natives du navigateur par défaut, Anime.js v4 uniquement lorsque clairement bénéfique.
7. Validez par rapport au contrat de fidélité du pack et aux vérifications d'ingénierie partagées. Ne déployez pas si la capture d'écran ne correspond pas au matériau promis.
8. Documentez les décisions : enregistrez les détails du pack chargé, les décisions d'ingénierie, et si un style provisoire a été utilisé.

Vérifications finales : FLOOR / REFLEX / FINISH

Toute implémentation doit passer par trois portes avant de terminer :

• FLOOR (Qualité minimale) : L'interface ressemble-t-elle visuellement au matériau promis ? Le contenu est-il réel (pas de remplissage) ? Le SEO est-il appliqué pour le travail public ? Les animations améliorent-elles sans distraire ?
• REFLEX (Cohérence) : Le style est-il appliqué de manière cohérente dans toute l'interface ? Les exceptions sont-elles justifiées ? La pile technique correspond-elle au projet ?
• FINISH (Complétude) : Toutes les exigences de l'utilisateur sont-elles satisfaites ? Le code est-il propre, commenté si nécessaire, et prêt pour la prochaine étape (examen, déploiement) ?

Les détails de chaque porte sont dans références/flux-qualite.md.

Intégration références locales

Ce fichier (SKILL.md) sert de point d'entrée. Sa puissance provient des fichiers locaux dans ce même dépôt :

Chemin	But
styles/<id>.md	Packs de conception de style individuels
references/engineering-router.md	Routage d'ingénierie après sélection de style
references/web-interface-quality.md	Porte de qualité d'interface web universelle
references/react-performance.md	Optimisations de performance React/Next
references/react-composition.md	Directives de composition React
references/native-mobile.md	Mobile natif (RN/Expo)
references/view-transitions.md	Transitions de vue de navigation
references/seo.md	Intégration SEO pour sites publics
references/seo-implementation.md	Recettes SEO concrètes
references/hero-layout.md	Disposition héros plein écran
references/motion-engine.md	Moteur d'animation Anime.js v4
references/style-router.md	Routage de style détaillé
references/auto-invocation.md	Découverte et contrat d'invocation
tests/engineering-routing.md	Tests de routage d'ingénierie
tests/seo-routing.md	Tests de routage SEO
tests/glassmorphism-visual.md	Tests de fidélité visuelle Glassmorphisme
examples/glassmorphism/frosted-surfaces.css	CSS de surfaces givrées
examples/react/anime-v4-press.jsx	Recette d'Anime.js React
styles/motion-profiles.json	Mappage des profils de mouvement de style
styles/registry.json	Registre d'ID de style avec alias
scripts/style_probe.py	Sonde de style Python optionnelle (si disponible)

Anti-slop : le garde-fou central

Le « slop » est une sortie générique produite sans décision de conception intentionnelle. Le Taste Engine traite le slop comme un bug : tout ce qui ressemble à une UI générique « bootstrap sans âme » ou une page « template startup » stylée sans choix esthétique est échoué à la porte FLOOR. Les panneaux de contrôle spécifiques sont :

• Dégradés non intentionnels : sauf explicitement autorisé par le matériau sélectionné (ex. Glassmorphisme).
• Héros sans substance : un héros plein écran sans contenu réel, rempli de fausses statistiques ou d'images d'archives.
• Décorations vides : lignes, formes, ou motifs sans signification.
• « Lorem ipsum » ou données fictives : le contenu factice est interdit ; utilisez le contenu réel de l'utilisateur ou une structure de squelette appropriée avec des indications claires.
• Typos sans âme : polices système par défaut sans hiérarchie typographique intentionnelle.
• Effets de survol gratuits : animations qui n'ont pas de but fonctionnel ou d'orientation.

Détection et correction : références/anti-slop.md.

Instructions finales à l'agent

1. N'écrivez jamais d'abord et n'ajustez pas le style après. La sélection de style vient toujours avant le code UI significatif.
2. Respectez la règle d'une question : un seul tour de style. Pas d'entretien à choix multiples. Pas de « au fait, préférez-vous X ? » plus tard.
3. Un pack de style sélectionné est une loi de conception. Ne le diluez pas avec des extras non sélectionnés.
4. Le SEO est automatique pour le travail public. Pas une réflexion après coup.
5. Le mouvement est optionnel et conscient du style. Pas de rebonds, de boucles ou d'effets inutiles.
6. Ne fabriquez pas de consentement : si vous ne pouvez pas demander, signalez-le.
7. Préférez la pile native : utilisez ce que le projet a déjà ; n'installez pas automatiquement Anime.js ou React si le projet utilise vanilla JS.
8. Documentez toujours les décisions de style et d'ingénierie pour la traçabilité.

Bon design. Créez quelque chose d'intentionnel.