Website Rebuild（受奖创意网站 1:1 复刻）

Website Rebuild（Preisgekrönte Kreativseiten 1:1 nachbauen）

Eine preisgekrönte Kreativ-Website (WebGL / Scroll-Narration / Portfolio) wird mit einer forensischen Methode als eigenständiges, verifizierbar rekonstruiertes Projekt nachgebaut. Kein „sieht so aus“-Nachbau – sondern eine zeilenweise Portierung, die das Bundle der Originalseite als einziges Spezifikationsdokument verwendet und mit quantitativen Abnahmetoren abschließt.

Diese Methodik wurde aus sechs aufeinanderfolgenden Praxisprojekten destilliert (Projektzeit von 6,5 Wochen auf 1 Tag reduziert) und durch 22 vollständige Rebuilds + 5 Rettungen toter Seiten sowie 43 Grenzfalltests kontinuierlich verfeinert und kalibriert (die Liste der validierten Seiten befindet sich im Repository-README unter „Validierte Websites“).

Nutzungsvoraussetzungen & Berechtigung ⛔ MUSS gelesen werden

Dieser Skill dient der originalgetreuen Nachbildung zu Lern- und Forschungszwecken, um die Implementierungstechniken preisgekrönter Kreativseiten zu studieren. Er ist anwendbar auf Websites, die Ihnen gehören, für die Sie eine Berechtigung haben oder die öffentlich zugänglich sind und das Lernen/Nachbilden erlauben. Er ist kein Werkzeug, um geschützte Inhalte unbefugt zu sammeln, Zugangskontrollen zu umgehen oder die Arbeit anderer kommerziell zu missbrauchen.

Halten Sie sich bei der Ausführung an die folgenden Grenzen:

• Respektieren Sie die Regeln der Zielseite: Befolgen Sie deren robots.txt, Nutzungsbedingungen und Urheberrecht; das Crawling erfolgt mit niedriger Frequenz, in einer einzigen Sitzung, ohne ungewöhnliche Last auf der Zielseite zu erzeugen. ⛔ robots.txt ist eine pfadweise Genehmigungserklärung, kein globaler Schalter – für jede URL einzeln entscheiden (längste übereinstimmende Regel gewinnt → keine Übereinstimmung bedeutet erlaubt). Nicht aufgrund einer einzigen Disallow-Zeile die gesamte Seite als „verboten“ einstufen (fast jede kommerzielle Seite hat Disallow-Einträge für /cart, /checkout, /admin); Verbote müssen nach Verhaltenskategorie klassifiziert werden. Nur Verbote, die sich auf „Crawling“ beziehen, beeinflussen den Spiegelumfang – Verbote für Transaktionen bedeuten nur „nicht auf den Checkout-Button klicken“. ⭐ „Ich verstehe es nicht / bin mir nicht sicher“ ist nicht gleich „verboten“: Bei Unsicherheit wird dem Benutzer eine Frage gestellt, nicht die Arbeit eingestellt oder gar der Crawl-Umfang selbstständig reduziert. Die Lesart finden Sie in references/legal-and-deploy.md §0.3.
• Berühren Sie keine geschützten Grenzen: Sammeln Sie keine Inhalte, die eine Anmeldung, eine Paywall oder eine Autorisierung erfordern; dieser Skill verarbeitet nur anonym zugängliche öffentliche Ressourcen. Wenn die Zielseite solche Kopien ausdrücklich verbietet, stoppen Sie und informieren Sie den Benutzer – was „ausdrücklich verboten“ bedeutet, ist in legal-and-deploy.md §0.3.6 durch vier festgeschriebene Schwellen definiert; alle anderen Unsicherheiten werden dem Benutzer vorgelegt, nicht die Arbeit eingestellt.
• Ergebnisse sind standardmäßig privat: Standardmäßig noindex, keine öffentliche Bereitstellung. Vor jeder Veröffentlichung muss eine Asset-für-Asset-Copyright-Prüfung durchgeführt werden, und es muss ein deutlicher Hinweis auf „Inoffizieller Nachbau“ und die Urheberschaft des Originals angebracht werden (siehe references/legal-and-deploy.md).

⛔ Rechtliche Beurteilung obliegt dem Benutzer, der Skill sammelt und präsentiert nur Beweise (drei Grundsätze, während des gesamten Prozesses gültig):

1. Die Entscheidung liegt beim Benutzer: Der Skill sammelt Fakten (Asset-für-Asset-Zuordnung, Lizenzstatus, Rechte Dritter, ob die Originalseite noch aktiv ist, Kennungen Dritter im Produkt), listet Optionen mit ihren jeweiligen Risikogrenzen auf, gibt eine Empfehlung mit Begründung; bei Fragen, ob etwas „öffentlich gemacht / bereitgestellt / weiterverteilt / gezeigt werden darf“, muss dies dem Benutzer explizit mit den untenstehenden „User Input Tools“ vorgelegt werden; der Agent darf keine eigenen rechtlichen Schlussfolgerungen ziehen und einfach weitermachen.
2. Solange keine klare Entscheidung des Benutzers vorliegt, wird der sichere Standard angewendet: Privates Repository + noindex + keine öffentliche Bereitstellung + keine Weiterverteilung. In der Kommunikation mit dem Benutzer wird dies als Standardaktion bezeichnet („Bevor Sie eine Entscheidung treffen, werde ich es nicht veröffentlichen“), nicht als rechtliche Schlussfolgerung des Agenten – die Verantwortung ist grundlegend unterschiedlich. Der Agent kann nur in konservativer Richtung handeln; für öffentliche Schritte ist eine explizite Entscheidung des Benutzers erforderlich.
3. ⛔ Rechtliche Erwägungen dürfen die Vollständigkeit des Spiegels oder die Abdeckung der Tore nicht beeinträchtigen: Der Spiegel ist die Beweisbasis, seine Vollständigkeit ist eine technische Invariante (das Vierfach-Scan-Verfahren, die Closure-Tore, GAP=0 bauen alle darauf auf). Nicht-Crawlen darf nur technische Gründe haben (keine Datei / Server stellt sie nicht bereit / erfordert Autorisierung oder Login / ausdrückliches Verbot der Originalseite) und muss dokumentiert werden; es ist nicht erlaubt, aus rechtlichen Gründen wie „es wird ja sowieso nicht veröffentlicht“ oder „man sollte nicht mehr als nötig speichern“ Lücken zu lassen. Empirischer Beleg: In einem Projekt wurde aus dem Grund „Das Ergebnis wird nie veröffentlicht“ eine Asset-Klasse „dokumentiert, aber nicht nachgezogen“ – es fehlten ca. 60% der Assets, während die fünf Tore durchgängig Grün zeigten und vier Meilensteine versteckten [objectarchive]. Rechtliche Entscheidungen betreffen die Nutzung des Ergebnisses, nicht die Vollständigkeit der Beweisbasis.

