Personal Website: Referenzbilder fixiert, 1:1

Persönliche Website (Personal Website)

Kernregeln

Nicht direkt in den Code einsteigen. Die Website als ein mehrstufiges, referenzbildgesteuertes Projekt betrachten:

1. Content- & Style-Festlegung
2. Referenzbild-Festlegung
3. Asset-Aufteilungsliste
4. Asset-Generierung & -Prüfung
5. High-Fidelity-Umsetzung & QA

Der für den Benutzer sichtbare Ablauf hat standardmäßig vier blockierende Bestätigungen:

1. Bestätigung des vollständigen Content- & Style-Briefings, einschließlich Site-Form, Abschnittsplanung, Inhaltsangemessenheit sowie der ausgewählten oder vom Benutzer bereitgestellten visuellen Richtung.
2. Bestätigung der Referenzbildgruppe nach Prüfung auf Konsistenz, Rhythmus und Umsetzbarkeit.
3. Bestätigung der Asset-Aufteilungsliste vor der Generierung oder Suche nach neuen Assets.
4. Bestätigung der generierten/gesammelten Assets und des knappen Umsetzungs-Briefings vor der Code-Implementierung der Seite.

Nach Bestätigung der Referenzbildgruppe nicht direkt in die Implementierung einsteigen. Zuerst jedes bestätigte Referenzbild prüfen, eine für den Benutzer sichtbare Asset-Aufteilungsliste erstellen und auf Bestätigung warten. Nach Bestätigung der Liste nur die genehmigten Assets generieren, suchen oder sammeln. Nach Fertigstellung der Assets die endgültigen Pfade, Prüfergebnisse und ein knappes Umsetzungs-Briefing auflisten; auf die Annahme des Benutzers, eine Aufforderung zur Neuerstellung oder eine Änderung der Aufteilung warten. Erst nach dieser Bestätigung mit der High-Fidelity-Umsetzung beginnen.

Die alte, leichte Pre-Build-Design-Notiz wird in die Asset-Prüfungsausgabe integriert und wird zu einem knappen Umsetzungs-Briefing. Es handelt sich nicht um einen zusätzlichen, unabhängigen Checkpoint: Der Benutzer bestätigt gleichzeitig die Asset-Ergebnisse und das Umsetzungs-Briefing vor dem Code.

Die nachfolgenden Phasen nicht zu einem gewöhnlichen Frontend-Build zusammenfassen. Bestätigte Referenzbilder sind kein Moodboard. Vor dem Schreiben von Code muss jedes Referenzbild einen bestätigten Render-Vertrag haben und in Code-zuständige Bereiche, Fusion-Szenen, unabhängige Medien, Identitäts-/Authentizitäts-Quell-Assets, visuelle Anker sowie endgültige Quellen- und Statusentscheidungen aufgeteilt werden.

Harte Stopp-Bedingung: Keine HTML-, CSS-, JS-, React-, Route- oder Komponenten-Dateien erstellen oder ändern, bevor die Asset-Aufteilungsliste bestätigt, die genehmigten Assets generiert oder gesammelt, und die Asset-Prüfung sowie das Umsetzungs-Briefing akzeptiert wurden. Nur in einem Fortschrittshinweis zu sagen "Ich werde die Referenzbilder aufteilen" gilt nicht als erledigt.

Anspruchsvolle, referenzbildgesteuerte Projekte setzen außerdem eine harte Evidenz-Stopp-Bedingung durch: references/evidence-gate.md lesen. Wenn die erforderlichen, auf der Festplatte gespeicherten Nachweise fehlen, darf der Status nur not verified lauten, nicht pass. Wenn der Benutzer das Überspringen des Bestätigungsstopps verlangt, bedeutet das nur, dass nach bestandener Hürde automatisch fortgefahren wird; es bedeutet keine automatische Bestätigung, kein stillschweigendes Ersetzen von Referenzbildern, kein Überspringen der Prüfung und keine Vervollständigung ohne Nachweise.

Wenn der Benutzer nur teilweise Unterlagen hat, zuerst die Lücken prüfen und vorrangig weniger aufwändige Methoden zur Dateneingabe vorschlagen, anstatt sofort zu verlangen, dass der Benutzer alles manuell schreibt. Wenn der Benutzer bereits bestätigte Inhalte, Referenzbilder und Assets hat, kann direkt zur entsprechenden Prüfung, Asset-Prüfung oder Umsetzungsphase gesprungen werden, aber die gleichen Bestätigungsgrenzen vor dem Code müssen eingehalten werden.

Ausführungsdisziplin

Beim Vorantreiben zwischen den Phasen die aktuellen Annahmen, das nächste überprüfbare Ziel und die Methode zu dessen Überprüfung erläutern. Wenn eine Anfrage mehrere Interpretationen zulässt, zuerst die Optionen klar darlegen und nachfragen, bevor eine bestimmte Richtung eingeschlagen wird.

Änderungen zurückhaltend vornehmen:

• Keine Abschnitte, Interaktionen, Inhalte, Routen, Asset-Typen oder Konfigurationen hinzufügen, die der Benutzer nicht angefordert oder bestätigt hat.
• Bei der Bearbeitung eines bestehenden Projekts nur die Dateien ändern, die für den bestätigten Umfang notwendig sind, und dabei den bestehenden Stil des Projekts beibehalten.
• Nur Code, Assets oder Imports entfernen, die durch diesen Workflow neu hinzugekommen und nun nutzlos sind; irrelevante, bereits vorhandene Tote-Code-Stellen nur erwähnen, nicht löschen.
• Das minimale Design-Briefing, die Asset-Liste, die Prompt-Gruppe oder die Implementierungsänderung verwenden, die benötigt werden, um die nächste Phase zuverlässig voranzutreiben.
• Mehrschrittige Aufgaben benötigen ausreichend spezifische Erfolgskriterien, um ein ratloses Vorantreiben zu vermeiden.
• Jeweils nur einen Abschnitt-Slice implementieren und validieren; nicht behaupten, dass mehrere Abschnitte bestanden haben, wenn nur ein Teil geprüft wurde.

Sprache & Lokalisierte Ausdrücke

Benutzersichtbare Führungshinweise müssen der primären Sprache des Benutzers entsprechen. Wenn der Benutzer auf Chinesisch fragt, werden Fortschrittshinweise, Phasenübergänge, Bestätigungsanfragen und Optionsbezeichnungen auf Chinesisch verwendet, z.B. 第一步 / 内容与风格锁定, 接下来进入第二步. Wenn der Benutzer auf Englisch fragt, wird Englisch verwendet, z.B. Step One / Content and Style Lock, Next I will move to Step Two. Wenn die Konversation gemischt ist, wird der aktuellen, eindeutigen Präferenz des Benutzers oder der Sprache der letzten inhaltlichen Anfrage gefolgt.

Gegenüber dem Benutzer gerichtete Hinweise, Phasenübergänge, Bestätigungsanfragen und Optionsbezeichnungen verwenden standardmäßig die Zielsprache (hier: Deutsch); notwendige Dateinamen, Befehle, Feldnamen und technische Begriffe bleiben auf Englisch, um den Ausführungsvertrag nicht zu ändern.

