Site perso : maquettes verrouillées, rendu 1:1

Site personnel (Personal Website)

Règles fondamentales

Ne passez pas directement au code. Considérez le site comme un projet piloté par des images de référence, divisé en phases :

1. Verrouillage du contenu et du style
2. Verrouillage des images de référence
3. Inventaire de décomposition des assets
4. Génération et validation des assets
5. Reproduction haute-fidélité et QA

Le flux visible par l'utilisateur comporte par défaut quatre confirmations bloquantes :

1. Confirmer le brief complet de contenu et de style, y compris la forme du site, la planification des sections, la suffisance du contenu, et la direction visuelle choisie ou fournie par l'utilisateur
2. Confirmer le groupe d'images de référence après un examen de cohérence, de rythme et de faisabilité
3. Confirmer l'inventaire de décomposition des assets avant de générer ou de trouver de nouveaux assets
4. Confirmer les assets générés/collectés et le bref d'exécution de reproduction avant de coder la page

Une fois le groupe d'images de référence confirmé, n'entrez pas directement dans l'implémentation. Examinez d'abord chaque image de référence confirmée, produisez un inventaire de décomposition des assets à montrer à l'utilisateur, et attendez sa confirmation. Une fois l'inventaire confirmé, générez, trouvez ou rassemblez uniquement les assets approuvés dans l'inventaire. Une fois les assets prêts, listez les chemins finaux, les résultats de vérification et un bref d'exécution de reproduction court ; attendez que l'utilisateur accepte, demande une régénération ou modifie la décomposition. Ce n'est qu'après cette confirmation que vous pouvez commencer la reproduction haute-fidélité.

Les anciennes notes de conception légères de pré-construction sont fusionnées dans la sortie de validation des assets pour former un bref d'exécution de reproduction court. Il ne s'agit pas d'un point de confirmation supplémentaire indépendant : l'utilisateur confirme simultanément les résultats des assets et le bref d'exécution de reproduction avant le code.

Ne réduisez pas les phases suivantes à une simple construction front-end ordinaire. Les images de référence confirmées ne sont pas des moodboards. Avant d'écrire du code, chaque image de référence doit avoir un contrat de rendu confirmé, décomposé en zones gérées par le code, scènes fusionnées, médias indépendants, assets d'identité/source réelle, points d'ancrage visuels, et décisions finales de source et de statut.

Condition d'arrêt stricte : ne créez ni ne modifiez aucun fichier HTML, CSS, JS, React, route ou composant tant que l'inventaire de décomposition des assets n'est pas confirmé, les assets approuvés générés ou rassemblés, et la validation des assets et le bref d'exécution de reproduction acceptés. Dire « Je vais décomposer les images de référence » dans un simple message de progression ne suffit pas.

Pour les projets pilotés par des images de référence soignés, appliquez également la condition d'arrêt de preuve : lisez references/evidence-gate.md. Si les preuves de sauvegarde requises sont manquantes, le statut ne peut être que not verified, pas pass. Si l'utilisateur demande de sauter les pauses de confirmation, cela signifie seulement continuer automatiquement après le passage du seuil ; cela ne signifie pas un passage automatique, un remplacement silencieux des images de référence, un saut de l'examen ou une réalisation sans preuve.

Si l'utilisateur ne dispose que d'informations partielles, examinez d'abord les lacunes et suggérez des moyens moins laborieux de fournir les informations, plutôt que de lui demander immédiatement d'écrire tout le contenu manuellement. Si l'utilisateur a déjà du contenu, des images de référence et des assets confirmés, vous pouvez passer directement à l'examen, à la validation des assets ou à la phase de reproduction correspondante, mais les mêmes limites de confirmation restent en vigueur avant le code.

Discipline d'exécution

Lorsque vous progressez entre les phases, énoncez l'hypothèse actuelle, le prochain objectif vérifiable et la manière de le vérifier. Si la demande a plusieurs interprétations, clarifiez d'abord les options et demandez avant d'entrer dans une direction spécifique.

Limitez les modifications :

• N'ajoutez pas de section, d'interaction, de contenu, de route, de type d'asset ou de configuration que l'utilisateur n'a pas demandés ou confirmés.
• Lorsque vous modifiez un projet existant, ne modifiez que les fichiers nécessaires dans le périmètre confirmé et respectez le style existant du projet.
• Supprimez uniquement le code, les assets ou les importations devenus inutiles après leur ajout par ce flux de travail ; mentionnez les éléments morts non liés sans les supprimer.
• Privilégiez la note de conception minimale, la liste d'assets, le groupe de prompts ou la modification d'implémentation qui permet de progresser de manière fiable vers la phase suivante.
• Les étapes multiples doivent avoir des critères de succès suffisamment spécifiques pour éviter de progresser par estimation.
• Implémentez et validez une seule tranche de section à la fois ; ne prétendez pas que plusieurs sections sont passées si vous n'en avez vérifié qu'une partie.

Langue et expressions localisées

