Ändere ein Repository mit mehreren Modulen und erzeugtem Code, ohne Freigaben zu überschreiten

## Lies vor dem Bearbeiten die Anweisungen im Hauptordner und in Unterordnern Ermitteln Sie zuerst die Vorgaben des Quellcodearchivs, die für die Dateien gelten, die Sie ändern dürfen. Behandeln Sie Projektdokumentation und untergeordnete Anweisungsdateien als maßgebliche Quelle für lokale Konventionen, statt allgemeine Annahmen über das technische Umfeld zu übernehmen. - Lesen Sie die Vorgaben im Stammverzeichnis und alle genaueren Anweisungen im Zielverzeichnis. - Prüfen Sie die für die Aufgabe maßgebliche Übersicht des Quellcodearchivs, den Beitragsleitfaden, die Einrichtung der Entwicklungsumgebung, die Testrichtlinien und die Veröffentlichungsdokumentation. - Befolgen Sie bei Abweichungen zwischen archivweiten und modulspezifischen Vorgaben die nächstgelegene anwendbare Anweisung. - Ermitteln Sie verwiesene Richtlinien aus gepflegten Projektdateien, statt sich auf erinnerte Befehle zu verlassen. - Finden Sie Dateien zur Zuständigkeitsregelung und die für den betroffenen Bereich verantwortlichen Prüfer. - Halten Sie vor der Bearbeitung den unterstützten Arbeitsablauf, erforderliche Genehmigungen und erwartete Nachweise fest. - Fragen Sie nur nach, wenn maßgebliche Quellen einander widersprechen oder eine folgenreiche Entscheidung ungeklärt bleibt. ## Finde das zuständige Modul und die Prüfer für die Änderung Verstehen Sie die Aufteilung der Quellcodebasis, bevor Sie den Ort einer Umsetzung wählen. In einem Archiv mit mehreren Modulen können sich Erstellungsgrenzen, Abhängigkeitsverzeichnisse, erzeugte Bereiche, Beispiele, Tests und Veröffentlichungseinheiten je nach Verzeichnis unterscheiden. - Ermitteln Sie das für das öffentliche Verhalten zuständige Modul und die systemnäheren Bestandteile, von denen es abhängt. - Unterscheiden Sie handgeschriebene Umsetzung von erzeugtem Quellcode, Vorlagen, Spezifikationen, Testdaten und Beispielen. - Prüfen Sie Modulverzeichnisse, um die Grenzen direkter und indirekter Abhängigkeiten zu verstehen. - Nutzen Sie Zuständigkeitsregeln, um die Verantwortlichen für Quellcode, Dienste und gemeinsam genutzte Infrastruktur zu ermitteln. - Verfolgen Sie, ob eine Änderung ein Paket, eine Modulgruppe oder eine gemeinsam genutzte Kompatibilitätsfläche betrifft. - Halten Sie sich an die bestehende Verzeichnisstruktur und Benennungsmuster, statt parallele Strukturen zu erfinden. - Lassen Sie sachfremde Module unverändert, sofern keine nachgewiesene Abhängigkeit abgestimmte Änderungen erfordert. ## Nutze die festgelegten Werkzeugversionen und Task-Befehle des Projekts Verwenden Sie die vom Quellcodearchiv und Zielmodul vorgegebene Werkzeugkette. Versionsunterstützung, Aufgabensteuerungen, Generatoren und Umgebungsvorbereitung sind Projektentscheidungen und dürfen nicht aus der neuesten lokalen Installation abgeleitet werden. - Bestätigen Sie die derzeit unterstützten Sprach- und Werkzeugversionen anhand gepflegter Richtlinien oder Einstellungen. - Bevorzugen Sie vom Quellcodearchiv verwaltete Aufgaben gegenüber direkten Sprachbefehlen, wenn sie zusätzliche Vorbereitungen ausführen. - Führen Sie Befehle in dem Modul- oder Arbeitsbereichsverzeichnis aus, das der dokumentierte Ablauf erwartet. - Bewahren Sie Umgebungsauswahl, Kompatibilitätsoptionen, erzeugte Ressourcen und andere Vorbereitungen der maßgeblichen Aufgaben. - Installieren Sie systemweite Voraussetzungen nur, wenn der dokumentierte Ablauf sie ausdrücklich verlangt. - Stimmen Sie Generator- und Übersetzerversionen mit den festgelegten oder unterstützten Projektversionen ab. - Melden Sie fehlende Voraussetzungen als konkretes Hindernis, statt den Arbeitsablauf stillschweigend zu ändern. ## Frage vor Releases, CI-Änderungen oder dem Einsatz von Zugangsdaten nach KI-Systeme dürfen Quellcode lesen, Verhalten erklären, Änderungen vorschlagen, genehmigte Bearbeitungen umsetzen, Tests ergänzen, Dokumentation verbessern und bei der Analyse von Problemberichten oder Prüfungen helfen. Vorgänge mit größerer Auswirkung erfordern weiterhin eine ausdrückliche menschliche Befugnis. - Lösen Sie ohne Genehmigung keine Veröffentlichungen aus, genehmigen Sie keine Veröffentlichungsstufen und veröffentlichen Sie keine Pakete. - Ändern Sie fortlaufende Integration, Bereitstellungsabläufe oder Ablaufsteuerungen nicht beiläufig als Teil einer anderen Änderung. - Ändern Sie Lizenzierung, rechtliche Hinweise oder Regeln zur Vorschriftskonformität nicht ohne ausdrückliche Befugnis. - Verwenden Sie keine Zugangsdaten, greifen Sie nicht auf externe Dienste zu und verändern Sie keinen entfernten Zustand außerhalb der erteilten Aufgabe. - Behandeln Sie die Einordnung von Problemberichten, Vorschläge für Kennzeichnungen und die Erkennung von Doppelungen als Empfehlungen, sofern Zustandsänderungen nicht genehmigt wurden. - Halten Sie vor schwer rückgängig zu machenden Vorgängen oder Änderungen an geschützten Umgebungen an und fordern Sie die erforderliche Entscheidung an. - Setzen Sie gewöhnliche Umsetzung und Prüfung innerhalb des Umfangs ohne unnötige Rückfragen fort. ## Ändere die Spezifikation und erzeuge neu, statt erzeugte Dateien zu bearbeiten Erzeugte Pakete benötigen einen anderen Änderungsweg als handgeschriebener Quellcode. Manuelle Änderungen an erzeugten Ergebnissen werden meist überschrieben und können die Umsetzung von ihrer maßgeblichen Spezifikation trennen. - Erkennen Sie erzeugte Dateien anhand von Archivkennzeichnungen, Verzeichnissen, Ortsdateien oder dokumentierten Verzeichnisregeln. - Ändern Sie erzeugte Ergebnisse nicht manuell, wenn das Projekt eine spezifikationsgesteuerte Neuerzeugung verlangt. - Ändern Sie die maßgebliche Spezifikation, Vorlage oder Generatoreingabe, wenn sie die dokumentierte Quelle ist. - Verwenden Sie den vorgeschriebenen Erzeugungsbefehl des Projekts und die erforderlichen Werkzeugversionen. - Prüfen Sie die erzeugte Änderungsübersicht auf unerwartete Dateien, reine Formatierungsänderungen und sachfremde Änderungen an Programmierschnittstellen. - Trennen Sie manuelle Erweiterungspunkte gemäß den Archivmustern von erzeugten Bereichen. - Wenn eine Neuerzeugung nicht verfügbar oder nicht genehmigt ist, erläutern Sie die Einschränkung, statt eine vorläufige Änderung als dauerhafte Behebung auszugeben. ## Mache kleine Änderungen, die abwärtskompatibel bleiben Bevorzugen Sie fokussierte Änderungen, die den bestehenden Quellcodekonventionen folgen und Kompatibilität bewahren. Wenn beide Wege die Anforderung erfüllen, ist eine kleine, leicht prüfbare Änderung sicherer als eine umfassende Umstrukturierung. - Lesen Sie benachbarte Umsetzungen, bevor Sie Hilfsfunktionen, Namen, Fehlermuster und Dateiplatzierung wählen. - Bewahren Sie Rückwärtskompatibilität, sofern eine inkompatible Änderung nicht ausdrücklich genehmigt und dokumentiert wurde. - Befolgen Sie lokale Konventionen für öffentliche Namen, Abkürzungen, Kommentare und die Dokumentation öffentlicher Programmierschnittstellen. - Verwenden Sie aussagekräftige Fehler, die nützlichen Zusammenhang erhalten, ohne vertrauliche Angaben offenzulegen. - Lassen Sie erforderliche Urheberrechts- und Lizenzhinweise unverändert. - Befolgen Sie die Abhängigkeitsrichtlinie des Moduls und fügen Sie keine externe Abhängigkeit für bereits lokal verfügbares Verhalten hinzu. - Trennen Sie sachfremde Aufräumarbeiten von der angeforderten Änderung, damit Prüfer die Absicht eindeutig beurteilen können. ## Baue und teste zuerst das betroffene Modul und erweitere nur bei Bedarf Führen Sie zunächst die kleinsten Befehle aus, die das betroffene Modul abdecken, und erweitern Sie die Prüfung nur, wenn gemeinsam genutztes Verhalten oder die Archivrichtlinie dies verlangt. Ein erfolgreicher Befehl ist nur aussagekräftig, wenn er den geänderten Pfad erfasst. - Erstellen Sie das Zielmodul mit seiner dokumentierten Aufgabe oder dem entsprechenden Sprachbefehl. - Führen Sie die unmittelbar relevanten Modultests vor umfassenderen Paket- oder Arbeitsbereichstests aus. - Ergänzen Sie Typprüfungen, statische Analyse, Formatierung und die Prüfung erzeugter Dateien, wenn das Modul sie verlangt. - Bestätigen Sie, dass die Testauswahl tatsächlich das beabsichtigte Paket und die vorgesehenen Fälle enthielt. - Prüfen Sie erforderliche Umgebungsvariablen, bevor Sie Integrationsprüfungen oder Tests in einer realen Umgebung versuchen. - Behaupten Sie keine erfolgreiche Prüfung aufgrund eines Befehls, der Ziele übersprungen hat oder von nicht verfügbarem externem Zustand abhing. - Halten Sie ausgeführte Befehle, beobachtete Ergebnisse und nicht abschließbare Prüfungen fest. ## Schreibe Tests ohne Abhängigkeit von Netzwerk oder Reihenfolge und lauffähige Beispiele Tests sollen die Verhaltensänderung belegen und auf verschiedenen Rechnern zuverlässig bleiben. Beispiele sollen eine unterstützte Verwendung zeigen und dabei den Konventionen des Quellcodearchivs für ausführbare Beispiele folgen. - Verwenden Sie die im Modul etablierte Prüfbibliothek und Teststruktur erneut. - Bestätigen Sie bei der Behebung eines Fehlers vor der Korrektur, dass der neue Test aus dem beabsichtigten Grund fehlschlägt. - Halten Sie Modultests unabhängig von Netzwerken, Zugangsdaten, zeitabhängigem Zustand und Ausführungsreihenfolge. - Speichern Sie Testdaten am vorgesehenen Ort und beschränken Sie sie auf das Nötige. - Trennen Sie Einstellungen für Tests in realen Umgebungen in genehmigte Umgebungsdateien und speichern Sie niemals vertrauliche Werte in der Versionsgeschichte. - Ergänzen Sie Prüfaussagen um Meldungen, wenn dies die Diagnose wesentlich verbessert. - Legen Sie Beispiele in der erwarteten Benennungs- und Paketstruktur ab und stellen Sie sicher, dass sie im dokumentierten Testablauf erstellt oder ausgeführt werden. ## Aktualisiere Moduldoku und Änderungsprotokoll, wenn sich Verhalten ändert Dokumentation gehört zur Umsetzungsfläche. Aktualisieren Sie sie, wenn Benutzer, Verantwortliche oder Veröffentlichungswerkzeuge sonst ein unvollständiges oder irreführendes Bild der Änderung erhalten würden. - Aktualisieren Sie die Modulübersicht, wenn sich Einrichtung, unterstütztes Verhalten oder öffentliche Verwendung ändern. - Ergänzen oder überarbeiten Sie Beschreibungen von Programmierschnittstellen gemäß dem Dokumentationsstil des Projekts. - Erfassen Sie für Benutzer sichtbare Änderungen in der vorgeschriebenen Änderungshistorie. - Stellen Sie Beispiele für neue öffentliche Programmierschnittstellen bereit, wenn die Archivrichtlinie dies erwartet. - Halten Sie Anleitungen zu Einrichtung, Erzeugung, Umstellung und Veröffentlichung mit den tatsächlichen Befehlen übereinstimmend. - Prüfen Sie, dass Verweise gültig bleiben und Leser nicht zu privaten oder veralteten Orten führen. - Vermeiden Sie unnötige Dokumentationsänderungen, wenn Verhalten und Arbeitsablauf unverändert bleiben. ## Öffne Änderungsanfragen vom freigegebenen Zweig nach Prüfung des ganzen Diffs Verwenden Sie den genehmigten Beitragsweg des Quellcodearchivs und machen Sie die vollständige Änderung leicht prüfbar. Ein Beitrag soll Umsetzung, Tests, Dokumentation und Begründung verbinden, ohne geschützte gemeinsame Historie zu verändern. - Beginnen Sie mit dem genehmigten Ausgangszweig und veröffentlichen Sie über die autorisierte persönliche Kopie oder entfernte Gegenstelle. - Prüfen Sie die vollständige Änderungsübersicht des Zweigs, bevor Sie einen Änderungsantrag eröffnen. - Verwenden Sie einen aussagekräftigen Titel und verweisen Sie auf zugehörige Arbeiten, wenn vorhanden. - Fügen Sie Tests gegen künftige Rückfälle und die von der Richtlinie verlangte Dokumentation hinzu. - Beantworten Sie Prüfrückmeldungen durch nachvollziehbare Folgeänderungen, sofern Verantwortliche keine andere Strategie für die Historie verlangen. - Prüfen Sie alle vorgeschriebenen automatischen Kontrollen und untersuchen Sie Fehler, statt sie zu umgehen. - Lassen Sie geschützte Zweige, Veröffentlichungszweige und gemeinsame Historie ohne ausdrückliche Genehmigung unverändert. ## Prüfe Code auf inkompatible Änderungen und Fehler in erzeugten Dateien Die Quellcodeprüfung soll Richtigkeit, Kompatibilität, Unversehrtheit der Erzeugung, Testqualität, Informationssicherheit und Wartbarkeit priorisieren. Wenden Sie projektspezifische Richtlinien statt einer allgemeinen Stilprüfliste an. - Prüfen Sie, dass die Änderung in das gewählte Modul gehört und dessen Architektur folgt. - Suchen Sie nach inkompatiblen Änderungen an Programmierschnittstellen oder Verhalten, einschließlich unauffälliger Änderungen an Standardwerten. - Prüfen Sie, ob Tests Erfolg, Fehlschlag, Grenzfälle und Wiederholbarkeit abdecken, soweit relevant. - Bestätigen Sie, dass erzeugte Dateien aus der genehmigten Quelle und dem genehmigten Erzeugungsablauf stammen. - Untersuchen Sie Änderungen an Abhängigkeiten und Verzeichnissen auf Richtlinienverstöße oder unnötige Ergänzungen. - Prüfen Sie Dokumentation und Änderungsaufzeichnungen auf Vollständigkeit und Richtigkeit. - Leiten Sie Befunde an die zuständigen Verantwortlichen weiter und unterscheiden Sie blockierende Fehler von freiwilligen Verbesserungen. ## Melde Sicherheitslücken vertraulich und übergib die Testergebnisse Sicherheitsmeldungen, Veröffentlichungen, Genehmigungen in Ablaufketten, Lizenzen und Zugangsdaten erfordern eine gesonderte Behandlung. Schließen Sie gewöhnliche Arbeit mit einer nachweisgestützten Übergabe ab und überlassen Sie geschützte Vorgänge befugten Menschen. - Melden Sie Sicherheitslücken über den privaten Kanal des Projekts und nicht in einem öffentlichen Problembericht oder einer öffentlichen Diskussion. - Nehmen Sie niemals Geheimnisse, private Kontaktdaten oder vertrauliche Reproduktionsangaben in öffentliche Ergebnisse auf. - Überlassen Sie Veröffentlichungsauslöser, Bereitstellungsgenehmigungen und Lizenzentscheidungen ausdrücklich befugten Verantwortlichen. - Erläutern Sie wichtige Umsetzungsentscheidungen und verknüpfen Sie sie mit den anwendbaren Projektrichtlinien. - Fassen Sie geänderte Pfade, durchgeführte Tests, beobachtete Ergebnisse und verbleibende Einschränkungen zusammen. - Benennen Sie die zuständigen Quellcode- oder Dienstverantwortlichen, wenn eine weitere Prüfung erforderlich ist. - Geben Sie klar an, wenn externer Zugriff, nicht verfügbare Werkzeuge oder eine Genehmigungsgrenze eine vollständige Prüfung verhindert haben.