Architecture Decision Record · 0007

Hero billboard erweitern statt eigenständige hero-keyvisual SDC: Slot-Komposition für die Brand-Keyvisual-Auslage

TL;DR — hero-billboard wird um overlay: gradient-left-blue und bottom_fade erweitert; das Figma-Keyvisual entsteht durch Slot-Komposition, nicht durch eine neue SDC.

Kontext

Das Figma-Design-System der SOLCOM-Site (figma.com/design/CHHDfbpX8Ys2LBiGs5HVK0, Node 670:13546 „Keyvisual") definiert den Brand-Hero: Vollbild-Background-Image, linearer Gradient-Overlay (--brand-bg-blue von links solid bis 25 %, danach Verlauf zu transparent), optionaler Bottom-Fade (transparent → --brand-bg-blue, ca. 94 px hoch), strukturierter Content-Block (Subheadline in Caps mit Montserrat ExtraBold 39 px, H1 mit ScalaSansLF Regular 59 px, optionaler Body, Primary-CTA als Lime-Pille mit Pfeil, optionale Secondary-CTA als Lime-Text-Link mit Pfeil).

Bestehend: drei Hero-SDCs in components/:

Buttons sind in ADR-0004 etabliert. Page-BG ist nach ADR-0003 --brand-bg-blue. Auslöser: Die Startseite canvas_page Entity 7 sollte das Figma-Keyvisual rendern — Bild war bereits hinterlegt, Content-Komposition vorhanden, nur die Brand-Mechanik fehlte.

Entscheidung

hero-billboard wird erweitert; kein eigenständiges hero-keyvisual. Konkret:

Rejected alternatives

Expand each rejected option to see the rationale.

Eigenständige hero-keyvisual SDC mit strukturierten Props rejected

Wäre 1:1-Mapping zur Figma-Library. Verworfen, weil: (a) group: Hero hat schon drei Komponenten — ein viertes mit überlappender Mechanik macht den SDC-Picker unklarer; (b) Hero-Mechanik (Background-Image-Layer, Overlay, Container/Position, overlap_navbar-Math) ist nicht-trivial — Code-Duplizierung ohne Mehrwert; (c) Strukturierte Props sperren Variations. Brand-Konsistenz hängt damit redaktionell am Site-Builder, nicht am Schema.

hero-billboard zur God-Komponente machen (strukturierte Props rein, Slot bleibt als Fallback) rejected

Bläht das Schema von 6 Achsen auf 11+, mischt zwei Komponenten-Typen (Layout-Shell + Content-Container) in einer YML, und macht jede zukünftige Hero-Variante zur Schema-Erweiterung an einer einzigen Datei.

uppercase-Bool am byte_theme:heading für Subheadline-Caps rejected

Kontaminiert das zentral genutzte Heading-Schema mit einem Use-Case, der für >95 % der Heading-Aufrufer irrelevant ist. Wenn die Brand-Identität später eine echte „Subheadline"-Style-Klasse erfordert, gehört das in eine eigene Subheadline-SDC.

overlay-Enum mit drei oder mehr Werten rejected

Sinnvoll, falls die Site mehrere Brand-Heros mit unterschiedlichem Overlay-Bedarf hätte. Hat sie aktuell nicht — Figma-Truth ist genau zwei Zustände. Wir folgen der Figma-Truth statt eines hypothetisch-zukünftigen Bedarfs.

bottom_fade an overlay koppeln rejected

Konzeptionell zwei verschiedene Aufgaben — Overlay regelt Text-Lesbarkeit, Bottom-Fade regelt visuellen Übergang zur nächsten Section. Letzteres kann auch ohne Gradient-Overlay sinnvoll sein. Orthogonal halten kostet ein Bool, gewinnt einen Use-Case.

Bottom-Fade als PNG/SVG-Asset rejected

Zusätzlicher HTTP-Roundtrip, schlechtere Skalierung auf variable Hero-Breite, und Token-Drift, falls die Brand-Farbe später wechselt. CSS-Gradient mit Token-Variable ist die token-konsistente Lösung.

Pixel-exaktes Pinning auf Figma-Hex #011C53 ohne Token-Indirektion rejected

Anti-Pattern, weil jede Brand-Color-Anpassung dann den Twig-Code anfassen muss. Token-Variable --brand-bg-blue ist die etablierte Source-of-Truth aus ADR-0003.

Drupal-Daten-Migration in separatem PR rejected

Hätte den Hero in der Live-Site nach Schema-Replace temporär ungültig hinterlassen (overlay_opacity aus dem Schema entfernt, in den Daten noch referenziert → Fehler beim Save). Replace-Schema-Bruch und Daten-Migration sind nicht trennbar.

Consequences