Boucle QA et gap visuel
Charger cette ressource uniquement quand un clone exécutable requiert la compilation/QA, l'extraction de résultats, la revue visuelle, la correction de gaps, la publication, ou le reçu d'achèvement de migration. Elle en est propriétaire de la boucle d'acceptation frontend terminal.
Lire references/qa-checklist.md, references/post-build-gap-contract.md, et references/output-contract.md.
Compiler le projet ; corriger les erreurs de compilation et réexécuter. Valider les déclarations de polices locales, le comportement des liens internes/fallback, le SEO, les états de contrôle, les assertions de normalisation UI, et chaque scène core avec interaction QA supportée par navigateur avant comparaison.
Lire extraction/latest.json, le manifeste figé, build/section-implementation.json, et les champs d'acceptation unitaire avant QA. Attribuer chaque constatation à la plus petite unité propriétaire et son hash de spec. Une evidence manquante locale ou un gap de faible confiance ne bloque pas la QA non liée ou la page d'accueil assemblée.
Lancer le clone et exécuter post-build-gap.mjs --result-url <local-url>. Il réextrait chaque route de résultat in-scope via le même pipeline que la source, mais lit l'analyse source originale immuable directement depuis docs/site-clone/ ; les itérations normales de gap ne doivent pas recapturer ou copier un source-snapshot. Inspecter chaque paire screenshot source/résultat dans gap-analysis/latest.json. Écrire le visual-review.json de l'itération canonique avec un enregistrement complet par paire : pairId et viewport correspondants, une observation non vide, et soit des findings canoniques liés, soit une rationale non vide de no-identity-gap. Exécuter finalize-gap-review.mjs ; ne pas utiliser un flag ou une affirmation textuelle comme substitut à l'evidence d'inspection.
Corriger les findings dans l'ordre du contrat : structure/texte/médias manquants, composition et dimensions importantes, interactions core, puis polish de support. Avant un lot de fix, nommer la(les) section(s) cible(s), le changement visible attendu, et la(les) paire(s) screenshot exacte(s). Recompiler, réextraire, et créer une nouvelle itération immuable. Si l'itération précédente avait des findings critiques/high, compléter le visual-progress.json généré : pour chaque finding bloquant antérieur, lier le screenshot source canonique, le screenshot résultat antérieur, le screenshot résultat actuel, et une observation avant/après. Conserver une modification d'implémentation uniquement quand cette evidence indique improved ; rapporter no-visible-improvement ou regressed avec honnêteté et rediagnostiquer. Après deux tentatives no-visible-improvement pour la même section, cesser de répéter la même tactique. Le budget extraction-gap est aussi au maximum deux tentatives ciblées distinctes ; répéter une tactique sans nouvelle evidence n'est pas du progrès. Après épuisement, préserver l'unité affectée comme provisoire et continuer. Les scores, les compteurs de findings, et le code modifié ne sont pas une evidence de progrès visuel. En travail manuel/standalone, utiliser au maximum deux passes de fix par défaut et rapporter les findings acceptés résiduels medium/low. En travail de compilation one_click migration, continuer automatiquement jusqu'à aucun finding d'identité critique/high restant, un vrai blocker durable, ou cinq cycles de gap visuel complétés. Au cap des cinq cycles, finaliser l'itération révisée cinquième et écrire un reçu d'achèvement done_with_gaps quand des blockers subsistent ; ne pas créer de sixième cycle ou prétendre à l'acceptation.
Avant d'arrêter une exécution one_click pour défaillance shell/navigateur/réseau, utiliser la politique de shell aligné et de retry d'escalade de la ressource contexte. Si l'état d'automation demande un facelift, retourner au superviseur root après acceptation normale du clone ; il doit charger la ressource facelift séparée avant tout reçu final. Sinon, sur acceptation d'achèvement migration, écrire website/completion.json avec finalize-migration-website.mjs --handoff ... --release-url .... L'import backend ou la première compilation réussie n'autorisent jamais ce reçu. Si l'achèvement ne peut pas procéder, enregistrer un reçu bloqué avec evidence, récupération tentée, propriétaire, et action exacte de déblocage, puis retourner le contrôle au superviseur root.
Générer final-report.json et .md. Pour chaque gap non résolu ou accepté par l'utilisateur inclure l'unité/localisation, le fait indisponible et raison, evidence/confiance/tentatives, implémentation provisoire, hypothèses/omissions, checks affectés/dépendants, et choix d'accepter, réessayer/corriger, fournir du matériel, remplacer, omettre, ou laisser non résolu. Les gaps locaux restants produisent done_with_gaps ; seul un blocker global produit blocked.