Landingpage-Feinschliff, Schritt 1: Form und Identität wählen

Signature — Form- und Identitätspipeline für OpenCode

Abgeleitet von Top 50 Websites für Design Inspiration (50 Seiten live im Browser geöffnet, verifiziert am 22. Oktober 2026) plus dem Prozesskern von Nutlopes Hallmark. Jede Form und Identität benennt echte Korpusbelege – die Bibliothek besteht aus Beobachtungen, nicht aus Geschmacksfolklore.

Arbeitsteilung (nicht vermischen)

• frontend-design besitzt das Handwerk: Art Direction, Typografie-Urteil, Farburteil, Bewegungsphilosophie, Textgestaltung, die Selbstkritik-Schleife. Wenn es geladen ist, folge ihm – wiederhole seine Regeln nicht hier.
• Signature besitzt Prozess und Bibliothek: welche Seiten-Form dieser Build hat, welche Identität er trägt, das Wiederholungsregister und eine mechanische (grep-und-berechnen) Gate-Liste.

Verben

Build (Standard)

1. Teile das Briefing auf in: Domain, Zielgruppe und Energiewörter („cinematic“, „dense“, „personal“, „grand“).
2. Wähle eine Form aus references/structures.md. Nenne sie in einem Satz: Form: <Name> (Zweitplatzierter: <Name>). Ist das Briefing vage, biete das Domain-Trio an – niemals stillschweigend standardmäßig wählen.
3. Verifiziere gegen den Korpus: Öffne 1–2 Beleg-URLs aus den Form-/Identitätszeilen mit dem Playwright MCP (navigate + screenshot Tools) oder webfetch. Ein toter Link befördert die nächste Zeile. Palettenanker dienen als Startwerte, bis du die Live-Seite angesehen hast.
4. Wähle eine Identität aus references/identities.md, die die Stimmung der Form teilt, und korrigiere dann ihre Token-Startwerte basierend auf dem, was du tatsächlich gesehen hast.
5. Schreibe zuerst Tokens: einen semantischen :root-Block + den Stempel (unten), vor jeglichem Komponenten-CSS.
6. Baue. Ein einprägsames Element trägt die Seite; alles andere bleibt ruhig (die Zurückhaltungsregel von frontend-design – anwenden, nicht neu ableiten).
7. Führe alle Gates aus und behebe jeden Fehlschlag. Dann der Geschmacksdurchlauf – über frontend-design, falls geladen, andernfalls anhand seiner Kalibrierungsliste von KI-Verrat-Merkmalen.

audit <Ziel>

Lese den Code/die Seite und führe nur die Gates aus. Jeder Fehlschlag ist ein Aufzählungspunkt: Datei:Zeile — Gate-Nr. — einzeilige Korrektur. Nur mechanische Befunde; handelt es sich um ein Geschmacksproblem, nenne das relevante frontend-design-Prinzip in einem Satz, anstatt eine neue Regel zu erfinden. Falls Stempel vorhanden sind, gib an, ob die Form einen früheren Build wiederholt.

redesign <Ziel>

Behalte Informationsarchitektur, Textinhalte und Marken-Assets bei. Durchsuche die Stempel: Die neue Form muss sich von der zuletzt gestempelten Form unterscheiden. Identität darf wechseln; das Ändern von Markenstimme oder Palette erfordert vorheriges Nachfragen.

study <URL | Screenshot>

Öffne die Quelle. Extrahiere: Abschnittsreihenfolge → nächstgelegene Form; Palettenanker (beispielhafte tatsächliche Farben); Typografie-Rollen und alle beobachteten Schriften → nächstgelegene Identität. Gib eine Zeile aus: study: source=<URL> form≈<Form> identität≈<Identität> anker=<Hexwerte>. Falls nichts in der Bibliothek passt, füge eine neue Identitätszeile hinzu (Format am Ende von identities.md) – aber ersetze niemals stillschweigend das Study-Ergebnis durch eine Bibliotheksauswahl: Wenn der Nutzer die untersuchte DNA wörtlich wünscht, wird der Stempel zu identität=studied:<Quelle> und die Study-Werte werden zu den Tokens.

Das Register ist Code

• Stempel am Anfang des Haupt-Stylesheets (und als Spiegelung im index.html-Head für reine HTML-Builds): /* signature: form=<Form> identität=<Identität> refs=<tatsächlich geöffnete URLs> */
• Vor der Auswahl das Projekt nach vorhandenen Stempeln durchsuchen. Keine zwei aufeinanderfolgenden Builds teilen eine Form; vorzugsweise auch die Identität nicht wiederholen.
• Keine separate Registerdatei. Das CSS ist das Register.

Vertrag

• Design-Tokens leben an einem Ort (:root-Custom-Eigenschaften oder tokens.css/Tailwind @theme des Projekts). Namen sind semantische Rollen (--color-ink), keine Werte.
• Verwende die eigenen Token-Namen des Projekts wieder, anstatt sie zu überdecken; erweitere das Tailwind-Theme, verwende niemals willkürliche Werte inline.
• Ein vorhandenes globales Stylesheet ist nur erweiterbar: behalte alle @tailwind/@import "tailwindcss"-Direktiven exakt an Ort und Stelle, füge Tokens unterhalb der vorhandenen Regeln hinzu und platziere neue @import ganz oben. Entferne niemals stillschweigend Framework-Direktiven – das ent-stylt die gesamte App. Vollständige Neuschreibungen nur auf ausdrückliche Anfrage.
• Befolge die Dateikonventionen des Frameworks. Erfinde keine Routing-/Layout-Muster, die das Projekt bereits hat, neu.
• Umfang: Dies ist ein Geschmacksprozess. Keine erfundenen Texte (wenn der Nutzer keine Worte gegeben hat, frage nach); keine Geschäftslogik; keine Auswahl einer Markenidentität aus dem Nichts – folge einer vorgegebenen.

