GCW — Gao Copy Website

Was macht GCW — Gao Copy Website?

Studiere, wie eine öffentliche Website tatsächlich funktioniert, reproduziere die Teile, die zählen, und überprüfe das Ergebnis in einem echten Browser. Bevorzuge echte Quellen und beobachtbare Laufzeitbeweise gegenüber plausibel klingenden KI-Vermutungen.

Beachte drei Regeln:

1. Finde Beweise vor der Implementierung.
2. Mache es lauffähig, bevor du es umstrukturierst.
3. Vergleiche, bevor du polierst.

Grenzen

• Fahre nur fort, wenn das Ziel dem Benutzer gehört, für die beabsichtigte Wiederverwendung lizenziert oder explizit autorisiert ist. Frage nur nach, wenn die Autorisierung unklar ist.
• Behandle authentifizierte, passwortgeschützte und private Inhalte als außerhalb des Bereichs, es sei denn, sie sind explizit autorisiert.
• Umgehe keine Zugriffskontrollen und stelle keine Anmeldeinformationen wieder her, versende oder committe sie nicht.
• Prüfe die Rechte an Code, Schriftarten, Bildern, Modellen und Marken getrennt voneinander, bevor du sie öffentlich wiederverwendest.
• Kennzeichne unsichere technische Behauptungen als SOURCE, PARTIAL oder GUESS.
• Präsentiere bereitgestellte Bundles nicht als ursprüngliche Quellcode-Autorenschaft.

1. Wähle das Ziel vor den Werkzeugen

Lies references/clone-modes.md und wähle einen primären Modus:

• TEARDOWN: Verstehe das tatsächliche Design und die Implementierung, ohne eine Neuentwicklung zu versprechen.
• FAITHFUL_CLONE: Reproduziere die beobachtbare Seite so genau wie möglich, wie es die Beweise zulassen.
• CREATIVE_REBUILD: Behalte ausgewählte Struktur-, Rhythmus- oder Interaktionsideen bei, während Marke und Inhalt ersetzt werden.
• PRODUCTION_RECOVERY: Stelle eine eigene bereitgestellte Seite wieder her, wenn wartbarer Quellcode nicht verfügbar ist.

Notiere einen kurzen Preflight:

- Ziel:
- Seitentyp:
- Verfügbarkeit von Quellen:
- Nutzungsgrenze:
- Bereich mit hohem Vertrauen:
- Ungefährer oder ausgeschlossener Bereich:
- Empfohlener Pfad:

Belaste nicht jedes Projekt mit den Kosten einer Produktionswiederherstellung. Verwende die geringsten Beweise und die geringste Verifikation, die das gewählte Ziel unterstützen können.

2. Suche zuerst nach der tatsächlichen Implementierung

Vor dem Scraping oder Neubau:

• Durchsuche den Seitennamen, Produktnamen, Domaininhaber und Deployment-Slug nach einem offiziellen öffentlichen Repository.
• Untersuche Source Maps, Framework-Metadaten und öffentliche Deployment-Artefakte.
• Überprüfe die Lizenzen von Repository und Assets; öffentliche Verfügbarkeit ist keine Erlaubnis zur erneuten Bereitstellung.
• Halte ursprünglichen Quellcode, bereitgestellte Artefakte und deine bearbeitbare Implementierung klar getrennt.
• Verwende die finale kanonische HTTP(S)-URL. GCW lehnt URLs mit Anmeldeinformationen und Dokumentweiterleitungen ab, die den konfigurierten Ursprung verlassen.

Wenn offizielle wiederverwendbare Quellen vorhanden sind, beginne mit ihnen. Wenn nicht, fahre mit der Laufzeitaufklärung fort und dokumentiere, was unbekannt bleibt.

3. Initialisiere den Projektbericht

Lies die Arbeitsbereichsdatei AGENTS.md. Wenn diese Maschine noch nicht überprüft wurde, führe npm install, npm run install:browser und npm run check im GCW-Repository aus.

Erstelle einen nicht-destruktiven Projektbericht:

python scripts/init_reconstruction.py <workspace> --url <canonical-url> --authorization <owned|licensed|authorized>

Verwende .gcw/ für Manifests, Screenshots, Berichte und bekannte Lücken. Überschreibe nicht stillschweigend vorhandene Beweise.

4. Erforsche die Seite und klassifiziere ihre Oberflächen

Führe das Inventar aus, wenn Node.js und Playwright verfügbar sind:

node scripts/site_inventory.mjs --url <canonical-url> --out <workspace>/.gcw/evidence/network/site-inventory.json

Überprüfe dann, was die Automatisierung nicht zuverlässig ableiten kann:

• Routen, Seitenfamilien, Deep Links und responsive Breakpoints
• DOM-Wurzeln, feste Overlays und innere Scroll-Container
• Hover-, Klick-, Zieh-, Scroll-, Zeit-, Größenänderungs-, Theme- und Speicherzustände
• Canvas, WebGL, WebGPU, Worker, Iframes, Video, Audio und verzögerte Ressourcen
• Ladezustand versus stabiler Anwendungszustand
• öffentliche APIs und Datenabhängigkeiten, die lokale Fixtures benötigen