Anwendungsbereich ⛔ MUSS gelesen werden

Hauptdomäne (Klasse A): Websites, die statisch gehostet werden und deren signifikantes Verhalten (Animationen/Interaktionen) vollständig in clientseitigen statischen Assets liegt – imperative WebGL/Canvas-Szenen, GSAP-Timelines, gebackene Datendateien (GLB/.buf/.riv), minimierte oder nicht obfuskierte Bundles. Die überwältigende Mehrheit der Awwwards-Art Kreativseiten fällt in diese Kategorie.

Bedingt unterstützt (Klasse B): Die Pipeline funktioniert, erfordert jedoch zusätzliche Szenarienbehandlung (Shopify-Plattformschicht-Abtrennung, Assets in Drittanbieter-Storage, Runtime-API-Snapshots, SSG-Payload-Expansion). Die aktuelle Version der Anleitung deckt die meisten B-Szenarien ab; bei nicht abgedeckten Fällen muss der Benutzer explizit auf das Risiko hingewiesen werden.

Explizit abgelehnt (Klassen C/D):

• C1 (ab v0.3 möglich: Rekonstruktives Reverse Engineering): Die serverseitige Komponentenquelle wird nicht ausgeliefert, aber ihre vollständige Ausgabe (Flight-Stream) ist inline im HTML jeder Seite enthalten und dient als vergleichbares Spezifikationsdokument. Vorgehen: Flight-Dekodierung zum Aufbau eines Koordinatensystems → Rekonstruktion eines baubaren Next-Projekts (clientseitige Komponenten werden gemäß C2 wortgetreu übersetzt, serverseitige Komponenten werden aus dem Flight-Baum als explizit registrierte Inferenzen zurückentwickelt) → verify-flight semantisches Tor zur Abnahme (Modul-ID-globale Bijektion). Getestet auf rauchg.com (Next 16/Turbopack): 18/18 Routen semantisch konsistent, blindes Reverse Engineering ergab Strukturübereinstimmung ≈95%, Verhalten ≈98%. ⚠ Für C1 werden L2/L3 zusammengelegt – das erste Ergebnis ist bereits „von Menschen geschriebener Quellcode + durch Tore bewiesene Äquivalenz“. Vollständiger Ablauf in references/rsc-reconstruction.md.
• C2 (machbar, läuft wie Klasse A): ⭐ Die Schreibweise ist deklarativ, aber der Quellcode wird ausgeliefert (R3F / Theatre / Vue SFC-Kompilierungsprodukte). Getestet an einer R3F-Seite: Der useFrame-Callback enthielt gewöhnlichen imperativen Code wie MathUtils.damp(x, y, 7, t), 18 Module wurden Wort-für-Wort in die Seite eingefügt: CLEAN, alle 8 Canvas vorhanden, seitliche Übereinstimmung 99.5%. Der Slicer interessiert sich nicht für das Paradigma – er schneidet Bytes. Der Renderer wird als Plattformschicht vom Spiegel bedient. ⛔ Der Diskriminator ist nicht der Bibliotheksname, sondern ob der Client die Verhaltensquelle besitzt (scope-and-fingerprint.md §4.0.1).
• D: Das Verhalten liegt hauptsächlich serverseitig (CMS-Inhaltsseiten, E-Commerce-Warenkorb/Lagerbestand, A/B-Testing-Buckets, Personalisierung) – der Client hat kein portierbares Zielobjekt und keine deterministische Abnahmegrundlage.

Klasse X (rettbar): Die Originalseite ist verschwunden (Domain-Besitzerwechsel, Plattform-Löschung, Pfadentfernung, Ersetzung an Ort und Stelle), aber das Internet Archive hat oft einen Snapshot – scripts/wayback-mirror.mjs wählt aus dem CDX-Index mit Anker + Zeitfenster einen konsistenten Moment aus, erfasst ihn als id_-Rohtext und erzeugt einen Standard-Spiegel (die nachgelagerten Tore funktionieren unverändert). Lücken werden als Fakt in wayback-holes.txt dokumentiert (Lesart und Ablauf in references/archival-rescue.md). ⭐ Die Rettungsausgabe ist ein Standard-Spiegel – Klasse X kann den gesamten L3-Durchlauf absolvieren (getestet first-launch: Strategie A-Hülle + numerisches Tor 9.856 Stichproben alle identisch + Pixel innerhalb der Bandbreite + self-contained Tor, kein Tor musste semantisch geändert werden). ⛔ „Keine CDX-Abdeckung ist das eigentliche „nicht machbar““ liest man Asset-Schicht für Asset-Schicht, nicht Seite für Seite: Der IA-Crawler führt kein JS aus. Bei listen-/assemblierungsgetriebenen Seiten kann die Code-Schicht zu 100% abgedeckt sein, während die Darstellungsschicht null ist (getestet: 157/160 Assets in keinem Jahrzehnt erfasst, ohne Internetverbindung sofort weißer Bildschirm) – Schritt 0 führt zuerst eine geschichtete Aufklärungsmission durch (Ableitung + CDX-Präfix-Abfrage), um die Rettungstiefe vorherzusagen, siehe archival-rescue.md §1.9. Die gemessene Verschwundensrate preisgekrönter Seiten über die Jahre liegt bei etwa 29% – deshalb ist „Spiegle sofort“ die erste Disziplin dieses Skills.

