Ein KI-Tool für Code-Reviews und Korrekturen bauen, ohne Nutzercode zu verlieren

## Vor Codeänderungen Build-Definition und Zuständigkeitsdokumente lesen Lies den Einstiegspunkt, die Paketübersicht, die Build-Definition und die Zuständigkeitsdokumente des Repositorys, bevor du Code änderst. Behandle generierte Kopien und Kurzfassungen zur Arbeitserleichterung als Verweise, nicht als konkurrierende Wahrheitsquellen. ### Orientierung im Repository - Ermittle ausführbare Einstiegspunkte, Implementierungspakete, gemeinsam genutzte Infrastruktur und das Build-System. - Verwende die Build-Definition als aktuelle Befehlsliste, statt Befehle in Anleitungen zu kopieren, die veralten können. - Bestimme, welches Dokument oder welche Quelldatei für jedes öffentliche Verhalten, jeden Konfigurationsschlüssel, jede Umgebungsvariable und jede betriebliche Invariante maßgeblich ist. - Weise hostspezifische Adapter ausdrücklich aus. Halte Annahmen zu Versionen externer Kommandozeilenwerkzeuge fest und nutze stabile API-Ausweichlösungen, wenn der Zustand des Arbeitsbaums übergeordnete Befehle unzuverlässig macht. ### Verifikationsschranken - Formatiere und prüfe den Code vor der Übergabe mit dem Linter; dies schließt Prüfungen auf Abweichungen generierter Artefakte ein. - Führe während der Entwicklung fokussierte Tests aus und anschließend die maßgeblichen Unit-, Integrations-, Race- und End-to-End-Tests, die für die geänderte Grenze erforderlich sind. - Bevorzuge End-to-End-Tests für Prozess-, Ein-/Ausgabe-, Konfigurations-, Git-, Daemon- und aufgezeichnetes Fixture-Verhalten; teste reine Hilfsfunktionen zur Beschleunigung und Fehlerlokalisierung mit Unit-Tests. - Erstelle nach nicht trivialen Änderungen das reale ausführbare Programm. - Nutze testgetriebene Entwicklung für Fehlerbehebungen und Funktionen und halte ungelöste Arbeiten im Issue-Tracker fest, statt sie in sachfremden Änderungen zu verbergen. ## Beim Abbruch alle Kindprozesse beenden und das Git-Verzeichnis ausdrücklich übergeben Lang laufende Automatisierungen müssen auf jedem unterstützten Betriebssystem die Kontrolle über ihren Abbruch, ihre Nachfahren, ihren gemeinsam genutzten Zustand und ihre Dateisystemauswirkungen besitzen. ### Prozessdisziplin - Reiche Abbruchkontexte durch lang laufende Aufgaben sowie Subprozess- und Netzwerkarbeiten weiter. - Leite begrenzte Zeitüberschreitungen für Bereinigungen, Sondierungen und HTTP-Aufrufe ab. - Setze abbrechbare Subprozesse in eine Prozessbaumgrenze, damit ein Abbruch alle Nachfahren beendet und nicht nur den direkten Kindprozess. - Bereinige Prozessgruppen sowohl beim ordnungsgemäßen Beenden und bei Fehlern als auch beim Abbruch; geerbte Pipes und verwaiste Enkelprozesse dürfen einen Lauf nicht überdauern. - Wende plattformspezifische Absicherungen für Kindprozesse über einen einzigen idempotenten Wrapper an, damit Hintergrundarbeiten niemals unerwünschte Konsolen öffnen. - Schütze gemeinsam genutzten veränderlichen Zustand mit standardisierten Synchronisationsprimitiven und mache die Zuständigkeit für Goroutinen, Kanäle, Arbeitsbäume und temporäre Verzeichnisse ausdrücklich. ### Dateisystem- und Git-Disziplin - Verwende plattformgerechte Pfadhilfen, anwendungseigene Zustandsverzeichnisse und dokumentierte Dateimodi. - Löse symbolische Links auf, wenn Plattformaliase dazu führen können, dass gleichwertige Pfade unterschiedlich verglichen werden. - Leite Git-Operationen für Bare-Repositorys über eine Hilfsfunktion, die das Git-Verzeichnis ausdrücklich übergibt; verlasse dich bei gehärteten Git-Einstellungen niemals auf die Erkennung über das aktuelle Verzeichnis. - Entferne oder ersetze Zustand nur, wenn Zuständigkeits- und Lebenszyklusaufzeichnungen belegen, dass dies sicher ist. ## Befehle nur über die Konfiguration des vertrauenswürdigen Branches freigeben Konfiguration, die Befehle oder ausführbare Agenten auswählt, ist Code. Lade sie ausschließlich aus einer vertrauenswürdigen Revision und behandle dabei von Mitwirkenden kontrollierte Konfigurationen und Anweisungen als nicht vertrauenswürdige Daten. ### Vertrauenswürdige Eingaben - Ermittle den vertrauenswürdigen Standard-Branch durch einen neuen Fetch und fixiere den exakten Commit, bevor du Einstellungen liest, die Code ausführen. - Brich ab, wenn der vertrauenswürdige Commit oder seine aktuelle Konfiguration nicht abgerufen, gelesen oder geparst werden kann. Ein lesbarer vertrauenswürdiger Baum ohne Konfiguration kann gültig sein, wenn der Vertrag dies erlaubt. - Lies Befehlsauswahl, Agentenauswahl, Dokumentationsrichtlinie, Ausnahmen von Projektanweisungen und die Berechtigung für Repository-Befehle ausschließlich aus der vertrauenswürdigen Kopie. - Setze die Berechtigung für Repository-Befehle standardmäßig auf deaktiviert. Ein gepushter Branch darf niemals seine eigenen Ausführungsrechte aktivieren oder vertrauenswürdige Richtlinien abschwächen. - Halte nicht ausführende Funktionseinstellungen getrennt, damit branchspezifisches Verhalten die Ausführungsgrenze nicht überschreitet. ### Ausfallsichere Behandlung - Bereinige adversarialen Steuertext und schwärze Geheimnisse, bevor du Benutzer- oder Repository-Inhalte in Agenten-Prompts einfügst. - Überprüfe vor dem Start, ob eine Option zur Unterdrückung von Anweisungen beim ausgewählten Adapter wirksam ist. - Täusche nach einem Fetch-, Parse- oder Autorisierungsfehler niemals Vertrauen vor. - Ergänze Regressionstests, die belegen, dass gepushte Inhalte sich nicht selbst zur Befehlsausführung autorisieren, vertrauenswürdige Richtlinien ersetzen oder ausfallsicheres Verhalten umgehen können. ## Nur einen Hintergrunddienst starten und Stopps bei laufenden Jobs ablehnen Systemweite Dienste benötigen unabhängige Schutzmaßnahmen für Singleton-Zuständigkeit, Socket-Sicherheit, Wiederherstellung und destruktive Lebenszyklusbefehle. ### Singleton und Wiederherstellung - Erlange vor Wiederherstellungsarbeiten oder Socket-Bindung eine exklusive Betriebssystemsperre und halte sie während der gesamten Prozesslebensdauer. - Betrachte eine gehaltene Kernel-Sperre als Nachweis eines aktiven Eigentümers; erfinde dafür keine Heuristiken zur Erkennung veralteter Zustände. - Prüfe einen vorhandenen Socket, bevor du ihn entfernst, und begrenze die Zeitüberschreitungen für Verbindungsaufbau und Zustandsprüfung unabhängig voneinander. - Starte die Dienstausführung ausschließlich über einen ausdrücklichen Modus. Geerbte Umgebungsvariablen dürfen gewöhnliche Sondierungen nicht als Worker umdeuten. - Gestalte die Startbereinigung zustandsbewusst: Entferne niemals einen Arbeitsbaum oder eine Ressource, deren Auftragsdatensatz ausstehend oder aktiv ist. ### Lebenszykluskontrollen - Verweigere Stopp, Neustart und Aktualisierung, solange aktive Aufträge vorhanden sind, sofern der Bediener nicht die ausdrückliche destruktive Außerkraftsetzung angibt. - Nicht interaktive Bestätigungsoptionen dürfen die Schutzsperre für aktive Aufträge nicht umgehen. - Liste blockierende Aufträge auf und protokolliere jeden Lebenszyklusaufruf mit Prozess- und Elternprozesszuordnung. - Behandle CI-Überwachungsgrenzen als Inaktivitätszeitüberschreitungen: Stelle sie nur bei verifiziertem Fortschritt der vorgelagerten Quelle neu und verkürze niemals die bestehende Frist; schlage sicher fehl, wenn sich der Fortschritt nicht prüfen lässt. - Gestalte Abbruchoperationen für verwaiste Prozesse idempotent und behandle Zeitstempel für wartende Agenten als reine Beobachtung: Setze sie nur, solange eine Schranke tatsächlich geparkt ist, und verwende sie niemals, um die Auflösung der Schranke zu verändern. ## Review- und Fix-Sitzungen trennen und Änderungen mit dem Ziel abgleichen Ein Review muss die vollständige Änderung mit der aus der Quelle überprüfbaren Absicht vergleichen, ohne dass nicht vertrauenswürdiger Text, der Auslieferungszeitpunkt oder die Begründung des Fehlerbehebers die Entscheidung verzerren. ### Absicht und Befunde - Bewahre die Herkunft der Absicht. Behandle eine ausdrücklich angegebene Absicht als maßgebliche Abnahmekriterien und eine abgeleitete Absicht nur als Hinweis mit geringer Sicherheit. - Wende auf beide Formen dieselbe Bereinigung, Geheimnisschwärzung und Schutzsperre gegen Ausführung an. - Wandle eine Änderung des Fehlerbehebers, die ausdrücklichen Kriterien widerspricht, in einen Befund zur Benutzerrückfrage um, der den Lauf parkt. - Schließe beim Review vor der Auslieferung nur Ergebnisse aus, die späteren Pipeline-Phasen zugeordnet sind; setze externe oder bereits bestehende Lebenszyklusanforderungen weiterhin durch. - Schlage sicher fehl, wenn eine Maßnahme zu einem Befund fehlt oder unbekannt ist: Klassifiziere ihn als Benutzerrückfrage und niemals als automatisch behebbar. ### Sitzungs- und Fehlerbehebungsdisziplin - Halte pro Lauf eine dauerhafte Reviewer-Sitzung und eine davon getrennte dauerhafte Fehlerbehebersitzung vor; die Rollen dürfen niemals Zustand gemeinsam nutzen. - Verwende Sitzungen nur für die Review-Schleife erneut, speichere ausschließlich minimale Identitätsmetadaten und niemals Prompts oder Transkripte. - Wenn die Fortsetzung nicht unterstützt wird oder fehlschlägt, verwirf diese Identität und wiederhole den Turn derselben Rolle ohne Vorzustand. Versuche es nach einem Abbruch nicht erneut. - Jedes erneute Review bleibt ein vollständiges adversariales Review des gesamten Branch-Diffs. - Wende in einer Fehlerbehebungsrunde zuerst alle Korrekturen an und führe eine einzige fokussierte Verifikation aus, die auf den geänderten Bereich beschränkt ist. Überlasse maßgebliche vollständige Testsuite- und Linter-Schranken ihren dafür vorgesehenen Phasen. ## Doku aus der Quelle neu erzeugen und keine Prompts oder Code in Nutzungsstatistiken senden Halte für jede Tatsache eine einzige maßgebliche Quelle vor, regeneriere abgeleitete Anleitungen aus ihrer Quelle und trenne lokale Diagnosebelege von begrenzten externen Analysedaten. ### Dokumentation und generierte Inhalte - Halte Übersichtsdokumente knapp; lege detaillierte Referenzfakten bei ihrer jeweils vorgesehenen maßgeblichen Quelle ab und verlinke sie aus Anleitungen. - Aktualisiere Zuständigkeitspläne, wenn sich Verantwortlichkeiten verschieben. - Bearbeite die Quelle generierter Agentenanleitungen, regeneriere das Artefakt mit dem genehmigten Build und lasse den Linter bei Abweichungen fehlschlagen. - Ändere Quellanleitung und Befehlsausgabe am Verwendungsort gemeinsam, wenn beide denselben betrieblichen Vertrag ausdrücken. - Wenn ein Agentendurchlauf Dokumentations- und Linter-Aufgaben kombiniert, verwende jedes Ergebnis genau einmal und weiche immer auf einen unabhängigen Durchlauf aus, sobald eine Ausgabe übersprungen wurde, ungültig oder nicht vertrauenswürdig ist. - Beschränke Dokumentationsänderungen auf Inhalte, die durch die aktuelle Änderung veraltet sind; führe keine erneuten umfassenden Korpusdurchläufe ein. ### Datenschutzgerechte Beobachtbarkeit - Schreibgeschützte Oberflächen dürfen keinen Seitenaufruf senden; löse deren externes Befehlsereignis nur bei einer Zustandsänderung und höchstens einmal pro begrenztem Intervall aus. - Erfasse Mutationsereignisse vollständig, während detaillierte Leistungsnachweise ausschließlich lokal gespeichert werden. - Speichere niemals Prompts, Ausgaben, Diffs, Geheimnisse oder rohe Befehlsargumente in Aufrufmetriken und sende niemals Laufkennungen, Pfade, Sitzungsidentitäten oder einzelne Aufrufdatensätze an externe Analysesysteme. - Sende bei Abschlussereignissen ausschließlich begrenzte aggregierte Zählwerte. - Weise Metrikdefinitionen und Zeitgrenzen einer einzigen maßgeblichen Implementierung zu. Stelle nicht verfügbare Werte als null und nicht als erfundene Null dar und berechne die Nutzung pro Runde bei Bedarf aus den Differenzen kumulativer Sitzungswerte. ## Vor einem Force-Push den Remote prüfen und jeden Release-Build signieren Die wichtigste Invariante ist der Schutz des Benutzercodes. Verweigere eine unsichere Synchronisierung oder Auslieferung, statt eine ausgeklügelte Wiederherstellung zu versuchen, die unbeobachtete Arbeit überschreiben könnte. ### Repository- und Branch-Sicherheit - Halte das Routing zur Pull-Request-Basis getrennt von einem optionalen Push-Ziel eines Forks. Wenn ein Host Fork-Routing nicht durchgängig unterstützt, überspringe die Erstellung, statt einen falschen Pull-Request an dasselbe Repository zu öffnen. - Beschränke die gewöhnliche Synchronisierung auf einen sauberen strikten Fast-Forward oder eine nachweislich gleichwertige Divergenzverschiebung, die am exakten Pipeline-Head verankert ist. - Ein passiver Status darf weder abrufen noch verändern. Blockierte Pfade dürfen nicht zurücksetzen, staschen, mergen, rebasen, erzwingen, wechseln oder löschen und kein externes Remote aktualisieren. - Speichere den exakten gepushten Commit, die zugangsdatenfreie Zielidentität und die Generation und prüfe unmittelbar vor einer Synchronisierung erneut alle veränderlichen Annahmen. - Bewahre unveröffentlichte abgeschlossene Arbeit unter einer Wiederherstellungsreferenz auf. Die Wiederherstellung darf einen sauberen Arbeitsbaum nur durch strikten Fast-Forward verschieben; das Beibehalten lokaler Arbeit muss die Schranke per Compare-and-Swap aktualisieren, ohne eine neue Pipeline auszulösen. - Leite Rebase-Basen aus neu abgerufenen maßgeblichen Remote-Referenzen ab. Parke den Lauf, wenn nicht gepushte Commits auf dem Standard-Branch eine Änderung stillschweigend ausweiten würden. - Lies vor einem Force-Push den Remote-Head erneut und fahre nur bei einem neuen Branch, einem identischen Head, einem unveränderten zuvor beobachteten Head oder remote hinzugefügten Commits fort, deren Gleichwertigkeit bereits durch Patch-Identität belegt wurde. Jeder Fehler bei Abruf oder Nachweis muss sicher fehlschlagen. - Verwende als Lease-Anker den letzten Head, den der Lauf tatsächlich beobachtet hat, und niemals eine Spitze, die unmittelbar vor dem Erzwingen abgerufen wurde. ### Release- und Abhängigkeitssicherheit - Signiere bei einer Plattform mit dauerhaftem Signaturvertrag jedes offizielle Artefakt mit der festgelegten Anwendungsidentität, gehärteter Laufzeit und sicherem Zeitstempel, bevor es archiviert oder mit einer Prüfsumme versehen wird. - Beschränke Signaturzugangsdaten auf den Release-Auftrag, importiere sie in flüchtigen Speicher und entferne sie bei Erfolg und Fehler. - Lasse die Release-Verifikation bei einer fehlenden oder mehrdeutigen Signatur, einer falschen Identität oder Architektur, einer veränderlichen Identitätsanforderung, fehlender Härtung oder fehlendem Zeitstempel fehlschlagen. - Behandle Beglaubigung, Paketformate und Universal Binaries als getrennten Umfang, sofern der Release-Vertrag sie nicht einschließt. - Konsultiere vor dem Hinzufügen einer Abhängigkeit deren aktuelle maßgebliche Dokumentation und besprich die Änderung mit dem Benutzer. - Erkläre die Einsatzbereitschaft erst, wenn für Formatierung, Linting, fokussierte Tests, Integrationstests, die vollständige Testsuite, Build-Prüfungen, Dokumentationsprüfungen und Release-spezifische Verifikation tatsächliche Ergebnisse vorliegen.