Swap tab background and text colors in card keyboard navigation pattern

2026-06-01 12:05:39 +02:00
parent d92817f179
commit e94f00246b
3 changed files with 94 additions and 271 deletions
@@ -1,63 +0,0 @@
 ---
 name: styleguide-anwendung
 description: Verwenden fuer die verbindliche Anwendung des zentralen Styleguides in konsumierenden Portalen. Erzwingt 1:1-Uebernahme von Patterns/Components, verbietet Inselloesungen und regelt strikt die Trennung von Upstream, Output und Portal-spezifischen Styles.
 ---
 # Styleguide-Anwendung
 ## Zweck
 Dieser Skill regelt verbindlich die fachlich korrekte Anwendung des zentralen Styleguides in konsumierenden Portalen.
 ## Scope
 - Gilt nur fuer konsumierende Portal-Repositories.
 - Gilt fuer die Anwendung von Tokens, Components, Patterns, Layouts und Templates aus dem Styleguide.
 ## Verbindliche Regeln
 1. Reuse first: Styleguide-Bausteine MUESSEN 1:1 angewendet werden; visuelle Nachbauten sind verboten.
 2. Components MUESSEN in Struktur, Klassenlogik und Semantik unveraendert bleiben.
 3. Wenn ein passender Baustein existiert, SIND lokale Sondervarianten und Inselloesungen verboten.
 4. Lokale Designentscheidungen ausserhalb des Styleguide-Systems sind verboten (Farben, Spacing, Typography, Radius, Shadow, States).
 5. Ueberschreibungen von Component-Internals aus dem Portal-Kontext sind verboten.
 6. Portal-spezifische Regeln sind nur zulaessig, wenn kein passender Baustein existiert, der Need fachlich belegt ist und keine Duplikation entsteht.
 7. Jede lokale Abweichung MUSS minimal, rueckbaubar, klar begruendet und auf den konkreten Portal-Kontext begrenzt sein.
 8. `public/assets/styles.css` ist read-only; manuelle Portal-Styles darin sind verboten.
 9. `public/assets/styleguide.upstream.css` ist read-only; Upstream wird nie lokal gepatcht.
 10. Eigene Portal-Styles duerfen ausschliesslich in `public/assets/styles.portal.css` gepflegt werden.
 ## 1:1-Uebernahmepflicht (kritisch)
 Wenn ein Pattern oder Component aus dem Styleguide vorgegeben ist, gilt:
 1. HTML-Struktur wird 1:1 uebernommen (kein vereinfachtes oder umgebautes Markup).
 2. Klassenbezeichnungen werden 1:1 uebernommen (keine Umbenennungen, keine Teilmengen).
 3. Alle dokumentierten States werden umgesetzt (z. B. default, hover, focus, active, disabled, selected).
 4. Alle dokumentierten Interaktionen/Funktionalitaeten werden umgesetzt (keine Teilimplementierung).
 5. Accessibility-Merkmale werden 1:1 uebernommen (ARIA, Labels, Keyboard-Fokus, semantische Elemente).
 6. "Sinngemaesse" Nachimplementierung ist unzulaessig; erlaubt ist nur die vollstaendige Uebernahme oder eine explizit freigegebene Abweichung.
 ## Guardrails
 - Keine Umgehung des Styleguides durch Inline-Styles oder seitenlokale Ad-hoc-CSS-Dateien.
 - Keine erneute Einfuehrung von Legacy-CSS-Bloecken oder lokalen Vollkopien von Styleguide-Regeln.
 - Keine Mischung von Upstream-Logik und Portal-Logik in derselben Quelldatei.
 - Konflikte mit Upstream werden nicht durch Hotfixes in Output-Dateien geloest.
 ## Arbeitsmodus bei Aenderungen
 1. Zuerst pruefen: Deckt ein bestehender Styleguide-Baustein den Fall ab.
 2. Wenn ja: unveraendert uebernehmen (Pfad endet hier).
 3. Wenn nein: minimalen Portal-Zusatz in `styles.portal.css` umsetzen, ohne Component-Internals zu beruehren.
 4. Betroffene Views auf visuelle und funktionale Regressionen testen.
 5. Lokale Abweichung im Commit mit kurzer fachlicher Begruendung dokumentieren.
 ## Abnahmekriterien
 - Vorhandene Styleguide-Bausteine wurden priorisiert und nicht lokal dupliziert.
 - Keine Portalregel greift in Component-Internals ein.
 - Alle lokalen Regeln sind auf das notwendige Minimum begrenzt.
 - `styles.css` und `styleguide.upstream.css` sind frei von manuellen Portal-Handedits.
 - Lokale Regeln in `styles.portal.css` sind fachlich begruendet und rueckbaubar dokumentiert.
 - Vorgegebene Patterns/Components sind in HTML, Klassen, States, Interaktionen und A11y vollstaendig 1:1 uebernommen.