Les guides visibles par l'utilisateur doivent correspondre à la langue principale de l'utilisateur. Lorsque l'utilisateur pose des questions en chinois, utilisez le chinois pour les messages de progression, les transitions de phase, les demandes de confirmation et les étiquettes d'options, par exemple 第一步 / 内容与风格锁定 ou 接下来进入第二步. Lorsque l'utilisateur pose des questions en anglais, utilisez l'anglais, par exemple Step One / Content and style lock ou Next I will move to Step Two. Si la conversation est mixte, suivez la préférence explicite la plus récente de l'utilisateur ou la langue de la dernière demande substantielle.

Par défaut, utilisez le chinois pour les invites, les transitions de phase, les demandes de confirmation et les étiquettes d'options adressées à l'utilisateur ; conservez les noms de fichiers, commandes, noms de champs et termes techniques nécessaires en anglais pour ne pas modifier le contrat d'exécution.

Les noms des phases doivent également être entièrement traduits. Pour un utilisateur chinois, écrivez 第五步 / 高保真复刻与 QA et non Step Five / Build and QA.

Competences intégrées (Companion Skills)

Cette compétence intègre des références compagnons, de sorte que le flux de travail ne dépend pas de l'installation d'autres compétences par l'utilisateur :

• references/imagegen-frontend-web.md : utilisé pour le contrat strict de génération d'images de référence de site web personnel (étape deux)
• references/visual-quality-gate.md : utilisé pour l'examen du sens réel, de la hiérarchie, des blancs, du recadrage, du chevauchement, de l'auctorialité et du contexte frais (étapes deux et cinq)
• references/evidence-gate.md et scripts/verify_identity_run.py : utilisés pour les hachages de référence non écrasables, les preuves de capture d'écran section par section, l'attribution topologique et la vérification d'achèvement déterministe
• references/reference-asset-splitter.md et references/split-patterns.md : utilisés pour l'arbitrage des assets sur trois axes et les cas de correction d'erreur réels (étape trois)
• references/frontend-app-builder.md : utilisé pour l'implémentation haute-fidélité et la QA après la validation des assets (étape cinq)

Pendant la phase de génération des images de référence du site personnel, vous devez lire references/imagegen-frontend-web.md, que la compétence autonome imagegen-frontend-web soit installée ou non. Pour des objectifs de qualité, de professionnalisme, de caractère distinctif ou de niveau Awwwards, vous devez également lire references/visual-quality-gate.md aux étapes deux et cinq. Ces fichiers intégrés sont le contrat strict de ce flux de travail ; les compétences autonomes peuvent compléter un vocabulaire créatif plus large, mais ne peuvent pas remplacer le brief confirmé, l'empreinte stylistique, le contrat de sens, le seuil de qualité visuelle, le budget d'assets et les règles de faisabilité.

Pendant la phase d'arbitrage des assets, utilisez la version installée de reference-asset-splitter si elle est disponible, sinon utilisez la version intégrée ; les deux doivent maintenir le même ensemble de classifieurs et de cas. Le brief confirmé de l'utilisateur et les limites strictes des phases de cette compétence ont priorité sur les règles par défaut des compagnons. À l'étape cinq, privilégiez toujours frontend-app-builder installé, la copie intégrée servant de repli.

Si une compétence compagne n'est pas installée, ne bloquez pas le processus, ne faites pas comme si un appel @skill était disponible, et ne demandez pas à l'utilisateur de l'installer pour continuer. Lisez la référence compagne intégrée à ce package et utilisez-la comme contrat d'exécution local minimal.

Ne discutez de l'installation séparée d'une compétence compagne que si l'utilisateur souhaite explicitement un composant installable indépendamment. Dans le chemin normal, l'installation de la seule compétence identity-skill devrait suffire.

S'il n'y a aucun outil de génération d'images, écrivez des prompts reproductibles que l'utilisateur peut copier-coller dans GPT web Image 2 ou un autre outil d'image, ou demandez à l'utilisateur de fournir ses propres images de référence. Si l'utilisateur saute complètement les images de référence, traitez la construction comme étant de moindre fidélité et précisez clairement que la QA visuelle ne peut se faire que par rapport au brief textuel, et non par rapport aux images de référence acceptées.

Protocole des messages de progression de phase

À la fin de chaque phase visible par l'utilisateur, donnez un message de progression clair :

• Progression actuelle : Première Étape / Verrouillage du contenu et du style
• Terminé : le résultat concret qui vient d'être produit
• Toujours manquant ou à risque : ne listez que les points bloquants qui affectent réellement la progression
• Ce que l'utilisateur peut faire maintenant : confirmer, modifier une partie nommée, fournir des informations manquantes ou choisir une option
• Prochaine étape : indiquez le nom de la phase suivante et ce qui va se passer

Ne laissez pas l'utilisateur à un point d'arrêt implicite. Si le processus se poursuit sans confirmation bloquante, expliquez clairement qu'il continue et pourquoi.

Première étape : Verrouillage du contenu et du style

Déterminez d'abord quelle voie de saisie de contenu est la plus appropriée. Ne forcez pas l'utilisateur à ressaisir manuellement des informations qui peuvent être lues à partir de fichiers, de liens, de CV, de profils, de notes, d'échantillons d'écriture, de documents de projet, de captures d'écran ou de sites web existants déjà fournis.

Voies de saisie de contenu

Utilisez l'une des voies suivantes :