Die Klassifizierung erfolgt durch die Fingerabdruck-Aufklärung in Schritt 0; der vollständige Entscheidungsbaum befindet sich in references/scope-and-fingerprint.md. Bei Ablehnung muss der Grund und die Klasse der Seite erläutert werden; nicht einfach ausführen.

User Input Tools

Wenn eine Frage an den Benutzer erforderlich ist (Umfangsbestätigung, rechtliche Entscheidung, Entscheidung über externe Abhängigkeiten): Bevorzugt das eingebaute Fragewerkzeug der aktuellen Laufzeit verwenden (z. B. AskUserQuestion); falls nicht vorhanden, eine nummerierte Liste der Fragen ausgeben, auf die der Benutzer mit Nummern antworten kann. Mehrere Fragen sollten, wenn möglich, in einer Anfrage zusammengefasst werden. Rechtliche Fragen sind nach dem Fünf-Absatz-Schema aus legal-and-deploy.md §0.1 zu verfassen: Fakten / Ungeklärtes / Optionen / Risikogrenzen jeder Option / Empfehlung und aktuelle Standardaktion.

Verfassung (Sechs eiserne Regeln, während des gesamten Prozesses gültig)

Die folgenden sechs Regeln werden in den sechs Quellprojekten als „Verfassungsrang“ bezeichnet; ein Verstoß gegen eine von ihnen wird sich in späteren Phasen als Bug rächen:

1. Der Spiegel ist heilig und darf nicht verändert werden: Die Diskdateien in mirror/ werden niemals modifiziert; alle Lokalisierungsanpassungen (CDN-Umschreibung, externe Link-Stubs) werden dynamisch beim Bedienen der Antwort in der Dienstschicht vorgenommen.
2. Der Quellcode der Originalseite ist die einzige Autorität, nicht das Gefühl: Jede Änderung muss zuerst die zugehörige Zeilennummer im Bundle/CSS/im gespiegelten HTML finden, bevor sie umgesetzt wird. Do not tune visuals, motion, or interaction by eye.
3. Was die Originalseite hat, muss vorhanden sein; was sie nicht hat, wird nicht gemacht: Kein selbst erfundener, kompensierender CSS/JS-Code. Lieber erstmal nicht ähnlich aussehen, als eigene Regeln zu erfinden – selbst erstellte Patches werden sich nach dem Mechanismus-Abgleich in Bugs verwandeln.
4. Bugs / toter Code / seltsame Schreibweisen werden unverändert übernommen: Jede seltsame Schreibweise im minimierten Code könnte das eigentliche Verhalten sein. Ein „gut gemeinter Fix“ eines No-op-Bugs hat einmal zum Absturz eines Übergangs geführt (empirischer Beleg in porting-discipline.md).
5. Jede bewusste Abweichung muss dokumentiert werden: Klar beschreiben, „wie die Originalseite es macht / wie wir es machen / warum / unter welchen Bedingungen es neu bewertet wird“. Nicht dokumentierte Abweichungen gelten als Bugs.
6. Code und Dokumentation im selben Commit: Jeder Meilenstein wird als Paar committed (Port xxx + Update rebuild plan: xxx), das Log enthält fest: Ergebnis / Abnahme / Lehren / nächste Haltepunkte (mit Zeilennummern).

⭐ Regel 3 an der Grenze von M(n+1): src/ ist ein explizit registriertes Derivat, keine Aussage über die Originalseite. Daher gilt das Umbenennen, Aufteilen von Modulen, Hinzufügen von Kommentaren in src/ nicht als „Erfindung“ – Regel 3 beschränkt das „Erfinden von Verhalten, um es wie das Original aussehen zu lassen“, nicht das „Lesbarmachen von bereits als äquivalent bewiesenem Code“. Zwei harte Grenzen bleiben jedoch unangetastet: ① Strukturelle Rewrites sind standardmäßig verboten (Duplikate zusammenführen, gemeinsame Funktionen extrahieren, Algorithmen ändern – sie machen Äquivalenz nicht entscheidbar); ② Spekulationen in Kommentaren müssen als solche gekennzeichnet sein, es ist nicht erlaubt, Vermutungen aus Reverse-Engineering-Notizen als Aussagesätze zu formulieren. port/ und mirror/ dürfen weiterhin kein einziges Byte verändert werden. Details in references/readable-source.md §3.4 und §5.

Arbeitsablauf

Fortschritts-Checkliste