@@ -1,261 +1,144 @@
 ---
 name: styleguide erstellung
-description: Verwenden für jede Weiterentwicklung des Styleguides. Erzwingt eine sauber kaskadierende, skalierbare Design-System-Architektur mit klarer Trennung von Foundations, semantischen Tokens, Components, Patterns, Layouts, Templates und Usage Guidelines. Nutze diesen Skill immer, wenn CSS, HTML, Tokens, Components, Patterns, Layouts, Templates, Dokumentation oder Styleguide-Strukturen geändert, erweitert oder geprüft werden.
+description: Verwenden für jede Weiterentwicklung oder Prüfung des zentralen Styleguides: CSS, HTML, Tokens, Components, Patterns, Layouts, Templates, Doku oder Styleguide-Struktur. Erzwingt ein kaskadierendes, portalübergreifendes Design-System ohne lokale Insellösungen, Workarounds, Hardcoded Design Values oder redundante UI-Bausteine.
 ---
 # Styleguide-Erstellung
 ## Ziel
-Pflege und erweitere den Styleguide als skalierbares Design-System für große Webportale.
+Pflege den Styleguide als zentrales Design-System für mehrere modulare Webportale.
-Jede Änderung muss:
+- Core: allgemeine Foundations, semantische Tokens, Components, Patterns und Guidelines für alle Portale.
 - Portal-spezifisch: nur klar benannte Layouts/Templates/Pages, z. B. mit Portalname im Dateinamen.
 - Ergebnis: cleanes, produktionsreifes Template ohne lokale Styles, Overrides, Workarounds, Legacy-Reste oder visuelle Nachbauten.
- sauber kaskadieren,
+## Kaskade
 - der richtigen Styleguide-Ebene zugeordnet sein,
 - bestehende Bausteine respektieren,
 - langfristig wartbar und wiederverwendbar sein,
 - zentral über Foundation Tokens und semantische Tokens in `styleguide.css` steuerbar bleiben,
 - ohne lokale Sonderlösungen, visuelle Nachbauten oder Workarounds auskommen.
-## Verbindliche Struktur und Kaskade
+Immer diese Ebene wählen und einhalten:
 Der Styleguide wird nach dieser Kaskade entwickelt:
 ```text
-Foundations / Grundlagen
+Foundations → semantische Tokens → Components → Patterns → Layouts → Templates/Pages → Usage Guidelines
 → Semantische Tokens / Design Tokens
 → Components / Komponenten
 → Patterns / Muster
 → Layouts
 → Templates / Seitentemplates
 → Usage Guidelines / Anwendungsrichtlinien
 ```
 Jede neue oder geänderte Lösung muss der passenden Ebene zugeordnet werden; Component- und Pattern-Kapitel dokumentieren dabei die semantischen Tokens, die dort verwendet werden.
 ## Modul-CSS-Konvention (verbindlich)
 Wenn der Styleguide modularisiert ist (z. B. `styles/*.css`), gelten zusätzlich:
 - `styleguide.css` ist der einzige CSS-Einstiegspunkt und enthält ausschließlich die verbindliche `@import`-Reihenfolge.
 - Neue CSS-Datei nur anlegen, wenn eine klar abgegrenzte fachliche Verantwortung entsteht (z. B. neues Pattern, neues Layout, neue Page/Template-Sektion). Bestehende Verantwortung wird in bestehender Datei erweitert.
 - Foundations und semantische Tokens werden zentral gepflegt (Foundations + semantische Token-Definitionen in `styleguide.css`/zentralem Token-Bereich), nicht verteilt über Pattern-/Layout-Dateien.
 - Components, Patterns, Layouts und Templates liegen in eigenen Moduldateien der jeweiligen Ebene; keine Vermischung fachfremder Ebenen in einer Datei.
 - Nomenklatur neuer Moduldateien:
  - Dateiname klein, kebab-case, ASCII.
  - Präfix mit Ordnungsgruppe, z. B. `01-`, `10-`, `20-`, `30-`, `40-`.
  - Danach Ebenenbezug + fachlicher Name, z. B. `22-patterns-object-card.css`.
 - Neue oder umbenannte Moduldateien müssen im selben Change-Set in `styleguide.css` per `@import` ergänzt/aktualisiert werden.
 - Import-Reihenfolge bleibt strikt kaskadierend:
  - Foundations/Base/Helpers
  - Components
  - Patterns
  - Layouts
  - Templates/Pages
 - Pro Datei genau ein primärer fachlicher Verantwortungsbereich; Sammel-/Restdateien ohne klare Verantwortung sind zu vermeiden.
 ## Ebenenregeln
 ### Foundations
 Foundations sind die einzige Quelle für konkrete visuelle Werte, z. B. Farben, Typografie, Spacing, Grid, Icons, Shadows, Border-Radius, Motion, Breakpoints, Z-Index und Containergrößen.
 Neue oder geänderte Foundation-Werte nur nach Rückfrage und expliziter Freigabe einführen.
 ### Semantische Tokens / Design Tokens
 Semantische Tokens abstrahieren Foundation Tokens nach Bedeutung, Zweck oder Verwendung im Interface und werden zentral in `styleguide.css` gepflegt.
 Sie benennen nicht den konkreten visuellen Wert, sondern die Rolle im System, z. B. `surface-button-active`, `text-button-process` oder `layout-input-label-width`.
 Regeln:
