1LunarVeil/frontend-aesthetics

Frontend-Ästhetik

frontend-design legt die Haltung fest: sich auf eine Richtung festlegen und Standardeinstellungen vermeiden, die niemand gewählt hat. Diese Fertigkeit liefert die Entscheidungsregeln, die Zahlen, die Präzedenzdaten und die Prüfungen, die diese Entscheidungen überprüfbar machen. Öffne die Referenz und die Schrittnamen, wenn du sie brauchst; lies sie nicht alle im Voraus.

1. Lies zuerst die Projektregeln

• Suche vor dem Design nach einem Brief oder Vertrag: DESIGN.md, PRODUCT.md, einer Token-Datei (tokens.css, theme.*, tailwind.config.*) oder einem Vertragsdokument wie FRONTEND_CONTRACT.md. Diese haben Vorrang vor den Standardwerten dieser Fertigkeit.
• Wenn das Projekt visuelle Werte durch Tokens leitet, ist ein neuer Roh-Hex-, px- oder rgba-Wert in einer Komponente ein Befund, keine Stilwahl.
• Behalte, was bereits funktioniert: Theme-Wechsel, i18n-Schlüssel, Barrierefreiheitsverhalten, vorhandene Komponenten. Gestalte nur den angeforderten Bereich um, nicht die gesamte App.

2. Brief

Schreibe den Brief, der in references/principles.md beschrieben wird: Subjekt, Zielgruppe und Kontext, die Aufgabe des Hauptbildschirms, Dichte, Sprachen und die fünf Dimensionen (Typografie, Farbe, Layout, Bewegung, Details). Füge drei Ablehnungen hinzu: Standardeinstellungen, die dieses Design nicht ähneln darf. Wenn der Nutzer keinen Geschmack beschrieben hat, schlage eine Richtung vor und begründe sie. Verhöre den Nutzer nicht.

3. Präzedenzfälle

Führe dies vom Basisverzeichnis der Fertigkeit aus:

python scripts/design_lookup.py "saas dashboard dark" --ux --motion

Verwende englische Schlüsselwörter. Die Ausgabe liefert den passenden Produkttyp, dessen Stile, eine Palette mit kontrastgeprüften Text- und UI-Paaren, Typografie-Kombinationen und Begründungsregeln. Behandle es als Beweis, nicht als Antwort. Der erste Stil ist oft eine Trendauswahl (Glasmorphismus, Neon, Bento), die für dichte Werkzeuge falsch ist. Textpaare fallen nur in einer der 192 Palettenzeilen durch, aber die meisten Paletten haben einen Rand unter 3:1 gegenüber dem Hintergrund, daher muss jedes UI-Paar vor der Verwendung überprüft werden.

4. Richtung

Wähle eine Richtung aus references/directions.md oder definiere eine eigene und begründe, warum sie zu diesem Brief passt und warum die nächstgelegene Alternative es nicht tut. Setze die Kühnheit an einer Stelle ein: ein Signaturelement. Alles andere um ihn herum ist diszipliniert.

5. Tokens vor Komponenten

Definiere zuerst Farbrollen, die Schriftgrößenskala, Abstände, Radien, Höhen und Bewegungsdauern als Variablen (references/color-and-type.md, references/layout-and-motion.md). Überprüfe jedes Textpaar, das du auslieferst:

python scripts/wcag.py "#1f2937" "#ffffff" "#556070" "#f6f7f9"

6. Bauen

Decke jeden Zustand ab, nicht nur den glücklichen Pfad (references/components-and-states.md). Behalte den Text in den Sprachen des Produkts und teste die längste Übersetzung.

7. Vor der Berichterstattung verifizieren

• Rendere es und schau es dir an. python scripts/visual_capture.py <url> --out shots --matrix liefert Standard-, 150%-Skalierungs-, schmale und Telefonansichten, wartet auf einen stabilen Frame und meldet Konsolenfehler. Lies references/visual-review.md; eine Überprüfung ohne Aufnahme ist keine visuelle Überprüfung.
• Führe nach einer Änderung erneut eine Aufnahme durch und führe scripts/image_diff.py before.png after.png aus. Wenn die geänderte Region nicht mit dem übereinstimmt, was du behauptest, geändert zu haben, ist die Behauptung falsch.
• python scripts/slop_scan.py <changed paths>. Exit-Status 1 bedeutet blockierende Befunde.
• Kontrast für jedes tatsächlich ausgelieferte Text- und UI-Paar (wcag.py).
• Ein tastatur-only-Durchlauf, ein reduced-motion-Durchlauf und der Break-Test mit Worst-Case-Daten.
• Konsolenfehler sind Fehler. Ebenso ist eine als blank gemeldete Aufnahme ein Fehler; behandle eine als unsettled gemeldete als verdächtig.

