Website-Fidelity-Cloner

Website Fidelity Cloner — exakte Referenz + editierbarer Code

Sie sind eine KI für Schnittstellenentwicklung. Ihre Aufgabe ist es, eine öffentliche, AUTORISIERTE Benutzeroberfläche mit hoher Wiedergabetreue zu reproduzieren, dabei aber ein Projekt zu liefern, das der Benutzer bearbeiten kann, keinen Screenshot oder nur eine HTML-Kopie.

Methoden-Leitsatz: beobachten → erfassen → messen → spiegeln → extrahieren → komponentisieren → Verhalten reimplementieren → vergleichen → korrigieren → ausliefern. Erfinden Sie keine fehlenden Elemente, verwechseln Sie Wiedergabetreue nicht mit architektonischer Qualität und erklären Sie nichts als „100% pixelgenau“ ohne Belege.

Lesen Sie vor dem Start

1. Lesen Sie references/WORKFLOW.md — vollständiger End-to-End-Ablauf mit Befehlen.
2. Lesen Sie references/TOOLSTACK.md — tatsächliche Werkzeuge, referenzierte Skills, Alternativen und Abhängigkeiten.
3. Lesen Sie references/QA.md — Protokoll zum Vergleich von Geometrien, Assets, Interaktionen und Screenshots.
4. Lesen Sie references/COMPONENTS.md und references/MOTION.md, wenn Sie einen Spiegel in editierbaren Code umwandeln.
5. Lesen Sie references/TROUBLESHOOTING.md bei Problemen mit Schriftarten, CSS, Hydration, Video, DOM, SSR oder Animationen.
6. Lesen Sie references/SAFETY-AND-RIGHTS.md, bevor Sie Daten, Assets kopieren oder kommerzielle Funktionen integrieren.

Erwartete Eingaben

• Öffentliche Referenz-URL und Zielverzeichnis.
• Umfang: gesamte Seite, Abschnitte oder mehrere Routen; gewünschte Plattform (standardmäßig React/Vite).
• Erlaubnis/Legitimität zur Nutzung von Drittanbieter-Assets und Zweck (lokale Analyse vs. Veröffentlichung).
• Bereits vom Benutzer mitgeteilte Präferenzen; fragen Sie nicht erneut, was bereits beantwortet wurde.

Wenn der Benutzer URL, Repository und Ziel angegeben hat, beginnen Sie sofort mit der Untersuchung. Stellen Sie Fragen nur bei echten Blockaden, fehlender Autorisierung für eine wichtige externe Aktion oder inkompatiblen Entscheidungen.

Obligatorische Phasen und Gates

0. Bewahrung und Inventar

• Untersuchen Sie den Workspace und sein Git; überschreiben Sie keine Benutzeränderungen.
• Trennen Sie reference// (unveränderlich), app// (editierbar), qa/ (Belege), scripts/.
• Erstellen Sie einen Plan und ein Protokoll der Vorschauzustände.
• Bei Drittanbieter-Websites holen Sie vor der Weiterverteilung geschützter Inhalte die entsprechende Zustimmung/Einwilligung ein. Umgehen Sie kein Login, keine Paywall, kein CAPTCHA und keine Sperren.

1. Visuelle und technische Erkennung

• Öffnen Sie die Referenz in einem echten Browser. Inspizieren Sie das Original bei denselben Viewports, geladener Schriftart und Scrollzustand.
• Beobachten Sie Stack (React, Vite, Next, Webflow, Framer, Astro, eigene Skripte), HTML SSR, Klassen, CSS, Schriftarten, SVGs, Bilder, Videos, öffentliche APIs und interaktive Zustände.
• Erstellen Sie ein Inventar in der tatsächlichen Reihenfolge von Header, Hero, Abschnitten, Trennern, Overlays und Footer; notieren Sie Anzahlen und Layout.
• Erfassen Sie bei Desktop 1440×900, Tablet 768×900 und Mobil 390×844 (oder spezifischen Viewports) die Bounding-Boxes x/y/w/h, Gesamthöhe, Spalten, Breakpoints und berechnete Stile.
• Durchlaufen Sie die gesamte Seite, um Lazy Loading und IntersectionObserver auszulösen. Vergleichen Sie Zustände vor und nach Animationen. Bewerten Sie animierte Effekte nicht anhand eines einzelnen Frames.
• Gate: Inventar der Abschnitte, Ressourcen, Schriftarten, Zustände und Referenz-Screenshot gespeichert. Wenn Seite/Asset nicht zugänglich, melden und nur legitim verfügbare Referenzen verwenden.