- Keine hardcoded Design Values außerhalb der Foundations.
+- Foundations sind die einzige Quelle konkreter Designwerte: Farben, Typografie, Spacing, Radius, Shadows, Motion, Breakpoints, Z-Index, Containergrößen.
- Semantische Tokens sind Aliase oder Kaskaden auf Foundation Tokens.
+- Neue Foundation Tokens nur nach expliziter Freigabe; bestehende Foundation Tokens bevorzugt wiederverwenden.
- Neue oder geänderte semantische Tokens an der fachlich passenden Stelle in `styleguide.css` ergänzen.
+- Semantische Tokens sind Aliase/Kaskaden auf Foundation Tokens; nie hardcoded Design Values.
- Semantische Tokens für `Patterns` und `Layouts` werden jeweils in eigenen CSS-Moduldateien unter `styles/` gepflegt und über `styleguide.css` importiert.
+- Components, Patterns, Layouts, Templates, Pages und HTML dürfen keine eigenen Foundation Tokens, lokalen `:root`-Blöcke oder hardcoded Design Values enthalten.
- Struktur, Reihenfolge, Gruppierung, Kommentarlogik und Benennungssystematik von `styleguide.css` einhalten.
+- Jede neue/geänderte CSS-Datei muss in `styleguide.css` importiert sein; `styleguide.css` ist der einzige CSS-Einstiegspunkt.
 - Wenn CSS in Moduldateien (z. B. unter `styles/`) ausgelagert ist, muss jede neue oder umbenannte Moduldatei explizit per `@import` in `styleguide.css` eingehängt werden; unimportierte Moduldateien sind unzulässig.
 - HTML-Dateien dürfen keine lokalen Token-Blöcke, keine eigenen `:root`-Definitionen und keine abweichenden Token-Definitionen enthalten.
 - HTML-Dateien dürfen semantische Tokens nur aus `styleguide.css` referenzieren.
-Ergänzungen semantischer Tokens dokumentieren mit:
+## Ebenenregeln
- Token-Name
+### Core vs. Portal
 - Token-Typ: Foundation oder semantischer Token für Component, Pattern, Layout oder Template
 - Wert oder Alias-Ziel
 - kurzer Zweck
-Wenn Foundation Tokens ergänzt oder geändert werden, `foundations.html` nachführen.
+- Foundations, globale semantische Tokens, Components und generische Patterns sind portalübergreifend.
-Wenn semantische Tokens für Components, Patterns, Layouts oder Templates ergänzt oder geändert werden, die passende Token-Dokumentation nachführen, insbesondere `semantic-tokens-components.html`, sofern dort die bestehende Struktur dafür vorgesehen ist.
+- Portal-spezifische Layouts/Templates/Pages dürfen Core-Bausteine komponieren, aber nicht duplizieren, überschreiben oder visuell nachbauen.
 - Portal-spezifische Dateien müssen eindeutig nach Portal benannt sein.
 - Wird eine portal-spezifische Lösung für mehrere Portale relevant, abstrahiere sie in den Core.
 - Fachliche Bedeutung oder Dateninterpretation gehört ins jeweilige Portal/owning Fachmodul, nicht in den Styleguide.
 ### Components