• Voie « Informations suffisantes » : l'utilisateur a fourni un CV, un curriculum vitae, un profil LinkedIn, une page personnelle, un portfolio, des liens vers des projets, des documents Notion/Markdown, une biographie, un dossier de presse, des pages de réseaux sociaux, des archives d'écriture ou du matériel similaire. Lisez le contenu accessible, extrayez les faits confirmés, les unités de contenu utilisables pour les sections, les liens, les assets et les lacunes. Ne posez que des questions de ciblage qui affecteront la conception du site.
• Voie du brief succinct : l'utilisateur a donné un objectif ou une identité, mais peu de contenu de support. Invitez d'abord l'utilisateur à fournir des informations plus simples, comme un CV, une présentation existante, des liens vers des projets, des liens vers des écrits, des photos, des sites de référence ou des captures d'écran. Si l'utilisateur ne souhaite pas fournir de fichiers, utilisez les questions d'orientation ci-dessous.
• Voie « À partir de zéro » : l'utilisateur n'a aucun matériel ou souhaite tout construire à partir de zéro. Regroupez les questions d'orientation en une seule fois, pas une question à la fois comme une longue interview.
• Voie « Démo rapide » : l'utilisateur met explicitement l'accent sur la rapidité ou un prototype grossier. Vous pouvez utiliser un contenu factice léger, mais tous les faits, projets, citations, indicateurs, liens ou détails biographiques inventés doivent être marqués comme contenu provisoire et devront être remplacés avant la version finale.

Les questions d'orientation doivent être recueillies de manière compacte :

• Objectif : CV, recherche d'emploi, portfolio, création/identité personnelle, conseil, présentation de fondateur/dirigeant, page de conférence/médias, ou autre objectif
• Public : qui va visiter le site, qu'attendez-vous d'eux après l'avoir vu
• Positionnement : étiquette d'identité, une phrase dont on se souviendra, limites de ton
• Éléments de preuve : expérience, projets, publications, produits, clients, couverture médiatique, conférences, récompenses ou autres preuves
• Détails du projet : questions de contexte, votre rôle/action, résultats, liens/médias, et ce que vous voulez que l'on retienne pour chaque projet important
• Assets et limites : photo de profil, logo, captures d'écran, documents, liens, contenu indisponible ou sensible, ce qui ne peut pas être généré ou exagéré
• Préférences utilisateur : densité d'information du site, préférence pour une page unique ou plusieurs pages, références appréciées, styles détestés, volonté de maintenance future

Document de contenu et de forme du site

Pour les sites personnels soignés, les sites d'identité personnelle, les portfolios, les objectifs de niveau Awwwards, ou toute situation où la qualité de conception est importante, produisez un document de contenu et de forme du site avant de passer aux images. Pour une démo rapide, conservez la même structure mais rédigez-la plus courtement.

Le document doit inclure :

• Couverture du contenu : quels fichiers, liens, notes ou réponses de l'utilisateur ont été utilisés
• Faits confirmés : n'écrivez que les faits fournis ou soutenus par les sources de l'utilisateur
• Contenu provisoire non confirmé : marquez clairement le texte proposé par l'agent, les exemples, les placeholders, les affirmations déduites ou les liens manquants
• Objectif et public du site : ce que le site doit accomplir et à qui il est destiné
• Points de mémorisation pour le visiteur : une à trois choses dont le visiteur doit se souvenir
• Recommandation de forme du site : page unique, CV d'une page, page d'accueil + case study, portfolio multi-pages, hub de créateur, page d'atterrissage de consultant, ou autre forme
• Raison de la recommandation : pourquoi cette forme convient aux objectifs de l'utilisateur, à la quantité de contenu, à la profondeur des preuves et à la volonté de maintenance
• Alternatives possibles : des structures plus légères ou plus complètes qui sont réalisables mais moins bonnes que la recommandation principale
• Planification des sections : objectif de chaque section, contenu requis, unités de contenu, liens/assets et statut (ready, needs detail, placeholder ou cut)
• Risques liés à la suffisance du contenu : sections vagues, modèles, fausses, encombrées, manquant de soutien ou ne méritant pas d'être conservées

La forme du site doit être recommandée en fonction des objectifs et de la densité du contenu de l'utilisateur, ne choisissez pas par défaut cinq ou six sections. Pour un CV ou une recherche d'emploi, une page unique ou une à deux pages suffisent généralement. Un portfolio approfondi peut nécessiter des routes de case study. Les sites de créateurs, fondateurs ou consultants n'ont besoin d'une narration ou d'un parcours de conversion plus fort que si le contenu le soutient.

Tout le contenu utilisé pour les images de référence doit provenir de l'utilisateur ou être explicitement approuvé par lui. L'agent peut proposer du contenu pour combler les lacunes, mais ce contenu n'est qu'un brouillon, pas un fait confirmé. Ne considérez pas le contenu proposé par l'agent comme confirmé simplement parce qu'il est bien écrit ou semble approprié.

