KI-erstellte Pull Requests mit menschlicher Prüfung an ein quelloffenes Framework senden

## KI-Arbeit kennzeichnen und nur in selbst erstellte Zweige pushen Behandle externe Schreibvorgänge, die Zuständigkeit für Arbeitstickets, Zweige und Urhebernennung als kontrollierte Handlungen. - Kennzeichne Beschreibungen von Zusammenführungsanfragen, Prüfungskommentare und Kommentare in Arbeitstickets eindeutig als KI-generiert und nenne die menschliche verantwortliche Person, wenn das Projekt dies verlangt. - Ermittle die Identität der verantwortlichen Person oder des Urhebers über eine authentifizierte Quelle. Errate niemals eine Identität; lass den Namen weg, wenn die Abfrage fehlschlägt. - Ergänze bei KI-gestützten Änderungseinträgen die vorgeschriebene Mitautorenschaftszeile. - Öffne nicht mehr als 10 Zusammenführungsanfragen pro verantwortlicher Person und Tag, wenn dies die Projektgrenze ist; bevorzuge wenige vollständige, gründlich getestete Änderungen. - Bearbeite nur geeignete, nicht zugewiesene Arbeitstickets. Weise das Ticket vor der Umsetzung der verantwortlichen Person zu und versetze es in den aktiven Zustand. - Übertrage Änderungen nur in einen Zweig, den der Agent selbst erstellt hat. Übertrage ohne ausdrückliche Erlaubnis nichts in den Zweig eines Mitwirkenden. - Bevorzuge eine persönliche Abspaltung, statt das übergeordnete Quellcodearchiv mit unbereinigten Zweigen zu füllen. Verwende einen aussagekräftigen Zweignamen mit Thema und Ticketkennung und lösche den Zweig nach Zusammenführung oder Ablehnung. Halte die Metadaten der Zusammenführungsanfrage aktuell. Aktualisiere nach jeder Übertragung Titel und Beschreibung, damit sie weiterhin den vollständigen Änderungssatz richtig wiedergeben. ## Vor Codeänderungen die Codehistorie und frühere Tickets lesen Gehe nicht davon aus, dass auffällig wirkender Code fehlerhaft ist. Langlebige Systeme enthalten oft frühere Einschränkungen, die in der aktuellen Implementierung nicht sichtbar sind. 1. Reproduziere und bestätige das gemeldete Problem; hinterfrage unvollständige oder falsche Annahmen. 2. Untersuche Dateiverlauf und zeilenbezogene Urheberdaten. Lies anschließend einschlägige Beschreibungen von Änderungseinträgen und verknüpfte Arbeitstickets, um den Grund für den Code zu verstehen. 3. Suche nach verwandten Arbeitstickets, um abgelehnte Ansätze, frühere Diskussionen und absichtliche Entscheidungen zu finden. 4. Lies die Entwurfsdokumente des betroffenen Bereichs, besonders zu Sicherheit, Telemetrie, Protokollkontext und öffentlichen Benennungsverträgen. 5. Wenn ein Modul ein anderes ersetzt hat, unterscheide beabsichtigte Änderungen von versehentlichen Auslassungen. 6. Wenn die vorgeschlagene Korrektur eine frühere absichtliche Änderung rückgängig macht, halte an und überdenke sie. Bleibt die Rücknahme gerechtfertigt, erkläre, warum sie trotz der ursprünglichen Begründung nötig ist. Lege der verantwortlichen Person vor der Umsetzung Erkenntnisse, Risiken, Unklarheiten und die mögliche Ungültigkeit des Problems dar. Wende bei der Prüfung einer Zusammenführungsanfrage dieselbe Sorgfalt an. Überprüfe aktuelle Versionen, Veröffentlichungen und Verhaltensweisen externer Abhängigkeiten anhand maßgeblicher Quellen. Stelle niemals allein aufgrund des Trainingswissens des Modells verbindliche Behauptungen über veränderliche externe Projekte auf. ## Feste Wartezeiten in Tests durch Warten mit Zeitlimit ersetzen Verwende in Tests niemals feste Wartezeiten. Sie machen Tests langsam, instabil und nicht deterministisch. - Wenn eine Komponente eigene zeitbegrenzte Prüfanweisungen besitzt, verwende sie für Bedingungen, die sie bereits ausdrücken kann. - Verwende für andere Bedingungen ein asynchrones Wartewerkzeug, etwa um vor der nächsten Handlung einen Zwischenzähler abzuwarten. - Umschließe eine eigene blockierende Prüfanweisung nicht mit einem Abfragewerkzeug; dies fügt um eine vorhandene Synchronisationssperre redundante Abfragen hinzu. - Setze bei einem Wartewerkzeug immer eine ausdrückliche maximale Zeitüberschreitung. - Verwende eine geprüfte Bedingung oder ein klares Prädikat, niemals eine aktive Warteschleife. - Wenn du einen vorhandenen Test mit fester Wartezeit änderst, stelle ihn auf die eigene zeitbegrenzte Prüfanweisung oder das allgemeine Wartewerkzeug um. Beispielsweise wartet `MockEndpoint.assertIsSatisfied()` bereits intern, während Awaitility für Bedingungen geeignet ist, die `MockEndpoint` nicht ausdrücken kann. Neue Tests dürfen `Thread.sleep()` nicht einführen. ## Festlegen, wem vertraut wird, und Schwachstellen nur vertraulich melden Entscheide anhand des maßgeblichen Bedrohungsmodells des Projekts, wem vertraut wird, wo Vertrauensgrenzen liegen und was in die Verantwortung des Rahmenwerks fällt. - Betrachte Codeautoren und Bereitstellungsverantwortliche als vertrauenswürdig, wenn sie absichtlich ausführbare Routen, Ausdrücke, vertrauliche Werte, Netzwerkfreigaben und Laufzeiteinstellungen konfigurieren. - Betrachte externe Nachrichtenabsender und alle Daten, die durch eine vertrauenswürdige Route fließen, als nicht vertrauenswürdig. - Das Rahmenwerk selbst darf als nicht vertrauenswürdig eingestufte Daten nicht eigenständig in Codeausführung, Dateizugriffe, Anfragefälschung oder Umgehung der Berechtigungsprüfung verwandeln. - Absichtliche Codeausführung durch einen vertrauenswürdigen Autor, Fehlkonfiguration durch den Betreiber und gefährliches Verhalten nach ausdrücklicher Aktivierung sind für sich allein keine Schwachstellen des Rahmenwerks. Gültige Befunde weisen einen Bruch der Vertrauensgrenze in einer Standardkonfiguration oder einer vernünftigerweise erwarteten Konfiguration nach. Typische Klassen sind unsichere Deserialisierung, XXE, Ausdrucksinjektion, Pfadüberschreitung, SSRF, Missbrauch der kopfzeilengesteuerten Weiterleitung, Umgehung von Authentifizierung oder Autorisierung, Offenlegung vertraulicher Werte, unsichere Voreinstellungen und Injektion in vom Rahmenwerk erstellte Abfragen. Ressourcenerschöpfung ohne erforderliche Begrenzungen, absichtlich freigegebene Verwaltungsoberflächen, nicht erreichbare Befunde in transitiven Abhängigkeiten und Ausgaben automatischer Prüfwerkzeuge ohne Beleg eines Grenzbruchs liegen normalerweise außerhalb des Zuständigkeitsbereichs des Rahmenwerks. Lege eine vermutete Schwachstelle niemals in einem öffentlichen Arbeitsticket, einer Zusammenführungsanfrage, einer Verteilerliste oder einem anderen öffentlichen Kanal offen. Befolge das vertrauliche Meldeverfahren und stelle die öffentliche Arbeit ein. ## Nicht vertrauenswürdige eingehende Daten blockieren und riskante Sicherheitsvorgaben deaktiviert lassen Prüfe jeden Nachrichtenkonsumenten, Syntaxanalysierer, jedes Datenformat, jeden Typkonverter, Aggregationsspeicher und jede sicherheitsrelevante Option anhand konkreter Missbrauchspfade. - Filtere interne Kopfzeilen des Rahmenwerks vor der Weiterleitung mit einer strengen, groß- und kleinschreibungsunabhängigen Strategie aus nicht vertrauenswürdigen eingehenden Nachrichten. - Deserialisiere nicht vertrauenswürdige Objekte nicht ohne einen geeigneten Eingabefilter. - Kennzeichne vertrauliche Werte in den Metadaten als geheim und ordne unsichere Konfigurationsschalter ihrer Risikofamilie zu. - Lass sicherheitsrelevante Voreinstellungen gesperrt, sofern sie nicht ausdrücklich aktiviert werden. Eine Lockerung erfordert einen Aktualisierungshinweis und die ausdrückliche Zustimmung eines Betreuers. - Überprüfe, dass Optionen für Authentifizierung und Autorisierung Aussteller, Zielgruppe, Signatur und jeden angekündigten Unterpfad tatsächlich so prüfen, wie sie es zusagen. Verwende bei Bereitstellungen das Sicherheitsprofil für den Produktivbetrieb, löse vertrauliche Werte über einen genehmigten Geheimnisspeicher auf, konfiguriere verifiziertes TLS, deaktiviere unsichere Serialisierung bei nicht vertrauenswürdigen Konsumenten und beschränke Verwaltungskonsolen sowie Laufzeitverwaltung auf vertrauenswürdige Netzwerke. Die Sicherheitsprüfung muss das Verhalten vertrauenswürdiger Routen vom Verhalten des Rahmenwerks unterscheiden und zugleich verhindern, dass nicht vertrauenswürdige Daten die Grenze überschreiten. ## Jede Änderung mit Tests und Doku liefern und erzeugte Dateien committen Jede Funktion oder Fehlerkorrektur muss passende Tests und benutzersichtbare Dokumentation enthalten. Dokumentiere geänderte Voreinstellungen, Erkennungsverhalten, umbenannte oder entfernte Optionen, Änderungen an Kopfzeilen, API- oder SPI-Änderungen, veraltete Funktionen und Migrationen im einschlägigen Leitfaden. - Führe für den geänderten Bereich die kanonischen Prüfungen des Quellcodearchivs für Formatierung, Importreihenfolge, Stil, Einheiten-, Integrations- und Quellcodeprüfung aus. - Erzeuge generierte Artefakte neu und nimm sie in einen Änderungseintrag auf; überlasse es nicht der kontinuierlichen Integration, diese Änderungen erstmals zu entdecken. - Vermeide neue Befunde der statischen Analyse, Verschlechterungen der Wartbarkeit, verbreitete Schwachstellenmuster und veraltete Programmierschnittstellen, selbst wenn eine lokale Prüfung nicht jedes Analysewerkzeug ausführt. - Importiere Klassen und verwende einfache Namen statt vollständig qualifizierter Klassennamen, außer wenn zwei Klassen denselben einfachen Namen besitzen. Bewahre ausdrückliche Ausnahmen für generierten Code. - Ergänze bei jedem neuen öffentlichen API-Typ und jeder neuen öffentlichen Methode die vorgeschriebene Einführungsversion, verwende die bevorstehende Veröffentlichungsversion und platziere sie nach den anderen Dokumentationsmarkierungen. - Aktualisiere alle Metadatenregister, die verschachtelte Erweiterungen erkennen; ein Quellverzeichnis allein macht eine Erweiterung nicht zwingend für Erstellungsläufe, Kataloge oder erzeugte Dokumentation sichtbar. - Überprüfe bei Behältern für Integrationstests jede unterstützte Architektur. Verwende eine genehmigte Registerspiegelung oder ausdrückliche architekturspezifische Ausnahmen, wenn kein Abbild verfügbar ist. - Verwende für interne Seiten interne Dokumentverweise und überprüfe versionsübergreifende Sprungmarken anhand des veröffentlichten Ziels, nicht nur anhand des Entwicklungszweigs. Wenn eine Funktion als veraltet gekennzeichnet wird, aktualisiere Erstellungsmetadaten, API-Anmerkungen, Dokumentationstitel und Aktualisierungsleitfaden gemeinsam. ## Vor dem Zusammenführen zwei Prüfende anfragen und eine menschliche Freigabe einholen Fordere eine Prüfung nur an, wenn die Zusammenführungsanfrage prüfbereit ist, niemals während sie als Entwurf geführt wird. - Ermittle einschlägige aktive Betreuer anhand des jüngsten Dateiverlaufs und der zeilenbezogenen Urheberdaten und fordere mindestens 2 geeignete Prüfer an. - Fordere nach der Bearbeitung aller Kommentare und erfolgreichen Prüfungen die vorhandenen Prüfer erneut zur Prüfung auf. - Führe niemals zusammen, solange noch ein Prüfungsgespräch ungelöst ist. - Verlange mindestens 1 menschliche Zustimmung und genehmige niemals die eigene Zusammenführungsanfrage des Agenten. - Leite den Veröffentlichungsmeilenstein aus dem Zielzweig ab und setze sowohl Meilenstein als auch Korrekturversion des Arbeitstickets, bevor du das Ticket schließt. - Ermittle den Autor der Zusammenführungsanfrage programmatisch, weise Anfrage und Arbeitsticket richtig zu und wende die durch Ticket und Änderung belegte Kategorienmarkierung an. - Stelle Veröffentlichung und Zusammenführung hinter eine einzige erfolgreiche Kette aus Formatierungs-, Typ-, Stil-, Test- und Sicherheitsprüfungen. - Bewahre die vorgeschriebene KI-Mitautorenschaft im endgültigen Zusammenführungseintrag. - Schließe nach der Zusammenführung das Arbeitsticket mit Korrekturversion und Verweis auf die Zusammenführungsanfrage ab und lösche den Zweig. Fasse benutzersichtbares Verhalten, aussagekräftige Validierung, Dokumentationsauswirkungen, ungelöste Risiken und jede nicht ausführbare Prüfung zusammen. Ein lokaler Test belegt keinen Erfolg der kontinuierlichen Integration, und unvollständige Nachweise rechtfertigen keine Veröffentlichungsbereitschaft.