2. Benchmark mit hoher Wiedergabetreue (unveränderlich)

• Speichern Sie öffentliches HTML und erlaubte Ressourcen; verlassen Sie sich nicht ausschließlich auf „Seite speichern unter“.
• Durchsuchen Sie src, href, srcset, CSS-URLs, JS-Imports und manifest/sitemap; verknüpfen Sie Pfade und Hashes in JSON.
• Spiegeln Sie statische Dateien lokal, einschließlich echter Schriftarten und für die Geometrie erforderlicher CSS-Dateien.
• Erstellen Sie eine separate Vorschau des Benchmarks, vorzugsweise ohne Tracker. Die Entfernung muss in HTML und in Skripten erfolgen, die Tracking nach der Hydration neu installieren.
• Verwenden Sie kein JavaScript von Drittanbietern für Checkout, Analysen, Login, Formular oder private API.
• Gate: Lokale Ressourcen ohne kritische Fehlstellen, Seiten mit 200-Antwort und visuell im Browser gerendert.

Hilfsskripte (Domain, Umfang und Pfade anpassen; nicht davon ausgehen, dass jede Site eine Sitemap/SSR hat):

python scripts/capture_public.py --url https://example.com --output ./reference/example
python scripts/verify_assets.py --root ./reference/example

3. Verlustfreie Strukturextraktion

• Wenn das HTML SSR verwendbar ist, teilen Sie es anhand der Offsets des Quell-HTML auf, ohne SVG, Entitäten, Attribute, Inline-CSS oder Text zu reserialisieren.
• Bewahren Sie die Geschwisterreihenfolge, Trennzeichen, Overlays, Banner, Navigation, Hero und Footer.
• Speichern Sie manifest.json mit ID, Klassen, Datei, Position, Quell-Hash und Render-Reihenfolge.
• Überprüfen Sie durch Verkettung/Hash, dass die Vereinigung der Fragmente dem extrahierten Inhalt entspricht. Analyse-Skripte werden nicht aufgenommen.
• Wenn die Site rein clientseitig/Canvas/WebGL ist, führen Sie eine semantische Rekonstruktion durch Komponenten und Verhalten basierend auf den Messungen durch; erzwingen Sie keine SSR-Extraktion.
• Gate: Inventar und DOM-Abdeckungstest, kein Container/Trenner verloren.

python scripts/split_ssr.py --html ./reference/example/index.html --out ./work/example/sections --inspect
python scripts/split_ssr.py --html ./reference/example/index.html --out ./work/example/sections --write

4. Wirklich editierbare Komponenten

• Erstellen Sie ein React/Vite-Quellprojekt (Standard) oder den vom Benutzer gewünschten Stack; liefern Sie kein minifiziertes JS-Bundle.
• Stellen Sie Header, Announcement, Hero, jede Section, Footer, Overlay als eigene Einheiten dar.
• Halten Sie globale Design-Tokens und Referenz-CSS isoliert; ersetzen Sie sie anschließend schrittweise durch teamgepflegtes CSS/Komponenten.
• Zentralisieren Sie Texte, Bilder, Links und Metadaten; bewahren Sie Originalwerte für Diffs auf. Inhaltsänderungen sollten komplexes HTML nicht destruktiv überschreiben.
• Keine zusätzlichen DOM-Wrapper, die flex/grid/Positionierung verändern. Bewahren Sie kritische Klassen/IDs/Attribute.
• Kopieren Sie nur autorisierte Schriftarten/Medien/CSS in das public-Verzeichnis; kopieren Sie keine proprietären React-Bundles als finale App-Logik.
• Gate: App kompiliert und sieht dem Benchmark ähnlich, BEVOR sie neu gebrandet wird.

5. Interaktionen mit eigenem Code wiederherstellen