[ ] Schritt 0  Fingerabdruck-Aufklärung & Umfangstor ⛔ (Klassifizierung A/B/C/D/X; bei C/D/X ablehnen oder umleiten, nicht fortfahren)
[ ] Schritt 1  Startbewertung (Architektur falsifizieren, Aufgabenschwierigkeit mit Sternen bewerten, Zeitaufwand schätzen, mit Benutzer Umfang + Endpunkt L1/L2/L3 bestätigen)
[ ] M0      Spiegel-Forensik ⛔ (BFS-Crawler + CDP-Ergänzung + Manifest-Hauptbuch; GAP=0)
[ ] M0.5    Spiegel offline zum Laufen bringen ⛔ (Null 404 / Null Konsolenfehler / Null externe Verweise; mit serve.mjs bedienen) ← L1 Spiegel-Archiv  Endpunkt
[ ] M1      Reverse Engineering Koordinatensystem aufbauen ⛔ (_pretty Version festnageln und entpacken; engine-notes vor jeglichem Code; Tech-Stack festnageln; REBUILD_PLAN erstellen)
[ ] M2+     Strenge quellverfolgte Portierung (Abhängigkeitsreihenfolge-Meilenstein-Fortschritt; zuerst eine vertikale Ende-zu-Ende-Kette schneiden; jeden Meilenstein mit Kaltstart testen + CLEAN Tor)
[ ] M(n-1)  Gegenüberstellungsabnahme (nach Entscheidungsbaum in verification-gates.md Tortyp wählen; Grundursache beheben, nicht durch Parameteranpassung glattbügeln)
[ ] M(n)    Abschluss ⛔ (Kaltstart-Review / Modullistenabgleich; Copyright-Forensik + dem Benutzer zur Entscheidung vorlegen – muss vor öffentlicher Bereitstellung abgeschlossen sein) ← L2 Engineering-Rebuild  Endpunkt
[ ] M(n+1)  Quellcode-Generierung (port/ → src/: Module aufteilen, Entobfuskierung umbenennen, Kommentare ergänzen, self-contained) ← L3 Quellcode-Generierung  Endpunkt

⛔ = Blockierendes Tor: Wenn die Abnahmekriterien nicht erfüllt sind, darf nicht in die nächste Phase eingetreten werden.

Ablauf

Schritt 0 – Fingerabdruck-Aufklärung & Umfangstor. Laden Sie references/scope-and-fingerprint.md. Führen Sie das Erkennungsprotokoll für die vom Benutzer angegebene URL aus (GET bis zur Pfadgranularität, End-URL-Identität, Double-Crawl-Diff, Spezies/Jahreszahl-Prüfung, Bundle-Erstprüfung) und geben Sie die Klassifizierung mit Begründung aus. Für Klasse A/B fortfahren; für C/D/X dem Benutzer erklären und anhalten oder umleiten.

Schritt 1 – Startbewertung. Laden Sie references/recon-and-rating.md. Zuerst die Architekturannahme falsifizieren (Abhängigkeitstabellen können lügen). Die Aufgabenschwierigkeit mit Sternen bewerten (Assets/3D/Scroll-Choreografie/private Formate/Plattformschicht). Dem Benutzer den Rebuild-Umfang (gesamte Seite oder bestimmte Seiten) und die Erwartungen bestätigen.

⭐ Stellen Sie dem Benutzer in derselben Frage die Wahl des Endpunkts (dreistufige Leiter, fragen Sie mit der Klassifizierung und einer geschätzten Kostenaufschlüsselung, nicht nur trocken die Optionen auflisten):

Endpunkt	Beantwortete Frage	Endet bei	Typische Verwendung
L1 Spiegel-Archiv	Wie sieht es aus	M0.5	Archivierung, Offline-Betrachtung (preisgekrönte Seiten haben eine jährliche Verschwundensrate von ca. 29%)
L2 Engineering-Rebuild	Was tut es	M(n)	Bereitstellbarer, verifizierbarer 1:1-Nachbau (inklusive Copyright-Forensik und Bereitstellungsbewertung)
L3 Quellcode-Generierung	Wie macht es das	M(n+1)	Forschung und Lernen von Implementierungstechniken

Die Leiter ist monoton; eine niedrigere Stufe zu wählen ist kein Verlust: Jede Stufe ist ein Präfix der nächsten, und die Spiegeldisziplin stellt sicher, dass der zeitkritische Teil immer zuerst erledigt wird – wenn Sie heute L1 wählen, können Sie später jederzeit upgraden (informieren Sie den Benutzer darüber). „Es für das eigene Projekt nutzen“ (als Scaffold) ist keine Phase dieses Skills – verweisen Sie den Benutzer bei Rückfragen auf references/beyond-the-rebuild.md für die Übergabe; das ist sein Projekt, der Skill endet dort, wo „ein Mensch den echten Code lesen kann“.

M0 / M0.5 – Spiegel-Forensik. Laden Sie references/mirroring.md. Verwenden Sie scripts/mirror-site.mjs für BFS-Crawling + scripts/netcapture.mjs für echte Browser-Nachaufnahmen. Das Manifest registriert jede Datei mit sha256. Disziplin: redirect: manual. Entscheidungen über externe Abhängigkeiten werden einzeln getroffen. scripts/verify-mirror.mjs ist das eigene Tor des Spiegels (fünf Behauptungen, die vor dem Offline-Tor ausgeführt werden – alle nachgelagerten Tore fragen „kann es gerendert werden?“, ein falscher Spiegel kann sie alle grün färben; ein HTTP 200 ist auch kein Beweis dafür, dass „Sie diese Ressource erhalten haben“). scripts/serve.mjs bedient den Spiegel; Offline-Abnahme. Dieser Schritt wird immer zuerst ausgeführt – die Originalseite kann jederzeit verschwinden oder sich ändern; der Spiegel ist die einzige Beweisbasis des gesamten Projekts und der Referenzserver für alle späteren Vergleiche.

