boyang-hu/website-rebuild-skill

Website Rebuild (Réplication 1:1 d'un site primé)

Répliquez un site web créatif primé (WebGL / narration défilante / portfolio) avec une approche forensique en un projet autonome, exécutable et vérifiable. Il ne s'agit pas d'une imitation « qui ressemble à » – c'est une transplantation ligne par ligne utilisant le bundle source du site d'origine comme seule spécification, avec un processus de validation quantifié.

Cette méthodologie est distillée à partir de six projets pratiques consécutifs (le temps de réalisation passant de 6,5 semaines à 1 jour), puis enrichie par 22 réplications complètes + la sauvegarde de 5 sites morts, et calibrée par l'exploration des limites de 43 sites (la liste des sites vérifiés se trouve dans le README du dépôt).

Conditions préalables et autorisation ⛔ À lire impérativement

Cette compétence est destinée à la réplication fidèle à des fins d'apprentissage et de recherche pour étudier les techniques de mise en œuvre de sites créatifs primés. Elle s'applique aux sites web dont vous êtes propriétaire, pour lesquels vous avez obtenu une autorisation, ou qui sont accessibles publiquement et autorisent l'apprentissage et l'imitation. Ce n'est pas un outil pour collecter sans autorisation du contenu protégé, contourner des contrôles d'accès, ou détourner commercialement le travail d'autrui.

Lors de l'exécution, respectez les limites suivantes :

• Respectez les règles du site cible : respectez son robots.txt, ses conditions d'utilisation et ses droits d'auteur ; maintenez une fréquence de capture basse, une seule session, et ne soumettez pas le site cible à une charge anormale. ⛔ Le robots.txt est une déclaration d'autorisation par chemin, pas un interrupteur global pour tout le site – déterminez chaque URL individuellement (sélection de groupe → correspondance la plus longue → aucune correspondance signifie autorisé), n'interdisez pas « tout le site » simplement parce qu'il existe une ligne Disallow (presque tous les sites commerciaux ont des Disallow pour /cart, /checkout, /admin) ; les interdictions doivent être classées par catégorie d'action, seules les interdictions concernant la « capture » affectent la portée de l'image miroir, les interdictions concernant les transactions signifient simplement « n'allez pas cliquer sur le paiement ». ⭐ « Je ne comprends pas / je ne suis pas sûr » n'est pas égal à « interdit » : soumettez le problème à l'utilisateur, ne vous arrêtez pas, et encore moins réduisez vous-même la portée de la capture. La méthode de lecture se trouve dans references/legal-and-deploy.md §0.3.
• Ne touchez pas aux limites protégées : ne collectez pas de contenu nécessitant une connexion, un paywall ou une autorisation pour y accéder ; cette compétence ne traite que des ressources accessibles au public de manière anonyme. Si le site cible interdit explicitement ce type de copie, arrêtez-vous et informez l'utilisateur – ce qu'est une « interdiction explicite » est défini dans les quatre seuils codés en dur legal-and-deploy.md §0.3.6, toute autre incertitude est soumise à l'utilisateur, pas d'arrêt.
• La sortie est privée par défaut : noindex par défaut, pas de déploiement public. Avant toute publication, une vérification des droits d'auteur par actif doit être effectuée et une mention « Réplique non officielle » avec l'attribution à l'auteur original doit être clairement indiquée (voir references/legal-and-deploy.md).

⛔ Le jugement légal incombe à l'utilisateur, la compétence ne fait que collecter des preuves et les présenter (trois règles, valables tout au long du processus) :

1. La décision appartient à l'utilisateur : la compétence collecte des faits (attribution par actif, statut de la licence, titulaires de droits tiers, si le site d'origine est toujours en activité, les identifiants tiers dans le produit), liste les options avec leurs limites de risque respectives, donne des recommandations et des justifications ; pour tout ce qui concerne « peut-on le rendre public / le déployer / le redistribuer / l'exposer à l'extérieur », le problème doit être explicitement soumis à l'utilisateur via les outils User Input Tools ci-dessous, l'agent n'est pas autorisé à tirer une conclusion juridique par lui-même et à continuer.
2. En l'absence de décision explicite de l'utilisateur, exécutez les paramètres sécurisés par défaut : dépôt privé + noindex + pas de déploiement public + pas de redistribution. Expliquez à l'utilisateur qu'il s'agit d'une action par défaut (« Avant votre décision, je ne le publierai pas »), pas une conclusion juridique prise par l'agent – la responsabilité des deux est complètement différente. L'agent ne peut exécuter le défaut que du côté conservateur, toute action vers le côté public nécessite une décision explicite de l'utilisateur.
3. ⛔ Les considérations légales ne doivent pas réduire l'intégrité de l'image miroir ou la couverture des portes : l'image miroir est la base de preuve, l'intégrité est une invariant technique (la méthode en quatre passes, la porte de fermeture, GAP=0 tout est construit dessus). Ne pas capturer ne peut être motivé que par des raisons techniques (pas un fichier / le serveur ne le fournit pas / nécessite une autorisation ou un état de connexion / interdit explicitement par le site source), tout doit être enregistré ; il est interdit de laisser des trous pour des raisons légales comme « de toute façon ce ne sera pas public », « on n'a pas besoin de stocker une copie de plus ». Preuve empirique : dans un certain projet, sous prétexte que « la sortie ne sera jamais publiée », une classe d'actifs a été « enregistrée, non récupérée », ce qui a entraîné l'absence d'environ 60 % des actifs tandis que les cinq portes restaient toujours vertes, cachant quatre jalons [objectarchive]. Les décisions juridiques déterminent comment la sortie est utilisée, pas si la base de preuve est complète.

