Eine Komponentenbibliothek für Oberflächen ändern und prüfen, dass nichts kaputtgeht

## Befehle mit der vorgegebenen Paketverwaltung vom Wurzelverzeichnis aus starten Verwende ausschließlich die vom Quelltextbestand festgelegte Paketverwaltung und Befehlsform für den Arbeitsbereich. Führe auf ein Paket begrenzte Vorgänge vom Wurzelverzeichnis aus über den Arbeitsbereichsfilter der Paketverwaltung aus, statt in Paketverzeichnisse zu wechseln und ein anderes Werkzeug aufzurufen. Installiere Abhängigkeiten nur bei Bedarf. Bevorzuge während der schrittweisen Arbeit den am engsten auf ein Paket begrenzten Befehl für Erstellung, Prüfung, statische Prüfung oder Typprüfung und nutze eine Erstellung des gesamten Quelltextbestands nur für Integrations- oder Veröffentlichungsprüfungen. Behandle Dokumentationsentwicklung, Paketerstellung, Dokumentationserstellung, Modultests, Webbrowserprüfungen, durchgängige Prüfungen, visuelle Regressionsprüfungen, Formatierung, statische Prüfung und Typprüfung als getrennte Arbeitsabläufe. ## Neue Komponenten im Versuchsbereich anlegen und interne Pakete nicht öffentlich machen Gliedere die Bibliothek in Kernkomponenten, Gestaltungssystem, experimentelle Komponenten, Symbole oder Ressourcen, gemeinsame Hilfsfunktionen, Styling-Engine-Abstraktion und nicht veröffentlichte interne Pakete. Beachte, welche Pakete öffentlich sind und welche ausschließlich den Arbeitsbereich unterstützen. Führe neue oder instabile Komponenten zuerst im vorgesehenen Versuchsbereich ein, bevor du sie in das stabile Paket übernimmst. Halte gemeinsame Gestaltung und Themenverhalten in der Gestaltungsschicht, statt sie über mehrere Komponenten hinweg zu vervielfältigen. Lege interne Pakete nicht über öffentliche Einstiegspunkte offen und umgehe die eingerichtete Styling-Engine-Abstraktion nicht mit umsetzungsspezifischen Annahmen. ## Dateien jeder Komponente ordnen und nur das Nötige importieren Befolge die Dateianordnung für Komponenten des Quelltextbestands bei Umsetzung, Deklarationen, Prüfungen, Gestaltungsklassen und öffentlichen Exporten. Belasse jede Verantwortung in der dafür zuständigen Datei, damit `API`-Dokumentation, Prüfungen und die Entfernung ungenutzten Quelltexts vorhersehbar bleiben. Verwende für öffentliche Komponenteneigenschaften die vom Quelltextbestand geforderte Deklarationsform und exportiere aus dem Komponentenmodul eine einheitlich benannte Eigenschaftenschnittstelle. Bewahre Pfad-Aliasse und Konventionen für öffentliche Exporte. Verwende im Arbeitsbereich eng begrenzte, einstufige Paketimporte, wenn breite Sammelimporte ein ganzes Paket in ein Programmpaket aufnehmen würden. Behandle die Importform als Leistungs- und Paketierungsvertrag, nicht als Stilvorliebe. ## Fehlermeldungen schreiben, die sagen, was passiert ist und wie man es behebt Jeder von einem öffentlichen Paket ausgelöste Fehler muss angeben, was geschehen ist, warum es wichtig ist und wie die aufrufende Stelle ihn beheben kann. Verwende das vorgeschriebene Bibliothekspräfix, einen lesbaren Meldungsaufbau und einen Dokumentationsverweis, wenn ein gepflegter Leitfaden vorhanden ist. Wende die vorgeschriebene Markierung zur Kürzung von Fehlermeldungen auf unterstützte Fehlerkonstruktoren an, damit Produktionspakete lange Meldungen durch stabile Codes ersetzen können, während sie bei der Entwicklung verständlich bleiben. Erzeuge nach dem Hinzufügen oder Ändern eines öffentlichen Fehlers den Fehlercodekatalog neu. Wenn Bedeutung und Anzahl der Argumente unverändert sind, aktualisiere den vorhandenen Katalogeintrag, statt für denselben Fehlervertrag einen neuen Code anzulegen. ## Komponenten so prüfen, wie Nutzer klicken und tippen Verwende das gemeinsame Darstellungswerkzeug und die Zusicherungswerkzeuge des Quelltextbestands, damit Komponentenprüfungen der unterstützten Umgebung entsprechen. Bevorzuge barrierefreie Abfragen und vollständige Benutzerinteraktionen gegenüber niedrigstufiger Ereignisauslösung oder direkter Änderung von Eigenschaften. Prüfe beobachtbares Verhalten, Zustandsübergänge, Warnungen und Fehler mit den eingerichteten Vergleichsregeln. Halte Modultests eng begrenzt und verwende während der schrittweisen Arbeit Namensfilter, ohne einen erfolgreichen gefilterten Lauf mit vollständiger Abdeckung zu verwechseln. Wenn eine Prüfung Anordnung, Webbrowser-`API` oder Darstellungsverhalten benötigt, das in einem nachgebildeten `DOM` nicht verfügbar ist, beschränke sie auf die unterstützte echte Webbrowserumgebung und dokumentiere den Grund in der Prüfbedingung. ## Screenshots abschalten, ohne die Barrierefreiheitsprüfung abzuschalten Führe die Barrierefreiheitsanalyse innerhalb der bestehenden Webbrowser-Regressionsschleife aus, wenn der Quelltextbestand diese Sitzung gemeinsam nutzt. Behandle Bildschirmaufnahmen und Barrierefreiheitszusicherungen als unabhängige Kontrollen: Eine Vorführung darf eine davon abschalten, ohne damit stillschweigend auch die andere abzuschalten. Halte den Abdeckungsumfang der Barrierefreiheitsregeln ausdrücklich fest. Erfasse bestandene, fehlgeschlagene und unvollständige Ergebnisse nach Vorführung und Regel, füge die zutreffenden Kennzeichnungen des Barrierefreiheitsstandards hinzu und behalte erforderliche Zusicherungen bei, sofern keine eng begrenzte und begründete Ausnahme eingerichtet ist. Starte keinen getrennten Webbrowser-Arbeitsablauf, wenn das eingebundene Regressionsgerüst bereits Seitennavigation, Darstellung, Bildschirmaufnahmen und Barrierefreiheitsanalyse übernimmt. ## Ausnahmeregeln so ordnen, dass das Überspringen einer Demo keine anderen überspringt Gleiche die Regressionskonfiguration mit stabilen Vorführungskennungen ab. Wenn Regeln ohne Vererbung nach dem Grundsatz „die letzte Übereinstimmung gewinnt“ arbeiten, platziere eng begrenzte Überschreibungen nach breiten Regeln und gib jedes Feld erneut an, das die Überschreibung beibehalten soll. Verwende eng begrenzte Muster für einzelne Vorführungen und breitere Muster nur für eine vollständige Komponentengruppe. Eine Regel, die eine einzelne Vorführung abschaltet, darf nicht versehentlich gleichgeordnete Vorführungen abschalten oder veraltete Ausnahmefelder erben. Erzeuge nach Regeländerungen die strukturierten Barrierefreiheits- und visuellen Ergebnisse neu. Die kontinuierliche Integration soll veraltete erzeugte Berichte zurückweisen, statt stillschweigend eine Konfiguration anzunehmen, die nie ausgeführt wurde. ## Beim Arbeiten nur Betroffenes prüfen, vor dem Übermitteln alle Prüfungen laufen lassen Begrenze lokale Regressionsläufe mit dem Namensfilter des Prüfausführungswerkzeugs, damit nicht passende Prüfungen weder den Webbrowser steuern noch sachfremde Ergebnisse neu schreiben. Bestätige, dass der Filter mit dem Pfad oder der Vorführungskennung übereinstimmt, die im Prüfungsnamen enthalten ist. Beachte, dass ein gefilterter Lauf nur die Berichte passender Komponenten erneuert. Führe vor dem Übermitteln der Änderungen den ungefilterten Regressionsbefehl aus, damit alle Berichte, Bildschirmaufnahmen und Barrierefreiheitsergebnisse aktuell sind. Halte den Regressionsdienst und das Ausführungswerkzeug als getrennte Prozesse, wenn der Arbeitsablauf des Quelltextbestands dies verlangt, und bewahre die dokumentierte Syntax der Paketverwaltung zur Weitergabe von Argumenten. ## Nach einer Komponentenänderung API-Dokumentation und Demos neu erzeugen Führe nach Änderungen an Komponenteneigenschaften oder Typdeklarationen die Werkzeuge zur Eigenschaftsextraktion und Erzeugung der `API`-Dokumentation aus. Prüfe die daraus entstandenen Änderungen an der öffentlichen `API` zusammen mit der Quelltextänderung. Erstelle die vorgesehene typisierte Vorführung als maßgebliche Quelle und erzeuge Varianten in anderen Sprachen über das unterstützte Formatierungs- oder Umwandlungswerkzeug. Bearbeite nicht ausschließlich eine erzeugte Vorführungsvariante von Hand, um eine Korrektur vorzunehmen. Wenn sich Vorführungen oder `Markdown` ändern, führe die zugehörigen Prüfungen für Vorführungserzeugung, Dokumentationserstellung, Schreibstil und Grammatik aus. Bewahre besondere Integrationsanleitungen in eigenständigen lokalen Anweisungsmodulen auf und lade das passende Modul für Arbeiten an Gestaltung, Themen, Darstellung oder Einbindung von Rahmenwerken. ## Die Prüfungen machen, die die Änderung braucht, und fehlende Prüfungen melden Formatiere vor der Überprüfung geänderte Dateien, führe statische Prüfung und Typprüfung aus, erledige zielgerichtete Modultests und erweitere die Prüfung je nach betroffenem Verhalten auf echte Webbrowser, durchgängige Abläufe, visuelle Darstellung, Barrierefreiheit, `API`-Dokumentation oder Schreibstil. Prüfe erzeugte Fehlercodes, `API`-Verweise, Vorführungsvarianten, Bildschirmaufnahmen und Barrierefreiheitsberichte, wenn sich ihre Quellen geändert haben. Melde jede blockierte oder nicht ausgeführte Freigabeprüfung, statt eine teilweise Überprüfung als vollständig darzustellen. Konzentriere die Überprüfung auf die Komponente und verwende das vorgeschriebene Format für Änderungstitel: zuerst einen stabilen Komponenten- oder Dokumentationsbereich, danach eine Beschreibung im Imperativ.