Phasennamen müssen ebenfalls vollständig übersetzt werden. Der Benutzer sollte Fünfter Schritt / High-Fidelity-Umsetzung & QA sehen, nicht Step Five / Build and QA oder ähnliche gemischtsprachige Bezeichnungen.

Integrierte Begleit-Skills

Dieses Skill enthält integrierte Begleit-Referenzen, sodass der Workflow nicht davon abhängt, dass der Benutzer zusätzlich andere Skills installiert:

• references/imagegen-frontend-web.md: Wird für den harten Vertrag zur Generierung von Referenzbildern für persönliche Websites im zweiten Schritt verwendet.
• references/visual-quality-gate.md: Wird für die Prüfung der tatsächlichen Bedeutung, Hierarchie, des Weißraums, des Beschnitts, der Überlappung, der Autorenschaft und des Fresh-Context im zweiten und fünften Schritt verwendet.
• references/evidence-gate.md & scripts/verify_identity_run.py: Werden für nicht überschreibbare Referenz-Hashes, abschnittsweise Screenshot-Nachweise, topologische Zuordnung und deterministische Vollständigkeitsprüfung verwendet.
• references/reference-asset-splitter.md & references/split-patterns.md: Werden für die Drei-Achsen-Asset-Entscheidung und reale Fehlerkorrekturbeispiele im dritten Schritt verwendet.
• references/frontend-app-builder.md: Wird für die High-Fidelity-Implementierung und QA nach der Asset-Prüfung verwendet.

In der Phase der Referenzbildgenerierung für persönliche Websites muss references/imagegen-frontend-web.md gelesen werden, unabhängig davon, ob das eigenständige imagegen-frontend-web installiert ist. Wenn das Ziel anspruchsvoll, professionell, unverwechselbar oder auf Awwwards-Niveau ist, müssen im zweiten und fünften Schritt auch references/visual-quality-gate.md gelesen werden. Diese integrierten Dateien sind die harten Verträge dieses Workflows; eigenständige Skills können ein breiteres kreatives Vokabular ergänzen, aber nicht das bestätigte Briefing, den Style-Fingerabdruck, den Bedeutungsvertrag, die visuelle Qualitätsschwelle, das Asset-Budget und die Umsetzbarkeitsregeln überschreiben.

In der Asset-Entscheidungsphase: Wenn reference-asset-splitter installiert ist, die installierte Version verwenden, andernfalls die integrierte Version; beide müssen den gleichen Klassifikator und die gleichen Beispiele verwenden. Das vom Benutzer bestätigte Briefing und die harten Phasengrenzen dieses Skills haben Vorrang vor den Standardregeln der Begleit-Skills. Im fünften Schritt wird der installierte frontend-app-builder bevorzugt; die integrierte Kopie dient als Fallback.

Wenn ein Begleit-Skill nicht installiert ist, nicht stecken bleiben, nicht so tun, als ob ein @skill-Aufruf verfügbar wäre, und den Benutzer nicht auffordern, es zu installieren, um fortzufahren. Die integrierte Begleit-Referenz dieses Pakets lesen und als lokalen, verbindlichen Ausführungsvertrag verwenden.

Die separate Installation eines Begleit-Skills nur dann ansprechen, wenn der Benutzer ausdrücklich eine unabhängig installierbare Komponente wünscht. Im normalen Pfad sollte die Installation des identity-skill allein ausreichen.

Wenn kein Bildgenerierungstool verfügbar ist, kopierbare Prompts schreiben, die der Benutzer in GPT Web Image 2 oder ein anderes Bildtool einfügen kann, oder den Benutzer bitten, eigene Referenzbilder bereitzustellen. Wenn der Benutzer Referenzbilder vollständig überspringt, den Build als niedrigere Wiedergabetreue betrachten und klarstellen, dass die visuelle Qualitätssicherung nur gegen das textliche Briefing und nicht gegen akzeptierte Referenzbilder durchgeführt werden kann.

Phasen-Hinweis-Protokoll

Am Ende jeder für den Benutzer sichtbaren Phase einen klaren Fortschrittshinweis geben:

• Aktueller Fortschritt: Erster Schritt / Phasenname
• Erledigt: Das soeben erzielte konkrete Ergebnis
• Noch fehlend oder riskant: Nur die Blockierungspunkte auflisten, die tatsächlich den Fortschritt behindern
• Was der Benutzer jetzt tun kann: Bestätigen, einen benannten Teil ändern, fehlende Daten bereitstellen oder eine Option auswählen
• Nächster Schritt: Den Namen der nächsten Phase und was passieren wird, erläutern

Den Benutzer nicht an einem impliziten Haltepunkt stehen lassen. Wenn der Workflow ohne blockierende Bestätigung fortgesetzt wird, klarstellen, dass und warum fortgefahren wird.

Erster Schritt: Content- & Style-Festlegung

Zuerst entscheiden, welcher Inhaltsweg zutrifft. Den Benutzer nicht zwingen, Informationen manuell zu wiederholen, die aus bereits bereitgestellten Dateien, Links, Lebensläufen, Profilen, Notizen, Schreibproben, Projektdokumentationen, Screenshots oder bestehenden Websites extrahiert werden können.

Dateneingabe-Wege

Einen der folgenden Wege verwenden:

• Datereicher Weg: Der Benutzer hat Lebenslauf, CV, LinkedIn, persönliche Homepage, Portfolio, Projektlinks, Notion/Markdown-Dokumente, Kurzbiografie, Medienkit, Social-Media-Profile, Schreibarchive oder ähnliches Material bereitgestellt. Zugängliche Inhalte lesen, bestätigte Fakten, für Abschnitte nutzbare Inhaltseinheiten, Links, Assets und Lücken extrahieren. Nur gezielte Nachfragen stellen, die die Website betreffen.
• Knappes Briefing: Der Benutzer hat ein Ziel oder eine Identität angegeben, aber wenig unterstützendes Material. Zuerst den Benutzer einladen, weniger aufwändige Eingaben zu machen, z.B. Lebenslauf, bestehende Vorstellung, Projektlinks, Schreiblinks, Fotos, Referenzwebsites oder Screenshots. Wenn der Benutzer keine Dateien bereitstellen möchte, die folgenden Leitfragen verwenden.
• Weg von Null: Der Benutzer hat kein Material oder möchte von Grund auf beginnen. Die Leitfragen gebündelt auf einmal stellen, nicht als Frage-für-Frage-langes Interview.
• Schneller Demo-Weg: Der Benutzer betont ausdrücklich Geschwindigkeit oder einen groben Prototyp. Leichte Mock-Inhalte können verwendet werden, aber alle erfundenen Fakten, Projekte, Zitate, Metriken, Links oder Details zur Person müssen als Platzhalterinhalte markiert werden, die vor der endgültigen Version ersetzt werden müssen.

Der Weg mit Leitfragen sollte kompakt sammeln:

• Ziel: Lebenslauf, Jobsuche, Portfolio, Creator/Personal IP, Berater, Founder/Executive-Vorstellung, Vortrags-/Medienseite oder andere Zwecke
• Zielgruppe: Wer wird die Seite besuchen, was sollen sie nach dem Besuch tun
• Positionierung: Identitäts-Tag, einprägsamer Satz, Tonalitätsgrenzen
• Nachweise: Erfahrung, Projekte, Schriften, Produkte, Kunden, Medienberichte, Vorträge, Auszeichnungen oder andere Belege
• Projektdetails: Hintergrundfragen zu jedem wichtigen Projekt, deine Rolle/Handlung, Ergebnis, Links/Medien, und woran man sich erinnern soll
• Assets & Grenzen: Profilbild, Logo, Screenshots, Dokumente, Links, nicht verfügbare oder sensible Inhalte, und was nicht generiert oder übertrieben werden darf
• Benutzerpräferenzen: Informationsdichte der Site, Präferenz für einseitig oder mehrseitig, gemochte Referenzen, nicht gemochte Stile, zukünftige Wartungsbereitschaft

Inhalts- & Site-Form-Dokument

Für anspruchsvolle persönliche Websites, Personal-IP-Seiten, Portfolios, Awwwards-Niveau-Richtung oder jedes Szenario, in dem die Designqualität wichtig ist, vor dem Generieren von Bildern ein Inhalts- & Site-Form-Dokument erstellen. Für schnelle Demos kann die gleiche Struktur beibehalten, aber kürzer geschrieben werden.

Das Dokument sollte enthalten:

• Datenabdeckung: Welche Dateien, Links, Notizen oder Benutzerantworten verwendet wurden
• Bestätigte Fakten: Nur Fakten schreiben, die vom Benutzer bereitgestellt oder durch Quellen gestützt werden
• Unbestätigte Entwurfsinhalte: Klar markierte, vom Agenten vorgeschlagene Texte, Beispiele, Platzhalter, abgeleitete Behauptungen oder fehlende Links
• Site-Ziel & Zielgruppe: Was soll diese Website erreichen, für wen ist sie
• Besuchererinnerung: Ein bis drei Dinge, an die sich der Besucher erinnern soll
• Site-Form-Empfehlung: Einseitig, einseitiger Lebenslauf, Startseite plus Case Study, mehrseitiges Portfolio, Creator-Hub, Berater-Landing-Page oder andere Formen
• Begründung der Empfehlung: Warum diese Form zum Ziel des Benutzers, zur Inhaltsmenge, zur Nachweistiefe und zur Wartungsbereitschaft passt
• Optionale Alternativen: Leichtere oder vollständigere Strukturen, die machbar, aber weniger empfehlenswert sind
• Abschnittsplanung: Zweck jedes Abschnitts, erforderliche Inhalte, Inhaltseinheiten, Links/Assets und Status (ready, needs detail, placeholder oder cut)
• Risiko der Inhaltsangemessenheit: Vage, schablonenhafte, falsche, überladene, nicht gestützte oder nicht erhaltenswerte Abschnitte

Die Site-Form muss basierend auf den Zielen des Benutzers und der Datendichte empfohlen werden; nicht standardmäßig fünf oder sechs Abschnitte annehmen. Für Lebenslauf- oder Jobsuchzwecke reicht in der Regel eine einseitige oder ein- bis zweiseitige Seite. Ein tiefgehendes Portfolio benötigt möglicherweise einen Case-Study-Route. Creator-, Founder- oder Berater-Seiten benötigen nur dann eine stärkere Erzählung oder Conversion-Pfad, wenn der Inhalt dies trägt.

Alle Inhalte, die für Referenzbilder verwendet werden, müssen vom Benutzer bereitgestellt oder ausdrücklich genehmigt sein. Der Agent kann Inhalte vorschlagen, um Lücken zu füllen, aber diese Inhalte sind nur Entwürfe, keine bestätigten Fakten. Nicht Agent-vorgeschlagene Inhalte als bestätigt behandeln, nur weil sie vernünftig oder gut klingen.

Vor der Bestätigung im zweiten Schritt die Evidenzquellenstrategie für jede identifizierbare Person, Firma, jedes Produkt, Werk, jede Veröffentlichung oder jedes Projekt festlegen. So früh wie möglich verfügbare Benutzer-Assets oder offizielle Assets sammeln, damit Referenzbilder direkt um echte Beweise herum komponiert werden können; nicht zuerst eine stärkere generierte Platzhalter-Komposition bestätigen und dann planen, sie nach der Festlegung durch offizielle Assets mit anderer visueller Gewichtung, Proportion oder anderem Motiv zu ersetzen.

Stilempfehlungen

Sobald Inhalt und Site-Form ausreichend klar sind, basierend auf Inhalt, Benutzerpräferenzen, Zielgruppe, Site-Zweck und vorhandenen Referenzen maximal drei visuelle Richtungen empfehlen. Der Benutzer kann eine auswählen, mehrere Optionen mischen oder seine eigene visuelle Richtung / Referenzen bereitstellen.

Die Stiloptionen müssen visuelle Konzepte sein, nicht nur Positionierungs-Tags. Nicht nur "Internationaler Studenten-Lebenslauf", "FinTech-Produktforscher", "KI + Finance Portfolio" geben, die nur die Zielgruppe oder die berufliche Erzählung unterscheiden. Diese Tags können erklären, warum etwas passt, aber die Optionen selbst müssen es dem Benutzer ermöglichen, sich die Seite vorzustellen, bevor Bilder generiert werden.

Jede Stiloption sollte kurz abdecken:

• Visueller Konzeptname: Kurzer Tag, der die Bildstimmung beschreibt, nicht nur die persönliche Rolle
• Stimmungs- und Positionierungs-Match
• Farbrichtung: 3-5 spezifische Farben oder Farbrollen, bei Bedarf mit Hex
• Schriftcharakter: Schriftcharakter und Strichstärkenkontrast für Display/Body
• Above-the-Fold-Komposition: Wie Name, Headline, Profilbild/Medien, CTA, Nachweishinweise jeweils erscheinen
• Layoutdichte & Abschnittsrhythmus: Zurückhaltend einseitig, editorialer Rhythmus, Bento-Nachweisblöcke, Case-Study-Tiefe oder anderer spezifischer Rhythmus
• Bild- oder Asset-Behandlung: Profilbild-Beschnitt, Projektscreenshots, Dokumentkarten, Datenvisualisierungen, redaktionelle Fotos, abstrakte Hintergründe oder Code-Render-Grafiken
• UI-Chrome & Navigationsgefühl: Header-Dichte, Wortmarke, CTA-Form, Rahmen, abgerundete Ecken, Icon-Stil und Active State
• Bewegungscharakter
• Was der Benutzer sehen wird: Ein Satz, der den visuellen Ersteindruck des Bildschirms beschreibt
• Warum es für diese Person und diese Site-Form geeignet ist
• Hauptrisiken oder Kompromisse

Wenn eine Stiloption nicht als sichtbares Website-Bild beschrieben werden kann, zuerst umschreiben, bevor sie dem Benutzer gezeigt wird. Wenn das Ziel des Benutzers die berufliche Positionierung ist, die Positionierung in visuelle Entscheidungen übersetzen, nicht den Options-Titel die gesamte Ausdruckskraft tragen lassen.

Bei Bedarf dieses kompakte Stiloptionsformat verwenden:

Option A — Editorial Lebenslauf / Tusche auf Papier
Farben: Warmweiß #F7F3EC, Tuscheschwarz #171717, Graublau #6B7280, Akzentblau #2563EB.
Schriften: Zurückhaltende Serifen-Display + saubere, serifenlose Body; professionell, aber nicht dekorativ.
Above the Fold: Name und ein Einzeiler zur Positionierung linksbündig in großzügigem, papierähnlichem Weißraum; rechts ein ruhig beschnittenes Profilbild oder LinkedIn-ähnliches Foto, darunter zwei Nachweislinks.
Rhythmus: Einseitiger Lebenslauf-Fluss, ruhige Abschnitte, Projektnachweise in kleinen Karten.
Visueller Eindruck: Wie ein anspruchsvoller, internationaler Kandidaten-Editorial-Lebenslauf, keine Startup-Landing-Page.
Risiko: Wenn der Benutzer eine stärkere persönliche Marke wünscht, wirkt es zu schwach im Wiedererkennungswert.

Keine Referenzbilder generieren, bevor der Benutzer das vollständige Content- & Style-Briefing bestätigt hat. Wenn der Benutzer eine Stiloption ausgewählt hat und keine Einwände gegen das Inhaltsdokument hat, diese Antwort nur dann als erste blockierende Bestätigung betrachten, wenn dein Hinweis klarstellt, dass "dies gleichzeitig Inhalt und Stil festlegt".

Diese Abschlusshinweisform für den ersten Schritt verwenden:

Aktueller Fortschritt: Erster Schritt / Content- & Style-Festlegung
Ich habe vorbereitet: Datenquellen-Zusammenfassung, bestätigte Fakten, Site-Form-Empfehlung, Abschnittsplanung, Inhaltsrisiken und Stiloptionen.
Bitte bestätigen oder ändern:
1. Site-Form und Abschnittsplanung
2. Alle als unbestätigt markierten Inhalte
3. Visuelle Richtung: Eine Option auswählen, mehrere Optionen mischen, Farben/Layout ändern oder eigene Referenzen bereitstellen
Nach Bestätigung werde ich in den zweiten Schritt gehen und Referenzbilder für jeden Abschnitt generieren oder vorbereiten.

Zweiter Schritt: Referenzbild-Festlegung

Abschnittsweise Referenzbilder als visuelle Faktenquelle verwenden.

Referenzbild-Prompts müssen auf dem bestätigten Content- & Style-Briefing basieren: genehmigte Inhalte, genehmigte Site-Form, ausgewählte oder vom Benutzer bereitgestellte visuelle Richtung, globale Chrome-Regeln und die spezifischen Inhaltseinheiten jedes Abschnitts. Wenn der Benutzer eine qualitativ hochwertige persönliche Website erwartet, keine Referenzbilder basierend auf einem dünnen Briefing oder nicht genehmigten Agent-Inhaltsvorschlägen generieren.

In dieser Phase immer references/imagegen-frontend-web.md lesen. Wenn das eigenständige imagegen-frontend-web verfügbar ist, es verwenden, um unter dem harten Vertrag der persönlichen Website ein breiteres Art Direction zu ergänzen. Die Referenzbildgruppe muss für jeden bestätigten Abschnitt ein horizontales Bild, eine starke Komposition, eine einheitliche persönliche IP-Welt und eine tatsächlich implementierbare Bildtopologie erreichen.

Wenn der Benutzer GPT Web Image 2 bevorzugt, für den Benutzer kopierbare Prompts schreiben, anstatt Bilder direkt zu generieren.

Referenzbild-Generierungsplan

Vor der Generierung von Abschnitten einen prägnanten Referenzbild-Generierungsplan erstellen. Dies ist ein internes Artefakt des zweiten Schritts und fügt kein neues Benutzerbestätigungstor hinzu. Wenn ein Projektverzeichnis vorhanden ist, diesen Plan in ein Wiederherstellungsdokument oder eine kleine docs/reference-production-plan.md schreiben; wenn kein Verzeichnis vorhanden ist, ihn im Arbeitsoutput des zweiten Schritts behalten.

Zuerst den gemeinsamen Style-Fingerabdruck für die gesamte Gruppe festlegen:

• Genaue Farbrollen und Hex-Werte
• Display/Body/Label/Nav-Schriftrollen und relative Schriftgrößen
• Globales Chrome, Rahmen-/Ecken-/Schatten-Sprache und CTA-Familie
• Material, Licht, Textur, Farbgebung von Fotos, Illustrations-/Icon-Sprache
• Dichtebereich, Abstandsrhythmus, Leinwandverhältnis und maximal ein optionales, signifikantes Motiv
• Konstanten, die nicht abdriften dürfen, und ein bis zwei Dimensionen, die pro Abschnitt variieren dürfen

Dann für jeden Abschnitt einen Render-Vertrag angeben:

• C0 code-only: Schriftarten, Layout und einfache Geometrie, keine Raster-Assets benötigt
• C1 integrated-scene: Code-UI über einer fusionierten Szene; die Szene kann full-bleed sein oder eine visuelle Insel mit Grenzen
• C2 independent-media: Code-Hülle plus ein bis drei Fotos, Screenshots, Cover oder Produkt-Mocks mit eigenständiger Bedeutung
• C3 scene-plus-identity: Eine fusionierte Szene plus ein echtes Quell- oder Replace-Later-Profilbild, Logo, offizielles Produktfoto

Jeder Render-Vertrag muss klar angeben: codezuständige Inhalte, erlaubte site-weite gemeinsam genutzte Assets, Grenzen der fusionierten Szene, unabhängige Medien-Slots, Identitäts-/Authentizitäts-Quell-Assets, verbotene Fusionen, responsives Verhalten, Textsicherheitsbereich, Asset-Budget und topologische Zuordnung (abschnittsspezifisch oder benannte und begründete gemeinsame Struktur). Hochwertige Ziele müssen außerdem die Bedeutung-Felder aus references/visual-quality-gate.md ergänzen: Drei-Sekunden-Information, persönlicher Nachweis, autoriale Design-Handlung, Fokusebene, Lesepfad, Weißraum-Karte, semantische Grafikbedeutung, Überlappungsliste, geschlossene Ausnahmebereiche und Above-the-Fold-Nutzlast. C0 code-only bedeutet 0 abschnittsspezifische Raster; wenn Papiertextur oder Scanstreifen zum festgelegten Fingerabdruck gehören, können ein bis zwei explizit deklarierte Site-weite Materialien wiederverwendet werden. Es bedeutet jedoch nicht, dass ein inhaltsarmer, nur von großen Schriftarten ausgefüllter Abschnitt fertig ist: Neben der großen Schriftart muss es eine zweite inhaltliche Designentscheidung geben, sonst den Abschnitt kürzen, zusammenlegen oder neu gestalten. Jedes gemeinsam genutzte Material wird nur einmal generiert und nur einmal site-weit gezählt. Standardmäßig pro Abschnitt ein primärer visueller Fokus, maximal eine fusionierte Szene, nicht mehr als drei abschnittsspezifische Raster-Einheiten; nur wenn der Benutzer eine dichte Evidenz-Wall-Richtung ausdrücklich genehmigt hat, kann davon abgewichen werden.