Champ d'application ⛔ À lire impérativement

Domaine principal (Classe A) : sites avec hébergement statique dont tout le comportement (animations/interactions) est stocké dans des actifs statiques côté client – scènes WebGL/Canvas impératives, timelines GSAP, fichiers de données pré-cuites (GLB/.buf/.riv), bundles minifiés ou non obscurcis. La grande majorité des sites créatifs de style Awwwards entrent dans cette catégorie.

Support conditionnel (Classe B) : le pipeline est valide mais nécessite un traitement supplémentaire (découplage de la couche plateforme Shopify, actifs de buckets de stockage tiers, instantanés d'API runtime, déploiement de payload SSG). La version actuelle du guide couvre la plupart des scénarios de classe B, mais pour les cas non couverts, le risque doit être clairement signalé à l'utilisateur.

Refus explicite (Classes C/D) :

• C1 (possible depuis v0.3 : rétro-ingénierie par reconstruction) : le composant serveur source n'est en effet pas envoyé, mais sa sortie complète (le flux flight) est intégrée dans le HTML de chaque page, et constitue une spécification comparable. Procédure : flight-decode pour établir le système de coordonnées → reconstruire un projet Next.js constructible (les composants côté client sont traduits mot à mot comme pour C2, les composants serveur sont déduits de l'arbre flight comme des inférences explicitement enregistrées) → la porte sémantique verify-flight pour la validation (bijection globale des ID de modules). Testé sur rauchg.com (Next 16/Turbopack) : 18/18 routes sémantiquement cohérentes, structure de réponse en aveugle ≈95%/comportement ≈98%. ⚠ Pour C1, fusion L2/L3 – le premier artefact est « code source humain + preuve de porte d'équivalence ». Processus complet dans references/rsc-reconstruction.md.
• C2 (possible, exécuté comme la classe A) : ⭐ L'écriture est déclarative mais le code source est envoyé (produits de compilation R3F / Theatre / Vue SFC). Testé sur un site R3F : dans le callback useFrame, il n'y a que du code impératif ordinaire comme MathUtils.damp(x, y, 7, t), découpage mot à mot de 18 modules échangés dans la page, résultat CLEAN, 8 canvas complets, similarité visuelle 99,5%. Le découpeur ne se soucie pas du paradigme – il découpe des octets. Le moteur de rendu est servi comme couche plateforme depuis l'image miroir. ⛔ Le discriminant n'est pas le nom de la bibliothèque, mais « le client détient-il la source du comportement ? » (scope-and-fingerprint.md §4.0.1).
• D : le comportement principal est côté serveur (sites CMS, panier/stock e-commerce, bucket d'expériences A/B, injection de personnalisation) – le client n'a pas d'objet portable à répliquer, et la validation déterministe n'a pas de base de référence.

Classe X (sauvetage possible) : le site d'origine a disparu (changement de propriétaire de domaine / récupération par la plateforme / suppression de chemin / remplacement sur place), mais Internet Archive a souvent des captures – scripts/wayback-mirror.mjs sélectionne un moment cohérent à partir de l'index CDX en utilisant un point d'ancrage + fenêtre temporelle, capture les octets originaux avec id_ dans une image miroir standard (les portes aval fonctionnent de la même manière), les trous sont enregistrés comme des faits dans wayback-holes.txt (méthode de lecture et processus dans references/archival-rescue.md). ⭐ Le résultat du sauvetage est une image miroir standard – la classe X peut parcourir tout le processus L3 (testé sur first-launch : coque stratégie A + porte numérique 9 856 échantillons tous égaux + dans la bande passante des pixels + porte d'auto-contenance, aucune porte n'a nécessité de modification sémantique). ⛔ « Aucune couverture CDX signifie vraiment impossible » se lit par couche d'actif, pas par site : le robot IA n'exécute pas JS, pour les sites pilotés par une liste/assemblage, la couverture du code peut être de 100 % tandis que la couverture visuelle est nulle (testé : 157/160 actifs aucune capture à aucune époque, écran blanc hors ligne) – Étape 0, effectuez d'abord une reconnaissance de couverture par couche (déduction + requête de préfixe CDX) pour estimer la profondeur du sauvetage, voir archival-rescue.md §1.9. Le taux de disparition effectif des sites primés au fil des ans est d'environ 29% – c'est aussi la raison pour laquelle « faire une image miroir immédiatement » est la première discipline de cette compétence.

La classification est déterminée par la reconnaissance de l'empreinte à l'Étape 0, l'arbre de décision complet est dans references/scope-and-fingerprint.md. En cas de refus, expliquez la raison et dites à quelle classe appartient le site, ne forcez pas l'exécution.

User Input Tools

Lorsque vous devez poser une question à l'utilisateur (confirmation de la portée, décision légale, décision de dépendance externe) : utilisez d'abord l'outil de questionnement intégré du runtime actuel (par exemple AskUserQuestion) ; s'il n'y en a pas, affichez une liste numérotée de questions et demandez à l'utilisateur de répondre par le numéro. Regroupez plusieurs questions en une seule fois si possible. Les questions juridiques doivent être rédigées selon le modèle en cinq parties de legal-and-deploy.md §0.1 : faits / points flous / options / limites de risque de chaque option / recommandation et action par défaut actuelle.

Constitution (six règles, valables tout au long du processus)

Les six règles suivantes sont appelées « de niveau constitutionnel » dans les six projets sources, toute violation sera remboursée sous forme de bug dans les étapes suivantes :

1. L'image miroir est sacrée et ne doit pas être contaminée : les fichiers disque mirror/ ne sont jamais modifiés ; toute adaptation de localisation (réécriture CDN, stub de lien externe) est effectuée dynamiquement au niveau de la réponse du service.
2. Le code source du site est le seul arbitre, ne corrigez pas à l'œil : chaque modification trouve d'abord le numéro de ligne d'appartenance dans le bundle/CSS/l'image HTML miroir avant d'être appliquée. Do not tune visuals, motion, or interaction by eye.
3. Tout ce que le site source a doit être présent, ce qu'il n'a pas ne doit pas être fait : ne créez pas de CSS/JS compensatoire. Mieux vaut ressembler moins d'abord que d'inventer des règles – les correctifs auto-créés se transformeront en bugs une fois l'alignement mécanique effectué.
4. Les bugs, le code mort, les écritures bizarres sont copiés sans correction : chaque écriture bizarre dans le code compressé peut être le comportement lui-même. « Corriger gentiment » un bug no-op a déjà provoqué un crash de transition (preuve empirique dans porting-discipline.md).
5. Les écarts intentionnels doivent être enregistrés : écrivez « comment le site source fait / comment nous faisons / pourquoi / dans quelles conditions reconsidérer ». Toute différence non enregistrée est considérée comme un bug.
6. Le code et la documentation dans le même commit : chaque jalon est soumis par paire (Port xxx + Update rebuild plan: xxx), le journal contient systématiquement le résultat / la validation / les leçons / le point de rupture suivant (avec numéro de ligne).

⭐ Règle 3 à la frontière de M(n+1) : src/ est un dérivé explicitement enregistré, pas une affirmation sur le site source, donc renommer, diviser des modules, écrire des commentaires dans src/ n'est pas considéré comme une « invention » – la règle 3 contraint « créer un comportement pour qu'il ressemble à », pas « rendre le code déjà prouvé équivalent lisible ». Mais deux limites strictes restent immuables : ① La réécriture structurelle est interdite par défaut (fusionner des doublons, extraire des fonctions communes, changer des algorithmes – elles rendent l'équivalence indécidable) ; ② Les spéculations dans les commentaires doivent être marquées comme telles, il est interdit d'écrire des suppositions issues de notes de rétro-ingénierie comme des affirmations. port/ et mirror/ restent intouchables, pas un seul octet. Voir references/readable-source.md §3.4 et §5.

Workflow

Progress Checklist

[ ] Step 0  Reconnaissance d'empreinte et porte de portée ⛔ (classification A/B/C/D/X ; refus ou orientation pour C/D/X, ne pas passer à l'étape suivante)
[ ] Step 1  Évaluation de démarrage (invalidation de l'architecture, notation de difficulté par élément, estimation de la durée, confirmation de la portée + point final L1/L2/L3 avec l'utilisateur)
[ ] M0      Capture d'image miroir forensique ⛔ (robot BFS + complétion CDP + registre manifeste ; GAP=0)
[ ] M0.5    Faire fonctionner l'image miroir hors ligne ⛔ (zéro 404 / zéro erreur console / zéro lien externe ; serve.mjs sert) ← Point final L1 Archive d'image miroir
[ ] M1      Rétro-ingénierie et établissement du système de coordonnées ⛔ (dépliage _pretty versions épinglées ; engine-notes avant tout code ; stack technologique verrouillée ; REBUILD_PLAN établi)
[ ] M2+     Transplantation strictement tracée (jalons par ordre de dépendance ; d'abord une coupe verticale d'une chaîne de bout en bout ; chaque jalon testé à froid + porte CLEAN)
[ ] M(n-1)  Validation par comparaison (sélection du type de porte selon l'arbre de décision de verification-gates.md ; correction de la cause racine, pas de réglage pour aplatir)
[ ] M(n)    Clôture ⛔ (révision à froid / vérification de la liste des modules ; collecte des preuves de droits d'auteur + soumission à l'utilisateur – doit être terminé avant le déploiement public) ← Point final L2 Réplication d'ingénierie
[ ] M(n+1)  Transformation en code source (port/ → src/ : diviser les modules, désobfusquer et renommer, ajouter des commentaires, auto-contenu) ← Point final L3 Code source

⛔ = Porte bloquante : ne pas passer à l'étape suivante si les critères de validation ne sont pas atteints.

Flow

Step 0 — Reconnaissance d'empreinte et porte de portée. Chargez references/scope-and-fingerprint.md, exécutez le protocole de détection sur l'URL fournie par l'utilisateur (GET au niveau du chemin, identité de l'URL finale, diff de double capture, validation de l'espèce/âge, inspection initiale du bundle), produisez la classification et la justification. Les classes A/B continuent ; pour C/D/X, expliquez à l'utilisateur puis arrêtez-vous ou orientez-le.

Step 1 — Évaluation de démarrage. Chargez references/recon-and-rating.md. Invalidez d'abord les hypothèses d'architecture (les tables de dépendances peuvent mentir), notez la difficulté par élément (actifs/3D/orchestration de défilement/format privé/couche plateforme), confirmez la portée de la réplication (site entier ou pages spécifiques) et les attentes avec l'utilisateur.

⭐ Dans la même question, laissez l'utilisateur choisir le point final (trois niveaux d'échelle, demandez avec la conclusion de classification et l'estimation du coût par niveau, ne listez pas les options de manière sèche) :

Point final	Question à laquelle il répond	S'arrête à	Utilisation typique
L1 Archive d'image miroir	À quoi ressemblait-il	M0.5	Archivage, visualisation hors ligne (taux de disparition annuel des sites primés d'environ 29%)
L2 Réplication d'ingénierie	Que faisait-il	M(n)	1:1 déployable et vérifiable (y compris la collecte de preuves de droits d'auteur et l'évaluation du déploiement)
L3 Code source	Comment était-il fait	M(n+1)	Recherche et apprentissage des techniques de mise en œuvre

L'échelle est monotone, choisir le niveau inférieur n'est pas une perte : chaque niveau est un préfixe du suivant, la discipline de l'image miroir garantit que la partie sensible au temps est toujours effectuée en premier – si vous choisissez L1 aujourd'hui, vous pouvez passer à un niveau supérieur plus tard (expliquez cela à l'utilisateur). « L'utiliser pour son propre projet » (transformer en échafaudage) n'est pas un stade de cette compétence – si l'utilisateur le demande, dirigez-le vers references/beyond-the-rebuild.md pour la transition, c'est son projet, la compétence s'arrête là où « une personne peut lire la vérité ».

M0 / M0.5 — Capture d'image miroir forensique. Chargez references/mirroring.md. Utilisez scripts/mirror-site.mjs pour le crawling BFS + scripts/netcapture.mjs pour la complétion par navigateur réel, enregistrez chaque fichier dans le manifeste avec sha256, discipline redirect: manual, décisions par dépendance externe. scripts/verify-mirror.mjs est la porte de l'image miroir elle-même (cinq assertions, exécutées avant la porte hors ligne – toutes les portes aval demandent « le rendu est-il possible ? », une image miroir erronée peut les rendre toutes vertes ; un HTTP 200 n'est pas une preuve que vous avez obtenu cette ressource). scripts/serve.mjs sert l'image miroir, validation hors ligne. Cette étape est toujours effectuée en premier – le site d'origine peut disparaître ou changer à tout moment, l'image miroir est la seule base de preuve du projet entier et le serveur de référence pour toutes les comparaisons ultérieures.

M1 — Rétro-ingénierie et établissement du système de coordonnées. Chargez references/reverse-engineering.md. ⛔ La première action est de déterminer la forme du bundle (concaténation plate / empaquetage modulaire / plusieurs chunks), puis choisir l'outil – la table de couches analyse les déclarations de premier niveau, alors que le nombre de déclarations de premier niveau d'un produit d'empaquetage webpack est 0, les limites et les arêtes de dépendance sont définies par l'empaqueteur (testé : 24 378 lignes → 569 modules prêts à l'emploi, en utilisant scripts/module-map.mjs). Si le conteneur n'est pas reconnu, FATAL, il est interdit de revenir à la table de couches (§0.5). scripts/beautify-bundle.mjs (js-beautify version 1.15.1 épinglée) déplie le bundle dans _pretty/, après quoi les numéros de ligne sont le seul système de coordonnées de traçage du projet. Écrivez d'abord docs/engine-notes.md (modèle : assets/templates/engine-notes.md) avant d'écrire du code. Déterminez la version exacte de la stack technologique à partir des preuves du bundle. Pour les animations pilotées par les données, dumpez d'abord le registre numérique. Établissez REBUILD_PLAN.md (modèle : assets/templates/rebuild-plan.md).

M2+ — Transplantation strictement tracée. Chargez references/porting-discipline.md, et chargez les guides de scénario correspondants selon la table de routage des branches. Chaque fichier transplanté comporte l'intervalle de lignes source en en-tête ; GLSL/constantes magiques/données sont extraits mot à mot ; les scripts d'actifs de données sont extraits et enregistrés, pas recopiés à la main.

M(n-1) — Validation par comparaison. Chargez references/verification-gates.md et references/determinism.md. Pour la largeur du rendu du site entier, utilisez scripts/sweep-routes.mjs (un seul navigateur pour toutes les routes, 0 erreur/0 échec/0 lien externe par route + crochets d'interaction et collecte par route), pour la profondeur d'une route unique, utilisez probe.mjs – ⛔ ne créez pas manuellement une boucle qui lance Chrome route par route, le coût est compté en nombre de lancements de navigateur, et les sondes concurrentes se récoltent mutuellement en orphelins. ⚠ Avant d'attribuer les résidus, établissez d'abord la bande passante d'auto-comparaison (pixelcompare --self, ≥4 fois par côté, exécution entrelacée) – tout résidu sans bande passante est UNCLASSIFIED, et UNCLASSIFIED est un échec, pas une réussite. Sélection du type de porte : s'il y a un HTML SSR/statique, établissez d'abord une porte d'octets → pour les scènes DOM statiques, gelez la source d'entropie et passez par byte-equal → pour les scènes vivantes (WebGL/vidéo/phase aléatoire), dégradez vers des métriques quantifiées + classification du bruit → pour les animations pilotées par les données, ajoutez une porte de sonde numérique → la porte CLEAN comme filet de sécurité tout au long. Avant de juger d'un bug de timing, calibrez d'abord la sonde (references/environment-traps.md).

M(n) — Clôture. Révision à froid : vérifiez un par un l'emplacement de chaque classe/module de premier niveau du bundle (les tests fonctionnels ne peuvent pas détecter l'absence d'un bloc entier, seule une vérification de liste peut le faire). Chargez references/legal-and-deploy.md pour effectuer la collecte de preuves de droits d'auteur et soumettre la décision à l'utilisateur – avant la décision de l'utilisateur, exécutez les paramètres sécurisés par défaut (privé + noindex + pas de déploiement), avant toute publication, une vérification des droits d'auteur par actif doit être effectuée et une mention « Réplique non officielle » doit être clairement indiquée.

M(n+1) — Transformation en code source. Chargez references/readable-source.md. Jusqu'à M(n), le résultat est prouvé correct mais illisible (testé : 14 271 lignes entassées dans un seul fichier, e apparaît 2 962 fois, les commentaires occupent 0,2%). Cette étape réécrit port/ en src/ : diviser les modules → désobfusquer et renommer en toute sécurité dans le scope → ajouter des commentaires par section → copier les actifs pour l'auto-contenance. ⛔ La granularité des divisions n'est pas un choix libre – l'ordre de déclaration des scripts plats est l'ordre d'évaluation, la granularité est déterminée par trois contraintes strictes (références mutuelles / ordre d'évaluation / les liaisons import ne peuvent pas être assignées), proposez d'abord un plan de division pour que quelqu'un le voie, puis coupez ; face à un module géant, testez d'abord la courbe de rendement d'une « liaison différée de quelques singletons finaux » avant de décider (testé : 6 liaisons réduisent de 11 246 lignes à 1 013 lignes, alors que changer de système de modules nécessite de sacrifier toute la chaîne d'outils pour obtenir la même granularité). ⭐ Le jugement « cette chose est impossible à faire » est extrêmement peu fiable – testé deux fois déclaré structurellement impossible, les deux fois le vrai coupable était un bug dans son propre outil ; doutez d'abord de l'outil qui le mesure, puis de l'objet (readable-source.md §3.1–3.1.3). ⛔ La condition préalable n'est pas négociable : il faut d'abord des portes toutes vertes. Une refactorisation sans arbitre est une modification aveugle ; avec un arbitre meanAbsDiff 0.00, chaque étape peut être prouvée – c'est la meilleure condition possible pour une refactorisation, et la raison pour laquelle elle doit être faite en dernier. Toutes les portes existantes sont réutilisées telles quelles (la cible devient le résultat de la construction de src/, la tolérance ne doit pas être assouplie), en ajoutant une porte de mappage de symboles et une porte d'auto-contenance. ⛔ La réécriture structurelle (fusionner des doublons, extraire des fonctions communes, changer des algorithmes) est interdite par défaut – elle ferait passer la porte de « prouver l'équivalence » à « n'a pas prouvé la non-équivalence ». ⭐ La règle 4 est toujours valable à cette étape : vous comprenez maintenant, l'impulsion « ceci est clairement un bug » sera plus forte que jamais, et il pourrait toujours s'agir du comportement lui-même.

⭐ Pour les produits sans conteneur scope-hoisted (Vite/esbuild, sites livrés couche par couche mot à mot), suivez une autre voie : ne réécrivez pas, découpez – décomposition par concaténation (scripts/census-bundles.mjs produit un graphique de chunks et des coordonnées → scripts/slice-esm.mjs découpe par déclaration en parties nommées sémantiquement, assemblées dans l'ordre pour que les octets soient égaux à l'original → scripts/verify-reassembly.mjs une seule porte pour trancher, quand l'équivalence en octets est établie, l'arbitrage de toutes les portes runtime est transféré gratuitement). Le côté exécution reste inchangé, le navigateur continue d'exécuter les chunks originaux. Voir readable-source.md §3.0.6.

Table de routage des branches

Les résultats de la reconnaissance de l'Étape 1 déterminent quels guides de scénario charger (selon les besoins, pas en charge complète) :

Résultat de la reconnaissance	Charger
Next.js App Router / RSC (self.__next_f flux flight) – C1 Reconstruction par rétro-ingénierie	references/rsc-reconstruction.md
Scènes WebGL / Canvas (three.js, moteur propriétaire, GLSL)	references/webgl-scenes.md
GSAP / données d'animation pré-cuites / animations CSS variables / machine d'état d'entrée propriétaire	references/animation-recovery.md
Formats binaires privés (.buf / .sog / VAT / GLB timeline / .riv)	references/binary-formats.md
Boutique Shopify (empreinte dans cdn/shop, Shopify.theme, cdn.shopify.com)	references/shopify-platform.md
Sanity CMS (empreinte dans cdn.sanity.io/images/<projectId>/, *.api.sanity.io, présence massive de _key/_type/_ref dans le payload) – ⛔ la classification dépend du moment de la cuisson du contenu, pas du nom de la bibliothèque, et les actifs auto=format retournent des octets différents selon l'en-tête Accept	references/sanity-platform.md
Sélection de la stratégie de couche DOM (tous les sites passent par là ; les branches sont différentes pour Webflow exporté / page statique unique / SSR d'un framework, avec la contrainte orthogonale que « le DOM est lu comme source de coordonnées par le moteur 3D »)	references/dom-shell-strategies.md
Actifs volumineux (médias de centaines de Mo / polices sous licence)	references/asset-management.md
Comportement de détection inhabituel ou suspicion de problème d'environnement	references/environment-traps.md

Step Summary

Étape	Action clé	Validation de la porte bloquante	Résultat
Step 0	Détection de l'empreinte et classification	Classification claire et communiquée à l'utilisateur	Conclusion de la classification et justification
Step 1	Invalidation + notation + confirmation de la portée	Confirmation par l'utilisateur	Tableau de notation des difficultés, consensus sur la portée
M0/M0.5	Image miroir + registre + fonctionnement hors ligne	verify-mirror les cinq points sont verts ; GAP=0 ; zéro 404/zéro erreur/zéro lien externe	mirror/ (lecture seule), manifeste, serveur de référence serve.mjs
M1	Dépliage du bundle, notes de rétro-ingénierie, stack verrouillée	engine-notes terminé ; tableau des versions épinglées terminé	_pretty/, docs/engine-notes.md, REBUILD_PLAN.md
M2+	Transplantation tracée, soumission par paire de jalons	Test à froid à chaque jalon + porte CLEAN verte	Code source avec commentaires de ligne, trois tables d'enregistrement mises à jour en continu
M(n-1)	Validation par comparaison	Type de porte sélectionné tout vert ou toutes les différences enregistrées	Script de validation + résultat de comparaison archivé (docs/compare/)
M(n)	Révision à froid + collecte de preuves de droits d'auteur + soumission à l'utilisateur	Vérification de la liste sans lacune ; l'utilisateur a pris la décision de déploiement (si non décidé, maintenir les paramètres sécurisés par défaut)	Enregistrement d'audit, DEPLOY.md
M(n+1)	Division des modules + désobfuscation + commentaires + auto-contenance	Toutes les portes existantes sont vertes et la tolérance n'a pas été assouplie ; la porte des symboles est une bijection sans orphelin ; la porte d'auto-contenance (copier, hors ligne, construire) réussit	src/ (projet lisible), docs/rename-map.json, src/README.md

Script Directory

Node 22+, chemins relatifs au répertoire de cette compétence. Voir scripts/README.md pour l'utilisation et la maturité.

⭐⭐ La discipline des dépendances est définie par stade, pas par répertoire : avant la transformation en code source, toute la pipeline a zéro dépendance.

De l'Étape 0 à M(n), n'installez rien ; le projet de réplication n'obtient des devDependencies qu'à M(n+1) (le renommage sécurisé dans le scope nécessite un véritable analyseur syntaxique). scripts/ (zéro dépendance) et tools/ (devDeps autorisées) ne sont que la projection de cette ligne de stades sur le répertoire – l'arbitre réside dans scripts/, le refactoring de l'étape de transformation en code source dans tools/.

⛔ Aucune porte ne doit import un outil (verification-gates.md §2.1.2) – l'inspecteur ne peut pas être le producteur.

⭐ Comment faire si les étapes précédentes ont besoin d'un véritable analyseur syntaxique ? Externe, pas import. beautify-bundle.mjs (js-beautify) et module-map.mjs (acorn) utilisent tous deux spawn d'un npx avec une version épinglée, le script lui-même reste sans dépendance et peut être examiné de manière indépendante. ⛔ N'écrivez pas un tokenizer à la main – dans cette compétence, un littéral d'expression régulière contenant des guillemets l'a dévoyé de 16 177 lignes (F27). La correspondance des parenthèses sur un flux de tokens est précise, la correspondance des parenthèses dans un texte est une supposition sur les chaînes, les regex et les commentaires.

⚠ Cette ligne a été découverte après avoir été violée : module-map.mjs dépendait de @babel/*, mais a résidé dans scripts/ pendant huit versions entières, alors que le texte original de cette discipline était écrit trois lignes au-dessus. Une règle qui n'est qu'écrite dans la documentation, et que rien ne vérifie, échoue silencieusement.

Script	Utilité	Stade d'utilisation
scripts/fingerprint.mjs	Implémentation équivalente multiplateforme du protocole de détection en six étapes de l'Étape 0 (GET pour la survie + chaîne de redirection et identité du domaine de l'URL finale, diff de double capture, espèce/âge, empreinte HTML technique, inspection initiale du bundle ; comptage des occurrences et nouvelle tentative avec Referer pour les fichiers <1 Ko intégrés ; collecte des preuves Sanity CMS – projectId/dataset/hôte API/auto=format/_key, normalisation de trois orthographes, en cas de correspondance, diriger vers sanity-platform.md). Ne collecte que des preuves, ne fait pas de classification – la classification suit toujours l'arbre de décision de scope-and-fingerprint.md §3	Step 0 (lorsqu'il n'y a pas de chaîne d'outils POSIX)
scripts/mirror-site.mjs	Robot BFS pour l'image miroir (liste blanche des actifs + itération jusqu'au point fixe ; redirect:manual + trois registres, sha256 par fichier ; ⭐ redirects.tsv s'accumule comme le manifeste entre les exécutions – --scope pour compléter des pages l'a déjà tronqué à seulement l'en-tête, la porte de charge utile a détecté un 404 sur /work). --scope <préfixe> limite la file d'attente des pages au chemin cible (obligatoire pour les micro-sites hébergés sur un domaine CMS d'entreprise ; ⛔ limite les pages, pas les actifs). Accumulation du registre (--seeds pour combler les lacunes ne tronque plus les lignes précédentes) + recensement hors-domaine (comptage des hôtes non suivis individuellement et alerte – la suppression silencieuse a déjà fait disparaître 827 références médiatiques alors que le rapport indiquait « 57 fichiers sauvegardés »)	M0 première passe
scripts/netcapture.mjs	Capture CDP par navigateur réel pour vérification et complétion des ressources runtime (les sites CDN doivent passer --hosts, sinon seuls les flux de même origine sont observés, ce qui peut signaler à tort GAP=0)	M0 deuxième passe
scripts/verify-mirror.mjs	La porte de l'image miroir elle-même, exécutée avant la porte hors ligne. Cinq assertions : injectivité de la correspondance / registre et sha256 disque / authenticité (corps de la page de défi + type de déclaration contre magic number – un 200 n'est pas une preuve que vous avez obtenu la ressource) / fermeture / échantillonnage optionnel de la source. Toutes les portes aval demandent « le rendu est-il possible ? », une image miroir erronée peut les rendre toutes vertes	Avant la clôture de M0, après chaque recapture de l'image miroir
scripts/gapfill-video.mjs	Complétion par paliers pour le streaming HLS/DASH (master → rendition → segment), angle mort structurel du robot statique	M0 (lorsqu'il y a du streaming)
scripts/reconcile-gaps.mjs	Confrontateur de lacunes runtime : pour chaque ligne GAP enregistrée par netcapture et la liste complète des actifs dérivée par déduction d'octets (par exemple, l'échelle srcset de next/image – testé 1 078 contre 217 rencontrés par le navigateur), ajoutez-la à l'image miroir une par une. ⭐ Échelle d'en-têtes de requête (profil standard 4xx → nouvelle tentative avec profil nu : le même 403 a deux remèdes opposés, landonorris veut Referer, video.twimg déteste Referer) + tolérance par URL + comptabilisation par lots (un crash ne laisse aucun fichier non comptabilisé). ⛔ Le profil standard des URL d'images envoie le même Accept d'image que le navigateur (lib/negotiate.mjs) – les CDN de type auto=format négocient le format en fonction de l'Accept, */* reçoit des octets de repli (basement D5 : 391 variantes toutes en repli alors que les portes étaient toutes vertes) ; le registre enregistre le profil+vary	M0 (sites avec beaucoup de ressources runtime)
scripts/flight-decode.mjs	Système de coordonnées pour C1 : transforme le flux self.__next_f.push de chaque page en une table de référencement des modules (les noms exportés sur la ligne I sont une preuve de nom de tier 1 donnée), préchargement HL, arbre d'éléments déréférencés + plan JSX. Les lignes T sont traitées en fonction du nombre d'octets de déclaration ; les lignes :HL avec id vide ne doivent pas casser la chaîne	M1 (C1)
scripts/verify-flight.mjs	Porte sémantique pour C1 : arbre flight du résultat de construction ≟ arbre flight de l'image miroir. Analyseur syntaxique intégré (⛔ n'importe pas flight-decode – l'inspecteur ne peut pas être le producteur) ; la normalisation n'accepte que ce qui « prouve qu'il ne porte pas de comportement » : les espaces de noms de hachage de construction (nom de chunk / classe css-module / hachage de média / point de montage de ressource évolutive / degré de liberté d'encodage), les ID de modules sont en bijection globale (un-à-plusieurs c'est rouge) ; les éléments enregistrés par site passent par --normalize-props (champs d'époque ISR) et --normalize-class (sous-arbre rendu par une bibliothèque) ; toute autre différence est en rouge	M(n-1) (C1)
scripts/serve.mjs	Serveur statique sans dépendance (MIME/Range/réécriture au niveau service/rejeu de redirection), sert également de serveur de référence pour le site source. --rewrite FROM::TO est une substitution littérale enregistrée, pour une chose que la localisation n'atteint pas – le programme source se branche selon son propre nom de domaine (location.hostname=="x.com" && (CDN=...), l'image miroir n'est pas sur ce domaine, donc toute la branche qui en dépend est ignorée au moment de l'exécution mais reste dans le bundle)	M0-M(n) (serveur de l'image miroir)