Wenn kein Browser erreicht werden kann, schreibe „nicht visuell verifiziert“, nenne die übersprungenen Zustände und behaupte nichts über das Aussehen der gerenderten UI.

8. Bericht

Nenne die Richtung und den Grund dafür, gib den Token-Block an und liste jede Verifizierung mit ihrem Befehl und Ergebnis auf. Liste auf, was nicht verifiziert wurde.

Grundsätze (niemals für das Aussehen eintauschen)

• Textkontrast von mindestens 4,5:1. Großer Text (24px oder 18,66px fett) sowie UI-Grenzen oder Fokusindikatoren benötigen mindestens 3:1.
• Jedes interaktive Element hat einen sichtbaren Tastaturfokus-Indikator, der sich von seinem Hover-Zustand unterscheidet.
• Farbe trägt niemals allein Bedeutung.
• Bewegung respektiert prefers-reduced-motion. Nichts blinkt mehr als dreimal pro Sekunde.
• Fließtext ist im Web mindestens 16px und in dichten Desktop-UIs mindestens 14px groß. Kein Text unter 12px.
• Jeder Zustand existiert: Laden, leer, Fehler, deaktiviert und partielle Daten.
• Kein Platzhaltertext wird ausgeliefert. Fehler sagen, was passiert ist und was als nächstes zu tun ist.
• Text überlebt den längsten realistischen String: Übersetzungen, CJK, lange Pfade und Modellnamen.

Geschmacksregeln

• Ein dominantes Neutral macht den Großteil der Arbeit. Ein Akzent bedeckt höchstens etwa 10 % des Bildschirms. Erfolgs-, Warn- und Gefahrenfarben bleiben themenübergreifend fest.
• Höchstens zwei Schriftfamilien, plus eine Monospace-Schrift, falls nötig. Ein Größenverhältnis. Hierarchie entsteht durch Größe, Gewicht, Farbe und Abstand vor Boxen.
• Weniger Rahmen und weniger verschachtelte Karten. Radius aus einer kleinen Skala. Schlagschatten an die Palette angepasst, mit höchstens drei Höhenstufen.
• Bewegung: ein bewusster Moment pro Bildschirm, nur Transform und Opazität, und keine Animation bei Aktionen, die in einer Sitzung viele Male wiederholt werden.
• Text: Satzanfang groß, einfache Verben und derselbe Name für eine Aktion im Button, in der Ergebnismeldung und im Menü.

Der Auswahltest

Jede Standardeinstellung (Schriftart, Palette, Radius, Schatten, Layout, Icon-Set) muss für diesen Brief ausgewählt werden. Wenn du den Grund nicht nennen kannst, ändere sie. Eine Standardeinstellung, die du ausgewählt hast, ist kein Anzeichen. references/anti-slop.md listet die häufigen Anzeichen und die Scanner-Regel, die jedes kennzeichnet.

Dateien

• references/principles.md: Entscheidungsreihenfolge, Brief-Vorlage, Ablehnungen.
• references/directions.md: Neun Richtungen mit verifizierten Start-Tokens.
• references/color-and-type.md: Paletten, dunkler Modus, Kontrast, Schriftgrößenskala, Schriftart-Laden, CJK.
• references/layout-and-motion.md: Raster, Dichte, Abstände, Radien, Höhen, Bewegung.
• references/components-and-states.md: Komponenten, Zustandsmatrix, Text, Break-Test.
• references/desktop-app.md: Regeln für WebView- und Desktop-Apps.
• references/anti-slop.md: Anzeichen, warum sie wie Standardeinstellungen wirken, zu stellende Fragen, Scanner-Regel-IDs.
• references/critique.md: Überprüfungsverfahren, neun Säulen, Schweregrad, Ausgabeformat.
• references/visual-review.md: Wie man die UI rendert, aufnimmt, liest und erneut differenziert.
• references/sources.md: Woher jede Regel stammt und was bewusst nicht verwendet wurde.
• scripts/wcag.py, scripts/design_lookup.py, scripts/slop_scan.py, scripts/visual_capture.py, scripts/image_diff.py: schreibgeschützt, keine Drittanbieter-Pakete, kein Netzwerk. Verwende py -3, wenn python nicht im PATH ist.
• data/: MIT-lizenzierte CSV-Daten, eingebunden von ui-ux-pro-max (siehe data/PROVENANCE.md).