Swap tab background and text colors in card keyboard navigation pattern

.codex/skills/styleguide-anwendung/SKILL.md

@@ -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.

.codex/skills/styleguide-erstellung/SKILL.md

@@ -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,
-- 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.
+## Kaskade
 
-## Verbindliche Struktur und Kaskade
-
-Der Styleguide wird nach dieser Kaskade entwickelt:
+Immer diese Ebene wählen und einhalten:
 
 ```text
-Foundations / Grundlagen
-→ Semantische Tokens / Design Tokens
-→ Components / Komponenten
-→ Patterns / Muster
-→ Layouts
-→ Templates / Seitentemplates
-→ Usage Guidelines / Anwendungsrichtlinien
+Foundations → semantische Tokens → Components → Patterns → Layouts → Templates/Pages → Usage Guidelines
 ```
 
-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.
-- Semantische Tokens sind Aliase oder Kaskaden auf Foundation Tokens.
-- Neue oder geänderte semantische Tokens an der fachlich passenden Stelle in `styleguide.css` ergänzen.
-- Semantische Tokens für `Patterns` und `Layouts` werden jeweils in eigenen CSS-Moduldateien unter `styles/` gepflegt und über `styleguide.css` importiert.
-- Struktur, Reihenfolge, Gruppierung, Kommentarlogik und Benennungssystematik von `styleguide.css` einhalten.
-- 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.
+- Foundations sind die einzige Quelle konkreter Designwerte: Farben, Typografie, Spacing, Radius, Shadows, Motion, Breakpoints, Z-Index, Containergrößen.
+- Neue Foundation Tokens nur nach expliziter Freigabe; bestehende Foundation Tokens bevorzugt wiederverwenden.
+- Semantische Tokens sind Aliase/Kaskaden auf Foundation Tokens; nie hardcoded Design Values.
+- Components, Patterns, Layouts, Templates, Pages und HTML dürfen keine eigenen Foundation Tokens, lokalen `:root`-Blöcke oder hardcoded Design Values enthalten.
+- Jede neue/geänderte CSS-Datei muss in `styleguide.css` importiert sein; `styleguide.css` ist der einzige CSS-Einstiegspunkt.
 
-Ergänzungen semantischer Tokens dokumentieren mit:
+## Ebenenregeln
 
-- Token-Name
-- Token-Typ: Foundation oder semantischer Token für Component, Pattern, Layout oder Template
-- Wert oder Alias-Ziel
-- kurzer Zweck
+### Core vs. Portal
 
-Wenn Foundation Tokens ergänzt oder geändert werden, `foundations.html` nachführen.
-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.
+- Foundations, globale semantische Tokens, Components und generische Patterns sind portalübergreifend.
+- 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.
-
-Component-Kapitel dokumentieren die semantischen Tokens, die eine Komponente verwendet, jeweils mit zugeordnetem Foundation Token und Verwendungszweck innerhalb der Komponente.
-
-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
+- Components sind kanonische UI-Bausteine.
+- Ohne Freigabe nicht verändern: HTML, Klassen, Nesting, Semantik, Varianten.
+- Component-Internals nie von außen überschreiben.
+- Components nie visuell nachbauen.
 
 ### 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
-- eigene Layout-/Wrapper-Strukturen
-- Pattern-spezifische Responsiveness
-- Pattern-spezifische Komposition
+### Dokumentation
 
