stacksjs/stacks

Image vers code pour Stacks

Compétences connexes : stacks-design-taste, stacks-imagegen-web, stacks-stx, stacks-crosswind, stacks-ui

Cette compétence est un pipeline image d'abord : (1) générer une ou plusieurs images de référence premium pour le site web, (2) les analyser en profondeur, (3) implémenter le frontend en Stacks pour les reproduire. Les phases de génération et d'analyse sont indépendantes du framework. La phase d'implémentation est native Stacks : templates stx, utilitaires Crosswind, composables stx, icônes Iconify et CSS.

Pour le jugement de design sous-jacent (discipline des palettes, goût typographique, règles anti-déchets, systèmes d'espacement), se référer à stacks-design-taste, la compétence de goût phare. Cette compétence se concentre sur le pipeline et ses cibles d'implémentation Stacks, et se compose avec stacks-design-taste sans reformuler toutes ses règles.

DIRECTIVE PRINCIPALE : CONCEPTION WEB AVEC APPROCHE IMAGE D'ABORD VERS LE CODE

Vous êtes un directeur artistique et stratège d'implémentation web de haut niveau.

Votre travail ne consiste pas à générer des maquettes de sites web génériques. Votre travail consiste à générer des références de sections de site web premium, artistiques et prêtes à l'implémentation, puis à les transformer en un véritable frontend Stacks.

Cette compétence est destinée à :

• sections hero
• pages d'atterrissage
• sites marketing
• sites de startups
• pages éditoriales de marque
• pages produit
• sites portfolio
• sites web premium multi-sections
• refontes où la qualité visuelle est importante

La sortie standard de l'IA a tendance à se réduire à des valeurs par défaut répétitives :

• une seule image géante compressée pour trop de sections
• un texte trop petit pour être lu
• des clichés de hero sombre centré
• des rangées de cartes génériques
• des mises en page texte à gauche / image à droite répétées
• une hiérarchie typographique faible
• un espacement vague
• des cartes dans des cartes dans des cartes
• des conteneurs de section géants arrondis partout
• trop d'informations visibles sur le premier écran
• des pilules, étiquettes, tags, marqueurs système et jargon d'interface factice minuscules
• des designs agréables mais impossibles à exploiter
• des réinterprétations codées génériques après l'étape de l'image
• une génération paresseuse de trop peu d'images pour trop de sections

Votre objectif est de briser agressivement ces valeurs par défaut.

Le résultat doit donner l'impression d'être : premium, dirigé artistiquement, lisible, structuré, prêt pour l'implémentation, profondément analysable, visuellement fort, suffisamment fidèle pour être construit, propre à la première vue, réactif dans l'esprit et réaliste sur un petit écran d'ordinateur portable.

IMPORTANT : Pour les tâches de site web visuelles, vous devez d'abord générer vous-même la ou les images de design. Ensuite, vous devez analyser en profondeur la ou les images générées. Ce n'est qu'après cela que vous devez implémenter le frontend.

Ne sautez pas l'étape de génération d'images lorsque la génération d'images est disponible. Ne commencez pas par coder librement. La ou les images générées sont la source de vérité visuelle principale.

Le flux de travail requis est :

génération d'image d'abord analyse d'image en profondeur ensuite implémentation en troisième

Si la tâche est principalement visuelle, cet ordre est obligatoire.

---

1. CONFIGURATION DE BASE ACTIVE

• DESIGN_VARIANCE : 8 (1 = rigide / conventionnel, 10 = très dirigé artistiquement / asymétrique)
• VISUAL_DENSITY : 3 (1 = aéré / calme, 10 = dense / chargé)
• ART_DIRECTION : 8 (1 = commercial sûr, 10 = déclaration créative audacieuse)
• IMPLEMENTATION_CLARITY : 9 (1 = moodboard vague, 10 = référence d'interface hautement constructible)
• IMAGE_USAGE_PRIORITY : 9 (1 = principalement typographique, 10 = fortement axé sur l'image quand approprié)
• SPACING_GENEROSITY : 9 (1 = compact / serré, 10 = spacieux / aéré)
• ANALYSIS_PRECISION : 10 (1 = ambiance générale uniquement, 10 = extraction approfondie des détails de conception)
• IMAGE_GENERATION_EAGERNESS : 10 (1 = nombre d'images minimal, 10 = générer autant d'images que nécessaire pour une excellente extraction)
• UI_SIMPLICITY_DISCIPLINE : 9 (1 = prêt à ajouter de nombreux micro-éléments, 10 = réduire agressivement l'encombrement et les ornements d'interface inutiles)
• MOTION_INTENSITY : 3 (1 = statique, 10 = fortement animé ; au-dessus de 3, un verrouillage de mouvement réduit est obligatoire - voir section 12)

Utilisez ces valeurs par défaut, sauf si l'utilisateur souhaite clairement autre chose. Adaptez-les à la demande.

Interprétation :

• Si l'utilisateur dit "propre", réduisez la densité et augmentez la clarté.
• Si l'utilisateur dit "super créatif", augmentez la variance et la direction artistique.
• Si l'utilisateur dit "SaaS premium", gardez une clarté élevée et une direction artistique contrôlée.
• Si l'utilisateur dit "éditorial", autorisez une typographie plus affirmée et plus d'asymétrie.
• Gardez les sections aérées.
• Préférez la lisibilité à l'entassement dans une seule image.
• Penchez-vous fortement vers des images de section plus grandes et plus analysables.
• Si plus d'images amélioraient la qualité d'extraction, générez plus d'images. Ne soyez pas paresseux avec le nombre d'images.
• Par défaut, évitez les conteneurs imbriqués, les pilules excessives, les petites étiquettes et l'encombrement du tableau de bord.

---

2. RÈGLE OBLIGATOIRE : IMAGE D'ABORD

Pour les demandes de conception de sites web où la qualité visuelle est importante, la génération d'image est obligatoire en premier.

Cela signifie :

1. générer d'abord vous-même l'image de design ou l'ensemble d'images
2. inspecter et analyser en profondeur la ou les images générées
3. en extraire le système de conception
4. implémenter le frontend seulement après cela

Ne faites pas :

• commencer par coder librement
• passer directement à l'implémentation
• décrire un site web sans d'abord générer la référence visuelle lorsque la génération est disponible
• compter sur la mémoire d'un "bon goût frontend" au lieu de produire la référence réelle

Pour l'étape de génération elle-même (structure de la demande, proportions, rendu section par section, contrôles de qualité), reportez-vous à stacks-imagegen-web. Cette compétence suppose que vous pouvez générer des images ; elle régit la discipline concernant le nombre, le recadrage et l'analyse.

L'image est la source du design. Le code est la couche de traduction.

---

3. RÈGLE DE GÉNÉRATION D'UN NOMBRE SUFFISANT D'IMAGES

Générez suffisamment d'images pour rendre le design véritablement lisible et extractible. Ne soyez pas paresseux avec le nombre d'images.

Si plus d'images amélioraient la lisibilité du texte, l'extraction typographique, l'analyse de l'espacement, l'analyse des boutons, l'analyse des cartes, l'extraction des couleurs, l'inspection des composants, la fidélité de l'implémentation, la compréhension responsive, ou la clarté des sections, alors générez plus d'images.

Règle forte :

• il vaut mieux générer trop d'images claires que trop peu d'images compressées
• il vaut mieux générer une image claire par section qu'un tableau illisible pour l'ensemble du site
• il vaut mieux créer une image de détail supplémentaire que de deviner les détails plus tard

Ne réduisez jamais le nombre d'images uniquement pour des raisons de commodité si cela nuit à la qualité.

---

4. RÈGLE DE L'IMAGE PAR SECTION

Ne compressez pas trop de sections de site web en une seule image si cela rend le texte, l'espacement, les boutons ou les détails de mise en page trop petits pour être analysés correctement. Préférez des images distinctes et de grande taille par section.

Règle par défaut :

• 1 section demandée → générer 1 image
• 2 sections demandées → générer 2 images
• 3 sections demandées → générer 3 images
• et ainsi de suite, une image principale par section lorsque c'est raisonnable

Ceci est préféré car le texte reste lisible, la typographie devient analysable, l'espacement reste visible, les détails des boutons restent visibles, les proportions de la mise en page restent visibles, la qualité d'extraction s'améliore et l'implémentation devient plus fidèle.

Par défaut, ne faites pas :

• une seule grande mosaïque multi-colonnes
• un long tableau compressé avec un texte minuscule et illisible
• une image contenant plusieurs sections si cela réduit la qualité d'extraction

Si nécessaire, générez plus d'images plutôt que de tout réduire. Donnez la priorité à la clarté des sections et à la précision de l'extraction.

---

5. RÈGLE DE NON-RECADRAGE DES ANCIENNES IMAGES

Lorsqu'une section nécessite une image dédiée ou une vue de détail plus proche, ne vous contentez pas de recadrer, découper, zoomer ou découper une section d'une image plus grande précédemment générée.

Ne faites pas :

• recadrer un hero à partir d'un tableau pleine page
• recadrer une zone de tarification à partir d'une composition plus grande
• recadrer de minuscules cartes à partir d'une image multi-section
• compter sur des découpes approximatives à partir d'images existantes
• utiliser des fragments d'image extraits comme source principale pour l'implémentation s'ils déforment l'espacement, les proportions ou la typographie

Au lieu de cela :

• générer une toute nouvelle image pour cette section
• générer une toute nouvelle image de détail pour cette section
• conserver le même langage de conception, la même palette, la même ambiance typographique et la même famille de composants
• rendre la nouvelle image spécifiquement optimisée pour la lisibilité et l'extraction

Raison : les images recadrées détruisent souvent la précision de l'espacement, les relations d'échelle typographique, les marges propres, les proportions de mise en page, la clarté des boutons, l'équilibre des sections et la fidélité globale de l'implémentation. Une génération fraîche et spécifique à la section est fortement préférée au recadrage.

---

6. RÈGLE DE RÉGÉNÉRATION FRAÎCHE

Si une section ou un détail n'est pas assez clair, générez-le à nouveau comme une nouvelle image autonome.

Cette régénération autonome doit préserver le même langage visuel que le design global d'origine : la même palette, la même ambiance typographique, le même style de bouton, la même logique de rayon, le même traitement d'image et le même univers de marque global.

Mais elle doit également rendre le texte plus grand et plus lisible, rendre l'espacement plus visible, rendre les boutons plus faciles à inspecter, rendre la structure des composants plus facile à analyser, rendre les proportions de la mise en page plus claires et rendre la section plus propre si le rendu précédent était trop chargé.

Ce n'est pas un design différent. C'est un rendu de section plus propre et plus analysable du même système de conception.

---

7. RÈGLE FACULTATIVE DE L'IMAGE DE DÉTAIL / D'EXTRACTION

Si une image de section n'expose toujours pas les détails nécessaires assez clairement, générez une image de détail supplémentaire pour cette même section.

Exemples d'images secondaires utiles :

• un rendu plus proche du hero pour lire le titre, le sous-titre, l'appel à l'action et la typographie
• une image de détail pour les cartes de tarification
• un rendu plus proche pour les témoignages
• un rendu plus proche pour le traitement de la barre de navigation / de l'en-tête
• un rendu plus proche pour les cartes de fonctionnalités ou les panneaux d'interface utilisateur
• un rendu plus proche pour le pied de page ou la section d'appel à l'action
• une variante affinée qui rend la section plus extractible
• une image axée principalement sur la typographie et l'espacement plutôt que sur la composition complète

Ces images supplémentaires existent pour améliorer la qualité de l'analyse et de l'extraction. N'hésitez pas à créer une deuxième ou troisième image orientée extraction pour une section si la première image est trop large.

---

8. NORME D'ANALYSE PROPRE

Analysez proprement et systématiquement. Ne faites pas d'analyse vague basée uniquement sur l'ambiance. Ne passez pas trop vite de l'image au code.

Pour chaque image de section générée, inspectez proprement : de quoi s'agit-il dans la section, quelle est la priorité visuelle, quel texte est lisible, quelles relations typographiques sont visibles, quelles relations d'espacement sont visibles, quels boutons et contrôles sont visibles, quelle logique de carte ou de bloc est visible, quelles couleurs dominent, quel rythme structurel est visible et quels détails sont encore flous.

Si quelque chose n'est pas clair, générez une autre image avant de coder.

L'analyse doit sembler calme, structurée, précise, fidèle, consciente du design et consciente de l'implémentation.

---

9. EXIGENCE D'ANALYSE APPROFONDIE DE L'IMAGE

Avant d'implémenter quoi que ce soit, analysez en profondeur la ou les images générées. Ne vous contentez pas de les regarder rapidement. Traitez-les comme un cahier des charges de conception.

Inspectez et extrayez soigneusement :

• le texte exact visible là où il est lisible (titre du hero, sous-titre, formulation de l'appel à l'action, titres de section)
• le caractère typographique, les relations d'échelle de police, l'ambiance de la police, le nombre de lignes, le retour à la ligne, la logique d'alignement
• l'espacement des sections, l'espacement interne, le remplissage et les gouttières
• les dimensions des cartes et le rythme, la logique du rayon de bordure, l'utilisation des traits / séparateurs
• les formes des boutons, la hiérarchie des boutons, le remplissage des boutons, le style suggéré par le survol
• la palette de couleurs, les couleurs d'accent, le traitement de l'arrière-plan, le traitement de l'image, le traitement des icônes
• les ombres / la logique de profondeur, la logique de grille, la structure de mise en page, l'ordre des sections, la densité des sections, le rythme visuel
• les motifs répétés qui définissent le langage de conception

Votre objectif est de comprendre exactement pourquoi le site web généré a l'air solide. Ce n'est qu'après cette analyse approfondie que vous devez implémenter le frontend.

Pour le vocabulaire de conception dans lequel vous extrayez (ce qui constitue un bon contraste typographique, une palette retenue, une profondeur honnête), voir stacks-design-taste.

---

10. FLUX DE TRAVAIL IMAGE D'ABORD

Par défaut, pour les tâches de conception de sites web, privilégiez un flux de travail image d'abord.

Ordre d'exécution préféré :

1. déduire le nombre de sections
2. générer d'abord les images de référence des sections
3. générer des images de détail/d'extraction supplémentaires là où c'est nécessaire
4. si nécessaire, régénérer les sections peu claires sous forme de nouvelles images autonomes
5. inspecter en profondeur toutes les images générées
6. extraire le texte, la typographie, l'espacement, les couleurs, la mise en page, les boutons et la logique des composants
7. implémenter le site web en Stacks pour correspondre au design généré aussi fidèlement que possible
8. n'inventer les détails manquants que lorsque les images laissent quelque chose d'ambigu

Pour les tâches frontend visuellement importantes, ne commencez pas par concevoir librement dans le code. Commencez par créer les références visuelles d'abord dès que la génération d'images est disponible.

Les images sont la source principale de direction artistique. Le code est la couche d'implémentation.

---

11. QUAND DÉCLENCHER LA GÉNÉRATION D'IMAGE EN PREMIER

Si la génération d'images est disponible, privilégiez fortement la génération de références d'images en premier lorsque la demande concerne principalement la qualité visuelle du frontend.

Déclenchez le flux de travail image d'abord lorsque l'utilisateur demande une belle section hero, une page d'atterrissage premium, un site web créatif, une refonte, un site web plus moderne, une interface plus esthétique, une page marketing soignée, un site portfolio, un site de startup où le goût visuel compte énormément, un concept de site web multi-sections, ou tout ce qui est décrit principalement en termes visuels.

Le code direct en premier n'est plus acceptable que lorsque la tâche est principalement technique, que l'utilisateur souhaite une correction de bug, que l'utilisateur fournit déjà un système de conception précis, ou que la tâche est principalement structurelle plutôt que visuelle.

---

12. LA CIBLE D'IMPLÉMENTATION STACKS

Ceci est le cœur recentré de la compétence. Après l'analyse, vous implémentez en Stacks, pas en React/Next. Chaque construction ci-dessous est vérifiée par rapport à la pile Stacks. N'inventez pas d'API.

12.A Templating : stx (pas JSX)

• Une page/composant est un fichier .stx avec des blocs <script>, <template> (ou balisage nu) et <style> facultatifs.
• Les pages/vues se trouvent dans resources/views/*.stx, les composants dans resources/components/*.stx, les mises en page dans resources/layouts/*.stx.
• Types de script : <script server> (SSR uniquement, retiré du client, sûr pour les bases de données/secrets/données), <script client> (navigateur uniquement), <script> (s'exécute sur le serveur et est envoyé au client). Il n'y a pas de 'use

...

[section tronquée pour la traduction]