Gates (mechanisch – jede Antwort muss „nein“ sein; jeder Fehlschlag = eine Korrektur vor der Übergabe)

Token-Disziplin

1. Fehlschlag, wenn ein #hex, oklch(), rgb() oder font-family in einer Komponente auftaucht, das nicht zu einem benannten Token aufgelöst wird. Hebe es an oder ersetze es.
2. Fehlschlag, wenn ein Padding/Gap/Margin außerhalb der Abstandsskala des Projekts liegt (Vielfache von 4px ohne benannten Token). Willkürliche 17px sind ein Verrat.
3. Fehlschlag, wenn der Stempelkommentar fehlt oder URLs nennt, die nie tatsächlich geöffnet wurden.

Layout-Überleben

4. Fehlschlag, wenn die Seite bei einer Viewport-Breite von 320–1920px horizontal scrollt. overflow-x: clip auf beiden html und body (nicht hidden – clip erhält sticky/fixed).
5. Fehlschlag, wenn eine 1fr-Grid/Row-Spur, die ein Bild enthält, nicht minmax(0, 1fr) ist.
6. Fehlschlag, wenn Text in Anzeigegröße overflow-wrap: anywhere vermissen lässt (und min-width: 0 auf seinem Container) – lange zusammengesetzte Wörter quellen über auf Handys.
7. Fehlschlag, wenn klickbarer Text (Button, Nav, Tab, CTA-Labels) bei 320/375/768/1280px auf zwei Zeilen umbrechen kann.

Code-Fakten

8. Fehlschlag bei transition: all – nenne die Eigenschaften.
9. Fehlschlag, wenn ein Element mehr als einen Hover-Effekt trägt (translate + scale + shadow + color-Kombinationen).
10. Fehlschlag, wenn Inputs die border-width zwischen Zuständen ändern; Zustandsänderungen gehen zu Farbe/Outline/Schatten. Fokus-Ringe sind outline, nicht border. Deaktiviert benötigt ≥2 von: opacity, cursor: not-allowed, disabled/aria-disabled.
11. Fehlschlag, wenn ein <svg>/<canvas>/dekoratives Element weder aria-hidden="true" noch einen zugänglichen Namen hat.

Bewegung & Performance

12. Fehlschlag, wenn eine Animation/ein Keyframe keinen prefers-reduced-motion: reduce-Fallback hat.
13. Fehlschlag bei automatisch rotierenden Inhalten ohne Pause-on-Hover-and-Focus (WCAG 2.2.2).
14. Fehlschlag, wenn das LCP-Hero-Asset loading="lazy" ist oder ein Hero-Video kein poster/fetchpriority="high" hat.

Kontrast & Ehrlichkeit

15. Fehlschlag, wenn ein Farb-/Hintergrundpaar WCAG 4,5:1 (Fließtext) oder 3:1 (großer Text, Icons, Fokusringe) verfehlt. Zwei heiße Punkte: Text, der eine Farbe erbt, während ein Elternteil die Hintergründe gewechselt hat; Button-Füllung innerhalb von 5% Helligkeit seines Texts.
16. Fehlschlag bei erfundenen Fakten – Metriken, Prozentsätzen, Zitaten, Namen, Preisen, die der Nutzer nie geliefert hat; Auffüllen von Statistik-Plätzen. Platzhalter sagen „bestätigen“, nie erfinden.
17. Fehlschlag bei Emojis, die als Feature-/Schritt-/Preis-Icons verwendet werden; maximal eine Icon-Bibliothek pro Seite.
18. Fehlschlag bei nachgebauter Browser-Oberfläche: gefälschte Browser-Leisten, gefälschte Handy-Notches, gefälschte Terminal-/IDE-Fensterrahmen. Verwende einen echten Screenshot oder nichts.

Bibliotheksdisziplin

19. Fehlschlag, wenn eine geladene Schriftart keine bekannte freie/lizenzierte Webschriftart ist. Foundry-Schriften im Korpus (Commercial Type, Klim, Grilli Type, type.today, Pangram Pangram-Testversionen) sind Anzeigereferenzen – überprüfe die Lizenz, frage vor dem Bezahlen. Google Fonts und offene variable Schriften bestehen.
20. Fehlschlag, wenn die Form dieses Builds mit dem aktuellsten Stempel des Projekts übereinstimmt (zuerst grep, gemäß der Registerregel).

Referenzen – bei Bedarf lesen, niemals alle auf einmal

• references/structures.md – zehn Seitenformen mit Gerüsten, Belegen und der Domain-Trio-Tabelle. Lesen bei der Formauswahl (build/redesign/audit).
• references/identities.md – zwanzig Identitäten: Paletten-Startwerte, Schriftpaare, Korpusbelege. Lesen bei der Identitätsauswahl (build/redesign/study).

Beispiel aus der Anleitung des Korpus

Briefing: „Meet India Journeys – Reiseveranstalter-Website für eine Fluss-und-Kulturerbe-Reise in Kerala.“ Domänenwort „Reise“ → Trio ist Scroll Story · Case Catalog · Luxury Ledger. Wähle Scroll Story (Zweitplatzierter: Case Catalog), weil das Thema nacheinander gezeigte Orte ist. Öffne apple.com und simplychocolate.dk live, um Kapiteltaktung, Hero-Medien und randlose Behandlung zu studieren. Identität: Forest Confection (Tiefgrün + Kakao, kondensierte Anzeigeschrift) passend zu Fluss und Kulturerbe; mustere die Live-Referenz, bevor du Tokens festlegst. Stempel: /* signature: form=Scroll Story identität=Forest Confection refs=apple.com,simplychocolate.dk */