M1 – Reverse Engineering Koordinatensystem aufbauen. Laden Sie references/reverse-engineering.md. ⛔ Die erste Aktion ist die Bestimmung der Bundle-Form (flache Aneinanderreihung / modularer Bundler / mehrere Chunks), dann das Werkzeug auswählen – die Layer-Tabelle scannt die obersten Deklarationen, während die Anzahl der obersten Deklarationen in einem Webpack-Bundle 0 ist; Grenzen und Abhängigkeitskanten werden vom Bundler vorgegeben (getestet: 24.378 Zeilen → 569 vorgefertigte Module, mit scripts/module-map.mjs). Wenn der Container nicht erkannt wird, FATAL, Rückfall auf die Layer-Tabelle ist verboten (§0.5). scripts/beautify-bundle.mjs (js-beautify Version 1.15.1 festnageln) entpackt das Bundle in _pretty/; von nun an sind die Zeilennummern das einzige Koordinatensystem für das gesamte Projekt. Schreiben Sie zuerst docs/engine-notes.md (Vorlage: assets/templates/engine-notes.md) und dann jeglichen Code. Der Tech-Stack wird aus dem Bundle auf die exakte Version festgenagelt. Bei datengesteuerten Animationen zuerst ein numerisches Hauptbuch dumpen. Erstellen Sie REBUILD_PLAN.md (Vorlage: assets/templates/rebuild-plan.md).

M2+ – Strenge quellverfolgte Portierung. Laden Sie references/porting-discipline.md und, je nach Verzweigungstabelle, die entsprechenden Szenarienanleitungen. Jeder portierten Quelldatei wird ein Header mit Quellzeilenbereichen hinzugefügt; GLSL/Magische Zahlen/Daten werden wortgetreu extrahiert; Daten-Asset-Skripte werden extrahiert und in einer Datenbank gespeichert, nicht von Hand abgeschrieben.

M(n-1) – Gegenüberstellungsabnahme. Laden Sie references/verification-gates.md und references/determinism.md. Die Breite des gesamten Seiten-Renderings wird mit scripts/sweep-routes.mjs getestet (alle Routen in einem Browser, für jede Route 0 Fehler/0 Fehlschläge/0 externe Verweise + Interaktionshaken und routenweise Sammlung). Für die Tiefe einer einzelnen Route wird probe.mjs verwendet – ⛔ keine manuell erstellte Schleife, die für jede Route Chrome startet, da die Kosten nach Browser-Starts bemessen werden und gleichzeitige Probes sich gegenseitig verwaiste Prozesse hinterlassen. ⚠ Vor der Fehlerzuordnung die Eigenvergleichsbandbreite aufbauen (pixelcompare --self, ≥4 Durchläufe pro Seite, verschachtelt) – Residuen ohne Bandbreite sind immer UNCLASSIFIED, und UNCLASSIFIED ist ein Fehlschlag, kein Bestehen. Tortyp-Auswahl: Bei SSR/statischem HTML zuerst ein Byte-Tor bauen → Bei DOM-Statikszenen mit eingefrorener Entropiequelle byte-equal verwenden → Bei Live-Szenen (WebGL/Video/Zufallsphasen) auf quantitative Metriken + Rauschklassifizierung zurückfallen → Bei datengesteuerten Animationen mit numerischem Sondentor ergänzen → CLEAN-Tor als Sicherheitsnetz verwendet immer. Vor der Bestimmung von Timing-Bugs zuerst die Sonden kalibrieren (references/environment-traps.md).

M(n) – Abschluss. Kaltstart-Review: Jede der obersten Klassen/Modulbezeichnungen im Bundle einzeln auf ihre Platzierung im Port überprüfen (funktionale Tests können keine vollständige Auslassung eines Moduls aufdecken; nur eine checklistenartige Überprüfung kann das). Laden Sie references/legal-and-deploy.md, führen Sie die Copyright Forensik durch und legen Sie die Entscheidung dem Benutzer vor – bis der Benutzer entscheidet, gilt der sichere Standard (privat + noindex + nicht bereitgestellt). Vor einer Veröffentlichung muss jedes Asset einer Copyright-Prüfung unterzogen und der Nachbau deutlich als inoffiziell gekennzeichnet werden.

M(n+1) – Quellcode-Generierung. Laden Sie references/readable-source.md. Das Ergebnis bis zu M(n) ist als korrekt bewiesen, aber für Menschen nicht lesbar (gemessen: 14.271 Zeilen in einer einzigen Datei, e kommt 2962 Mal vor, Kommentare machen 0,2% aus). Diese Phase schreibt port/ in src/ um: Module aufteilen → Bereichssicheres Entobfuskierungs-Umbenennen → Abschnittskommentare ergänzen → Assets kopieren, um Selbstständigkeit zu erreichen. ⛔ Die Aufteilungsgranularität ist keine freie Wahl – bei flachen Skripten ist die Deklarationsreihenfolge gleich der Auswertungsreihenfolge; die Granularität wird durch drei harte Einschränkungen bestimmt (gegenseitige Referenzen / Auswertungsreihenfolge / Import-Bindungen sind nicht zuweisbar). Zuerst einen Aufteilungsplan erstellen, den der Benutzer sieht, dann schneiden. Bei riesigen Modulen zuerst die Nutzenkurve eines „verzögerten Bindens weniger Singleton am Ende“ messen, dann entscheiden (gemessen: 6 Bindungen reduzierten die Datei von 11.246 auf 1.013 Zeilen, während ein Wechsel des Modulsystems die gesamte Toolchain geopfert hätte, um dieselbe Granularität zu erreichen). ⭐ Die Einschätzung „das ist nicht machbar“ ist äußerst unzuverlässig – zweimal wurde es als strukturell unmöglich eingeschätzt, und zweimal war der wahre Schuldige ein einzelner Bug in den eigenen Werkzeugen; zuerst das Werkzeug verdächtigen, mit dem gemessen wird, dann das Objekt (readable-source.md §3.1–3.1.3). ⛔ Die Vorbedingung ist nicht verhandelbar: Es müssen erst alle Tore Grün sein. Ein Refactoring ohne Schiedsrichter ist blindes Ändern; mit einem Schiedsrichter, der meanAbsDiff 0.00 anzeigt, kann jeder Schritt bewiesen werden – das ist die bestmögliche Bedingung für ein Refactoring und der Grund, warum es als Letztes kommt. Alle bestehenden Tore werden unverändert wieder verwendet (das Ziel wird auf das Build-Produkt von src/ geändert, die Toleranzen dürfen nicht gelockert werden), dazu kommen ein Symbolzuordnungstor und ein Self-Contained-Tor. ⛔ Strukturelle Rewrites (Duplikate zusammenführen, gemeinsame Funktionen extrahieren, Algorithmen ändern) sind standardmäßig verboten – sie würden das Tor von „Äquivalenz beweisen“ zu „keine Ungleichheit gefunden“ degradieren. ⭐ Regel 4 gilt in dieser Phase weiterhin: Sie können es jetzt lesen, der Drang, „das ist offensichtlich ein Bug“ zu sagen, wird stärker sein als in jeder anderen Phase, und es könnte immer noch das eigentliche Verhalten sein.