Verwende web-shader-extractor für Canvas-/WebGL-/WebGPU-Besitz, Shader und Rendering-Pipelines. Verwende design-dna, wenn das Ziel darin besteht, Typografie, Abstände, Farbpalette, Layout, Bewegung oder visuelle Sprache zu erhalten und nicht Byte-für-Byte-Artefakte.

5. Wähle den Implementierungspfad

Wähle den Pfad basierend auf Beweisen und Seitentyp:

Beweis oder Seitentyp	Standardpfad
Offizielle wiederverwendbare Quelle	Ausführen und Anpassen der Quelle im Rahmen ihrer Lizenz
Einfache statische Seite	Öffentliche Dateien und URL-Pfade erhalten, dann Tracking entfernen und Inhalt ersetzen
Inhaltsreiche React-/Vue-/Next-Seite	Seitenvorlagen neu erstellen und öffentliche oder lokale Fixture-Daten verwenden
Multi-Page-Marketing-Seite	Routen und Seitenfamilien vor dem Erstellen gemeinsamer Vorlagen kartieren
Interaktionsreiche Seite	Zuerst Zustände erfassen, dann die Zustandsübergänge reproduzieren
WebGL-/Canvas-Seite	Das Render-/Eingabe-/Ausgabe-Modell wiederherstellen, bevor es projektisiert wird
Nur visuelle Inspiration	Design-DNA extrahieren und eine originelle Implementierung erstellen
Produktionsseite ohne Quellcode	references/recovery-tiers.md und references/gates.md lesen, dann ein verifiziertes Wiedergabe-Orakel einrichten

Archiviere oder kopiere keine Drittanbieter-Artefakte, die der gewählte Modus nicht benötigt.

6. Baue ein ausführbares lokales Projekt

• Behalte einen stabilen Referenz- oder Beweisbericht bei, während du das neue Projekt bearbeitest.
• Stelle jede relevante Route wieder her, nicht nur die Startseite.
• Bewahre Navigations- und Deep-Link-Verhalten auf dem gewählten Host.
• Ersetze nicht verfügbares Serververhalten durch explizite Fixtures oder sichere Fallbacks.
• Überprüfe den Produktionsbuild und die statische Vorschau, nicht nur den Dev-Server.

Führe Routenprüfungen durch, wo anwendbar:

python scripts/route_smoke.py --base-url <preview-url> --route / --route /example

7. Überprüfe in einem echten Browser

Lies references/qa-scenarios.md und references/tooling.md.

Definiere Quell- und Kandidatenszenarien, erfasse dann übereinstimmende Zustände:

node scripts/capture_compare.mjs --config <capture-scenarios.json> --output <results-dir>
python scripts/batch_image_diff.py <results-dir> --diff-dir <results-dir>/diff

Stimme Viewport, DPR, Route, Zeiger, Scrollen, Zufallsstartwert, Bereitschaft und Zeitphase ab. Untersuche die Screenshots und Diff-Bilder; ein einzelner globaler Score kann Interaktions- oder Compositor-Fehler nicht erklären.

Verstecke fehlende Verbindungen nicht durch Anpassen von Farben, Offsets oder Animationsgeschwindigkeit. Halte phasenempfindliche Bereiche getrennt von deterministischen Fehlern.

8. Liefere das Gelernte, nicht nur den Klon

Gib nur die Dokumente aus, die der gewählte Modus erfordert:

• TEARDOWN.md: tatsächliche Implementierung, Evidenzniveau und übertragbare Techniken
• DESIGN_DNA.json: Designsystem, visuelle Sprache und Effekte für einen kreativen Neubau
• REPLACE_GUIDE.md: wo Text, Medien, Farben, Schriftarten, Modelle und Daten ersetzt werden müssen
• CLONE_REPORT.md: Quell-vs.-lokal-Vergleich, Abwägungen und bekannte Lücken
• ausführbares Projekt, Build-Befehl und Bereitstellungshinweise

Bei fortgeschrittenen Asset-Fällen, wie z. B. in GLTF-/GLB-Geometrie eingebranntem Text, lies references/special-cases.md, anstatt den Hauptworkflow zu erweitern.

9. Härte nur bei Bedarf

Für gewartete Projekte oder Produktionswiederherstellung installiere den Screenshot-Regression-Runner:

python scripts/install_ci.py <project-root> --source-url <canonical-url>

CI ist optional für eine einmalige Teardown- oder Lernübung. Wenn installiert, muss es Screenshots, Diffs und Berichte hochladen, auch wenn Schwellenwerte nicht erreicht werden.

10. Schließe ehrlich ab

• Führe den Build und die im Preflight versprochenen QA-Szenarien erneut aus.
• Dokumentiere bekannte Lücken und die nächsten benötigten Beweise; erfinde niemals erfolgreiche Interaktionen.
• Entferne Tracking und ursprüngliche Markenreste, bevor du eine angepasste Version veröffentlichst.
• Hinterlasse einen sauberen Git-Checkpoint; pushe niemals ohne Benutzerautorisierung.
• Unterscheide ursprüngliche Ideen, wiederverwendete lizenzierte Assets, beobachtetes Verhalten und deine eigene Implementierung.