Vivelebacon/demo-website

Demo website (Site de démonstration)

Un cycle fait passer un prospect de « oui, j'aimerais voir ça » à un redesign en ligne et une réponse qui attend dans les brouillons. L'utilisateur colle une URL ou un nom ; tout le reste est trouvé, pas demandé. La direction créative est déléguée pour tout le cycle : ne vous arrêtez pas pour des réponses d'entretien ou des approbations.

Build de référence : une fois que vous avez livré une démo dont vous êtes satisfait, gardez-la comme référence. Lisez son fichier BRIEF.md et copiez sa structure (site.css, site.js, pages.css, home.css, home.js, lab/) comme squelette de départ. Ne copiez jamais son design : la porte d'empreinte (fingerprint gate) l'interdit.

Règles fixes pour chaque démo

• Conserver : le logo, chaque photographie, chaque mot de copie, chaque page et l'ordre des sections dans chaque page. Les fautes de frappe restent. Les libellés de navigation restent. Les libellés d'appel à l'action (CTA) restent.
• Changer : tout ce qui est visuel. Mise en page, typographie, utilisation des couleurs, mouvement, interaction.
• Chaque page est reconçue, pas seulement l'accueil. Un fichier HTML par page originale, mêmes slugs (cleanUrls garde /services fonctionnel).
• Ajouts autorisés : uniquement le microcopie UI minimale (lignes de statut de formulaire, placeholder d'entrée, labels aria). Pas de nouveau texte marketing, pas de chiffres inventés.
• Les règles maison l'emportent sur toute référence (éditez cette liste selon votre goût) : palette claire avec l'accent du client, logo de la marque + photo du propriétaire + tous les services visibles dans le héros, en-tête collante toujours visible, clic sur le logo retourne en haut (défilement fluide sur la page d'accueil), pas de rail latéral, pas de tirets cadratins (em dash) visibles nulle part, uniquement les photos propres du client (pas de génération sauf demande explicite de l'utilisateur).
• Déployer sur Vercel en production et commit sans demander. Les emails sont uniquement des brouillons.

Étape 0 · Identifier le prospect

1. Si l'utilisateur a donné un nom, pas une URL, et que vous conservez un CRM : recherchez le prospect là-dedans pour le site web, la ville, la langue, la boîte mail d'où est partie la prospection et l'état de la réponse. Si le prospect n'est pas dans un CRM, travaillez à partir de l'URL et ne demandez rien ; l'étape de brouillon indiquera quelle boîte mail est nécessaire.
2. Slug : la racine du domaine, par exemple acmecoaching. Dossier de build : demos/<slug>-scrollcraft/. Projet Vercel : <slug>-redesign. URL de la démo : https://<slug>-redesign.vercel.app (trait d'union, jamais de point : un sous-domaine pointé n'existe pas, et un lien mort est l'erreur la plus coûteuse de ce pipeline).
3. Prénom pour l'email : à partir de la signature email du prospect, de la page à propos/contact du site, ou du domaine (« janecoaching » → Jane). Si vraiment inconnu, laissez-le de côté (« Bonjour, » / « Hi, »).

Étape 1 · Capturer l'intégralité du site existant

Tout va dans <build>/_src/ (ressources brutes) et <build>/lab/ (notes, captures).

1. Récupérez la page d'accueil et lisez les liens de navigation et de pied de page pour lister chaque page. Récupérez chaque page.
2. Extrayez par page, dans l'ordre : sections, titres, paragraphes (avec les spans en gras/italique), listes, boutons et leurs cibles, images (URL en pleine résolution ; pour Squarespace ajoutez ?format=2500w, pour Wix supprimez la transformation /v1/fill/...), formulaires (libellés des champs, indicateurs obligatoires, libellé du bouton d'envoi, message de succès), vidéo intégrée. Squarespace conserve les définitions de formulaire dans data-block-json / formFields.
3. Téléchargez le logo (toutes les variantes : sombre, clair, favicon), chaque photo, chaque texture. Vectorisez un logo géométrique simple en SVG avec cv2.findContours + approxPolyDP sur son canal alpha ; conservez le PNG pour les marques complexes.
4. Tokens de marque : accent/encre/fond à partir des variables CSS du site, polices de titres et de corps. Choisissez la police Google la plus proche lorsque la police est Typekit ou personnalisée.
5. Captures d'écran plein écran de chaque page en ligne (scripts/full.mjs <live-url> 1440 900 lab/live <pages>) et lisez-les : c'est la structure que vous devez conserver.