Avant la confirmation de la deuxième étape, verrouillez la stratégie de source de preuve pour chaque personne, entreprise, produit, travail, publication ou projet identifiable. Rassemblez dès que possible les assets utilisables de l'utilisateur ou les assets officiels, afin que les images de référence puissent être composées directement autour de preuves réelles ; ne confirmez pas d'abord une composition placeholder générée plus forte, prévoyant de la remplacer par un asset officiel au rendu, à l'échelle ou au sujet différent après le verrouillage.

Recommandations de style

Une fois le contenu et la forme du site suffisamment clairs, recommandez un maximum de trois directions visuelles, basées sur le contenu, les préférences de l'utilisateur, le public, l'objectif du site et les références existantes. L'utilisateur peut en choisir une, combiner plusieurs options, ou fournir sa propre direction/référence visuelle.

Les options de style doivent être des concepts visuels, pas seulement des étiquettes de positionnement. Ne donnez pas seulement « CV étudiant international de qualité », « Chercheur en produits FinTech », « Portfolio AI + Finance » qui ne différencient que le public ou le récit professionnel. Ces étiquettes peuvent expliquer pourquoi le style convient, mais les options elles-mêmes doivent permettre à l'utilisateur d'imaginer à quoi ressemble la page avant de générer des images.

Chaque option de style doit couvrir brièvement :

• Nom du concept visuel : une courte étiquette décrivant l'ambiance visuelle, pas seulement le rôle personnel
• Adéquation émotionnelle et de positionnement
• Direction des couleurs : 3 à 5 couleurs spécifiques ou leurs rôles, avec codes hexadécimaux si nécessaire
• Caractère typographique : personnalité de la police d'affichage/corps et contrastes de graisse
• Composition de l'écran d'accueil : comment le nom, le titre, l'avatar/le média, l'appel à l'action et les indices de preuve apparaissent
• Densité de la mise en page et rythme des sections : page unique sobre, rythme éditorial, blocs de preuve en bento, profondeur de case study, ou autre rythme spécifique
• Traitement des images ou des assets : recadrage de l'avatar, captures d'écran de projet, fiches documentaires, visualisations de données, photos éditoriales, arrière-plans abstraits ou graphiques rendus par code
• Sensation du chrome UI et de la navigation : densité de l'en-tête, wordmark, forme de l'appel à l'action, bordures, coins arrondis, style des icônes et état actif
• Personnalité des animations
• Ce que l'utilisateur verra : une phrase décrivant l'impression visuelle immédiate à l'écran
• Pourquoi cela convient à cette personne et cette forme de site
• Principaux risques ou compromis

Si une option de style ne peut pas être décrite comme une image de site web visible, réécrivez-la d'abord avant de la montrer à l'utilisateur. Si l'objectif de l'utilisateur est un positionnement professionnel, traduisez ce positionnement en décisions visuelles, ne laissez pas le titre de l'option porter toute l'expression.

Utilisez ce format d'option de style compact si nécessaire :

Option A — Editorial Resume / Sensation papier encre
Couleurs : blanc chaud #F7F3EC, noir encre #171717, gris bleu #6B7280, bleu d'accentuation #2563EB.
Typographie : police d'affichage sobre serif + police de corps sans propre ; professionnel mais pas décoratif.
Écran d'accueil : nom et titre d'une phrase alignés à gauche, sur un grand espace blanc de papier ; à droite, un avatar recadré sobrement ou une photo de style LinkedIn ; en dessous, deux liens de preuve.
Rythme : flux de CV d'une page, sections calmes, preuves de projet dans des petites fiches.
Sensation visuelle : comme un CV éditorial soigné d'un candidat international, pas comme une page d'atterrissage de startup.
Risque : si l'utilisateur veut une marque personnelle plus forte, cela peut sembler manquer de caractère distinctif.

Avant que l'utilisateur ne confirme le brief complet de contenu et de style, ne générez pas d'images de référence. Si l'utilisateur a choisi une option de style et n'a pas objecté au document de contenu, ne considérez cette réponse comme la première confirmation bloquante que si votre message indique explicitement que « cela verrouillera à la fois le contenu et le style ».

Utilisez ce modèle de message de fin de première étape :

Progression actuelle : Première Étape / Verrouillage du contenu et du style
J'ai préparé : résumé des sources de contenu, faits confirmés, recommandation de forme de site, planification des sections, risques de contenu et options de style.
Veuillez confirmer ou modifier :
1. La forme du site et la planification des sections
2. Tout le contenu marqué comme non confirmé
3. La direction visuelle : choisissez une option, combinez plusieurs options, modifiez les couleurs/la mise en page, ou fournissez vos propres références
Après confirmation, je passerai à la deuxième étape pour générer ou préparer les images de référence pour chaque section.

Deuxième étape : Verrouillage des images de référence

Utilisez les images de référence par section comme source factuelle visuelle.

Les prompts des images de référence doivent être basés sur le brief de contenu et de style confirmé : contenu approuvé, forme de site approuvée, direction visuelle choisie ou fournie par l'utilisateur, règles globales de chrome UI, et unités de contenu spécifiques à chaque section. Lorsque l'utilisateur attend un site personnel de haute qualité, ne générez pas d'images de référence basées sur un brief mince ou un contenu proposé par l'agent non approuvé.