Zuerst den Anchor-Abschnitt generieren, der die Identität am besten definiert, normalerweise der Hero. Nachfolgende Abschnitte in derselben Charge generieren; wenn das Bildtool Referenzeingaben unterstützt, den Anchor als visuelle Anleitung verwenden, sonst denselben Style-Fingerabdruck wortwörtlich wiederverwenden. Kein zusätzliches Bestätigungstor zwischen Anchor und nachfolgenden Bildern einfügen.

Standardausgabe:

• Ein horizontales Referenzbild pro Abschnitt
• Keine langen, vertikalen, ganzen Seiten-Collagen
• Keine feinen, schwer lesbaren Mehr-Abschnitt-Boards
• Alle Abschnitte behalten eine konsistente persönliche IP-Weltsicht
• Referenzbilder sollten wie echte Website-Screenshots aussehen, nicht wie Poster
• Code-zuständiger Text und Steuerelemente müssen sauber von Raster-Material trennbar sein
• Statische fusionierte Szenen bleiben eine vollständige visuelle Einheit; unabhängige Medien-Slots dürfen keine grenzüberschreitenden Schatten, Reflexionen oder Überlappungen aufweisen

Bevor die Referenzbildgruppe dem Benutzer zur Bestätigung vorgelegt wird, eine vierfache Prüfung durchführen:

1. Visuelle Bedeutungsprüfung: Alle harten Hürden aus references/visual-quality-gate.md durchführen, einschließlich Drei-Sekunden-Vermittlung, einziger erster Fokus, Liste von Elementen mit Zweck, persönlicher Spezifität, abgeschlossener Komposition, Dichte-Obergrenze/-Untergrenze, bedeutungsvoller Weißraum, grafische Semantik, Beschnittintegrität, Überlappungssicherheit und responsive Above-the-Fold-Nutzlast. Ein Abschnitt scheitert, selbst wenn er schön oder implementierbar ist, wenn die Idee, die Evidenz oder die Komposition schwach ist.
2. Konsistenzprüfung: Jedes Bild mit dem präzisen Style-Fingerabdruck vergleichen und globale Navigation, Schriftrollen, Farbpalette, Abstände, Box-Sprache, Bildfarbgebung, Motiv und mobile Logik prüfen. Es muss auf den ersten Blick als zur selben Website gehörig erkennbar sein.
3. Rhythmusprüfung: Das Kompositionsskelett jedes Abschnitts auflisten und die Variationsbreite prüfen. Es kann maßvoll in Abschnittsaufgabe, Maßstab, Ausrichtung, Beschnitt oder Dichte variiert werden, aber nicht jeder Bildschirm sollte ein völlig neues visuelles Konzept sein. Einen Grau-Block-Test durchführen: Nachdem Fotos in Graublöcke verwandelt wurden, sollten mindestens die Hälfte der Abschnitte durch Schriftarten, Layout, Farbe und Struktur immer noch Designgefühl vermitteln.
4. Umsetzbarkeitsprüfung: Jedes Bild mit dem Render-Vertrag vergleichen. Wenn Codetext und Raster-Material nicht trennbar sind, unabhängige Assets harte Schatten/Überlappungen teilen, Identitäts-Assets unwiderruflich in die generierte Szene eingebettet sind, responsives Umbrechen das Verschieben von Pixeln innerhalb eines einzelnen Bildes erfordert, das Asset-Budget ohne Genehmigung überschritten wird oder ungeplante Bildinseln auftauchen, scheitert der Abschnitt.

Wenn die Referenzbild-Topologie fehlschlägt, redesign-required verwenden: Den gesamten Site-weiten Style-Fingerabdruck beibehalten, nur den fehlgeschlagenen Abschnitt neu generieren und dann dem Benutzer zur Bestätigung vorlegen. Nicht nicht implementierbare Referenzbilder im dritten Schritt erzwingen, indem fragile Slices oder Low-Fidelity-Code als Ersatz verwendet werden.

Nach Bestätigung der geprüften Referenzgruppe diese in ein neues, nicht überschreibbares Verzeichnis kopieren, z.B. references/locked/v1/, und den SHA-256 jedes Bildes in docs/identity-evidence.json schreiben. Bereits gesperrte Dateien nicht überschreiben; Neugenerierung oder Restrukturierung muss eine neue Version erstellen und die betroffene Prüfung des zweiten Schritts erneut durchführen.

Wenn die Designqualität wichtig ist oder der Benutzer eine Geschmacksberatung wünscht, gleichzeitig references/taste-calibration.md und references/visual-quality-gate.md lesen. Die Geschmacksbeispiele kalibrieren die optionale visuelle Welt, die Qualitätsschwelle entscheidet, ob diese Welt tatsächlich klar ausgedrückt und das Design vollendet ist.

Diese Abschlusshinweisform für den zweiten Schritt verwenden:

Aktueller Fortschritt: Zweiter Schritt / Referenzbild-Festlegung
Ich habe vorbereitet: Site-weiten Style-Fingerabdruck, Bedeutung & Render-Vertrag für jeden Abschnitt, Referenzbilder sowie visuelle Bedeutungs-/Konsistenz-/Rhythmus-/Umsetzbarkeitsprüfung.
Bitte bestätigen oder ändern:
1. Diese Bilder als Bauziel akzeptieren
2. Abschnitte angeben, die neu generiert werden sollen
3. Vor dem Bau die visuelle Richtung anpassen
Nach Bestätigung der Bilder werde ich in den dritten Schritt gehen und formell die Asset-Aufteilungsliste erstellen: Was bleibt im Code, was ist eine fusionierte Szene, was sind unabhängige Medien, was muss eine echte Quelle sein, was ist blockiert, Replace-Later oder Redesign-Required. Ich werde auf Ihre Bestätigung warten, bevor ich neue Assets generiere oder suche.

Dritter Schritt: Asset-Aufteilungsliste

Nach Bestätigung der Referenzbildgruppe zuerst die akzeptierten Referenzbilder prüfen, keine Assets generieren und keinen Code schreiben. Diese Phase erstellt eine für den Benutzer sichtbare Asset-Aufteilungsliste und hält zur Bestätigung an.

Vor der Erstellung der Liste: Wenn reference-asset-splitter installiert ist, dieses und references/split-patterns.md lesen; andernfalls die integrierten references/reference-asset-splitter.md & references/split-patterns.md lesen. Den Drei-Achsen-Klassifikator in Reihenfolge durchführen: Grenzgranularität, Rendering-Medium, Bildebene. Nicht drei Dinge in einen Satz wie "sieht komplex aus" packen.

Eine feste Konfliktpriorität verwenden: Echte Identitäts-/Quell-Assets; Live-semantische Inhalte & Barrierefreiheit; unabhängige Interaktion/Ersatz/Update/responsives Umbrechen; Code-Whitelist & Raster-Signale; Fusionsbeziehungen; Asset-Budget; zuletzt ästhetische Präferenz. Visuelle Komplexität allein erzwingt weder eine feine Aufteilung noch beweist sie, dass Code eine High-Fidelity-Umsetzung erreichen kann.

Das Ziel ist Praktikabilität, nicht Über-Spezifikation: Dem Benutzer sagen, welche sichtbaren Teile im Code bleiben sollten, welche separat generiert oder als Assets gesammelt werden müssen, welche transparente/Vordergrund-Assets benötigen, welche zum Hintergrund gehören, welche echten Assets nicht gefälscht werden dürfen und welche Entscheidungen, wenn sie falsch getroffen werden, die endgültige Umsetzungstreue beeinträchtigen.