-Components sind kanonische, wiederverwendbare UI-Bausteine.
+- Components sind kanonische UI-Bausteine.
-
+- Ohne Freigabe nicht verändern: HTML, Klassen, Nesting, Semantik, Varianten.
-Component-Kapitel dokumentieren die semantischen Tokens, die eine Komponente verwendet, jeweils mit zugeordnetem Foundation Token und Verwendungszweck innerhalb der Komponente.
+- Component-Internals nie von außen überschreiben.
-
+- Components nie visuell nachbauen.
 Ohne explizite Freigabe nicht erlaubt:
 - Component-HTML verändern
 - Component-Klassen verändern, ergänzen oder entfernen
 - Component-Nesting verändern
 - Component-Semantik verändern
 - Component-Varianten erfinden
 - Components visuell nachbauen
 - Component-Internals von außen überschreiben
 ### Patterns
-Patterns kombinieren bestehende Components für konkrete Anwendungsfälle.
+- Patterns komponieren bestehende Components für Anwendungsfälle.
 - Erlaubt: Pattern-Klassen, Wrapper, Layout, Responsiveness.
 - Verboten: Component-Optik duplizieren, Component-Internals stylen, Components ersetzen.
 - Falls ein Pattern Component-Internals stylen müsste: stoppen und Component-Token/-Variante oder andere Architekturentscheidung vorschlagen.
-Pattern-Kapitel dokumentieren die semantischen Tokens, die ein Pattern verwendet, jeweils mit zugeordnetem Foundation Token und Verwendungszweck innerhalb des Patterns.
+### Layouts und Templates/Pages
-Erlaubt:
+- Layouts regeln Struktur, Container, Raster, Anordnung und Responsiveness.
 - Templates/Pages sind reine Komposition aus Layouts, Patterns und Components.
 - Sie dürfen keine neuen Foundations, Token-Logiken, Component-Varianten, lokalen Styles oder visuellen Regeln einführen.
- eigene Pattern-Klassen
+### Dokumentation
 - eigene Layout-/Wrapper-Strukturen
 - Pattern-spezifische Responsiveness
 - Pattern-spezifische Komposition
-Nur erlaubt, wenn bestehende Components unverändert eingebettet werden.
+Nachführen, wenn betroffen:
-Verboten ohne Freigabe:
+- `index.html` bei neuen HTML-Seiten
 - `foundations.html` bei Foundation-Änderungen
 - semantische Token-Seiten bei Token-Änderungen
 - betroffene Component-, Pattern-, Layout-, Template- oder Page-Doku
-```css
+## CSS-Struktur
 .pattern .component-internal-class { ... }
 .pattern .sg-card-segment { ... }
 .pattern .sg-button__label { ... }
 ```
-Wenn ein Pattern Component-Internals stylen müsste, nicht umsetzen. Rückfrage stellen und begründen, ob ein Component-Token, eine Component-Variante oder eine andere architektonische Lösung nötig ist.
+- Foundation Tokens: nur in vorgesehenen Foundation-/Base-Dateien, insbesondere `01-foundations.css` und, falls vorhanden/strukturell vorgesehen, `02-base.css`.
-
+- Semantische Tokens: nur in vorgesehenen zentralen Token-Bereichen oder klar zugeordneten Component-/Pattern-/Layout-/Template-Dateien; immer über `styleguide.css` importiert.
-### Layouts
+- Components, Patterns, Layouts und Templates liegen in eigenen Dateien der passenden Ebene; keine Ebenen vermischen.
-
+- Neue CSS-Datei nur bei klar neuer Verantwortung; sonst bestehende Datei erweitern.
-Layouts regeln Struktur, Container, Raster und Anordnung.
+- Portal-spezifische CSS-Dateien nur für klar abgegrenzte Layouts/Templates/Pages und mit Portalname im Dateinamen.
-
+- Import-Reihenfolge: Foundations/Base → globale semantische Tokens → Components → Patterns → allgemeine Layouts → portal-spezifische Layouts → allgemeine Templates/Pages → portal-spezifische Templates/Pages.
 Layouts dürfen Flächen strukturieren, Spalten und Container definieren, Abstände zwischen größeren Bereichen steuern und responsive Seitenanordnung regeln.
 Layouts dürfen keine Component-Optik ersetzen, keine Pattern-Logik nachbauen, keine Component-Internals überschreiben und keine lokalen Designwerte einführen.
 ### Templates
 Templates beschreiben wiederkehrende Seitentypen.
 Templates verwenden bestehende Layouts, Patterns und Components. Sie dürfen keine neuen visuellen Grundlagen, Component-Varianten oder Pattern-Logiken erfinden.
 ### Usage Guidelines
 Usage Guidelines dokumentieren die korrekte Verwendung des Systems.
 Sie klären insbesondere:
 - wann welches Pattern verwendet wird,
 - responsive Verhalten,
 - Accessibility,
 - Dos & Don’ts,
 - Abgrenzung ähnlicher Components, Patterns, Layouts oder Templates.
 Guidelines müssen präzise, praxisnah und konsistent mit der bestehenden Styleguide-Struktur formuliert werden.
 ## Arbeitsablauf