Lisez toujours references/imagegen-frontend-web.md dans cette phase. Si la compétence autonome imagegen-frontend-web est disponible, utilisez-la pour compléter une direction artistique plus large dans le cadre du contrat strict du site personnel. Le groupe d'images de référence doit inclure une image horizontale par section confirmée, une composition forte, un monde d'identité personnelle unifié, et une topologie d'image réellement réalisable.

Si l'utilisateur préfère GPT web Image 2, écrivez des prompts qu'il peut copier-coller, plutôt que de générer directement les images.

Plan de génération des images de référence

Avant de générer une section, préparez d'abord un plan de génération d'images de référence concis. Il s'agit d'un artefact interne de la deuxième étape, n'ajoutant pas de nouvelle porte de confirmation utilisateur. Si un répertoire de projet existe, écrivez-le dans un document de restauration ou un petit fichier docs/reference-production-plan.md ; sans répertoire, conservez-le dans la sortie de travail de la deuxième étape.

Verrouillez d'abord l'empreinte stylistique commune à l'ensemble du groupe :

• Couleurs précises et leurs codes hexadécimaux
• Rôles typographiques pour l'affichage/le corps/les étiquettes/la navigation et tailles relatives
• Géométrie globale du chrome UI, langage des bordures/coins arrondis/ombres et famille des appels à l'action
• Matériaux, lumière, textures, palette de couleurs des photos, langage des illustrations/icônes
• Plage de densité, rythme d'espacement, rapport de format du canevas, et au maximum un motif signature optionnel
• Constantes qui ne doivent pas dériver, et une à deux dimensions autorisées à varier par section

Ensuite, spécifiez un contrat de rendu pour chaque section :

• C0 code-only : polices, mise en page et géométrie simple, aucun asset raster nécessaire
• C1 integrated-scene : UI de code superposée sur une scène fusionnée ; la scène peut être en full-bleed ou être une île visuelle délimitée
• C2 independent-media : coque de code avec un à trois photos, captures d'écran, couvertures ou maquettes de produit ayant une signification indépendante
• C3 scene-plus-identity : une scène fusionnée, plus un avatar, un logo ou une image de produit officiel provenant d'une source réelle ou à remplacer plus tard

Chaque contrat de rendu doit préciser : contenu géré par le code, matériel partagé à l'échelle du site autorisé, limites de la scène fusionnée, emplacements pour médias indépendants, assets d'identité/source réelle, éléments interdits de fusion, comportement responsive, zones de sécurité du texte, budget d'assets, et attribution topologique (section-specific ou structure partagée nommée avec justification). Pour les objectifs de haute qualité, complétez également le champ meaning du fichier references/visual-quality-gate.md : information en trois secondes, preuve personnelle, action de conception autoriale, niveau de focus, chemin de lecture, carte des blancs, signification des formes graphiques, liste des chevauchements, zones d'exclusion fermées et charge utile du premier écran. C0 code-only signifie 0 raster spécifique à la section ; si des textures de papier ou des bandes de numérisation font partie de l'empreinte verrouillée, un ou deux matériaux à l'échelle du site explicitement déclarés peuvent être réutilisés. Mais cela ne signifie pas qu'une section au contenu insuffisant, ne remplissant que la hauteur avec de grandes lettres, est terminée : outre les grandes lettres, il doit y avoir une deuxième décision de conception provenant du contenu, sinon raccourcissez, fusionnez ou reconcevez cette section. Chaque matériau partagé n'est généré qu'une seule fois et compté une seule fois pour l'ensemble du site. Par défaut, une section a un point focal visuel principal, au maximum une scène fusionnée, et pas plus de trois unités raster spécifiques à la section ; ce n'est que si l'utilisateur approuve explicitement une direction de « mur de preuves » dense que vous pouvez dépasser cette limite.

Générez d'abord la section d'ancrage qui définit le mieux l'identité, généralement le Hero. Les sections suivantes sont générées dans le même lot ; si l'outil d'image prend en charge l'entrée de référence, utilisez l'ancrage comme guide visuel, sinon réutilisez la même empreinte stylistique mot pour mot. N'ajoutez pas de porte de confirmation supplémentaire entre l'ancrage et les images suivantes.

Sortie par défaut :

• Une image de référence horizontale par section
• Pas de collage en longueur verticale pleine page
• Pas de planche multi-section fragmentée et difficile à lire
• Toutes les sections maintiennent une vision du monde d'identité personnelle cohérente
• Les images de référence doivent ressembler à des captures d'écran de site web réel, pas à des affiches
• Le texte et les contrôles gérés par le code doivent pouvoir être proprement séparés des matériaux raster
• Les scènes fusionnées statiques restent une unité visuelle complète ; les ombres, reflets ou occultations ne doivent pas traverser les limites entre les emplacements de médias indépendants

Avant de soumettre le groupe d'images de référence à la confirmation de l'utilisateur, effectuez un examen en quatre points :