Diese Phase erstellt oder aktualisiert ein sichtbares Wiederherstellungsartefakt. Akzeptable Formen sind:

• docs/restoration-plan.md, das die Referenzbildzuordnung, das Asset-Manifest und das nachfolgende knappe Umsetzungs-Briefing kombiniert
• docs/reference-to-build-map.md plus docs/asset-manifest.md
• Wenn das Repository bereits eine docs-Konvention hat, kann auch eine äquivalente, projektinterne Dokumentation verwendet werden

Das Artefakt muss vor der Asset-Generierung und vor der Code-Editierung der Seite erstellt werden. Es muss jedes bestätigte Referenzbild und jeden Abschnitt/Seite auflisten. Es reicht nicht aus, dies nur im Chat zusammenzufassen, die Überlegungen zu verstecken oder einen einzigen Fortschrittshinweis zu geben.

Die für den Benutzer sichtbare Asset-Aufteilungsliste sollte kürzer sein als das interne Artefakt. Jeder Abschnitt enthält:

• Code-zuständige Elemente: Text, Navigation, Buttons, Layout, einfache Formen, Labels und bearbeitbare Animationen
• Site-weites gemeinsam genutztes Asset: Optionales Papier, Körnung, Scanstreifen oder anderes nur einmal generiertes und wiederverwendetes Fingerabdruck-Material, oder none
• Fusioniertes Szenen-Asset: Ganzer Hintergrund oder fusionierte Szene mit Grenzen, Textur, Karte, Fotofeld, Desktop-Welt, Karten-Collage, oder none
• Unabhängiges Medien-Asset: Profilbild, Produkt-Mock, Screenshot, Foto, Cover, eigenständige Illustration, oder none
• Vorhandenes echtes Asset: Vom Benutzer bereitgestelltes Foto, Logo, Produktscreenshot, offizielles Asset oder zu kopierende Quelldatei
• Generierbares Asset: Sicher generierbare Atmosphärenbilder, dekorative Elemente, abstrakte Produkt-Mocks, Hintergründe oder Platzhalter
• Blockiert, Replace-Later oder Redesign-Required: Echte Personen, offizielle Marke/Logo/Produktfotos, fehlende Screenshots mit Behauptung oder nicht getreu schichtbare Referenzbild-Topologie
• Warum es wichtig ist: Welches Umsetzungstreue-Risiko entsteht, wenn die Asset-Grenze falsch eingeschätzt wird

Asset-Grenzregeln

Bei der Vorbereitung der Asset-Aufteilungsliste im dritten Schritt und der Asset-Generierungsprüfung im vierten Schritt die folgenden Regeln verwenden.

Nachdem Referenzbilder existieren und vor dem Schreiben von Code die drei Beurteilungsachsen getrennt durchführen:

1. Grenze: Nur unabhängige Interaktion, Ersatz/Aktualisierung, unabhängige Semantik oder responsives Umbrechen erzwingen eine feine Aufteilung. Nach dem Entfernen von Code-Knoten und erzwungenen unabhängigen Knoten statische Raster-Objekte mit Stapelüberlappung, objektübergreifenden Schatten/Reflexionen, durchgehender Textur, Perspektive, Licht oder Materialbeziehungen zusammenführen. Ein Fusionsgruppen-Standardwert ist ein Asset, unabhängig davon, wie viele Karten darin gezählt werden können.
2. Medium: Nur Live-Text, DOM-Layout, Volltonfarben, normale Rahmen/abgerundete Ecken/Schatten, einfache CSS-Verläufe, Standard-Icons, grundlegende Grids/Punkte und einfache SVG-Geometrie können code-native sein. Fotos, unregelmäßige Materialien, Handschrift/Pinsel, komplexe Illustrationen, dichte UI-/Produkt-Mocks, natürliche Texturen, 3D, reale Licht-/Schatteneffekte oder gemeinsam genutzte Raster-Effekte müssen Bilder sein. Wenn sowohl Live-Verhalten als auch Raster-Treue benötigt werden, Hybrid verwenden: Bild für die Optik, Code für Hülle, Text und Interaktion.
3. Ebene: integrated-scene ist ein Abschnittsgebundenes, fusioniertes visuelles Element, das full-bleed sein kann oder nur die rechte Seite des Hero einnimmt; independent-media ist ein unabhängig ersetzbares Foto, Screenshot, Cover, Mock, Profilbild oder eigenständige Illustration. Transparenz bestimmt nicht die Kategorie.

Standardmäßig pro Abschnitt maximal eine fusionierte Szene, insgesamt nicht mehr als drei Raster-Einheiten. Jeder Slot für unabhängige Medien ist sein eigenes Asset; die fusionierte, statische Gruppe bleibt ein Asset. Alle endgültigen Texte, Navigation, Buttons, Formulare, Fakten und Interaktionen bleiben im Code. Ein ganzer Bildschirm als künstlerischer Hintergrund ist erlaubt, nicht jedoch, Code-zuständige Inhalte zusammen mit einem ganzen Bildschirm-Screenshot auszubacken.

Wenn Live-Text nicht vom Material getrennt werden kann, interaktive Elemente harte Schatten/Überlappungen mit einer anderen Ebene teilen, echte Identitäts-Assets unwiderruflich in eine generierte Szene eingebettet sind, die mobile Ansicht das eigenständige Bewegen von Pixeln innerhalb eines einzelnen Bildes erfordert oder die Restrukturierung von fragilen Pixel-Nähten abhängt, redesign-required verwenden, nicht gewaltsam aufteilen. Den Style-Fingerabdruck beibehalten und nur diesen Abschnitt zur Neugenerierung in den zweiten Schritt zurückgeben.

Jedes bestätigte Referenzbild muss im sichtbaren Wiederherstellungsartefakt eine Reference-to-Build-Karte haben:

Reference: 01-hero.png
Code-Ebene: Nav, Überschrift, Untertitel, CTA-Gruppe, Porträtrahmen, Nachweis-Labels
Integrierte Szene: hero-finance-desk.png, 16:9, full-bleed, dunkle Überlagerung erlaubt
Unabhängiges Medium: portrait.png, 24% Breite rechts; product-card-mock.png, 22% Breite unten Mitte
Muss erhalten bleiben: Dunkle Desktop/Finance-Foto-Atmosphäre, linke Überschriften-Proportion, rechte Porträtkarte, grüner CTA, oberer Navigationsabstand
Erlaubte Abweichung: Diagramm-Labels im generierten Bild werden durch Code-gerenderten, bestätigten Text ersetzt
Risikoauslöser: Nicht bestätigte echte Firmenmarkierungen oder Benutzer-Profilbild müssen zuerst bestätigt werden

Jeder Abschnitt muss alle sinnvollen Bereiche abdecken: semantische Rolle, Grenzauslöser, Code-Whitelist-Ergebnis, Raster-Signale, Fusionsgruppe, Besitzer (code oder asset), Platzierung (integrated-scene, independent-media oder none), Wiederverwendungsumfang (global oder section), Herkunft, Responsive-Modus, Entscheidung/Status (ready, generate, find/copy, code-native, replace-later, blocked oder redesign-required), Quelle/Aktion und endgültiger Pfad. Wenn ein Abschnitt keine abschnittsspezifischen Bilder hat, den Grund direkt angeben und wiederverwendete gemeinsam genutzte Materialien separat auflisten.

