Das Code-Repository eines Produkts mit App und Befehlszeile ordentlich halten

## Zuerst die Hauptregeldatei befolgen, dann die Regeln jedes Ordners Behandle die Stammrichtlinie als repositoryweite Wahrheitsquelle für übergreifende Grenzen, Arbeitsabläufe und Befehle. Halte sie knapp genug, um neue Mitwirkende zu orientieren, ohne Einzelheiten der Module zu wiederholen. - Veröffentliche einen kurzen Wegweiser zu Produkt-, Architektur-, Mitwirkungs-, Prüfungs- und aktuellen Planungsdokumenten. - Kennzeichne archivierte Spezifikationen eindeutig und behandle frühere Entscheidungen niemals als aktuelles Verhalten. - Verweise für jedes Hauptverzeichnis auf eine eigene Richtlinie zu lokaler Zuständigkeit und lokalen Einschränkungen. - Lies vor Arbeiten in einem geregelten Verzeichnis zusätzlich zu den Stammregeln dessen örtliche Richtlinie. - Wenn zwei Dokumente einander widersprechen, folge der benannten Wahrheitsquelle und melde den Konflikt, statt beide Inhalte zu vermischen. Übertrage Regeln auf Modulebene nicht zurück in das Stammdokument. Aktualisiere eine Regel auf der engsten Ebene, die sie vollständig besitzt, und verknüpfe sie nur bei Bedarf zur Auffindbarkeit aus allgemeineren Dokumenten. ## Vor Änderungen festlegen, wohin neuer Code und neue Tests gehören Pflege eine Repository-Karte, die erklärt, wofür jeder Bereich der obersten Ebene zuständig ist und welche Abhängigkeiten seine Grenze überschreiten dürfen. Nutze diese Karte, um den Platz für neuen Code, Prüfungen, Vorlagen, Dokumentation und Laufzeitdaten zu bestimmen. - Trenne Benutzeranwendungen, gemeinsame Verträge, Plattformgrundbausteine, Ablaufsteuerungswerkzeuge, durchgängige Prüfungen und Inhaltserweiterungen. - Halte Anwendungslogik frei von Einzelheiten der Prozesssteuerung und Paketierung. - Verhindere, dass eine Anwendung private Quellen oder Prüfungen einer anderen Anwendung importiert. - Verschiebe laufzeitübergreifende DTOs, Ereignisse, Fehler und Aufgabenformen in eine reine gemeinsame Vertragsschicht. - Lege Prüfungen in das Verzeichnis der geprüften Schicht; platziere anwendungsübergreifende Konsistenzprüfungen in der durchgängigen Prüfschicht. - Erfasse entfernte oder inaktive Verzeichnisse, damit Mitwirkende veraltete Architektur nicht versehentlich neu anlegen. Wenn ein wiederverwendbares Anliegen keine eindeutige Zuständigkeit besitzt, halte an und hole eine Zuständigkeitsentscheidung ein, bevor du einen weiteren gemeinsamen Ort anlegst. ## Den Speicherort der Daten an einer Stelle festlegen und weitergeben Löse jede Laufzeitwurzel, jeden Namensraum und jede Identität einmal an der zuständigen Grenze auf und gib den festgelegten Wert anschließend weiter. Komponenten müssen diesen Wert verwenden, statt ihn aus Ports, Arbeitsverzeichnissen, Anwendungsnamen oder Umgebungsersatzwerten neu zusammenzusetzen. - Leite alle laufzeiteigenen Datenpfade aus der aufgelösten Datenwurzel oder daraus abgeleiteten Konstanten ab. - Behandle eng begrenzte Überschreibungen und Migrationsquellen als ausdrückliche Ausnahmen, nicht als alternative Wurzeln. - Trenne vorübergehende Übertragungsangaben von der beständigen Laufzeitidentität. - Weise paketierten Zuständen und Entwicklungszuständen Namensräume zu, bevor du Unterprozesse startest. - Übergib den aufgelösten Zustand an Unterprozesse; lass sie ihre Speicherorte nicht selbst erraten. - Dokumentiere bekannte veraltete Ausweichpfade als Entfernungskandidaten und verwende sie niemals als Beispiele. Wenn eine offensichtliche Korrektur besteht, führe den Pfad über die maßgebliche Wurzel oder ein ausdrückliches Argument. Ist die richtige Zuständigkeit unklar, fordere eine Entscheidung der Verantwortlichen an, statt eine neue Konvention zu erfinden. ## Jede neue Funktion in App und Befehlszeile einbauen Entwirf Benutzerfunktionen um einen einzigen Dienstvertrag und stelle sie über jede unterstützte Bedienoberfläche bereit. Gleichwertigkeit zwischen den Oberflächen gehört zur Funktionsvollständigkeit und ist keine spätere Erweiterung. Führe für jede neue Funktion Folgendes aus: 1. Definiere oder aktualisiere gemeinsame Anfrage-, Antwort-, Fehler- und Ereignisverträge. 2. Implementiere den Dienstendpunkt als einzige Verhaltensquelle. 3. Füge die grafische Oberfläche hinzu, die diesen Endpunkt aufruft. 4. Füge die Befehlszeilenoberfläche hinzu, die denselben Endpunkt aufruft. 5. Stelle bei Bedarf maschinenlesbare Befehlsergebnisse und dateibasierte Eingaben für lange Anweisungen bereit. 6. Aktualisiere die Änderungsprüfliste und kennzeichne jede betroffene Oberfläche. Implementiere in verschiedenen Clients kein voneinander abweichendes Verhalten. Wenn eine Oberfläche tatsächlich nicht anwendbar ist, erläutere den Grund im Änderungsnachweis, statt sie stillschweigend auszulassen. ## Bildschirmbausteine wiederverwendbar und für alle leicht bedienbar bauen Ordne die visuelle Zuständigkeit der kleinsten stabilen Komponente zu und bewahre dabei bewusst festgelegte globale Verträge. Nutze gemeinsame Grundbausteine, bevor du neue örtliche Varianten erstellst. - Halte das globale Stylesheet als bewusste Grenze für Einbindungen und Gestaltungsvariablen. - Lege komponenteneigene Stile neben der Komponente ab und verwende standardmäßig bereichsgebundene Module. - Beschränke globale Selektoren auf Rücksetzungen, Gestaltungsvariablen, Anwendungsrahmen, gemeinsame Inhaltsverträge und Einbindungsstellen für Drittanbieter. - Bewahre beim Aufteilen von Stylesheets die Kaskadenreihenfolge und prüfe, dass sich die Spezifität nicht unbeabsichtigt ändert. - Nutze für Schaltflächen, verborgene Beschriftungen und gemeinsames Formularverhalten semantische Steuerelemente und zugängliche gemeinsame Grundbausteine. - Füge einen gemeinsamen Grundbaustein nur bei echter Wiederverwendbarkeit hinzu; belasse produktspezifische Anordnungen in der Produktschicht. - Lass bedingt sichtbare Elemente eingebunden, wenn die Ausblendbewegung wichtig ist, und schalte ihren Zustand über Klassen um. - Bevorzuge schnelle Abbremsbewegungen, kürzere Ausblend- als Einblendzeiten und eine Anfangsskalierung ungleich null. Wenn sich ein benachbarter globaler Stil durch eine kleine, prüfbare Änderung sicher verlagern lässt, verschiebe ihn zusammen mit der Komponente. Verbinde keine umfangreiche mechanische Verlagerung mit nicht zugehörigen Verhaltensänderungen. ## Änderungen mit dem leichtesten Test prüfen, der den Fehler findet Wähle die leichteste Prüfebene, die die Anforderung beobachten kann, und ergänze breitere Prüfungen nur dann, wenn das Risiko Grenzen überschreitet. Die Prüfung muss zur Zuständigkeit und zur Benutzerwirkung der Änderung passen. - Beginne bei Fehlern mit einer widerlegbaren Rückfallprüfung und bestätige, dass sie vor der Korrektur fehlschlägt. - Begrenze die Prüfung auf das gemeldete Verhalten und erfasse benachbarte Fehler als getrennte Folgearbeiten. - Führe Repository-Schutzprüfungen und statische Prüfungen sowie gezielte Prüfungen oder Bauvorgänge für geänderte Pakete aus. - Spiele aufgezeichnete Sitzungen bei Änderungen an Analyseprogrammen oder Agentenereignisströmen ab, bevor du echte Anbieteraufrufe verbrauchst. - Nutze Browserprüfungen für sichtbare Interaktionen, Bewegungen oder Wettlaufsituationen, die Modulprüfungen nicht belegen können. - Aktualisiere bei Änderungen am Arbeitsbereich oder an Abhängigkeiten die vom Repository geforderten erzeugten Verknüpfungen und Paketierungsprüfsummen. - Vergleiche mit dem Ausgangszustand, wenn benachbarte Prüfsammlungen bekannte Fehler besitzen. Lass die Implementierung eine dauerhafte Invariante statt einer historischen Ausnahme ausdrücken. Behaupte nicht allein aufgrund erfolgreicher automatischer Prüfungen, dass etwas bereit ist, wenn das Abnahmekriterium einen sichtbaren menschlichen Vergleich erfordert. ## Test- und stabile Versionen trennen und jede Version vor der Auslieferung prüfen Lege Freigabeidentität, Paketierungsverhalten und Prüfungsnachweise für jeden Auslieferungskanal ausdrücklich fest. Lass nicht zu, dass bequeme Abkürzungen die Kanaltrennung aufheben oder vertrauenswürdige Prüfungen umgehen. - Gib Entwicklungs-, internen Prüf-, Vorschau- und stabilen Kanälen unterschiedliche Zwecke und öffentliche Identitäten. - Definiere Freigabeabhängigkeiten ausdrücklich; mache einen stabilen Kanal nicht von einem unverbundenen Vorschauweg abhängig. - Halte paketierte Laufzeitpfade nach Namensraum getrennt und unabhängig von vorübergehenden Ports. - Führe die Ablaufsteuerung über zuständige Paketgrundbausteine, statt Prozessargumente oder Suchregeln in Aufrufern neu zusammenzusetzen. - Verlange, dass Änderungsbeschreibungen den auslösenden Anwendungsfall, die sichtbare Benutzerwirkung, betroffene Oberflächen und Prüfnachweise benennen. - Füge bei sichtbaren Oberflächenänderungen Bildschirmaufnahmen des Einstiegspunkts bei, nicht nur Bilder einzelner Komponenten. - Verknüpfe Fehlerkorrekturen mit ihren Rückfallprüfungen und Vorgangsaufzeichnungen. - Halte nicht zugehörige Erkenntnisse aus der aktuellen Änderung heraus, sofern sie nicht Korrektheit, Sicherheit, Datenintegrität oder Vertragskompatibilität blockieren. Prüfe das Artefakt vor der Freigabe über denselben Weg, den Benutzer ausführen werden. Genehmige keine Änderungen, die Repository-Grenzen verletzen, erforderliche Prüfungen auslassen, Geheimnisse offenlegen oder beständige Daten beschädigen könnten.