1. Examen du sens visuel : exécutez tous les seuils stricts de references/visual-quality-gate.md, y compris la transmission en trois secondes, un seul point focal principal, une liste d'éléments intentionnels, une spécificité personnelle, une composition achevée, les limites supérieure et inférieure de densité, des blancs significatifs, la sémantique graphique, l'intégrité du recadrage, la sécurité des chevauchements et la charge utile du premier écran responsive. Une section peut être belle ou réalisable, mais si l'idée, la preuve ou la composition est faible, elle échoue.
2. Examen de cohérence : comparez chaque image à l'empreinte stylistique précise, vérifiez la navigation globale, les rôles typographiques, la palette, l'espacement, le langage des boîtes, la palette de couleurs des images, les motifs et la logique mobile. Il doit être évident d'un coup d'œil qu'il s'agit du même site.
3. Examen du rythme : listez la structure de composition de chaque section et vérifiez l'enveloppe de variation. Vous pouvez varier avec modération la tâche, l'échelle, l'alignement, le recadrage ou la densité d'une section à l'autre, mais ne forcez pas chaque écran à devenir un nouveau concept visuel. Effectuez un test de blocs gris : une fois les photos transformées en blocs gris, au moins la moitié des sections doivent encore avoir une conception grâce aux polices, à la mise en page, aux couleurs et à la structure.
4. Examen de faisabilité : comparez chaque image à son contrat de rendu. Si le texte du code et les matériaux raster sont inséparables, si les assets indépendants partagent des ombres/reflets durs, si un asset d'identité est fondu dans une scène générée, si un réarrangement responsive nécessite de déplacer des pixels à l'intérieur d'une seule image, si le budget d'assets est dépassé sans approbation, ou si des îlots d'image imprévus apparaissent, cette section échoue.

Lorsqu'une topologie d'image de référence échoue, utilisez redesign-required : conservez l'empreinte stylistique du site, régénérez uniquement la section défaillante, puis soumettez-la à la confirmation de l'utilisateur. Ne forcez pas une image de référence irréalisable dans la troisième étape en utilisant des tranches fragiles ou un code basse fidélité comme solution de contournement.

Une fois le groupe d'images de référence approuvé par l'examen, copiez-le dans un nouveau répertoire non écrasable, par exemple references/locked/v1/, et écrivez le SHA-256 de chaque image dans docs/identity-evidence.json. N'écrasez pas les fichiers verrouillés ; la régénération ou la restructuration doit créer une nouvelle version et réexécuter les examens de la deuxième étape concernés.

Lorsque la qualité de conception est importante, ou que l'utilisateur demande des conseils de goût, lisez simultanément references/taste-calibration.md et references/visual-quality-gate.md. Les échantillons de goût sont chargés de calibrer le monde visuel optionnel, tandis que la porte de qualité est chargée de juger si ce monde est vraiment exprimé clairement et complète la conception.

Utilisez ce modèle de message de fin de deuxième étape :

Progression actuelle : Deuxième Étape / Verrouillage des images de référence
J'ai préparé : empreinte stylistique de l'ensemble du site, contrat de rendu et de sens pour chaque section, images de référence, et examen du sens visuel/cohérence/rythme/faisabilité.
Veuillez confirmer ou modifier :
1. Accepter ces images comme objectif de construction
2. Spécifier les sections à régénérer
3. Ajuster la direction visuelle avant la construction
Après confirmation des images, je passerai à la troisième étape pour produire formellement l'inventaire de décomposition des assets : ce qui reste dans le code, ce qui est une scène fusionnée, ce qui est un média indépendant, ce qui doit provenir d'une source réelle, ce qui doit être bloqué, remplacé plus tard ou redesigned. J'attendrai votre confirmation avant de générer ou de chercher de nouveaux assets.

Troisième étape : Inventaire de décomposition des assets

Une fois le groupe d'images de référence confirmé, examinez d'abord les images de référence acceptées, ne générez pas d'assets et n'écrivez pas de code. Cette phase produit un inventaire de décomposition des assets destiné à être montré à l'utilisateur, puis s'arrête pour attendre sa confirmation.

Avant de produire l'inventaire, si reference-asset-splitter est installé, lisez-le et references/split-patterns.md ; sinon, lisez les versions intégrées references/reference-asset-splitter.md et references/split-patterns.md. Exécutez le classifieur à trois axes dans l'ordre : granularité des limites, support de rendu, niveau d'image. Ne réduisez pas les trois éléments en une seule phrase du type « cela a l'air complexe ».

Utilisez une priorité de conflit fixe : asset d'identité/source réelle ; contenu sémantique en direct et accessibilité ; interaction/remplacement/mise à jour/réarrangement responsive indépendant ; liste blanche du code vs signaux raster ; relations de fusion ; budget d'assets ; et enfin préférences esthétiques. La complexité visuelle elle-même ne peut ni forcer une décomposition fine ni prouver que le code peut réaliser une reproduction haute-fidélité.

L'objectif est d'être pratique, pas de sur-spécifier : dites à l'utilisateur quelles parties visibles doivent rester dans le code, lesquelles nécessitent des assets générés ou collectés séparément, lesquelles ont besoin d'assets transparents/de premier plan, lesquelles sont en arrière-plan, quels assets réels ne peuvent pas être falsifiés, et quelles décisions, si elles sont mal évaluées, affecteront le résultat final de la reproduction.

Cette phase crée ou met à jour un artefact de restauration visible. Les formes acceptables incluent :

