Menyor/menyor-frontend-skill

Menyor Frontend

Alles, was für diesen Nutzer gebaut wird, muss so aussehen und sich so verhalten wie die Menyor Nigeria App (~/Projects/menyor-nigeria), die pixelgenau aus deren Figma entstanden und auf jeden Bildschirm erweitert wurde. Diese Skill ist dieses System. Befolge sie genau, es sei denn, der Nutzer sagt im aktuellen Request etwas anderes.

Rangfolge: die Worte des Nutzers in diesem Request → ein Figma/Design, das er anhängt → diese Skill → dein eigener Geschmack. Wenn ein neues Figma eintrifft, hat dieses Vorrang für diese Arbeit: Vermesse es (siehe references/verification.md) und notiere in deinem Bericht alle Abweichungen von dieser Skill.

Vor dem Start lesen

Benötigt	Datei
Exakte Tokens, Schriftenskala, Abstände, Breakpoints, Copy- und Barrierefreiheitsregeln	references/design-system.md
Markup und Klassen für jede Komponente (Buttons, Pills, Cards, Drawer, Timeline …)	references/components.md
Motion-Presets und wie jeder Effekt aufgebaut ist	references/motion.md
Wie man ein Figma abgleicht, einen Screenshot erstellt, auditiert und berichtet	references/verification.md
Bereits aufgetretene Fallstricke (Next 16, Turbopack, Stacking-Kontexte, Portale)	references/gotchas.md
Das echte Stylesheet, Logo, Motion-Datei und Kernkomponenten zum Kopieren	assets/
Skripte für Screenshots, Side-by-Side-Vergleich, Messung und Audits	scripts/

Starte ein neues Projekt mit assets/globals.css, assets/motion.ts und den Komponenten in assets/components/ statt sie neu abzuleiten.

Das System im Überblick

Schriftarten (nur diese zwei):

• Cormorant Garamond für jede Überschrift, Stärke 700 mit letter-spacing: -0.02em. So verwendet es das Figma, auch wenn das ursprüngliche Briefing 500/600 vorgab.
• DM Sans 400/500/600 für alles andere, einschließlich Eingabefelder, Buttons und Selects, mit font-variation-settings: "opsz" 33, damit es dem engeren Schnitt des Figma entspricht.
• Beide mit next/font/google, display: 'swap', vorgeladen.
• Das Logo ist ein SVG, niemals eine Schriftart.

Farben (nur diese):

Token	Hex	Verwendung
--brand-blue	#006BA6	Buttons, Links, Überschriften, blauer Streifen, Footer
--brand-blue-hover	#005A8C	Hover
--brand-blue-tint	#E6F0F6	Badges, ausgewählte Zeilen
--bg	#EBEAEA	Seite, Zeilen innerhalb von Cards
--surface	#FFFFFF	Cards, Eingabefelder, Drawer
--ink	#111111	Text
--ink-muted	#5F6368	Bildunterschriften, Hilfstexte
--success	#1E8E3E	nur Icons und Punkte „Bestätigt", niemals Fließtext (Kontrastverhältnis 4,2:1 auf Weiß)
--error	#C62828	Fehler
--on-blue	#FFFFFF	Text auf Blau; Trennlinien bei 60%

Hex-Werte existieren nur in :root und in der BRAND.colors-Konfiguration (E-Mails und PDFs lesen daraus). Trennlinien und Overlays werden mit color-mix(in srgb, var(--ink) 12%, transparent) abgeleitet.

Form:

• Jeder Button, Tab, Eingabefeld, Select, Suchfeld und Reise-Steuerelement ist eine Pill.
• Große Cards haben einen Radius von 48px, Cards 24px, Bilder 24px und Zeilen 16px.
• Steuerelemente mit Umriss und Eingabefelder haben einen 1px blauen Rand.
• Cards haben keine Ränder und nichts hat einen Schatten.
• Die Hierarchie entsteht durch graue vs. weiße Oberflächen.

Schriftgrößen (Desktop → Telefon):

Element	Größe
Hero	110px / 112px Zeilenhöhe → 48px
Abschnitts- und Seitenüberschrift (.display)	64px / 1,22 → 40px
Card-Titel	30px
Auflistungszeilen	24px
Fließtext	16px
Hilfstext	14px
Badges	13px
Preise	22px, Stärke 600, Tabellenziffern
Augenbrauen	DM Sans 16px, GROSSBUCHSTABEN, blau