-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
-.pattern .component-internal-class { ... }
-.pattern .sg-card-segment { ... }
-.pattern .sg-button__label { ... }
-```
+## CSS-Struktur
 
-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.
-
-### Layouts
-
-Layouts regeln Struktur, Container, Raster und Anordnung.
-
-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.
+- 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.
+- 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.
+- 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.
 
 ## Arbeitsablauf
 
-Vor jeder Umsetzung:
+Vor Umsetzung:
 
 1. Task-Scope bestimmen.
-2. Bestehenden Code und relevante Dokumentation im Scope analysieren.
-3. Styleguide-Ebene der Änderung bestimmen.
-4. Prüfen, ob bestehende Foundation Tokens, semantische Tokens, Components, Patterns, Layouts oder Templates verwendet werden können.
-5. Offene oder nicht belegte Punkte klären.
+2. Relevanten Code und Doku im Scope prüfen.
+3. Ebene bestimmen.
+4. Core oder portal-spezifische Erweiterung bestimmen.
+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.
-Wenn etwas nicht eindeutig im Code, in der Dokumentation oder in der Aufgabe belegt ist, Rückfrage stellen.
+Nicht belegte Punkte nicht umsetzen. Aussagen klassifizieren als: belegt, plausibel, nicht belegt.
 
-## 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
-- 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
+Technische CSS-Werte ohne Designentscheidung sind erlaubt, z. B. `display`, `position`, `overflow`, `width: 100%`, `height: auto`, `flex`, `min-width: 0`.
 
-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.
-
-Verboten:
-
-- 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.
+- 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
+- keine Aufgabe als fertig melden, solange lokale Styles, hardcoded Werte, visuelle Nachbauten, doppelte Token, unimportierte CSS-Dateien oder veraltete Doku vorhanden sind
 
 ## Abschlusscheck
 
-Vor Abschluss prüfen:
+Vor Abschluss bestätigen:
 
-- richtige Styleguide-Ebene gewählt
-- Kaskade Foundations → semantische Tokens → Components → Patterns → Layouts → Templates → Usage Guidelines eingehalten
-- Lokale Overrides sind streng verboten!! Nur sauber kaskadierende Tokens!!
-- keine hardcoded Design Values außerhalb der Foundations
-- neue oder geänderte semantische Tokens in `styleguide.css` gepflegt
-- bestehende Struktur von `styleguide.css` eingehalten
-- bei modularisiertem CSS: alle relevanten Moduldateien sind in `styleguide.css` importiert, keine verwaisten `styles/*.css`
-- betroffene Dokumentation nachgeführt
-- Components unverändert verwendet
-- keine Component-Internals überschrieben
-- Pattern-CSS steuert nur Komposition, Layout und Responsiveness
-- 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
+- `AGENTS.md` und dieser Skill beachtet
+- richtige Ebene und Core/Portal-Zuordnung gewählt
+- Kaskade eingehalten
+- keine lokalen Styles, Overrides, Workarounds, Legacy-Reste oder hardcoded Design Values
+- neue/geänderte Foundation Tokens korrekt gepflegt und freigegeben
+- neue/geänderte semantische Tokens korrekt gepflegt, importiert und dokumentiert
+- alle relevanten CSS-Dateien in `styleguide.css` importiert
+- Components unverändert bzw. nur mit Freigabe geändert
+- Patterns bauen auf Components; Layouts/Templates/Pages bauen auf Patterns/Components
+- betroffene Doku nachgeführt
+- bearbeiteter Scope ist clean und produktionsreif
 
 ## Ergebnisbericht
 
-Nach Umsetzung kurz berichten:
+Kurz berichten:
 
-- geänderte Dateien
-- relevante geprüfte Dateien
-- gewählte Styleguide-Ebene
-- verwendete oder ergänzte Foundation Tokens und semantische Tokens
-- verwendete Components, Patterns, Layouts oder Templates
-- nachgeführte Dokumentation
-- offene Punkte oder benötigte Freigaben
+- geänderte und geprüfte Dateien
+- Ebene und Core/Portal-Einordnung
+- verwendete/ergänzte Tokens und Bausteine
+- nachgeführte Doku
+- entfernte Insellösungen/Workarounds, falls vorhanden
+- Bestätigung von Abschlusscheck und Selbstbereinigung
+- offene Punkte/Freigaben

styles/32-patterns-card-group-keyboard-nav.css

@@ -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,