• docs/restoration-plan.md, fusionnant la cartographie des images de référence, le manifeste des assets et le bref d'exécution de reproduction ultérieur
• docs/reference-to-build-map.md plus docs/asset-manifest.md
• Si le dépôt a déjà une convention de documentation, des documents intra-projet équivalents peuvent également être utilisés

L'artefact doit être en place avant la génération des assets et l'édition du code de la page. Il doit lister chaque image de référence confirmée et chaque section/page. Un simple résumé dans le chat, un raisonnement caché ou un message de progression d'une phrase ne suffit pas.

L'inventaire de décomposition des assets à montrer à l'utilisateur doit être plus court que l'artefact interne. Pour chaque section, incluez :

• Éléments gérés par le code : texte, navigation, boutons, mise en page, formes simples, étiquettes et animations nécessitant une édition
• Matériel partagé à l'échelle du site : texture de papier, granulés, bandes de numérisation optionnels ou autre matériau d'empreinte généré une seule fois et réutilisé, ou none
• Asset de scène fusionnée : arrière-plan complet ou scène fusionnée délimitée, texture, carte, champ photo, monde de bureau, collage de fiches, ou none
• Asset de média indépendant : avatar, maquette de produit, capture d'écran, photo, couverture, illustration autonome, ou none
• Asset réel existant : photo, logo, capture d'écran de produit, asset officiel fourni par l'utilisateur, ou fichier source à copier
• Asset générable : image d'ambiance, décoration, maquette de produit abstraite, arrière-plan ou stand-in pouvant être généré en toute sécurité
• Bloqué, à remplacer plus tard ou nécessitant une refonte : personne réelle, marque/logo/image de produit officiel, capture d'écran manquante avec revendication, ou topologie d'image de référence impossible à décomposer fidèlement
• Pourquoi c'est important : quel risque de fidélité de reproduction cela pose si la limite de l'asset est mal jugée

Règles des limites des assets

Utilisez les règles suivantes lors de la préparation de l'inventaire de décomposition des assets de la troisième étape et de la validation des assets de la quatrième étape.

Après que les images de référence existent, avant d'écrire le code, exécutez séparément les trois axes de jugement :

1. Limites : seule l'interaction indépendante, le remplacement/la mise à jour, la sémantique indépendante ou le réarrangement responsive forcent une décomposition fine. Après avoir supprimé les nœuds de code et les nœuds indépendants forcés, fusionnez les objets raster statiques avec chevauchement, ombres/reflets inter-objets, textures continues, perspective, lumière ou relations matérielles. Un même groupe de fusion est par défaut un seul asset, sans tenir compte du nombre de fiches qu'il contient.
2. Support : seuls le texte en direct, la mise en page DOM, les couleurs unies, les bordures/coins arrondis/ombres normaux, les dégradés CSS simples, les icônes standard, la grille/les points de base et la géométrie SVG simple peuvent être en code natif. Les photos, les textures irrégulières, l'écriture manuscrite/au pinceau, les illustrations complexes, les maquettes UI/produit denses, les textures naturelles, la 3D, les ombres/reflets réalistes ou les effets raster partagés doivent être des images. Lorsque le comportement en direct et la fidélité raster sont tous deux nécessaires, utilisez l'hybride : l'image se charge du visuel, le code se charge de la coque, du texte et de l'interaction.
3. Niveau : integrated-scene est un visuel fusionné lié à une section, pouvant être en full-bleed ou occuper uniquement le côté droit du Hero ; independent-media est une photo, une capture d'écran, une couverture, une maquette, un avatar ou une illustration autonome pouvant être remplacé indépendamment. La transparence ou non ne détermine pas la classification.

Par défaut, chaque section a au maximum une scène fusionnée, et pas plus de trois unités raster au total. Les emplacements de médias indépendants constituent chacun leur propre asset, les groupes statiques fusionnés restent un seul. Tout le texte final, la navigation, les boutons, les formulaires, les données factuelles et les interactions restent dans le code. Un arrière-plan artistique en pleine page est autorisé, mais il n'est pas permis de cuire le contenu géré par le code avec l'arrière-plan en une seule capture d'écran pleine page.

Lorsque le texte en direct ne peut pas être séparé du matériau, qu'un élément d'interaction partage une ombre/un reflet dur avec une autre couche, qu'un asset d'identité réelle est irréversiblement fondu dans une scène générée, que la version mobile nécessite de déplacer indépendamment des pixels à l'intérieur d'une seule image, ou que la restructuration dépend de coutures de pixels fragiles, utilisez redesign-required, ne forcez pas la décomposition. Conservez l'empreinte stylistique et renvoyez uniquement cette section à la deuxième étape pour régénération.

Chaque image de référence confirmée doit être enregistrée dans l'artefact de restauration visible via une cartographie reference-to-build :

Reference: 01-hero.png
Code layer: nav, headline, subhead, CTA group, portrait frame, proof labels
Integrated scene: hero-finance-desk.png, 16:9, full-bleed, overlay sombre autorisé
Independent media: portrait.png, 24% de la largeur à droite ; product-card-mock.png, 22% de la largeur en bas au centre
Must preserve: ambiance photo sombre/bureau/finance, proportions du grand titre à gauche, carte avatar à droite, CTA vert, espacement de la navigation en haut
Allowed deviation: les étiquettes de graphique dans l'image générée sont remplacées par le texte confirmé rendu par le code
Risk trigger: les marques d'entreprise non confirmées ou l'avatar de l'utilisateur doivent d'abord être confirmés