⭐ Produkte ohne Container-Scope-Hoisting (Vite/esbuild, wortweise geschichtete Auslieferung der Seite) gehen einen anderen Weg: nicht umschreiben, sondern schneiden – konkatative Zerlegung ( scripts/census-bundles.mjs erstellt eine Chunk-Karte und Koordinaten → scripts/slice-esm.mjs schneidet nach Deklarationen in semantisch benannte Komponenten, die sequenziell zusammengesetzt byteweise gleich dem Original sind → scripts/verify-reassembly.mjs entscheidet mit einem Tor; wenn die Byte-Äquivalenz hergestellt ist, werden die Entscheidungen aller Runtime-Tore kostenlos übertragen). Die Ausführungsseite ändert sich nicht; der Browser läuft weiterhin mit den Original-Chunks. Details in readable-source.md §3.0.6.

Verzweigungstabelle

Das Ergebnis der Aufklärung in Schritt 1 bestimmt, welche Szenarienanleitungen geladen werden (nach Bedarf, nicht alle auf einmal laden):

Erkennungsergebnis	Zu laden
Next.js App Router / RSC (self.__next_f Flight-Stream) – C1 Rekonstruktives Reverse Engineering	references/rsc-reconstruction.md
WebGL / Canvas-Szenen (three.js, Eigenentwicklung-Engine, GLSL)	references/webgl-scenes.md
GSAP / Gebackene Animationsdaten / CSS-Variablen-Animationen / Eigenentwicklungs-Input-Zustandsmaschine	references/animation-recovery.md
Private binäre Formate (.buf / .sog / VAT / GLB-Timeline / .riv)	references/binary-formats.md
Shopify-Shop (Fingerabdruck: cdn/shop, Shopify.theme, cdn.shopify.com)	references/shopify-platform.md
Sanity CMS (Fingerabdruck: cdn.sanity.io/images/<projectId>/, *.api.sanity.io, Payload mit vielen _key/_type/_ref) – ⛔ Klassifizierung basiert auf dem Zeitpunkt des Content-Bakings, nicht auf dem Bibliotheksnamen; auto=format Assets verhandeln je nach Accept-Header unterschiedliche Bytes	references/sanity-platform.md
DOM-Layer-Strategie-Auswahl (alle Seiten durchlaufen dies; Webflow-Export / statische Einzelseite / Framework-SSR haben unterschiedliche Zweige, zusätzlich gibt es die orthogonale Einschränkung, dass das DOM von der 3D-Engine als Koordinatenquelle gelesen wird)	references/dom-shell-strategies.md
Umfangreiche Assets (Medien im hundert-MB-Bereich / lizenzierte Schriftarten)	references/asset-management.md
Headless Detection Verhaltensauffälligkeiten / vermutete Umgebungsprobleme	references/environment-traps.md

Schritt-Zusammenfassung

Phase	Schlüsselaktion	Blockierendes Tor-Abnahme	Ergebnisse
Schritt 0	Fingerabdruck-Erkennung und Klassifizierung	Klassifizierung steht fest und wurde dem Benutzer mitgeteilt	Klassifizierungsergebnis und Begründung
Schritt 1	Falsifikation + Bewertung + Umfangsbestätigung	Benutzerbestätigung	Schwierigkeitsbewertungstabelle, Umfangskonsens
M0/M0.5	Spiegel + Hauptbuch + Offline-Lauffähigkeit	verify-mirror alle fünf Punkte Grün; GAP=0; Null 404/Null Fehler/Null externe Verweise	mirror/ (schreibgeschützt), Manifest, serve.mjs Referenzserver
M1	Bundle entpacken, Reverse-Engineering-Notizen, Tech-Stack festnageln	engine-notes abgeschlossen; Version-Festnagel-Tabelle abgeschlossen	_pretty/, docs/engine-notes.md, REBUILD_PLAN.md
M2+	Quellverfolgte Portierung, Meilenstein-Paar-Commits	Jeder Meilenstein mit Kaltstart getestet + CLEAN Tor Grün	Quellcode mit Zeilennummern-Kommentaren, drei Registrierungstabellen laufend aktualisiert
M(n-1)	Gegenüberstellungsabnahme	Alle ausgewählten Tortypen Grün oder alle Abweichungen registriert	Verifizierungsskripte + Vergleichsergebnisse archiviert (docs/compare/)
M(n)	Kaltstart-Review + Copyright-Forensik + Vorlage an Benutzer	Checklistenabgleich null Lücken; Benutzer hat Bereitstellungsentscheidung getroffen (ungelöst: sicherer Standard beibehalten)	Prüfprotokoll, DEPLOY.md
M(n+1)	Module aufteilen + Entobfuskierung + Kommentare + Self-Contained	Alle bestehenden Tore Grün und Toleranzen nicht gelockert; Symboltor bidirektional bijektiv null Waisen; Self-Contained-Tor (kopieren, offline, bauen) bestanden	src/ (lesbares Projekt), docs/rename-map.json, src/README.md