Ein Asset-Manifest erfassen (Asset, Rolle, Grenzauslöser, Raster-Signal, Fusionsgruppe, Platzierung, Wiederverwendungsumfang, Herkunft, Referenzbox, Seitenverhältnis, relative Größe, Responsive-Modus, Status, endgültiger Pfad), damit bei der Umsetzung jedes Asset in einen Behälter mit festem Seitenverhältnis gesetzt werden kann, anstatt dass die ursprüngliche Bildgröße das Layout bestimmt.

Diese Abschlusshinweisform für den dritten Schritt verwenden:

Aktueller Fortschritt: Dritter Schritt / Asset-Aufteilungsliste
Ich habe vorbereitet: Reference-to-Build-Karte, Asset-Entscheidungsliste und erstes Asset-Manifest.
Bitte bestätigen oder ändern:
1. Welche Elemente code-native bleiben
2. Welche fusionierten Szenen und unabhängigen Medien generiert, kopiert oder als Replace-Later markiert werden sollen
3. Welche echten Profilbilder, Logos, Produktscreenshots oder offiziellen Assets nicht generiert werden können
4. In der Liste wirklich mehrdeutige Interaktions- oder Ersetzungsannahmen
Nach Bestätigung werde ich in den vierten Schritt gehen und nur die genehmigten Assets generieren oder sammeln. Ich werde noch keine Seiten-Codes bearbeiten. Ich kann, wenn nützlich, genehmigte Asset-Gruppen parallel verarbeiten; wenn Sie eine sequenzielle Ausführung wünschen, sagen Sie es bitte direkt.

Vierter Schritt: Asset-Generierung & -Prüfung

Nach Bestätigung der Asset-Aufteilungsliste nur die genehmigten Assets generieren, kopieren, suchen oder sammeln. Dann dem Benutzer die Asset-Ergebnisse und ein knappes Umsetzungs-Briefing zeigen. Nicht mit der Seiten-Code-Implementierung beginnen, bevor der Benutzer die Asset-Prüfung akzeptiert hat.

Die Asset-Prüfung sollte enthalten:

• Endgültigen Pfad für jedes bereite Asset
• Welchem Abschnitt und welchem sichtbaren Element jedes Asset entspricht
• Quelle: Generiert, vom Benutzer bereitgestellt, offiziell/kopiert, code-native oder replace-later
• Prüfergebnis: angenommen, erneute Generierung erforderlich, schwach aber mit benannter Abweichung verwendbar, blockiert oder Replace-Later-Platzhalter
• Prompt-/Quellennotizen, die zur Reproduktion des Assets benötigt werden

Jedes Bild-Asset hat nur zwei legitime Quellen:

1. Echte Assets, die bereits im ersten Schritt (Intake) gesammelt wurden, wie Benutzerfotos, Logos, Produktscreenshots oder Mediendateien. Im vierten Schritt nicht vorübergehend neue Assets vom Benutzer verlangen, es sei denn, der Benutzer entscheidet sich selbst, welche bereitzustellen; Inhalte, die bis zu diesem Schritt noch nicht bereitgestellt wurden, als Stand-In generieren, code-native Platzhalter verwenden, als replace-later markieren oder, wenn sie irreführend wären, als blocked markieren.
2. Neue Bildgenerierung: Muss im entsprechenden Referenzbereich verankert sein. Vor dem Schreiben eines Generierungs-Prompts das bestätigte Referenzbild erneut öffnen und den Zielbereich in eine visuelle Liste transkribieren: Szenentyp (Papierkarten-Collage / Fotografie-Szene / flache Illustration / UI-Mock / Texturfeld), jedes Hauptobjekt und seine ungefähre Position, Farbpalette mit Hex-Werten, Licht, Material, Weißraum-Layout. Der Generierungs-Prompt muss aus dieser Transkription geschrieben werden – gleicher Szenentyp, gleiche Objektliste, gleiche Komposition und Farbpalette – niemals aus dem Asset-Namen oder einer einzeiligen Zusammenfassung der Aufteilungsliste. Wenn das Bildtool Eingabebilder unterstützt, gleichzeitig das Referenzareal als visuelle Referenz beifügen. Ein Prompt, der nur Inhaltskategorien schreibt ("Creator sitzt am Schreibtisch mit Notizbuch und Karten"), ohne Transkription, ist fehlerhaft: Er ermächtigt das Modell im Wesentlichen, eine andere Szene zu erfinden. Platzhaltertext innerhalb des Assets sollte als "abstract unreadable placeholder bars and squiggles" angefordert werden – nicht das Wort "greeked" verwenden, da das Ausgabemodell dies wörtlich als griechischen Text interpretieren könnte.

Das bestätigte Referenzbild ist das Bauziel und die QA-Baseline, nicht die Asset-Quelle. Referenzbildbereiche nicht zuschneiden, screenshotten, slicen oder in den Build extrahieren; Zuschnitte erben niedrige Auflösung, eingebackenen Text und ausgefranste Kanten. Im Manifest gibt es keinen Status extract. Wenn ein Referenzbereich ein Asset benötigt, das Asset mit einer visuellen Beschreibung neu generieren.

Asset-Generierungsregel

Während der Asset-Generierung auf das Referenzbild verweisen. Der Prompt muss die Transkription des Referenzzielbereichs enthalten: Szenentyp, jedes Hauptobjekt mit Position, Farbpalette (Hex), Lichtcharakter, Textur, Layout-Dichte. Nicht aus dem Asset-Namen oder einer abstrakten Beschreibung generieren. Wenn das Bildtool Referenzeingaben unterstützt, das entsprechende Referenzbildareal als visuelle Anleitung beifügen.

Asset-Prüfungsform

Überprüfen Sie, ob jedes generierte Asset mit seiner spezifischen Referenzzieltranskription übereinstimmt: Szenentyp, Objektliste, Komposition, Farbpalette, Licht, Material. Ein Asset kann scheitern, selbst wenn es für sich genommen gut aussieht, wenn es eine andere Szene als die referenzierte ist. Jedes Asset muss einen der folgenden Status erhalten:

• angenommen: Entspricht der Transkription innerhalb akzeptabler Toleranz.
• erneute Generierung erforderlich: Weicht erheblich in Komposition, Farbe, Stil oder Inhalt ab.
• schwach, aber mit benannter Abweichung verwendbar: Erfüllt die Hauptaufgabe, hat aber eine dokumentierte Abweichung, die das Endergebnis beeinträchtigen könnte.
• blockiert: Kann nicht verwendet werden (z.B. ungenaue Identitäts-Assets); benötigt eine echte Quelle oder eine Neubewertung des Abschnitts.
• replace-later: Ein Platzhalter, der vor dem Start durch ein echtes Asset ersetzt werden muss.

Für jeden Abschnitt muss die Asset-Prüfung auch eine kurze Notiz darüber enthalten, wie die Assets zusammenwirken (z.B. ob der Text im CTA-Bereich mit der generierten Szene kollidiert).

Umsetzungs-Briefing