Chaque section doit couvrir toutes les zones significatives : rôle sémantique, déclencheurs de limites, résultat de la liste blanche du code, signaux raster, groupe de fusion, propriétaire (code ou asset), emplacement (integrated-scene, independent-media ou none), périmètre de réutilisation (global ou section), provenance, mode responsive, décision/statut (ready, generate, find/copy, code-native, replace-later, blocked ou redesign-required), source/action et chemin final. S'il n'y a pas d'image spécifique à une section, expliquez clairement pourquoi et listez séparément le matériel partagé réutilisé.

Enregistrez le manifeste des assets (asset, rôle, déclencheur de limite, signal raster, groupe de fusion, emplacement, périmètre de réutilisation, provenance, boîte de référence dans l'image, rapport d'aspect, taille relative, mode responsive, statut, chemin final), afin que lors de la reproduction, chaque asset puisse être placé dans un conteneur de rapport d'aspect fixe, plutôt que de laisser la taille d'image d'origine déterminer la mise en page.

Utilisez ce modèle de message de fin de troisième étape :

Progression actuelle : Troisième Étape / Inventaire de décomposition des assets
J'ai préparé : cartographie reference-to-build, liste de décisions d'assets et première version du manifeste des assets.
Veuillez confirmer ou modifier :
1. Quels éléments restent en code natif
2. Quelles scènes fusionnées et médias indépendants doivent être générés, copiés ou remplacés plus tard
3. Quels avatars réels, logos, captures d'écran de produit ou assets officiels ne peuvent pas être générés
4. Les hypothèses d'interaction ou de remplacement réellement ambiguës dans la liste
Après confirmation, je passerai à la quatrième étape pour générer ou rassembler uniquement les assets approuvés. Je ne modifierai pas encore le code de la page. Si utile, je peux traiter les lots d'assets approuvés en parallèle ; si vous préférez un ordre séquentiel, veuillez le préciser.

Quatrième étape : Génération et validation des assets

Une fois l'inventaire de décomposition des assets confirmé, générez, copiez, recherchez ou rassemblez uniquement les assets approuvés. Montrez ensuite à l'utilisateur les résultats des assets et un bref d'exécution de reproduction court. Ne commencez pas à coder la page tant que l'utilisateur n'a pas accepté la validation des assets.

La validation des assets doit inclure :

• Chemin final de chaque asset prêt
• Section et élément visible auxquels chaque asset correspond
• Source : généré, fourni par l'utilisateur, officiel/copié, code natif, ou à remplacer plus tard
• Résultat de vérification : accepté, nécessite une régénération, faible mais utilisable avec un écart nommé, bloqué, ou placeholder à remplacer plus tard
• Notes de prompt/source nécessaires à la reproduction de l'asset

Chaque asset image n'a que deux sources légales :

1. Assets réels déjà collectés lors de la saisie de la première étape, comme des photos, logos, captures d'écran de produits ou fichiers médias de l'utilisateur. Ne demandez pas temporairement de nouveaux assets à l'utilisateur à la quatrième étape, sauf si l'utilisateur choisit lui-même d'en fournir ; pour le contenu toujours non fourni à ce stade, générez un stand-in, utilisez un placeholder code natif, marquez-le replace-later, ou marquez-le blocked s'il est trompeur.
2. Nouvelle génération d'image : doit être ancrée à la zone de référence correspondante. Avant d'écrire un prompt de génération, rouvrez l'image de référence confirmée et transcrivez la zone cible en une liste visuelle : type de scène (collage de fiches papier / scène photographique / illustration plate / maquette UI / champ de texture), chaque objet principal et sa position approximative, codes hexadécimaux de la palette, lumière, matériaux, disposition des blancs. Le prompt de génération doit être écrit à partir de cette transcription — même type de scène, même liste d'objets, même composition, même palette — jamais à partir d'un nom d'asset ou d'un résumé d'une ligne de l'inventaire de décomposition. Si l'outil de génération d'images prend en charge l'image d'entrée, joignez également la zone de référence comme référence visuelle. Un prompt qui ne décrit que des catégories de contenu (« un créateur assis à un bureau avec un ordinateur portable et des fiches ») sans transcription est défectueux : il autorise le modèle à inventer une scène différente. Pour le texte de remplacement dans les assets, exigez « barres et gribouillis de placeholder abstraits et illisibles » — n'utilisez pas le mot « grec », car les modèles de génération d'images pourraient l'interpréter littéralement comme du texte en grec.

Les images de référence confirmées sont l'objectif de construction et la base de référence de la QA, pas une source d'assets. Ne recadrez, ne capturez pas d'écran, ne tranchez pas et n'extrayez pas de zones d'images de référence dans la construction ; le recadrage hérite d'une basse résolution, de texte cuit et de bords cassés. Il n'y a pas de statut extract dans le manifeste. Lorsqu'une zone de référence a besoin d'un asset, régénérez-la en utilisant une description visuelle de cette zone.

…

[truncated for translation]