Codebeiträge vorbereiten, die ein Mensch prüft und einreicht

## Die Regeln des Repositorys befolgen und auf die Freigabe der Projektverantwortlichen warten Behandle den Beitragsleitfaden, die Richtlinie zur künstlichen Intelligenz und die verzeichnisspezifischen Anweisungen für Softwareassistenten als maßgebliche Quellen für die zu ändernden Dateien. ### Anwendbare Regeln bestimmen - Lies vor jeder Bearbeitung die Beitrags- und Sicherheitsrichtlinien im Stammverzeichnis. - Wende beim Betreten eines Fachverzeichnisses auch dessen örtliche Anweisungen zu Laufzeitverhalten, öffentlichen Schnittstellen, Anbindungen, Dokumentation oder Prüfungen an. - Halte bei widersprüchlichen Anweisungen an und lege den Widerspruch offen, anstatt die für die Umsetzung bequemere Regel zu wählen. - Nutze optionale Fähigkeiten von Softwareassistenten nur, wenn das verwendete Programm sie unterstützt und sie die Richtlinien des Projektarchivs nicht außer Kraft setzen. ### Genehmigungspunkte - Reiche Vorgänge, Zusammenführungsanträge oder Entwürfe solcher Anträge nicht über Browserautomatisierung, Befehlszeilenwerkzeuge von Bereitstellungsdiensten oder Programmierschnittstellen von Diensten ein. - Formuliere den Einreichungstext anhand der Vorlagen des Projektarchivs so, dass ein Mensch ihn prüfen, versenden und unmittelbar einfügen kann. - Übertrage keine Entwicklungszweige und bereite kein Material für eine öffentliche Einreichung vor, bevor der betreffende Vorgang eingeordnet und der menschlichen beitragenden Person zugewiesen wurde. - Setze keine nicht triviale Funktion, Änderung einer öffentlichen Schnittstelle, Umstrukturierung oder Verhaltensänderung ohne festgehaltene Anweisung der Projektverantwortlichen um. Fehlt diese Anweisung, halte bei einem Vorschlag an. ## Geheimnisse aus Commits halten und Tests nicht mit echten Diensten verbinden Schütze während der gesamten Aufgabe Zugangsdaten, die Qualität der Nachweise, den Verlauf des Projektarchivs und die Abschottung der Prüfungen. ### Nicht verhandelbare Regeln - Übernimm niemals Geheimnisse, Zugangsdaten, nicht öffentliche Anbieterdaten oder empfindliche Umgebungswerte in den Versionsstand. - Erfinde niemals Prüfergebnisse, Genehmigungen, Quellenangaben, Durchsichtszustände oder Aussagen zur Vereinbarkeit. - Modultests dürfen keine produktiv eingesetzten Modelle, Anbieter oder Dienste externer Anwendungen kontaktieren. - Verwende deterministische Ersatzlösungen und eine Umgebung, die Zugangsdaten produktiver Dienste aus den Prüfprozessen entfernt. - Füge keine erzeugten Medien, großen erzeugten Dateien oder künstlichen Datensätze ohne eindeutige Herkunft und Zustimmung der Projektverantwortlichen hinzu. - Füge Lizenzköpfe nicht von Hand hinzu, wenn die Automatisierung des Projektarchivs ihre Einfügung übernimmt. - Füge Kommentare nur auf Anforderung hinzu. Bewahre bestehende Kommentare, Dokumentationszeichenketten und Lizenzköpfe, sofern die Änderung sie nicht sachlich falsch macht. ### Geschützte Dateien Bearbeite Änderungsprotokolle, erzeugte Dateien, Abhängigkeits-Sperrdateien, Prüfschnappschüsse oder andere werkzeugverwaltete Erzeugnisse nicht von Hand, es sei denn, die Aufgabe verlangt ausdrücklich den Neuerzeugungsablauf des Projektarchivs. Werden Änderungsprotokolle erzeugt, nimm den Hintergrund für Veröffentlichungshinweise in einen Vorschlag oder Einreichungsentwurf auf. ## Abhängigkeiten nur bei Bedarf ändern und die festgelegten Werkzeuge nutzen Nutze die verbindliche, festgeschriebene Umgebung und die Aufgabenbefehle des Projekts, anstatt andere Ausführungswege zu improvisieren. ### Änderungen an Abhängigkeiten - Füge keine Abhängigkeiten hinzu und aktualisiere sie nicht, sofern die Aufgabe dies nicht erfordert. - Nutze für vorübergehende Untersuchungen eine abgeschottete Umgebung, die den festgehaltenen Abhängigkeitsstand nicht verändert. - Ordne eine notwendige Änderung der Abhängigkeiten der kleinsten geeigneten Abhängigkeitsgruppe oder dem kleinsten geeigneten Satz wahlfreier Funktionen zu. - Lege eindeutige Vereinbarkeitsgrenzen fest und verschiebe wahlfreie Anbindungen nicht in den vorgegebenen Installationsweg. - Halte Änderungen an Abhängigkeiten und Sperrdateien von sachfremden Bearbeitungen getrennt. ### Werkzeugeinsatz - Nutze für Installation, Prüfungen, Dokumentation, Formatierung und statische Untersuchung die im Projektarchiv festgelegten Versionen der Laufzeit und Werkzeuge. - Unterscheide verbindliche Prüfbefehle von Diagnosebefehlen. Ein eigenständiges Stil- oder Typprüfprogramm kann die Diagnose unterstützen, ersetzt aber nicht die vorgeschriebenen Prüfungen vor einem Versionseintrag oder den verbindlichen Prüfweg des Projektarchivs. - Behandle Skripte, die umfangreich Dateien für Versionseinträge vormerken, Versionseinträge erstellen oder das gesamte Projektarchiv prüfen, als Werkzeuge mit großer Auswirkung. Führe sie nur aus, wenn dies ausdrücklich erforderlich ist, und möglichst in einem unveränderten Arbeitsbaum. ## Die Tests passend zur Art der Änderung auswählen Wähle anhand der tatsächlichen Änderungsart die kleinste ausreichende Prüfung und erweitere sie nur, wenn ein Risiko für gemeinsam genutztes Verhalten oder Vereinbarkeit dies rechtfertigt. ### Prüfmatrix - Dokumentation oder Metadaten des Projektarchivs: Prüfe die geänderten Dateien. Erzeuge die Dokumentation, wenn Darstellung, Verweise, Beispiele oder Dokumentationseinstellungen betroffen sein können. - Laufzeitfehlerbehebung: Füge einen gezielten Rückfalltest hinzu oder führe ihn aus und prüfe anschließend die geänderten Dateien wie vorgeschrieben. - Öffentliche Schnittstelle, Einstellung oder Sprachverhalten: Führe gezielte Prüfungen aus und aktualisiere die zugehörige Dokumentation oder Beispiele. Ergänze bei bedeutsamem Vereinbarkeitsrisiko umfassendere Paketprüfungen. - Server-, Datenstrom-, Ablaufverfolgungs-, Aktions- oder Erzeugungspfad: Prüfe den geänderten Pfad und seinen Ausweichpfad oder den nicht unterstützten Pfad. - Paketierung, Abhängigkeit oder Sperrdatei: Führe die einschlägigen Installations- oder Paketierungsprüfungen aus und halte die Änderungen an den Abhängigkeiten abgeschottet. ### Umfang und Abschottung - Ermittle, was der verbindliche Befehl für die vollständige Prüfserie umfasst. Nimm nicht an, dass er nur das naheliegendste Prüfverzeichnis abdeckt. - Bevorzuge den Prüfeinstieg, der Zugangsdaten produktiver Anbieter entfernt und deterministische Ersatzlösungen bereitstellt. - Untersuche abschottungsbedingte wechselhafte Fehler, indem du den üblichen Parallellauf mit einem deterministischen Reihenlauf unter denselben Umgebungsschutzmaßnahmen vergleichst. - Behandle Kennzeichnungen für langsame oder serielle Ausführung als Hinweise, sofern das Prüfprogramm sie nicht tatsächlich erzwingt. - Nutze keinen bequemen alternativen Prüfbefehl, wenn er produktive Zugangsdaten beibehalten oder vorgeschriebene Prüfpfade umgehen kann. ### Belege für die Übergabe Führe für eine zur Durchsicht bestimmte Änderung vor der Übergabe die verbindlichen Prüfungen vor dem Versionseintrag aus, damit Ergebnisse zu Formatierung, Lizenz und Typen stabil sind. Berichte jede ausgelassene Pflichtprüfung und den Grund dafür. ## Doppelte Arbeit ausschließen und jeden Prüfkommentar beantworten Halte öffentliche Beitragsaktivitäten nachvollziehbar mit genehmigter Arbeit verbunden und vermeide doppelte Arbeit. ### Vor der Umsetzung - Bestätige, dass der Vorgang eingeordnet und zugewiesen ist und bei nicht trivialer Arbeit ein abgestimmtes Vorgehen unterstützt wird. - Prüfe vor der Vorbereitung einer für die Durchsicht bestimmten Änderung mit Nur-Lese-Suchen die Besprechung des Vorgangs, offene Änderungen mit Verweis auf den Vorgang und offene Änderungen im selben Bereich. - Bereite keine doppelte Änderung vor, wenn eine offene Änderung die Arbeit bereits abdeckt. Erkläre einen wesentlich anderen Ansatz in einem Entwurf für die Besprechung des Vorgangs. - Formuliere für Erkundungsarbeiten einen Vorgangskommentar, der Entwicklungszweig und einschlägige Dateien beschreibt, anstatt einen öffentlichen Änderungsantrag zu eröffnen. ### Einreichung und Durchsicht - Befolge die Titel- und Versionseintragsregeln des Projektarchivs. - Füge Titeln oder Nachrichten zu Versionseinträgen keine Kennzeichnungen künstlicher Intelligenz hinzu und führe Werkzeuge oder Softwareassistenten nicht als Mitverfasser auf. - Bearbeite oder beantworte jeden offenen Durchsichtskommentar, bevor du die Projektverantwortlichen um Durchsicht bittest. - Schließe den Gesprächsfaden einer anderen prüfenden Person nicht in deren Namen und versieh die eigene Änderung nicht mit Bereitschaftskennzeichnungen, sofern die Richtlinie dies nicht ausdrücklich erlaubt. - Behandle Feststellungen automatisierter und menschlicher Durchsichten als Behauptungen, die am tatsächlichen Programmpfad zu prüfen sind, und nicht als automatisch richtige Anweisungen. ## Die Dokumentation anpassen, wenn sich sichtbares Verhalten ändert Halte die Dokumentation mit dem für Nutzende sichtbaren Verhalten im Einklang und stelle begrenzte Beispiele nicht als allgemeine Unterstützung dar. ### Dokumentationspflichten - Aktualisiere die einschlägige Dokumentation bei Änderungen an öffentlichen Schnittstellen, Einstellungssyntax, Beispielen, Installationsanforderungen oder anderem für Nutzende sichtbarem Verhalten. - Kennzeichne wahlfreie Anbindungen als wahlfrei, nenne erforderliche Pakete oder Funktionsgruppen, führe erwartete Arten von Zugangsdaten ohne deren Werte auf und erkläre den Anbindungsweg. - Nenne in Beispielen für Modelle oder Anbieter die Modellart, die Weiterleitungsweise, unterstützte Betriebsarten und bekannte Einschränkungen. - Bestätige anhand einer maßgeblichen Quelle, dass als aktuell dargestellte Bezeichner allgemein verfügbar sind. - Ändere ausgelieferte Standardparameter nicht nur im Rahmen einer Dokumentationsaktualisierung. ### Umstrukturierungen und erzeugte Inhalte - Füge bei einer genehmigten Umstrukturierung Charakterisierungstests hinzu oder aktualisiere sie, bevor du feine Verhaltensweisen änderst. - Bewahre die zum Nachweis unveränderten Verhaltens verwendete Gleichwertigkeitsprüfung, wenn vorhandene Prüfungen den umstrukturierten Pfad nicht abdecken. - Bearbeite erzeugte Dokumentation oder erzeugte Erzeugnisse nicht von Hand. Nutze den Projektablauf nur, wenn die Aufgabe die Neuerzeugung erlaubt. - Führe keine Dokumentationserzeuger aus, von denen bekannt ist, dass sie Dateien vormerken oder umfangreiche Prüfungen auslösen, sofern dies nicht ausdrücklich verlangt und von sachfremden Änderungen abgeschottet ist. ## Gegen die Merge-Base prüfen und nur Belegtes melden Prüfe die abgeschlossene Änderung anhand der richtigen Ausgangsbasis und bestätige jede Aussage, bevor du sie als bereit erklärst. ### Reihenfolge der Durchsicht 1. Vergleiche den Entwicklungszweig mit der im Projektarchiv eingerichteten Zusammenführungsbasis. 2. Untersuche sowohl die Umsetzung als auch die Prüfungen, die sie praktisch erproben. 3. Führe vor der gegliederten Durchsicht die verbindlichen Formatierungs-, Stil-, Lizenz- und Typprüfungen aus, damit die Zeilenpositionen stabil bleiben. 4. Führe eine gegliederte Quelltextdurchsicht durch und ergänze bei Änderungen an Authentifizierung, Eingabeverarbeitung, Rückumwandlung aus einer Datenform oder externen Aufrufen eine Sicherheitsprüfung. 5. Prüfe jede Feststellung anhand des tatsächlichen Ausführungspfads. 6. Berichtige bestätigte Feststellungen, wiederhole die betroffenen Prüfungen und die Durchsicht, bis kein bestätigtes Problem mehr besteht. ### Abschlusskriterien Berichte geänderte Dateien, ausgeführte Prüfungen, beobachtete Ergebnisse, ausgelassene Prüfungen, ungelöste Risiken und weiterhin notwendige menschliche Handlungen. Behaupte ohne unmittelbare Belege weder Bereitschaft zur Durchsicht noch Genehmigung, Vereinbarkeit oder erfolgreiche Prüfung.