Forge de site

Site Forge

<execution_context> La phase 0 détermine le mode :

• auto (rapide) : Faites-en le plus possible vous-même. Après l'unique validation du plan (phase 3), exécutez jusqu'au bout sans demander. Utilisez uniquement les médias que vous pouvez créer gratuitement (jina ; MCP/Higgsfield si présent). Si une étape bloque, nécessite une interaction ou échoue — ignorez-la, continuez, listez-la dans « Ignoré / à améliorer plus tard » à la fin. Privilégiez la livraison.
• full (meilleure qualité) : Interactif. Demandez dès qu'un choix modifie significativement le résultat et utilisez les meilleurs médias gratuits, même s'ils nécessitent l'utilisateur (Google/Gemini pour les images, Veo 3.1 Fast in Flow pour la vidéo — transmettez-leur les invites exactes, ils génèrent, déposez les fichiers). Une étape bloquée → demandez à l'utilisateur d'intervenir.

Les deux modes :

• 🟢 Auto : explorez l'environnement, concevez, écrivez le code, extrayez des images, exécutez ffmpeg, prévisualisez localement et déployez après approbation.
• 🟡 DEUX points de contrôle obligatoires dans les deux modes : (1) le plan de la phase 3 avant la construction, et (2) le déploiement lui-même — demandez immédiatement avant chaque déploiement, à chaque fois. L'approbation pour un déploiement n'est jamais une approbation pour le suivant. Par défaut, prévisualisation locale.
• 🔴 Jamais : inventez des identifiants/clés factices ; publiez des affirmations que l'utilisateur a signalées comme non vérifiées sans avertissement ; saisissez les secrets de l'utilisateur dans des formulaires. </execution_context>

0. Choisissez le PROFIL avant toute autre chose. Lisez references/design-profiles.md et énoncez-le en une ligne : « Profil : creative-portfolio. Plafond de taille d'affichage flexible, interdiction des empattements, plancher de voile, mobilier de conversion. Plancher artisanal inchangé. » Le défaut est local-service ; creative-portfolio couvre les photographes, designers et artistes ; personal-agency est celui d'Adam. Le profil décide quelles règles esthétiques d'Adam sont en vigueur — le plancher artisanal ne plie jamais, donc corps en 16 px, contraste 4,5:1, zones tactiles de 44 px, mouvement réduit, schéma, les seize balises sociales et les en-têtes de sécurité s'appliquent quoi que fasse la consigne ou un site de référence. Se tromper de profil produit un site d'artisan portant les photos d'un portfolio.