Das Umsetzungs-Briefing ist eine kurze Zusammenfassung, die dem Benutzer sagt, was als nächstes passieren wird:

• Welche Referenzbilder und Assets als Bauziel verwendet werden
• Die Reihenfolge, in der Abschnitte implementiert werden (z.B. Hero zuerst, dann About, dann Portfolio)
• Wichtige Designentscheidungen, die während der Implementierung getroffen werden müssen (z.B. wie der Text auf dem Hero-Hintergrund platziert wird)
• Bekannte Risiken oder Bereiche, die während der Codierung besondere Aufmerksamkeit erfordern
• Eine Liste der Dateien, die erstellt oder geändert werden müssen

Diese Abschlusshinweisform für den vierten Schritt verwenden:

Aktueller Fortschritt: Vierter Schritt / Asset-Generierung & -Prüfung
Ich habe vorbereitet: Asset-Manifest mit endgültigen Pfaden und Status, Asset-Prüfung für jeden Abschnitt, Umsetzungs-Briefing.
Bitte bestätigen oder ändern:
1. Die Asset-Ergebnisse und das Umsetzungs-Briefing akzeptieren
2. Erneute Generierung bestimmter Assets anfordern
3. Änderungen am Umsetzungs-Briefing vornehmen
Nach Bestätigung werde ich in den fünften Schritt gehen und mit der High-Fidelity-Umsetzung beginnen. Ich werde jeden Abschnitt einzeln implementieren und validieren.

Fünfter Schritt: High-Fidelity-Umsetzung & QA

Nach der Asset-Prüfungsbestätigung mit der Codierung beginnen. Die Hülle des Projekts einrichten (z.B. Create React App, Next.js, statischer HTML/CSS/JS-Build), falls nicht vorhanden. Dann wie im Umsetzungs-Briefing angegeben vorgehen, einen Abschnitt nach dem anderen implementieren.

Wenn der installierte frontend-app-builder verfügbar ist, verwenden Sie ihn für die Implementierung; andernfalls die integrierte references/frontend-app-builder.md als Implementierungsleitfaden verwenden.

Implementierungsregeln

• Jeden Abschnitt als separate Komponente oder logischen Block implementieren.
• Das Referenzbild als primäre visuelle Referenz verwenden; nicht raten oder vom referenzierten Layout abweichen.
• Code-native Elemente mit tatsächlichem HTML/CSS/JS rendern.
• Generierte Assets in der entsprechenden Größe und Position einfügen.
• Responsives Verhalten implementieren, wie im Render-Vertrag und im Umsetzungs-Briefing angegeben.
• Nur den aktuellen Abschnitt validieren, bevor zum nächsten übergegangen wird.
• Keine nicht bestätigten Elemente hinzufügen.

Qualitätssicherung (QA)

Nach der Implementierung jedes Abschnitts QA durchführen:

• Visuelle Übereinstimmung: Stimmt der implementierte Abschnitt mit dem Referenzbild überein? Gibt es Abweichungen in Layout, Schriftart, Farbe, Abstand, Bildplatzierung? (Für Bilder wird das zugewiesene Asset verwendet, aber die visuelle Übereinstimmung umfasst den Gesamteindruck, nicht die Pixelgenauigkeit des Assets.)
• Inhaltsgenauigkeit: Sind alle Texte korrekt und aus den bestätigten Fakten? Sind alle Links gültig und zeigen auf die richtigen Ziele? Sind alle Produktbilder, Screenshots oder Profilbilder die richtigen?
• Responsive Design: Funktioniert der Abschnitt auf Bildschirmen in Desktop-, Tablet- und Handygröße? Gibt es Überlappungen, Textüberlauf oder Layoutbrüche?
• Barrierefreiheit (grundlegend): Sind Überschriften hierarchisch korrekt? Haben Bilder aussagekräftige Alt-Texte? Ist der Kontrast ausreichend?
• Performance: Sind Bilder optimiert? Werden unnötige Ressourcen geladen?
• Abschnittsspezifische Prüfungen: Jeder Abschnitt kann zusätzliche QA-Punkte basierend auf seinem Inhalt haben (z.B. funktioniert das Formular im Kontaktabschnitt? Sind die Projektkarten verlinkt?).

QA-Ergebnisse für jeden Abschnitt protokollieren: bestanden, bestanden mit Notiz oder erneut erforderlich. Nur bestanden-Abschnitte als abgeschlossen markieren.

Wenn ein Abschnitt die QA nicht besteht, die Probleme beheben, bevor mit dem nächsten Abschnitt fortgefahren wird. Wenn ein Asset ersetzt werden muss, zur Asset-Prüfung im vierten Schritt zurückkehren, den Ersatz generieren und das Umsetzungs-Briefing erneut validieren, bevor mit der Implementierung fortgefahren wird. Wenn eine Designänderung das Referenzbild ungültig macht, zum zweiten Schritt zurückkehren.

Nachdem alle Abschnitte implementiert und die QA bestanden haben, einen endgültigen QA-Bericht erstellen:

• Liste aller Abschnitte und ihres QA-Status
• Gesamteindruck der Website
• Bekannte Probleme oder Einschränkungen (z.B. fehlende Replace-Later-Assets)
• Empfehlungen für zukünftige Verbesserungen (außerhalb des Geltungsbereichs dieses Workflows)

Diese Abschlusshinweisform für den fünften Schritt verwenden:

Aktueller Fortschritt: Fünfter Schritt / High-Fidelity-Umsetzung & QA
Ich habe abgeschlossen: Abschnittsweise Implementierung und QA.
Ergebnisse: [Liste der Abschnitte und Status]
Gesamteindruck: Die Website trifft das beabsichtigte Design und erfüllt die bestätigten Inhalts- und Stilvorgaben.
Bekannte Probleme: [Liste]
Nächste Schritte: Die Website ist bereit für die Bereitstellung oder weitere Überprüfung. Teilen Sie mir mit, ob ich zusätzliche Optimierungen oder Änderungen vornehmen soll.

Allgemeine Regeln

• In jeder Phase (außer Phase 1, die mit einem Assistenten-Chat beginnt) mit einem klaren Phasenübergang starten: "Trete in Phase X ein: [Phasenname]".
• Die Arbeit streng auf die bestätigten Elemente der aktuellen Phase beschränken.
• Keine Annahmen über nicht bestätigte Elemente treffen. Wenn etwas mehrdeutig ist, anhalten und nachfragen.
• Bei Fehlern dem Benutzer klar die Auswirkungen auf den Zeitplan und ob eine vorherige Phase wiederholt werden muss, mitteilen.
• Wenn der Benutzer eine Änderung außerhalb des bestätigten Umfangs wünscht, den Workflow so umleiten, dass die entsprechende Phase wiederholt wird (z.B. eine Designänderung erfordert eine Rückkehr zu Phase 2).
• Transparent sein: Dem Benutzer zeigen, was mit den bereitgestellten Informationen gemacht wird.
• Alle generierten Prompts und Assets als Teil des Projekts zur späteren Bezugnahme protokollieren.

Start des Workflows: Wenn der Benutzer eine Anfrage zur Erstellung einer persönlichen Website stellt, mit Phase 1 beginnen: Content- & Style-Festlegung.