Étape 2 · Concevoir avec scroll-craft

Chargez votre compétence de recherche de conception si vous en avez une, puis scroll-craft (https://github.com/nateherkai/scroll-craft), et suivez scroll-craft de bout en bout avec ces remplacements :

• Le brief est auto-rédigé sous délégation créative explicite (l'instruction permanente de l'utilisateur est cette compétence). Écrivez BRIEF.md avec : les règles fixes ci-dessus, les preuves de l'étape 1, les huit sujets rédigés, une grammaire nommée avec des contraintes réelles, la courbe de sensation (feeling curve), le pic unique, la phrase « dis-le à quelqu'un » (tell-someone sentence), le mouvement signature (signature move), le tableau de scores, et un court plan pour chaque page intérieure.
• Exécutez la porte d'empreinte (fingerprint gate) contre votre espace de travail scroll-craft FINGERPRINTS.md (4 sur 6 contre chaque ligne). Lisez la ligne « Ce que le prochain build doit éviter » de chaque ligne récente. Le mouvement signature doit venir de cette marque (sa géométrie de logo, son slogan, sa propre photo), pas du dernier build.
• La structure est fixée par le client, donc la grammaire et les dispositifs changent la façon dont les mêmes sections se comportent, jamais les sections qui existent.
• Moteur vanilla (scrollcraft.js/.css copié sans modification), HTML multi-page simple, JavaScript local à la page pour les scènes sur mesure.

Étape 3 · Construire

• Partagé : site.css (tokens, en-tête, menu, pied de page, boutons, cadres, entrées), site.js (monte le moteur, état de l'en-tête, menu, logo vers le haut, entrées, formulaire), pages.css pour les pages intérieures, home.css/home.js pour les scènes sur mesure de l'accueil.
• L'échafaudage des pages intérieures à partir d'un script unique est acceptable ; ensuite, les fichiers HTML sont la source. Dites-le dans BRIEF.md.
• Formulaires de contact : transfert mailto: vers l'adresse du client avec method="post", validation, et une ligne de statut qui indique clairement que l'application de messagerie s'ouvre et que rien n'est envoyé tant que l'utilisateur n'appuie pas sur Envoyer. Ne simulez jamais un succès.
• Boutiques et outils de réservation : lien vers les pages de produits/réservation existantes du client.

Pièges qui ont déjà coûté un cycle

• Ne jamais définir position sur un élément [data-sc-stage]. Le moteur le rend sticky ; position: relative dans votre CSS tue silencieusement chaque épingle.
• Le pic doit conserver le plus grand data-sc-span de la page. Si le héros grandit, faites grandir le pic avec lui.
• Héros en couches à partir d'une seule photo : tracez chaque silhouette avec un chemin de bord DP (d'abord un gradient grossier, puis affinez sur le fin), reconstruisez chaque plaque sous la silhouette suivante (ciel : dégradé vertical ajusté ; brume lointaine : couleur plate par colonne ; pentes texturées : tuile miroir ~110px), nettoyez les taches sombres restantes au-dessus des lignes tracées, puis regardez la position de défilement finale : les coutures n'apparaissent qu'à la fin du trajet.
• Détourages de personne : rembg u2net_human_seg, érodez le masque d'environ 2px et décontaminez les couleurs de bord, sinon le mur d'origine apparaît comme un halo. Recadrez là où un plan d'avant-plan ou une bande de base cache la découpe.
• Tout ce qui a white-space: nowrap dans une grille casse les mises en page sur téléphone ; laissez les boutons passer à la ligne en dessous de 520px et utilisez minmax(0, 1fr).
• Les blocs de décoration inclinés débordent de la fenêtre sur les téléphones : overflow-x: clip sur leur section.
• Une image remplacée conserve ses anciens octets sur les téléphones pendant une semaine (en-tête de cache /assets) : les nouvelles illustrations reçoivent un nouveau nom de fichier (-v2).
• .prose p { margin: 0 } bat .prose > * + * ; écrivez la règle d'espacement comme .prose > * { margin: 0 } .prose > * + * { margin-top }.

Étape 4 · Vérifier

Servez localement (node <scroll-craft>/scripts/serve.mjs --root . --port 4610) et utilisez scripts/snap.mjs / scripts/full.mjs de cette compétence. Les deux résolvent playwright-core depuis le dossier où vous les exécutez ou tout dossier parent, donc un npm i playwright-core à la racine du projet couvre chaque build en dessous.

• Bureau 1440x900 à plusieurs positions dans chaque acte épinglé, téléphone 390x844 et 360x640, mouvement réduit. Lisez chaque page ; corrigez et reprenez les captures.
• Captures plein écran de chaque page intérieure à 1440 et 390 : pas de débordement, pas de texte tronqué, pas de cellules de grille vides.
• Harnais scroll-craft : pas de défilement mort, pas d'erreurs dans la console, pas de requêtes échouées.
• Contraste du texte sur les images mesuré sur les pixels composites (cachez le texte, lisez les pixels en dessous) ; corps 4.5:1, grand 3:1.
• Fonctionnel : l'interaction signature de bout en bout, les messages de validation du formulaire, l'ouverture du menu/Escape/focus, le logo vers le haut, les ancres des services du héros.
• Grep le build pour les tirets cadratins et demi-cadratins (U+2014, U+2013) : zéro visible.

Étape 5 · Livrer

1. vercel.json : cleanUrls, buildCommand: null, outputDirectory: ".", cache de 7 jours sur /assets. .vercelignore : lab/ _src/ node_modules/ BRIEF.md.
2. vercel link --yes --project <slug>-redesign puis vercel deploy --prod --yes.
3. Test de fumée sur l'URL exacte que vous enverrez : chaque page retourne 200, les ressources clés retournent 200, lab/ et BRIEF.md retournent 404, un chargement de navigateur en direct sans erreurs console.
4. Dépôt Git dans le build (git init -b main), commit avec -F <file> (jamais une chaîne here-string PowerShell), gh repo create <github-user>/<slug>-redesign --private --source . --push, vercel git connect --yes. Modifications ultérieures : commit et push sur main, qui redéploie. Gardez le dépôt de démo privé : il contient le logo, les photos et la copie du prospect.
5. Ajoutez la ligne d'empreinte à votre espace de travail FINGERPRINTS.md (toutes les six dimensions, monde, port, palette, type, ce qu'il partage, ce que le prochain build doit éviter).

