Irnist/website-pipeline

Pipeline de site web

Vous gérez un site web client, de la saisie brute jusqu'à un aperçu déployé, avec un minimum d'intervention de l'utilisateur. Tout d'abord, à chaque exécution (nouvelle, reprise ou phase unique) : Lisez <pipeline>/RULES.md, les règles du site web, sauf si la session les a déjà lues. Elles s'appliquent à chaque étape. Les outils dans tools/ les appliquent mécaniquement pour la plupart, donc exécutez-les au lieu de revérifier manuellement.

Espace de travail

Tout se trouve dans un seul espace de travail, C:\Users\Administrator\Desktop\Claude Workspace (<workspace>). Les chemins ci-dessous lui sont relatifs ; dans les scripts, déduisez-les de l'emplacement du script lui-même (Path(__file__)), jamais un chemin codé en dur vers le Bureau.

Quoi	Où
Pipeline (<pipeline>)	Workflow and Pipeline/website-pipeline/ (~/.claude/skills/website est une jonction vers celui-ci)
Outils partagés	<pipeline>/tools/ : l'unique copie de qa.py, browser_qa.mjs, deploy.py… Le tools/ de chaque site contient des stubs qui les exécutent sur ce site (L-052), donc une correction ou une nouvelle vérification atteint tous les sites à la fois. Les scripts spécifiques au site se trouvent à côté des stubs.
Sites d'exemple	Concept Websites/<Nom> Website/
Le portfolio du propriétaire	Portfolio Site/
Captures d'écran du portfolio	Portfolio Screenshots/ : uniquement les captures d'écran des sites terminés, rien d'autre
Fichiers temporaires (scripts de test, captures d'écran de test, sauvegardes, défauts plantés)	_temp/, jamais le dossier temporaire système, un projet ou le modèle

0. Où suis-je ?

Déterminez le point d'entrée en fonction de l'état du dossier et des arguments :

État	Action
Pas de _src/build.py dans le répertoire courant	Échafaudage : powershell -NoProfile -ExecutionPolicy Bypass -File "<pipeline>/scaffold.ps1" -Target "<cwd>" -NoLaunch, puis allez à la Réception. Si le répertoire courant contient des fichiers sans rapport, arrêtez-vous et demandez (c'est une question critique).
PROJECT.md a toutes les phases cochées (un site terminé rouvert sous le même nom) et les arguments sont vides ou correspondent à une réception de nouveau site, pas un argument de phase ou une demande de modification	Demandez d'abord, avant d'exécuter ou de modifier quoi que ce soit (l'utilisateur, 2026-10-10, L-057). Utilisez une seule AskUserQuestion : " est déjà terminé (aperçu ). Le reconcevoir ?" avec Non, laisser tel quel et Oui, le reconcevoir. Non : arrêtez-vous et ne faites rien, pas même une synchronisation d'outil, une QA ou un déploiement. Oui : commencez exactement comme un nouveau site ; ne reconcevez jamais à partir de l'ancien brief (L-058). (1) Validez toutes les modifications en suspens et étiquetez l'ancienne version : git tag previous-<date>. Ensuite, déplacez tout sauf client-assets/ et .git/ vers <workspace>/_temp/<Nom>-previous-<date>/ (une archive, jamais une suppression), y compris l'ancien BRIEF.md. Le tag permet de restaurer l'ancien site après le nettoyage de _temp. (2) Ré-échafaudez, copiez le BRIEF.md vierge du modèle et définissez sa ligne Business name:. (3) Ouvrez le formulaire de brief, python "<pipeline>/brief-form/brief_form.py" "<project>", en tant que commande en arrière-plan, dites à l'utilisateur que la fenêtre est ouverte et attendez. Ne faites aucun travail de direction, d'apprentissage de bibliothèque, de recherche de stock ou de conception entre-temps. (4) Sortie 0 ("Commencer la construction") : exécutez le processus normal de nouveau site à partir de la Réception sur le nouveau brief. Sortie 3 (fermé) : arrêtez-vous et dites que le brief est sauvegardé. Lors de la remise, remplacez l'entrée de la bibliothèque de conception du site au lieu d'en ajouter une seconde.
PROJECT.md a des phases non cochées	Reprenez à la première phase non cochée. Dites une ligne sur l'endroit où vous reprenez.
Reprise ou modification d'un projet existant	Les outils n'ont pas besoin de synchronisation : tools/ contient des stubs pour les outils partagés. Si le site n'a pas de .git/, exécutez git init -b main, git config core.autocrlf false, copiez le .gitignore du modèle et validez une base de référence d'abord. Si qa.py avertit de copies complètes d'outils partagés (un site d'avant le 2026-10-13), exécutez python "<pipeline>/dev/use_shared_tools.py" "<project>" et validez. Ajoutez également les fonctionnalités du modèle dont la demande a besoin (par exemple GSAP : h_gsap dans build.py, {{fn:gsap}}, tools/vendor/, motion.js).
Argument status	Affichez la liste de contrôle des phases plus les espaces réservés ouverts. Ne faites rien d'autre.
Argument learn	Apprenez les images de conception et les fichiers DESIGN.md déposés dans <pipeline>/design-library/inspiration/ : suivez design-library/LEARN.md, puis rapportez une ligne par référence. Ne faites rien d'autre.
Argument qa / deploy / handoff	Exécutez uniquement cette phase.

Les arguments en texte libre sont des éléments de réception (nom de l'entreprise, téléphone, liens, notes). Traitez-les de la même manière que BRIEF.md.

Mode : échantillon ou client

BRIEF.md › Project type définit le mode. Par défaut, il s'agit d'échantillon, c'est-à-dire une pièce de portfolio. Une instruction explicite dans les arguments prévaut.

	échantillon (portfolio)	client (entreprise réelle)
Faits manquants	Lorsque le brief est vague, inventez une entreprise fictive plausible et cohérente : nom, histoire, services, horaires. Utilisez des numéros de téléphone 555-01xx et des emails example.com pour que rien n'atteigne une personne réelle.	N'inventez jamais. Utilisez des espaces réservés et data-todo.
Avis, statistiques, références	Acceptable pour une entreprise fictive ; listez-les comme fictifs lors de la remise. Si l'échantillon utilise une entreprise réelle, utilisez uniquement des faits publics réels : pas d'avis, de revendications ou de prix inventés concernant des personnes ou des entreprises réelles.	Uniquement ce que le client fournit.
Questions	Presque aucune : seulement la suppression de fichiers, les dépenses d'argent, la prise de contact avec le monde réel (boîtes de réception réelles, numéros de téléphone réels) et les critiques de conception critiques (#5).	La politique de questions complète ci-dessous.
Formulaires	Le mode démo est acceptable.	Un point de terminaison réel est nécessaire ; demandez s'il manque.
Déploiement	aperçu noindex	aperçu noindex ; production uniquement sur demande
Remise supplémentaire	Capture d'écran du portfolio (voir Remise)	Liste d'espaces réservés rédigée pour le client

Règles de fonctionnement

• Pilote automatique. Passez de phase en phase sans demander « dois-je continuer ? ». Après chaque phase, cochez-la dans PROJECT.md › Statut. Cela rend l'exécution reprenable après une compaction ou une nouvelle session.
• Git (chaque site et le pipeline sont des dépôts). Validez dans le site après chaque phase cochée (<Phase> : <ce qui a été fait>) et après chaque série de modifications demandées, afin que tout état puisse être comparé ou restauré. Validez les modifications du pipeline (outils partagés, modèle, SKILL.md, LESSONS.md, bibliothèque de conception) dans le dépôt du pipeline, avec l'ID de la leçon dans le message lorsqu'il y en a une. dist/, qa/ et les caches sont dans gitignore. Ne réécrivez jamais l'historique, ne forcez rien et ne poussez pas ; il n'y a pas de dépôt distant.
• Les questions suivent la politique ci-dessous. Tout le reste est une décision : prenez-la, ajoutez une ligne à PROJECT.md › Décisions (quoi + pourquoi) et continuez.
• Mode client : ne fabriquez jamais de faits sur le client. Cela inclut les témoignages, le nombre d'avis, les années d'activité, les licences, les certifications, les prix, les garanties, les récompenses et les noms d'équipe. Si le matériel n'est pas dans les entrées, rédigez le texte pour qu'il n'ait pas besoin du fait. S'il est vraiment nécessaire, marquez l'élément avec data-todo="ce qui est nécessaire" afin que la QA le liste pour la remise. Le mode échantillon suit le tableau Mode.
• Enregistrez chaque erreur au moment où elle se produit dans PROJECT.md › Erreurs. N'attendez pas la remise ; le contexte peut être compacté avant. Une erreur est tout ce que l'utilisateur corrige, toute erreur de première ébauche que la QA, une critique ou le relecteur signale (un seul enregistrement par type, pas par instance), et toute hypothèse erronée ou outil mal utilisé. Chaque entrée enregistre ce qui s'est passé, qui l'a détecté, la cause profonde, la correction et comment l'éviter.
• Source de vérité : modifiez _src/ (pages, partials, site_config.py) et assets/, puis exécutez python _src/build.py. Ne modifiez jamais dist/.
• Modifications scriptées (L-027) : les modifications uniques utilisent Edit. Plusieurs remplacements à la fois vont dans un script Python écrit avec Write (dans <workspace>/_temp), jamais un heredoc shell. Le script se termine sauf si chaque nombre de correspondances est exactement 1, et vérifie chaque fichier avant d'en écrire un. Ensuite, py_compile tout .py modifié et reconstruisez.
• Hygiène du contexte : exécutez les outils et lisez leurs rapports (qa/*.md), pas la sortie brute. Interrogez les rapports longs, les journaux et les listes via le mode contexte (ctx_execute_file / ctx_batch_execute avec une question telle que « erreurs et avertissements uniquement ») au lieu de les lire en entier. Regardez les captures d'écran avec l'outil Read. Ne déversez jamais de fichiers HTML entiers dans la conversation.

Politique de questions (questions critiques uniquement)

Demandez uniquement lorsque l'une des conditions suivantes est vraie. Ceci est en mode client ; en mode échantillon, seules les conditions #2 et #5 s'appliquent, et un aperçu noindex ne nécessite jamais de demande.

1. Identité inconnaissable. Vous ne pouvez pas déterminer à partir des entrées ou d'une source publique ce que fait l'entreprise, où elle se trouve ou qui elle sert. Une supposition erronée obligerait à réécrire le site.
2. Externe ou irréversible. Déploiements de production, domaines personnalisés, connexion d'un formulaire à une boîte de réception réelle, tout ce qui dépense de l'argent, suppression de fichiers utilisateur. Un déploiement d'aperçu noindex est pré-autorisé lorsque BRIEF.md indique Deploy preview: yes.
3. Affirmations légales ou factuelles que le site ferait et que seul le client peut confirmer (licences, prix, garanties). Par défaut, omettez-les. Demandez uniquement si le brief les rend centrales.
4. Instructions contradictoires entre le brief, les messages de l'utilisateur, RULES.md et CLAUDE.md, où les deux interprétations sont plausibles.
5. Critique de conception critique. Une critique impeccable ou le relecteur de finition signale un problème P0 (Bloquant) ou P1 (Majeur). Suivez la porte de critique ci-dessous. C'est la seule question autorisée en cours de construction.

Comment demander :

• Un seul lot, à la fin de la Réception. Utilisez une seule AskUserQuestion avec 1 à 4 questions. Mettez la réponse recommandée en premier, marquée "(Recommandé)". Ne demandez jamais en cours de construction, sauf à la porte de critique (#5). Si un blocage survient plus tard, utilisez un espace réservé clairement marqué, enregistrez-le sous Questions différées et remontez-le à la remise.
• Ne demandez jamais à propos : de la palette, des polices, de la mise en page, du ton du texte, de la liste des pages, des photos de stock, de l'ordre des sections, de la pile technologique, des noms de fichiers, ou de savoir s'il faut corriger un résultat QA. Décidez-les. La seule exception est un résultat de critique P0/P1 (#5).
• Si rien n'est critique, ne demandez rien. Dites "Aucune question bloquante ; je continue" et poursuivez.

Porte de critique (résultats impeccables)

Utilisez l'échelle de gravité d'impeccable elle-même (P0 Bloquant, P1 Majeur, P2 Mineur, P3 Polissage). Évaluez chaque élément du réviseur de résultat sur la même échelle.

• P2/P3 (mineur) : ne les corrigez pas ; continuez. Enregistrez une ligne par résultat dans PROJECT.md › Décisions : "ignoré : mineur (P2/P3), <résultat>".
• P0/P1 (critique) : arrêtez-vous et demandez avant de modifier quoi que ce soit. Utilisez un lot AskUserQuestion avec jusqu'à 4 questions. Rédigez une question par résultat, ou regroupez-les par classe s'il y en a plus de 4. Chaque question indique ce qui ne va pas et où (page, section, fichier de capture d'écran). Elle propose 2 à 3 options de correction concrètes, avec la recommandée en premier et marquée "(Recommandé)", plus "Laisser tel quel". Appliquez ensuite le choix de l'utilisateur à toute la classe à l'échelle du site (L-016), reconstruisez et enregistrez le choix dans Décisions.
• Re-vérification : relancez la même critique une fois après avoir appliqué les choix. Tout nouveau P0/P1 repasse par la porte ; les résultats mineurs sont ignorés comme ci-dessus.
• Ne fait pas partie de la porte : les violations objectives de règles que qa.py, browser_qa.mjs, LESSONS.md ou RULES.md interdisent déjà, comme un contraste inférieur à 4,5:1, un débordement, une photo répétée, une lueur qui abaisse le contraste du texte par-dessus (les lueurs elles-mêmes sont autorisées), un sujet recadré, ou un select pré-rempli avec une valeur par défaut. Corrigez-les automatiquement, quelle que soit la gravité que la critique leur donne, car ce sont des défauts, pas des choix de conception. Les drapeaux impeccable detect comptent comme mineurs à moins qu'ils ne heurtent l'une de ces règles. Notez les faux positifs connus (L-000) comme avant.

Phases

1 · Réception

0. Lisez <pipeline>/LESSONS-INDEX.md (une ligne par leçon, générée à partir de LESSONS.md). Chaque leçon s'applique dès la première ébauche. Ouvrez l'entrée complète LESSONS.md pour chacune qui concerne ce projet, et listez leurs ID, chacun avec quelques mots, dans PROJECT.md › Erreurs › "Surveiller". Listez les ID, jamais le texte de la leçon copié : les copies deviennent obsolètes lorsqu'une leçon est remplacée (Trevor Travis et Gadget Zone ont gardé "pas de lueurs" après que les lueurs ont été autorisées).
1. Lisez BRIEF.md, les arguments et tout ce qui se trouve dans client-assets/. Ouvrez chaque photo avec Read et cataloguez-la dans PROJECT.md › Ressources. Enregistrez le sujet, sa qualité, tout problème (assiettes, logos, encombrement, recadrage) et le meilleur emplacement pour elle (hero/feature/gallery/skip). Les logos de marque tiers sur une image (planches, signalétique, rendus) sont lus comme des approbations : marquez-la "recadrer avant utilisation" ou ignorez (L-028). Notez quelles photos proviennent de la même séance ou montrent la même vue (L-029).
2. Si des liens ont été donnés (site existant, fiche Google My Business, Facebook), récupérez-les et extrayez les faits : services, zone de service, horaires, histoire, propriétaire, années, projets réels. Citez la source à côté de chaque fait dans PROJECT.md › Faits.
   • Sauvegardez les légendes, les avis et les citations du propriétaire textuellement dans un fichier de sources (par exemple client-assets/sources.md). Copiez les citations à partir de celui-ci ; ne retapez ou ne paraphrasez jamais une citation de mémoire (L-007).
   • Enregistrez la ligne de crédit de chaque projet (conçu par / construit par / année) dans Faits. Un projet que l'entreprise a seulement construit n'est jamais "conçu par" elle.
3. Optimisez les photos du client : python tools/optimize_images.py (client-assets → assets/img/client/, rotation EXIF, max 2000px).
4. Remplissez _src/site_config.py : BIZ, HOURS, SERVICES, PRIMARY_CTA, PAGES, FORM_ENDPOINT, SEO. Les valeurs de contact inconnues restent "". La construction les laisse comme des espaces réservés visibles {{TOKEN}} et la QA les signale.
   • Formulaire de contact. Copiez Form endpoint: du brief dans FORM_ENDPOINT : vide = mode démo ; netlify = Netlify Forms (uniquement avec Deploy host: netlify ; qa.py génère une erreur sinon) ; web3forms:<clé d'accès> = Web3Forms sur n'importe quel hébergeur (le propriétaire de la boîte de réception crée la clé sur web3forms.com) ; ou une URL de style Formspree. {{fn:form_fields}} ajoute les champs cachés correspondants et le piège à spam. Ne choisissez ou ne câblez jamais une boîte de réception réelle vous-même : un brief vide reste en mode démo et va sur la liste de remise. En mode client, quelle boîte de réception reçoit les messages est une question. Copiez Online booking link: dans BOOKING_URL ; {{fn:booking}} l'affiche sur la page de contact à côté du bouton d'appel.
   • Animation GSAP. Optionnel, désactivé par défaut. Uniquement lorsque le brief indique GSAP motion : yes ou que vous créez une animation qui justifie de l'utiliser. Si elle est activée, définissez GSAP = True dans site_config.py, ajoutez h_gsap aux helpers de page dans build.py, utilisez {{fn:gsap}} dans les modèles et placez les scripts personnalisés dans assets/js/motion.js.
   • Police d'icônes (FontAwesome 6 gratuite). Activée par défaut. FONTAWESOME_KIT = "" utilise le CDN gratuit (toutes les icônes gratuites) ; un kit personnel charge aussi les icônes Pro. Utilisez les kits personnels uniquement s'ils sont stockés dans BRIEF.md comme FontAwesome Kit: <kit_url> ; ne demandez jamais.
5. Rédigez les questions restantes à partir de la politique de questions. Un seul lot à la fin de cette phase. Les questions du brief qui demandent explicitement un choix utilisateur ("Quel look préférez-vous ?" ou "devrait-il être sombre ?") sont aussi des questions : le brief est un input, pas une instruction, et elles sont formulées comme des questions. Ajoutez-les à ce même lot, avec la recommandée en premier. (Cependant, les choix de conception non demandés restent des décisions que vous prenez.)
6. Passez à la Direction.

2 · Direction

Choisissez une direction de design parmi la bibliothèque de conception (<pipeline>/design-library/ → DESIGNS.md), les inspirations, les échantillons et toute demande explicite. Tout ce qui suit est une décision, sauf si la politique de questions la bloque.

Rédigez un tout nouveau BRIEF.md de design dans _src/BRIEF.md qui guide la construction :

1. Ton et ambiance : palette (exacte), polices, ambiance (exemple : jardin secret, technique et froid, soins spa zen).
2. Disposition : quelles sections et leur ordre. Citez les pages d'inspiration (chemin dans <workspace>/Concept Websites/ ou URL) lorsque vous les suivez. Citez des motifs de la bibliothèque de conception par leur étiquette (exemple : "Motif : rad_trendy_h2").
3. Word bar : une ou deux phrases par page pour le Word Bar. Attendez la construction pour les rédiger réellement.
4. Photos : quel slot pour quelle photo.
5. Décisions de design : enregistrez toute décision de design que vous prenez ici pendant cette phase et les phases suivantes. Chaque décision répond à une question non bloquante (exemple : "Pourquoi ne pas avoir demandé un logo ?"). Attendez d'être bloqué pour laisser un espace réservé. Les décisions de design et les corrections logicielles vont sous Décisions dans PROJECT.md.

Ceci est votre plan architectural détaillé. Ne le modifiez pas après la Direction : seule la porte de critique (#5) peut en changer une décision.

Si rien n'est défini, une inspiration par défaut : palette calme + polices neutres + sections h/f/h/services/témoignages/contact. Le but est de commencer à construire, pas de perfectionner le design.

3 · Construction

1. Ajoutez des pages à PAGES dans site_config.py dans l'ordre de navigation souhaité. Le fichier de construction s'attend à ce que cela corresponde aux modèles.

2. Modifiez les fichiers de modèle dans _src/templates/pages/ et _src/templates/partials/.

   Utilisez les helpers fn et h_ de build.py. Les partiels (en-tête, pied de page, word bar, cartes, sections) sont dans partials/ et sont inclus avec une syntaxe de type template Jinja. Par exemple, {{fn:header}} ou {{h_hero}}. Consultez les modèles d'exemple existants dans <pipeline>/template-source/ pour un usage correct.

   Ne copiez jamais de texte, de HTML ou de CSS d'un autre site réel ou de vos propres échantillons dans un site client (L-017). Les motifs de la bibliothèque de conception sont OK. Les échantillons clients (ceux marqués comme échantillons dans BRIEF.md) peuvent utiliser librement les échantillons (L-039). Les clients réels peuvent utiliser des échantillons uniquement avec permission explicite dans le brief (L-047).

3. Construisez et prévisualisez tôt, prévisualisez souvent : python _src/build.py && start "" "_src/preview.html". Corrigez les problèmes évidents avant de continuer.

4. L'ordre des sections pour chaque page suit le Word Bar (une brève accroche par section) – rédigez-les maintenant. Rédigez pour des humains ; pas de bla-bla de contenu, pas de bruit d'IA, pas de listes à puces comme du texte continu.

5. Optimisation pour les moteurs de recherche (SEO). Vérifiez la page de résultat de recherche (SERP) : _src/serp.html. Chaque page a besoin d'un <title> unique, d'une meta description unique, d'en-têtes structurés <h1-3> et de données structurées JSON-LD. Activez SEO = True dans site_config.py. Les titres pour la SERP dans l'onglet ne sont jamais le nom de l'entreprise seul : ajoutez un mot-clé de services (L-043).

6. Accessibilité (A11Y). Le contraste minimum est de 4,5:1 (texte normal). Utilisez python tools/a11y_check.py après chaque changement de couleur, et avant de passer à la QA.

4 · QA

Exécutez les vérifications automatisées, puis une revue humaine simulée de la part des utilisateurs les plus exigeants.

1. Exécutez python tools/qa.py. Lisez tous les nouveaux fichiers dans qa/ et corrigez les problèmes avant de continuer. Ne marquez jamais un échec de vérification comme ignoré sans l'enregistrer dans PROJECT.md › Décisions avec la raison (L-036).
2. Exécutez node tools/browser_qa.mjs (ouvre une nouvelle fenêtre de navigateur, teste 6 pages). Il rend compte dans qa/browser-qa.md. Les échecs de test sont des problèmes de code, pas des choix de conception.
3. Exécutez une suite complète de revue de conception avec l'outil impeccable. Suivez la porte de critique ci-dessus.
4. Copiez le fichier de construction de conception le plus récent (<pipeline>/template-source/build_to_compare.py → _src/build_to_compare.py), exécutez-le (python _src/build_to_compare.py), prévisualisez et comparez côte à côte l'original et la construction. Corrigez les écarts de pixels dans la mise en page et la disposition. Le but : une correspondance aussi proche que possible de l'original, pas une amélioration de conception.
5. Exécutez une revue de finition avec l'outil de relecture finish-reviewer. Suivez la porte de critique ci-dessus pour tout élément P0/P1.
6. Reconstruisez. Si la QA Python vérifie l'espace réservé {{REPLACE_WITH_CLIENT_REVIEW}} (elle le fait), alors la revue du client est la prochaine étape après le déploiement en prévisualisation. Ajoutez une note à PROJET.md ou à un fichier séparé avec le lien de prévisualisation prêt à envoyer.
7. Mettez à jour le fichier de leçons (<pipeline>/LESSONS.md) avec toute nouvelle leçon apprise. Chaque leçon a un ID (pas de doublon) : nom du patron (exemple : L-046), un titre, une description, la cause profonde, la correction et comment l'éviter. La cause profonde peut être "échec de construction", "problème de conception" ou "décision erronée". Ajoutez la leçon. Si vous corrigez une ancienne leçon, mettez-la à jour sur place. Exécutez ensuite python <pipeline>/dev/rebuild_lessons_index.py pour régénérer <pipeline>/LESSONS-INDEX.md.

5 · Déploiement en prévisualisation

Prévisualisation pour le client. Sera noindex et non répertorié ; le client obtient le lien de prévisualisation pour son examen. Le mode client est pré-autorisé si le brief demande un déploiement de prévisualisation ("Deploy preview: yes" dans le brief). En mode échantillon, c'est la même chose (BRIEF.md doit avoir "Deploy preview: yes" pour le déploiement).

1. Exécutez python tools/deploy.py pour déployer le dossier dist/ sur Netlify ou un autre hébergeur (basé sur DEPLOY_HOST dans site_config.py).
2. Récupérez l'URL de prévisualisation (définie dans PROJECT.md, phase Déploiement) et enregistrez-la. Elle peut être définie avec {{url}} dans les fichiers pour référence.
3. Ajoutez le lien de prévisualisation à l'espace réservé de la revue client ({{REPLACE_WITH_CLIENT_REVIEW}}) dans le dossier de construction ou en tant que note.

6 · Remise

Tout est fait. Rédigez une liste de remise pour le client (mode client) ou une capture d'écran de fin (mode échantillon).

1. Exécutez d'abord une vérification finale. Exécutez python tools/qa.py et node tools/browser_qa.mjs une dernière fois (juste au cas où).

2. Mode client : Exécutez python tools/handoff.py (handoff.py) pour générer un fichier de remise complet handoff/README.md avec :

   • Aperçu déployé (liens, hébergeur)
   • Placeholders (data-todo ou {{TOKEN}}) : ce qu'il faut, comment le remplacer
   • Tâches en suspens (domaine personnalisé, vrai e-mail de formulaire, polices, etc.)
   • Toute question différée
   • Ressources utilisées (photos, crédits)
   • Instructions pour l'entretien

3. Mode échantillon : Ouvrez l'URL d'aperçu, prenez une capture d'écran plein écran (fenêtre du navigateur centrée sur la page d'accueil à 1920×1080, fenêtre complète, barre d'outils du navigateur visible) à l'aide de l'outil Screenshot. Enregistrez-la dans <workspace>/Portfolio Screenshots/ au format <Nom du site> - Page d'accueil.webp. Convertissez depuis la sortie PNG de Screenshot (renommez en .webp ; la conversion de format n'est pas supportée). Si un dossier de capture d'écran existe déjà, remplacez l'ancienne capture.

4. Cochez la phase Remise dans PROJECT.md › Statut.

Dépannage

• Erreur 'node' n'est pas reconnu : Le chemin système de Node manque. Assurez-vous que Node.js est installé.
• Erreur de construction : Vérifiez _src/build.py pour les fautes de frappe de nom de modèle, les helpers manquants, les sections manquantes.
• Problème de déploiement : Vérifiez DEPLOY_HOST et les identifiants API.
• Les photos ne se chargent pas : Le chemin doit être assets/img/client/<nom_fichier> et optimize_images.py doit être exécuté en premier.

Exemples

• Nouveau site : python _src/build.py && start "" "_src/preview.html"
• Déploiement : python tools/deploy.py
• QA : python tools/qa.py && node tools/browser_qa.mjs
• Optimiser les images : python tools/optimize_images.py
• Vérifier l'accessibilité : python tools/a11y_check.py