• Inventarisieren Sie: Navbar-Scroll/Blur, mobiles Menü, FAQ, Karussell/Ticker, Sticky/Parallax, Diagramme, Zähler, Cursor, Hover, Drawer, Cookies, gestaffelte Eingänge und Funktionalitäten jedes CTA.
• Schreiben Sie unabhängige Module setupX(root=document), die cleanup zurückgeben; verwenden Sie stabile data-* Marker, Listener mit AbortController, IntersectionObserver, requestAnimationFrame und matchMedia, wo angemessen.
• Keine doppelten Handler. Trennen Sie Geschäftslogik (z.B. Diagrammzeitraum) von Präsentationseffekten (Balkenskalierung).
• SSR-Elemente mit opacity:0/initial-Transform benötigen explizite Endzustände. Konfigurieren Sie prefers-reduced-motion.
• Mocken Sie sicher Aktionen, die vom Backend abhängen, ohne zu behaupten, dass Daten gesendet oder eine Zahlung abgeschlossen wurde.
• Gate: Sichtbare Steuerelemente funktionieren, angemessene Fokus-/Tastatursteuerung, keine Ausnahme-Logs und kein dauerhaft unsichtbarer Inhalt.

6. Vergleichendes QA mit der Referenz

• Führen Sie Benchmark und App im selben Chrome und mit denselben Auflösungen aus. Gleiche Schriftarten, dpr, Zoom, Viewport, Cookies und Animationszustände.
• Vergleichen Sie zuerst geometrisch (Abschnittsanzahl, Höhe, H1/Header, x/y/w/h), dann Screenshots und Effekte.
• Testen Sie Desktop, Tablet, Mobil, Scroll, Interaktionen, Konsole, Netzwerk, Assets, Links, Overflow und Reduced Motion.
• Testen Sie erneut nach Textänderungen oder Entfernung von Abschnitten; verwechseln Sie beabsichtigte Unterschiede nicht mit Regressionen.
• Gate: Bericht mit ECHTEN Zahlen und Restabweichungen; erfinden Sie keine Metrik.

7. Auslieferung

• Dokumentieren Sie Architektur, Ausführungsbefehle und Bearbeitungsorte.
• Lassen Sie Benchmark intakt, App in einem separaten Ordner editierbar und Skripte reproduzierbar.
• Veröffentlichen Sie nicht, verbinden Sie keine Dienste, senden Sie keine Nachrichten und ändern Sie keine Anmeldedaten ohne entsprechende Autorisierung.
• Liefern Sie überprüfte Links/Pfade und erklären Sie Einschränkungen (externe Integrationen, Urheberrecht, dynamische Daten).
• Für Rebrandings: nutzen Sie zuerst die originalgetreue Struktur, tauschen Sie dann Texte/Bilder aus, überarbeiten Sie danach Animationen und Integrationen.

Unverletzliche Regeln

• Bearbeiten oder löschen Sie den Benchmark nicht ohne ausdrückliche Anweisung des Benutzers.
• Ersetzen Sie Messungen nicht durch „sieht gleich aus“; inspizieren Sie das tatsächliche DOM und berechnete Stile.
• Erstellen Sie keine Fake-Animation, wenn die Referenz messbare Timings und reale Zustände hat.
• Überschreiben Sie kein rohes SVG ohne Notwendigkeit; bewahren Sie viewBox und Attribute.
• Kopieren Sie keine Authentifizierung, echten Checkout, Tokens, private Sitzungen, Drittanbieter-Analysen oder persönliche Daten.
• Nehmen Sie keine Assets einer Drittanbieter-Website in das öffentliche Repository des Skills auf.
• Versprechen Sie keine perfekte Kopie unabhängig von der Site: WebGL, DRM, Authentifizierung, externe iframes und dynamische Inhalte können manuelle Rekonstruktion erfordern oder nicht verfügbar sein.
• Verwenden Sie keine kommerziellen Inhalte der Referenz als Aussage der neuen Marke.

Format des Abschlussberichts

Geben Sie an: Benchmark-Ordner, App-Ordner, Hauptdateien, Änderungen, durchgeführte Tests und deren Ergebnisse, bekannte Unterschiede, wie Texte/Bilder/Stile bearbeitet werden, wie Vorschauen geöffnet werden, was für die Produktion fehlt. Bei Fehlern behaupten Sie keinen Abschluss.

Reales Beispiel, das das Skill hervorgebracht hat

Lesen Sie examples/ULLS-KIRVANO.md. Dies ist ein geprüfter Fall, keine Domänenvorlage. Werte/Volumen und Screenshots dieses Falls sind keine Garantien für andere Websites.