Skript-Verzeichnis

Node 22+, Pfade relativ zu diesem Skill-Verzeichnis. Verwendung und Reifegrad in scripts/README.md.

⭐⭐ Die Abhängigkeitsdisziplin ist nach Phasen gegliedert, nicht nach Verzeichnis: Vor der Quellcode-Generierung ist die gesamte Pipeline null Abhängigkeiten.

Schritt 0 → M(n) installiert nichts; das Rebuild-Projekt erhält erst in M(n+1) devDependencies (bereichssicheres Umbenennen erfordert einen echten Parser). scripts/ (null Abhängigkeiten) und tools/ (devDeps erlaubt) sind nur eine Projektion dieser Phasengrenze auf das Verzeichnis – die Beurteilung liegt bei scripts/; die Refactoring-Werkzeuge der Quellcode-Generierungsphase liegen in tools/.

⛔ Kein Tor darf irgendein Werkzeug importieren (verification-gates.md §2.1.2) – der Prüfer darf nicht der Produzent sein.

⭐ Was ist, wenn frühere Phasen einen echten Parser benötigen? Extern, nicht importieren. beautify-bundle.mjs (js-beautify) und module-map.mjs (acorn) verwenden beide spawn für eine festgenagelte Version von npx; das Skript selbst bleibt null Abhängigkeiten und unabhängig prüfbar. ⛔ Nicht versuchen, einen manuellen Lexer zu schreiben – in diesem Skill getestet: ein Regex-Literal mit Anführungszeichen hat ihn um 16.177 Zeilen in die Irre geführt (F27). Klammernpaarung im Token-Stream ist präzise; Klammernpaarung im Text ist eine Schätzung für Strings/Regexes/Kommentare.

