Ein Designsystem bauen, das KI richtig nutzt, und die erzeugten Komponenten prüfen

## Vor jeder Änderung klären, welche Pakete Komponenten und Dokumentation verwalten Behandle das Designsystem als gemeinsamen Produktvertrag und nicht als Sammlung visueller Fragmente. Bestimme vor jeder Änderung, welche Pakete für Komponenten, Dokumentation, Beispiele, Vorschauoberflächen, Testumgebungen und Migrationswerkzeuge zuständig sind. Verwende den aktuellen Zweig des Projektarchivs als maßgebliche Quelle für verfügbare APIs und Konventionen. Leite die Unterstützung nicht aus allgemeinem Wissen über Webplattformen, einem anderen Zweig oder einer neueren Bibliotheksversion ab. Behalte die eingerichtete Paketverwaltung, Laufzeitumgebung, das Modulformat und das Testausführungssystem bei, sofern die Aufgabe die Werkzeugkette nicht ausdrücklich ändert. ## Vor dem Start Dokumentation und Komponentenliste des aktuellen Zweigs lesen Vor der Arbeit an Komponenten: 1. Lies die Anweisungen des Projektarchivs und des Pakets, die für das Ziel gelten. 2. Prüfe die lokale Befehlszeilenhilfe und liste die verfügbaren Dokumentationsthemen auf. 3. Lade die Designprinzipien, Design-Tokens, Theme-Regeln und das Komponentenverzeichnis. 4. Prüfe Seitenvorlagen, wenn die Aufgabe die Anordnung statt eines einzelnen Grundelements betrifft. 5. Lies die aktuelle API, Varianten, den Aufbau, Beispiele und Einschränkungen der Zielkomponente. Wiederhole diese Vorbereitung in jedem Zweig, da sich erzeugte Dokumentation und unterstützte APIs unterscheiden können. Führe nach einer Aktualisierung der Designsystem-Abhängigkeiten das Migrationswerkzeug des Projektarchivs aus, bevor du sachfremde manuelle Änderungen vornimmst. ## Dateikopf und Komponentendokumentation gemeinsam aktualisieren Pflege zwei einander ergänzende Dokumentationsebenen. Lege knappe Metadaten zu Eingabe, Ausgabe und architektonischer Position in jedem Quelldateikopf ab. Bewahre ausführliche Eigenschaften, Funktionen, Beispiele, Hinweise zur Barrierefreiheit und Anleitungen zur Zusammensetzung in einer von der Komponente verwalteten Dokumentationsdatei auf. Aktualisiere bei Änderungen an der Umsetzung beide Ebenen und beachte Synchronisierungsmarkierungen, die zusammengehörige Dateien kennzeichnen. Verwende das Dokumentationsformat, das das Darstellungsprogramm tatsächlich unterstützt. Nutze beispielsweise Codeblockbegrenzungen in Beispielen ohne Sprachkennzeichnung, wenn Begrenzungen mit Sprachkennzeichnung den aktiven Parser für automatische Dokumentation stören. Prüfe das dargestellte Ergebnis, statt anzunehmen, gültige Quellsyntax erzeuge gültige Dokumentation. ## Festhalten, welche CSS-Funktionen das Styling-Werkzeug wirklich unterstützt Erfasse die Version des Stilsystems und seine geprüfte Unterstützung für At-Regeln, Pseudoklassen, Pseudoelemente, zusammengesetzte Selektoren, Werte, Animationen, Variablen, Erscheinungsbilder, dynamische Werte und bedingte Selektoren. Unterscheide unterstützte Syntax von Syntax, die zwar kompiliert, aber ungültiges oder unbrauchbares CSS erzeugt. Bevorzuge native CSS-Lösungen, wenn die Matrix deren Unterstützung bestätigt. Häufige Möglichkeiten sind Media-, Feature- und Container-Queries, Anfangsstile, Geltungsbereichsbegrenzung, Interaktions- und Strukturpseudoklassen, Pseudoelemente für erzeugte Inhalte, moderne Farb- und Größenfunktionen, Übergänge und Keyframes. Erstelle nicht nur deshalb eine JavaScript-Ausweichlösung, weil eine ältere Fähigkeitstabelle die Funktion nicht enthielt. ## Hover- und Fokus-Effekte auf die eigene Komponente beschränken Stelle Vorfahren-, Nachfahren- und Geschwisterzustände mit dem vom Stilsystem unterstützten Mechanismus für bedingte Selektoren dar. Wenn dieser Mechanismus eine Markierung erfordert, bringe sie am tatsächlichen Vorfahren an und halte ihre Definition nahe bei der zuständigen Komponente. Verwende für Formularelemente und andere verschachtelte interaktive Elemente komponentenspezifische Markierungen. Nutze niemals eine globale Standardmarkierung, wenn äußere Einblendfenster, Bereiche oder Container Mauszeiger- oder Fokuszustände auf das Steuerelement übertragen könnten. Halte Selektorverträge ein, etwa Vorfahrenbedingungen, die ausschließlich Pseudoselektoren erlauben, und bilde nicht unterstützte CSS-Verschachtelung nicht nach. Schütze reine Mauszeigereffekte mit einer Medienabfrage zur Mauszeigerunterstützung, damit Berührungsgeräte keine dauerhaft haftenden Interaktionszustände übernehmen. Bewahre Tastaturfokus und das Verhalten deaktivierter Zustände unabhängig vom Mauszeigerzustand. ## Anordnung und Animation mit CSS statt mit JavaScript umsetzen Verwende Raster, Flexbox mit Abständen, Seitenverhältnisse, Überlaufsteuerung und Bildlaufleisteneigenschaften direkt, wenn sie unterstützt werden. Bevorzuge Containerabfragen für ein auf den Komponentencontainer reagierendes Verhalten, statt Elemente mit Beobachtern zu vermessen. Nutze für abwechselnde Zeilen Strukturpseudoklassen statt indexbasiertem JavaScript. Setze Eingangsübergänge mit Anfangsstilen um, statt Zustandsverwaltung mit einer Steuerung über Animationsrahmen zu verbinden. Drücke geordnete CSS-Ausweichwerte mit der Ausweichabstraktion des Stilsystems aus, statt die Laufzeitumgebung manuell zu erkennen. Verwende besondere Positionierungsfunktionen nur, wenn das erzeugte CSS mit den unterstützten Browsern geprüft wurde. ## Links und Themes austauschbar machen, damit niemand Komponenten kopieren muss Führe laufzeitabhängige Werte durch typisierte Stilfunktionen, statt eingebettete Stile zu verwenden. Setze bedingte Stile mit dem Mechanismus des Systems für Stileigenschaften zusammen, statt behelfsmäßig Klassennamen umzuschalten. Bewahre Variablen und die Erstellung von Erscheinungsbildern in den vom Compiler verlangten Dateitypen auf und verwende typisierte Variablen oder Konstanten zur Kompilierzeit, wenn sie die Prüfung verbessern. Stelle Navigation über eine austauschbare Verweisabstraktion dar, statt Ankerelemente fest einzubauen. Dadurch können Nutzende ihren Router bereitstellen, ohne Komponenten abzuspalten. Beachte die Asset-, Font-, Public-Path- und Theme-Provider-Verträge des Repositorys, damit paketierte Komponenten übertragbar bleiben. ## Testen, ob die KI Komponenten richtig baut, auch spät in einem langen Gespräch Miss, ob die Agentenanweisungen Modelle beim Erzeugen gültigen Komponentencodes unterstützen. Führe entweder die vollständige Eingabensammlung oder für schnelle Rückmeldungen eine geschichtete Stichprobe aus. Verwende für jede Eingabe eine getrennte Arbeitsinstanz, die die Aufgabe liest, mit dem dokumentierten System eine Komponente erzeugt, Ausweichwege selbst erkennt und sowohl Code als auch Bewertungsmetadaten speichert. Ergänze einen Degradationsmodus, der die Kontexterhaltung über ein Gespräch mit 10 Runden prüft, das Füll-, Ablenkungs- und Erholungsrunden enthält. Untersuche repräsentative Punkte wie die Runden 0, 6, 8 und 10 und vergleiche anschließend den Verlauf jeder Eingabe, statt nur über die letzte Runde zu berichten. Verbinde Prüfeingaben, erzeugte Ergebnisse und Bildschirmaufnahmen mit einer stabilen Iterationskennung. Verarbeite unabhängige Eingaben parallel, lasse Arbeitsinstanzen aber keine veränderbaren Ergebnisdateien gemeinsam nutzen. ## Jedes Testergebnis speichern und finden, wo die KI das Designsystem umgangen hat Speichere genügend strukturierte Metadaten, um jeden Fall nachzustellen und zu vergleichen: Iterations- und Eingabekennung, Zeitstempel, Modell, Nutzerprofil, Eingabekategorie, Verlaufstiefe, Eingabe, erzeugte Antwort, Erfolgsbeurteilung, verwendete Komponenten und erkannte Ausweichwege. Erzeuge vor der Zusammenführung Vorschauseiten und fertige Bildschirmaufnahmen an. Bewerte sowohl den funktionalen Erfolg als auch, ob das Ergebnis das Designsystem durch unabstrahierte Elemente, eingebettete Stile, fest eingebaute Navigation, nicht unterstützte Selektoren, doppelte Grundelemente oder JavaScript-Ausweichlösungen für unterstütztes CSS umgeht. Behandle die Selbsteinschätzung des Modells als einen Hinweis und nicht als Beleg. Verbinde maschinelle Prüfungen, Vorschaunachweise und stichprobenartige menschliche Prüfung. Nutze zusammengeführte Ergebnisse erst zur Verbesserung der Dokumentation oder APIs, nachdem du das wiederkehrende Fehlermuster gefunden hast. ## Nach jeder Änderung kleine Prüfungen laufen lassen und das Bestandene melden Prüfe vor der Änderung einer Komponente ihre aktuelle Dokumentation und entscheide, ob Konfiguration, Zusammensetzung, eine neue Variante oder das ausdrückliche Herauslösen des Quellcodes für eine tiefgreifende Anpassung den Bedarf am besten erfüllt. Bewahre öffentliche Verträge und vermeide ein paralleles Grundelement, wenn ein bestehender Erweiterungspunkt vorhanden ist. Aktualisiere nach der Änderung die synchronisierte Dokumentation und führe die kleinsten maßgeblichen Unit-Tests, Typ- und Lint-Prüfungen, die Prüfung der Gestaltungsmöglichkeiten und die Komponentenvorschau aus. Weite die Prüfung nur dann auf die vollständige Suite aus, wenn sich die Änderung auf gemeinsam genutzte Verträge erstreckt. Hat sich die Version des Kernpakets geändert, führe den dokumentierten Migrationsschritt aus und prüfe seine Unterschiede. Berichte über das geänderte Verhalten, die aktualisierte Dokumentation, bestandene Prüfungen, jede entdeckte nicht unterstützte Fähigkeit und jede Prüfung, die nicht ausgeführt werden konnte.