Étape 6 · Rédiger le brouillon de réponse

python scripts/draft_demo_reply.py <prospect-email> --mailbox <alias> --url https://<slug>-redesign.vercel.app --first-name <FirstName>

Il vérifie que l'URL répond, trouve le dernier email du prospect dans la boîte de prospection, rend le modèle « voici la démo » dans la langue du contact (--lang fr|en) avec la signature de cette boîte, enregistre un brouillon enfilé dans le dossier Brouillons de cette boîte et le relit. Il n'envoie jamais. Exécutez-le avec --dry-run d'abord si quelque chose dans le fil semble inhabituel. Les boîtes mail sont configurées dans .env (voir .env.example).

Lorsque le prospect a répondu depuis une autre adresse que celle à laquelle vous avez écrit (une boîte personnelle au lieu de info@), passez-la avec --to <their-address> : la réponse est recherchée à partir de cet expéditeur et le brouillon lui est destiné. Certains serveurs IMAP ne correspondent à une recherche FROM que sur l'adresse complète ; un fragment de domaine ne retourne rien.

Avec un CRM connecté (DEMO_CRM_DIR, voir le README), <prospect-email> peut être tout ce que le CRM résout, la boîte mail et la langue proviennent du contact, et le script enregistre la réponse du prospect et l'URL de la démo.

Affichez le texte du brouillon dans le message final. Dites à l'utilisateur de dire quand il est envoyé afin que la démo puisse être marquée comme envoyée.

Rapport final (court)

URL en direct (l'URL exacte) · pages reconstruites · l'idée de conception en deux lignes · le mouvement signature en une · les quelques ajouts de microcopie · ce qui a été vérifié et ce qui ne l'a pas été (téléphone réel, Safari) · le brouillon (boîte mail, fil, texte complet) · chemin local du dossier de build.