⚠ Diese Linie wurde erst entdeckt, nachdem sie verletzt wurde: module-map.mjs war von @babel/* abhängig, lebte aber ganze acht Versionen lang in scripts/, während der gleiche Text dieser Disziplin nur drei Zeilen darüber stand. Eine Regel, die nur in der Dokumentation steht und von nichts überprüft wird, kann leise versagen.

Skript	Verwendung	Einsatzphase
scripts/fingerprint.mjs	Schritt 0 Plattformunabhängige äquivalente Implementierung des Sechs-Schritte-Erkennungsprotokolls (GET-Lebensfähigkeit + Redirect-Kette und End-Domain-Identität, Double-Crawl-Diff, Spezies/Jahreszahl, HTML-Technologie-Fingerabdruck, Bundle-Erstprüfung; Vorkommenszählung und <1KB Referer-Wiederholungen integriert; Sanity CMS-Beweissammlung – projectId/dataset/API-Host/auto=format/_key, drei Schreibweisen normalisiert, Treffer verweist auf sanity-platform.md). Sammelt nur Beweise, gibt keine Klassifizierung – Klassifizierung erfolgt weiterhin über den Entscheidungsbaum in scope-and-fingerprint.md §3	Schritt 0 (wenn keine POSIX-Toolchain verfügbar)
scripts/mirror-site.mjs	BFS-Crawler-Spiegel (Asset-Whitelist + Iteration bis zum Fixpunkt; redirect:manual + drei Hauptbücher, inklusive sha256 pro Datei; ⭐ redirects.tsv kumuliert wie das Manifest über Läufe hinweg – --scope zum Ergänzen von Seiten hatte es einmal auf nur die Kopfzeile abgeschnitten, das Ladetor stieß auf /work auf einen 404 und fand es). --scope <Präfix> begrenzt die Seiten-Warteschlange auf den Zielpfad (unverzichtbar bei Mikroseiten, die unter einer Unternehmens-CMS-Domain hängen; ⛔ begrenzt nur Seiten, nicht Assets). Hauptbuch kumuliert (--seeds zum Schließen von Lücken schneidet nicht die vorherige Runde ab) + Off-Host-Zählung (nicht verfolgte Hosts werden einzeln gezählt und gemeldet – stilles Verwerfen hatte einmal 827 Medienverweise verschwinden lassen, während der Bericht „57 Dateien gespeichert“ ausgab)	M0 erster Durchlauf
scripts/netcapture.mjs	Echter Browser CDP-Paketaufnahme zum Abgleich und zur Nachaufnahme von Runtime-Ressourcen (CDN-Seiten MÜSSEN --hosts übergeben, sonst werden nur Same-Origin-Traffic beobachtet und fälschlich GAP=0 gemeldet)	M0 zweiter Durchlauf
scripts/verify-mirror.mjs	Eigenes Tor des Spiegels, läuft vor dem Offline-Tor. Fünf Behauptungen: Abbildungsinjektivität / Hauptbuch vs. Disk-sha256 / Authentizität (Herausforderungsseitentext + Deklarationstyp vs. Magic Number – eine 200 ist kein Beweis dafür, „dass Sie diese Ressource erhalten haben“) / Closure / optionales Stichproben-Zurück zur Quelle. Alle nachgelagerten Tore fragen „kann es gerendert werden?“, ein falscher Spiegel kann sie alle grün färben	M0 vor dem Abschluss, nach jedem erneuten Crawlen
scripts/gapfill-video.mjs	HLS/DASH-Streaming-Medien stufenweise Nachaufnahme (Master → Rendition → Segmente), strukturelle blinde Flecken statischer Crawler	M0 (bei Streaming-Medien)
scripts/reconcile-gaps.mjs	Runtime-Lückenabgleicher: Fügt die von netcapture protokollierten GAP-Zeilen mit der aus Byte-Ableitung erstellten vollständigen Liste (z. B. vollständige srcset-Stufung von next/image – gemessen: 1.078 vs. vom Browser angetroffene 217) Zeile für Zeile in den Spiegel ein. ⭐ Anforderungsheader-Leiter (Standardprofil 4xx → nacktes Profil wiederholen: Derselbe 403 hat zwei gegensätzliche Heilmittel, landonorris will Referer, video.twimg hasst Referer) + URL-für-URL-Fehlertoleranz + stapelweise Buchführung (ein Absturz hinterlässt keine Dateien außerhalb des Hauptbuchs). ⛔ Das Standardprofil für Bild-URLs sendet denselben Bild-Accept-Header wie der Browser (lib/negotiate.mjs) – auto=format-ähnliche CDNs verhandeln das Format nach dem Accept-Header, */* erhält Fallback-Bytes (Basement D5: 391 Varianten alle Fallback, alle Tore Grün); das Hauptbuch protokolliert profile+vary	M0 (Seiten mit vielen Runtime-Ressourcen)
scripts/flight-decode.mjs	C1s Koordinatensystem: Dekodiert den self.__next_f.push-Stream jeder Seite in eine Modulreferenztabelle (I-Zeilen Exportname = geschenkter Tier-1-Benennungsbeweis), HL-Preloads, dereferenzierten Elementbaum und JSX-ähnliche Gliederung. T-Zeilen werden nach Deklarationsbytelänge durchlaufen; :HL leere id-Zeilen dürfen nicht die Kette brechen	M1 (C1)
scripts/verify-flight.mjs	C1s semantisches Tor: Build-Produkt Flight-Baum ≟ Spiegel Flight-Baum. Eigener Parser (⛔ importiert nicht flight-decode – der Prüfer darf nicht der Produzent sein); Normalisierung sammelt nur Build-Hash-Namensräume, die „kein Verhalten mitführen“ (Chunk-Namen/css-module-Klassen/Medien-Hashes/hebbare Ressourcen-Mount-Punkte/Kodierungsfreiheitsgrade). Modul-IDs werden global bijektiv abgebildet (eins-zu-viele = Rot). Seitenspezifische Registrierungseinträge verwenden --normalize-props (ISR-Ära-Felder) und --normalize-class (Bibliotheks-Render-Subtree); alle anderen Unterschiede werden rot markiert	M(n-1) (C1)
scripts/serve.mjs	Null-Abhängigkeits-Statikserver (MIME/Range/Dienstschicht-Umschreibung/Redirect-Wiedergabe), dient auch als Referenzserver der Originalseite. --rewrite FROM::TO ist ein registrierter literaler Ersatz, für eine Sache, die Lokalisierung nicht erreicht – das Quellprogramm verzweigt nach seinem eigenen Domainnamen (location.hostname=="x.com" && (CDN=...); der Spiegel befindet sich nicht auf dieser Domain, also ist der gesamte Zweig tot, unabhängig davon, ob die URLs auf der Festplatte existieren. Das Tor in Schritt M0.5 (Offline-Lauffähigkeit) würde diesen Fehler melden, aber die Fehlerbehebung muss hier ansetzen	Alle Phasen (Referenzserver)
scripts/sweep-routes.mjs	Breitenabnahme-Tool: Alle Routen in einem Browser, sammelt Konsolen-/Netzwerk-/Ausnahme-Ereignisse	M(n-1)

... (weitere Einträge in scripts/README.md)

Referenzdokumentation

• references/scope-and-fingerprint.md – Schritt 0 Klassifizierungsbaum und Erkennungsprotokoll
• references/recon-and-rating.md – Schritt 1 Architekturfalsifikation und Aufgabenschwierigkeitsbewertung
• references/mirroring.md – M0 Spiegel-Forensik-Protokoll und -Werkzeuge
• references/reverse-engineering.md – M1 Reverse Engineering
• references/porting-discipline.md – M2+ Portierungsdisziplin
• references/verification-gates.md – M(n-1) Abnahmetor-Auswahl
• references/determinism.md – Entropiequellen-Handhabung und Rauschklassifizierung
• references/legal-and-deploy.md – M(n) Copyright-Forensik und Entscheidungsvorlage
• references/readable-source.md – M(n+1) Lesbare Quellcode-Generierung
• references/environment-traps.md – Fehlerbehebung bei gescheiterten Portierungsabnahmen
• references/asset-management.md – Umfangreiches Asset-Handling
• references/binary-formats.md – Private binäre Formate
• references/animation-recovery.md – Animationswiederherstellung
• references/webgl-scenes.md – WebGL-Szenen
• references/dom-shell-strategies.md – DOM-Schalenstrategien
• references/archival-rescue.md – Rettung toter Seiten
• references/rsc-reconstruction.md – C1 RSC-Rekonstruktion (ab v0.3)
• references/sanity-platform.md – Sanity CMS Plattformschicht
• references/shopify-platform.md – Shopify-Plattformschicht
• references/beyond-the-rebuild.md – Über den Rebuild hinaus
• scripts/README.md – Skriptverzeichnis-Dokumentation