-Vor jeder Umsetzung:
+Vor Umsetzung:
 1. Task-Scope bestimmen.
-2. Bestehenden Code und relevante Dokumentation im Scope analysieren.
+2. Relevanten Code und Doku im Scope prüfen.
-3. Styleguide-Ebene der Änderung bestimmen.
+3. Ebene bestimmen.
-4. Prüfen, ob bestehende Foundation Tokens, semantische Tokens, Components, Patterns, Layouts oder Templates verwendet werden können.
+4. Core oder portal-spezifische Erweiterung bestimmen.
-5. Offene oder nicht belegte Punkte klären.
+5. Bestehende Tokens, Components, Patterns, Layouts und Templates auf Wiederverwendung prüfen.
 6. Nötige Doku-Nachführung bestimmen.
 7. Bei nicht belegten Punkten Rückfrage stellen.
-Nicht umsetzen, solange eine notwendige Grundlage fehlt.
+Nicht belegte Punkte nicht umsetzen. Aussagen klassifizieren als: belegt, plausibel, nicht belegt.
 Wenn etwas nicht eindeutig im Code, in der Dokumentation oder in der Aufgabe belegt ist, Rückfrage stellen.
-## Scope und Grenzen
+## Verbote
-Keine Änderungen außerhalb des expliziten Task-Scopes.
+Nie einführen oder stehen lassen:
-Nicht erlaubt ohne Freigabe:
+- lokale Styles, lokale `:root`-Blöcke, lokale Token-Blöcke
 - hardcoded Design Values außerhalb Foundations
 - überlagernde Korrektur-Styles statt Ursachenbehebung
 - visuelle Nachbauten bestehender Components/Patterns
 - portal-spezifische Duplikate von Core-Bausteinen
 - Workarounds, Quickfixes, Legacy-Fehlmuster
 - unimportierte oder verwaiste CSS-Dateien
 - Refactorings außerhalb Scope ohne Freigabe
- bestehende Components umbauen
+Technische CSS-Werte ohne Designentscheidung sind erlaubt, z. B. `display`, `position`, `overflow`, `width: 100%`, `height: auto`, `flex`, `min-width: 0`.
 - Foundation Tokens oder semantische Tokens umbenennen
 - Kaskade von Foundation Tokens zu semantischen Tokens verändern
 - CSS-Struktur aufräumen
 - HTML-Struktur verbessern, wenn nicht beauftragt
 - neue Foundation-Werte einführen
 - neue Component-Varianten erfinden
 - bestehende Dokumentationsstruktur neu sortieren