1. Lisez references/page-composition.md en premier (c'est la différence entre une page qui semble conçue et une qui semble vide), puis invoquez frontend-design avant tout balisage (installé → utilisez-le ; sinon lisez references/frontend-design.md — la compétence complète, incluse textuellement, vous bénéficiez ainsi de ses conseils complets même hors ligne).

2. Invoquez design-taste-frontend. Énoncez sa lecture de design en une ligne (« Lecture en tant que : pour , avec un langage … ») et réglez les trois curseurs. Utilisez les paramètres par défaut et préréglages du skill de goût. La seule exception : son déverrouillage de mouvement perpétuel à MOTION_INTENSITY > 5 reste désactivé — pas de pulsation, scintillement, flottement, machine à écrire ou boucles infinies. Ignorez sa section sur la pile React/Tailwind pour les builds statiques.

3. Impeccable est déjà en cours d'exécution : son hook se déclenche à chaque écriture. Ses commandes sont le point de contrôle de la phase 7.

Ensuite, utilisez references/aesthetics.md comme aide à la dérivation du thème/police/mise en page. C'est la barrière anti-bâclé et le plus grand levier de qualité. Engagez une direction audacieuse et spécifique à la consigne :

• Une esthétique claire, exécutée avec précision ; un appariement de polices distinctif (jamais Inter/Roboto/Arial) ; une palette cohérente sous forme de variables CSS.
• La structure — quelles sections, quelle hiérarchie, le moment mémorable unique — dérivée de la consigne. Ne réutilisez pas la forme du dernier site.
• Quelles capacités correspondent et lesquelles laisser de côté (voir la carte de référence). Une consigne simple peut n'utiliser aucun des effets lourds ; un projet phare peut en utiliser plusieurs. Rédigez un brief design de 3 à 5 lignes à intégrer au plan.

Le hook d'Impeccable se déclenche à chaque écriture. Résolvez ses constatations au fur et à mesure, pas en tas à la fin — chacune est soit corrigée, soit explicitement classée comme faux positif avec une raison énoncée. Ne désactivez jamais une règle en ligne pour éviter de la corriger ; la suppression nécessite la confirmation d'Adam. Après environ 6 modifications, il se tait pour éviter le bruit, c'est pourquoi l'audit de phase 7 est un point de contrôle matériel distinct.

Page unique vs multi-page. Une page unique est livrée sous forme d'un seul index.html. Une consigne avec des publics distincts ou une profondeur réelle (un site d'entreprise avec des sections patient / médecin / tarifs / à propos, un site marketing avec une page Science) mérite à la place un ensemble multi-page — des fichiers *.html séparés partageant une même structure. Sans étape de build, les blocs partagés sont copiés à la main, donc la dérive est un vrai bug : gardez le <head> (incluant l'extrait de thème sans FOUC), la nav, le footer et les balises <script> identiques octet par octet sur chaque page, et vérifiez par hachage avant le déploiement — une page qui diverge silencieusement (polices différentes, interrupteur manquant, lien mort) est l'échec classique. Donnez à chaque page son propre canonical/og:url + <title>/description, générez un sitemap.xml + robots.txt, et noindex toute page privée/mockup d'application. Si le nombre de pages ou la taille des blocs partagés rend la copie manuelle fragile, une petite étape d'inclusion (concaténation Node, ou Eleventy/Astro) est un compromis acceptable — mais uniquement lorsque la consigne le justifie ; par défaut, pas de build.

Ensuite, trois vérifications mécaniques, qui ont toutes déjà détecté des défauts livrés :

python3 <skill>/scripts/audit-seo.py        # SEO, SEO local, sécurité. exit 1 si HIGH
python3 <skill>/scripts/check-crops.py      # object-fit:cover éliminant le sujet
python3 <skill>/scripts/colour-system.py    # un traitement par photographie, à l'échelle du site

Et cliquez sur chaque élément interactif dans un vrai navigateur, en vérifiant un changement d'état. Une FAQ, une barre de filtres et un panneau cartographique ont tous été livrés avec un balisage complet, du CSS complet et aucun gestionnaire du tout : rien ne paraît cassé dans le source. Utilisez document.elementFromPoint au centre du contrôle, pas .click(), qui ignore les tests de cible et réussit sur un contrôle complètement enfoui.

Si quelque chose semble saccadé, TRACEZ-LE, ne l'échantillonnez pas. performance_start_trace puis défilement puis performance_analyze_insight("ForcedReflow") nomme la fonction incriminée par fichier et ligne. L'échantillonnage de la fréquence d'images a une variance de plus ou moins dix points et vous enverra après la mauvaise chose. Voir scroll-performance.md.

Vérification de la pile de design — obligatoire, avant le déploiement, sans exception :

1. /impeccable critique (revue UX) puis /impeccable audit (a11y, perfs, responsive).
2. Chaque constatation corrigée, ou classée comme faux positif avec une raison énoncée. Ne désactivez jamais en ligne. La suppression nécessite la confirmation d'Adam.
3. Exécutez la liste de vérification pré-vol du skill de goût (sa section 14).
4. Recherchez dans le CSS les animations infinite et les box-shadow teintés, et neutralisez les deux. Cela rattrape le seul paramètre du skill de goût que nous remplaçons délibérément.

Par défaut, LOCAL. Prévisualisez avec python3 -m http.server 8080 dans le répertoire de build et itérez là. Ne déployez pas à moins que l'utilisateur ne le demande à ce moment-là — une URL en ligne n'est justifiée que pour un client payant ou une démo programmée, et chaque déploiement coûte des crédits Netlify (38 déploiements sur un seul site ont épuisé une allocation mensuelle et forcé une mise à niveau payante). Regroupez chaque correction en attente en UN SEUL déploiement par cycle de révision.

La QA mobile est reportée au premier vrai déploiement — elle ne peut pas être effectuée localement et le navigateur d'automatisation ne peut pas émuler une véritable fenêtre mobile. Planifiez une session mobile dédiée au moment de la démo plutôt que de prétendre qu'elle a été vérifiée plus tôt.

NE DÉPLOYEZ JAMAIS la racine du projet. .netlifyignore N'EST PAS honoré par netlify deploy --dir, et déployer une racine a déjà publié l'ADRESSE DU DOMICILE d'un client et un MOT DE PASSE de traceur sur l'ensemble du parc. Créez un répertoire de publication explicite et vérifiez la surface en ligne, à chaque fois :

python3 scripts/make-dist.py .        # publie uniquement les fichiers web, exclut .py/.md/package.json
netlify deploy --prod --dir dist
scripts/verify-published.sh <host> [nom-de-rue-du-propriétaire]   # doit afficher "clean" ; sortie non nulle = fuite

Lorsque l'utilisateur approuve, déployez avec scripts/deploy-netlify.sh (references/deploy.md) — Netlify est la seule chose installée à la fin ; activez les formulaires (ignore_html_forms) + le hook de notification s'il y a un formulaire. Ensuite, configurez Cloudflare Web Analytics par défaut (l'utilisateur le veut généralement) : demandez un jeton de balise pour le nom d'hôte déployé, injectez l'extrait avant </body> sans SRI (Cloudflare le fait tourner — l'exception documentée) et redéployez. En mode auto, présentez-le comme un élément « nécessite l'utilisateur » avec le nom d'hôte exact. Détails dans references/deploy.md. Signalez l'URL en ligne, ce qui a été utilisé et (en mode auto) la liste « Ignoré / à améliorer plus tard ».

Carte de référence

…

[tronqué pour la traduction]