Layout:

• Container max 1480px, Ränder 40px (24px auf Telefonen).
• Header 96px (72px auf Telefonen), fixiert auf der grauen Seite mit einer 1px Trennlinie nach dem Scrollen.
• Abschnitte ca. 160px Abstand auf Desktop und 80px auf Telefonen.
• Breakpoints: 1360 (kompakte Reise-Pill), 1180 (Navigation wird zum Menü), 960 (eine Spalte), 640 (Telefon).

Copy:

• Display-Überschriften in Title Case („Everything For Your Trip, In One Place").
• UI-Texte in Satzform („Add to my trip").
• Sämtlicher Text lebt in src/content/*.ts. Niemals Zeichenketten fest in Komponenten codieren.
• Markenwerte (E-Mail, Telefon, WhatsApp, Firmenname, Social Media) kommen aus BRAND.
• Preise immer über den Währungshelfer (Standard NGN, gemerkt).
• Niemals Bewertungen, Sterne, Statistiken oder Kontaktdaten erfinden.
• Platzhalter bleiben sichtbar [IN ECKIGEN KLAMMERN].

Nicht verhandelbar

1. Nur die zwei Schriftarten und die obigen Farben. Führe auf jedem neuen Bildschirm scripts/audits.mjs (paletteAudit) aus.
2. Keine Schatten, keine Card-Ränder, keine Verläufe. Die einzige Ausnahme ist ein dezenter Fotoverlauf, und nur wenn Text ihn benötigt.
3. Jedes Steuerelement ist eine Pill mit einem 1px blauen Umriss oder einer durchgehenden blauen Füllung. Fokus zeigt einen 2px weißen + 2px blauen Ring.
4. Eine einzige gemeinsame Motion-Presets-Datei. Animiere nur transform und opacity; FAQ- und Buchungskarten-Höhe sind die bewussten Ausnahmen. prefers-reduced-motion deaktiviert alles und zeigt den Inhalt sofort an.
5. Standardmäßig barrierefrei:
   • WCAG-AA-Kontrast.
   • Beschriftete Steuerelemente.
   • Drawer und Modals fangen den Fokus, schließen mit Escape, geben den Fokus an den öffnenden Button zurück und rendern in einem Portal auf document.body.
   • Toggles verwenden aria-pressed, Pill-Auswahlen role="radio" mit aria-checked.
   • Rein visuelle Platzhalter sind aria-hidden.
6. Copy in Content-Dateien und Markenwerte aus BRAND. Bilder benötigen echten Alternativtext, ihre Pfade leben in Content-Dateien.
7. Responsiv bei 390, 768 und 1440px ohne seitliches Scrollen:
   • Telefone erhalten Snap-Karussells mit einem Vorschaubild der nächsten Karte.
   • Filter und Buchungsformulare wandern in Bottom Sheets.
   • Die Hauptaktion wird in einer fixierten unteren Leiste platziert.
   • Drawer werden zu Bottom Sheets.
8. Vor dem Bericht verifizieren:
   • Screenshot bei 1440 und 390.
   • Mit dem Design Side-by-Side vergleichen.
   • Die Paletten- und Kontrast-Audits und axe ausführen.
   • Lighthouse Mobile auf einem Produktions-Build ausführen: Performance mindestens 85, Accessibility mindestens 95, CLS 0.
   • Die Unterschiede ehrlich berichten.

Erstellen eines neuen Bildschirms: die Reihenfolge

1. Zuerst den Text in eine Content-Datei setzen.
2. Den Bildschirm aus bestehenden Komponenten in references/components.md zusammensetzen.
   • Typische Struktur: Ein zentrierter page-head (Augenbraue + .display-Zeilen + Einleitung), dann weiße large-card/step-card/checkout-card-Blöcke auf der grauen Seite.
   • Listen kommen in graue update-row/listing-row-Zeilen innerhalb weißer Cards.
3. Nur wenn nichts passt, eine neue Klasse im richtigen Abschnitt von globals.css hinzufügen, basierend auf Tokens. Kein Tailwind und keine Inline-Farben.
4. Die Motion-Presets verdrahten (Reveal, SectionHeading-Linien-Aufstieg, Hover-Lift).
5. Verifizieren (references/verification.md), dann mit Screenshots berichten.