-Neue HTML-Seiten nur dann in `index.html` ergänzen, wenn tatsächlich neue Seiten angelegt werden. Bei reinen Änderungen bestehender Seiten ist keine `index.html`-Anpassung erforderlich.
+## Selbstbereinigung vor Abschluss
-## Anti-Insellösung
+Vor jeder Abschlussmeldung aktiv bereinigen:
-Jede Lösung muss systemfähig sein.
+- lokale Insellösungen, Overrides, Workarounds, Legacy-Reste und unsaubere Zwischenlösungen im bearbeiteten Scope entfernen
-
+- lokale Korrekturen auf die richtige Ebene zurückführen: Foundation, semantischer Token, Component, Pattern, Layout oder Template
-Verboten:
+- keine Aufgabe als fertig melden, solange lokale Styles, hardcoded Werte, visuelle Nachbauten, doppelte Token, unimportierte CSS-Dateien oder veraltete Doku vorhanden sind
 - lokale Styles zur Umgehung der Architektur
 - seitenlokale Sonderregeln statt zentraler Foundation Tokens oder semantischer Tokens
 - visuelle Nachbauten bestehender Components
 - Workarounds, die Architekturdefizite verdecken
 - Legacy-Fehlmuster kopieren
 - direkte Designwerte in Components, Patterns, Layouts, Templates oder HTML-Dateien
 Technische CSS-Werte sind erlaubt, wenn sie keine Designentscheidung darstellen, z. B.:
 ```css
 display: flex;
 position: relative;
 overflow: hidden;
 min-width: 0;
 width: 100%;
 height: auto;
 flex: 1 1 auto;
 ```
 Wenn unklar ist, ob ein Wert eine Designentscheidung ist: Rückfrage stellen.
 ## Unsicherheiten
 Bewerte relevante Aussagen als:
 - **belegt**: direkt im Code oder in der Dokumentation nachweisbar
 - **plausibel**: ableitbar, aber nicht eindeutig belegt
 - **nicht belegt**: benötigt Rückfrage oder Freigabe
 Nicht belegte Punkte dürfen nicht umgesetzt werden.
 ## Abschlusscheck
-Vor Abschluss prüfen:
+Vor Abschluss bestätigen:
- richtige Styleguide-Ebene gewählt
+- `AGENTS.md` und dieser Skill beachtet
- Kaskade Foundations → semantische Tokens → Components → Patterns → Layouts → Templates → Usage Guidelines eingehalten
+- richtige Ebene und Core/Portal-Zuordnung gewählt
- Lokale Overrides sind streng verboten!! Nur sauber kaskadierende Tokens!!
+- Kaskade eingehalten
- keine hardcoded Design Values außerhalb der Foundations
+- keine lokalen Styles, Overrides, Workarounds, Legacy-Reste oder hardcoded Design Values
- neue oder geänderte semantische Tokens in `styleguide.css` gepflegt
+- neue/geänderte Foundation Tokens korrekt gepflegt und freigegeben
- bestehende Struktur von `styleguide.css` eingehalten
+- neue/geänderte semantische Tokens korrekt gepflegt, importiert und dokumentiert
- bei modularisiertem CSS: alle relevanten Moduldateien sind in `styleguide.css` importiert, keine verwaisten `styles/*.css`
+- alle relevanten CSS-Dateien in `styleguide.css` importiert
- betroffene Dokumentation nachgeführt
+- Components unverändert bzw. nur mit Freigabe geändert
- Components unverändert verwendet
+- Patterns bauen auf Components; Layouts/Templates/Pages bauen auf Patterns/Components
- keine Component-Internals überschrieben
+- betroffene Doku nachgeführt
- Pattern-CSS steuert nur Komposition, Layout und Responsiveness
+- bearbeiteter Scope ist clean und produktionsreif
 - Layout-CSS steuert nur Struktur und Anordnung
 - Templates verwenden bestehende Layouts, Patterns und Components
 - keine lokalen Token-Blöcke oder `:root`-Definitionen in HTML-Dateien
 - keine Refactorings außerhalb Scope
 - keine Insellösungen oder Workarounds eingeführt
 - Nach der Bearbeitung konsequent alle Legacy entfernen und nur ein cleanes production-reifes Styleguide als Resultat zulassen
 ## Ergebnisbericht
-Nach Umsetzung kurz berichten:
+Kurz berichten:
- geänderte Dateien
+- geänderte und geprüfte Dateien
- relevante geprüfte Dateien
+- Ebene und Core/Portal-Einordnung
- gewählte Styleguide-Ebene
+- verwendete/ergänzte Tokens und Bausteine
- verwendete oder ergänzte Foundation Tokens und semantische Tokens
+- nachgeführte Doku
- verwendete Components, Patterns, Layouts oder Templates
+- entfernte Insellösungen/Workarounds, falls vorhanden
- nachgeführte Dokumentation
+- Bestätigung von Abschlusscheck und Selbstbereinigung
- offene Punkte oder benötigte Freigaben
+- offene Punkte/Freigaben
@@ -7,7 +7,10 @@
  flex-direction: column;
  gap: var(--spacing-small);
  width: 100%;
-  --surface-tab-unselected: var(--color-white);
+  --surface-tab-selected: var(--color-white);
  --surface-tab-unselected: var(--color-dark-grey);
  --text-tab-selected: var(--color-dark-grey);
  --text-tab-unselected: var(--color-font-light);
 }
 .sg-content-block-card-group__tabs,