mukulmunda41-create/new-section

Nouvelle section

Une routine courte pour une section sur un site qui a déjà ses règles. C'est l'étape de section de la compétence futuristic-web-design, empaquetée pour fonctionner seule.

Si ../futuristic-web-design/ se trouve à côté de cette compétence, ses fichiers de référence contiennent les détails. Lisez celui dont la tâche a besoin : references/design-system.md pour le vocabulaire de mise en page et l'audit de site générique, references/ship.md pour le formulaire de contact et le pass téléphone.

Si le projet n'a pas encore de fichier de règles ou de système de design, arrêtez-vous et utilisez futuristic-web-design depuis sa première phase. Une section construite sans système de design est à l'origine du rendu générique.

La routine

1. Lire les règles. Ouvrez le fichier de règles du projet (AGENTS.md, CLAUDE.md ou GEMINI.md) et les jetons du thème. Utilisez uniquement les polices et la palette définies, et la pile technologique que le projet utilise déjà.
2. Confirmer le contenu. Lorsque des faits sont importants (prix, affirmations, noms, citations), demandez. N'inventez jamais de clients, d'avis ou de statistiques pour une entreprise réelle. Ailleurs, rédigez un contenu réel et signalez les lignes que vous avez inventées. Pas de texte de remplissage.
3. Choisir une mise en page intentionnellement. Fractionnée, centrée, à fond perdu, en grille, bento ou asymétrique. Dites laquelle et pourquoi en une ligne. Évitez le défaut d'un titre centré sur trois cartes identiques : mettez un élément en avant et décalez les autres.
4. Construire un composant dans son propre fichier sous components/, ou l'équivalent du projet.
5. Vérifier à 390 px, 768 px et 1440 px dans un navigateur, et réparez ce que vous voyez. Une mise en page peut respecter toutes les règles et sembler incorrecte.
6. Faire correspondre l'espacement au-dessus et en dessous avec les sections voisines.
7. Rapporter en trois lignes : ce qui a été construit, le chemin du fichier, et ce qui nécessite l'attention de l'utilisateur (copie inventée, boutons non câblés, tout ce que vous n'avez pas pu vérifier).

Ne modifiez que la section demandée. Un diff plus large que la demande masque quelle modification a aidé.

Options de mise en page

Lorsque l'utilisateur demande des options, ou ne peut pas décrire ce qu'il veut, construisez deux ou trois variantes à partir du même contenu. Placez chacune sur sa propre route de prévisualisation (/preview-1, /preview-2, ou /before et /after pour un restylage) avec une description d'une ligne. Les gens choisissent plus facilement qu'ils ne spécifient.

Laissez la page réelle intacte jusqu'à ce qu'ils choisissent. Ensuite, supprimez les autres variantes et leurs routes, car les routes de prévisualisation restantes sont livrées avec le site.

Ce qui rend une section conçue

• Typographie. La police des titres en grande taille avec un crénage serré, la police de lecture pour tout le reste. Deux polices seulement ; les valeurs par défaut du framework telles que font-mono sur une étiquette comptent comme une troisième. Un titre de hero fait au maximum huit mots.
• Un bouton principal. Rempli, dans la couleur de bouton de la palette, lié à l'action dans le brief. Une deuxième action est un lien texte avec une flèche ou un contour discret. Deux boutons de poids égal signalent qu'aucune décision n'a été prise.
• Chaque bouton mène quelque part de réel. Si la destination est inconnue, utilisez la cible honnête la plus proche et listez le bouton comme non câblé dans le rapport.
• Surface et espace. Espaces blancs généreux, remplissages plats, bordures fines, grain ou verre optionnel. Pas de dégradés remplaçant une palette. Ombre au survol uniquement.
• Images. Servies à la taille d'affichage, chargées paresseusement en dessous du premier écran, avec un texte alternatif qui décrit l'image (« flacon de sérum ambre sur pierre pâle », jamais « image 1 »).
• Mouvement. Un fondu court et quelques pixels de déplacement vers le haut, sous 500 ms, une fois. Sous prefers-reduced-motion, rien ne bouge, y compris le défilement fluide et les transitions au survol.

La vérification à 390 px

Les téléphones représentent la plupart des visites, c'est donc la largeur qui décide si la section est terminée.

• Le texte du corps est lisible et aucun titre ne s'étend sur cinq lignes ou plus.
• Rien n'est pressé contre le bord de l'écran.
• Les cibles tactiles font environ 44 px ou plus.
• Il n'y a pas de défilement horizontal.
• La navigation se réduit derrière un bouton de menu qui s'ouvre et se ferme.
• Les cartes en ligne gardent les prix et les boutons sur la même ligne, quelle que soit la longueur du texte au-dessus. Vérifiez cela aux trois largeurs.

Section de contact

Un formulaire sans destination fait du tort, car les gens supposent que leur message est arrivé. Le modèle est une boîte aux lettres : ouverte pour le dépôt pour tout le monde, verrouillée pour la lecture pour tout le monde sauf le propriétaire.

• Champs name, email, message, sauvegardés dans une table leads dans Supabase, ou le backend que le projet utilise déjà.
• Sécurité au niveau des lignes activée : insertion anonyme autorisée, aucune lecture publique. N'enchaînez pas .select() sur l'insertion ; sans accès en lecture, cela fait échouer l'appel.
• Le code du site utilise uniquement la clé publique, chargée depuis .env.local, qui reste dans .gitignore.
• Validez avant l'envoi (format d'email plausible, message non vide) et expliquez tout rejet. Donnez des messages distincts pour le succès et pour l'échec.
• Défense anti-spam : un champ honeypot caché qui doit rester vide, plus le rejet des soumissions qui arrivent plus vite qu'une personne ne pourrait taper.
• Testez comme le ferait un visiteur : un message vide, un email mal formé, une soumission valide. Seule une nouvelle ligne dans la table prouve que cela fonctionne ; une confirmation à l'écran ne le fait pas.
• Lorsqu'une sauvegarde échoue, lisez l'erreur et corrigez la politique. Ne désactivez jamais la sécurité au niveau des lignes, car cette table contient les noms et adresses des personnes.