Eine Codebasis mit mehreren Paketen ändern, ohne Funktionierendes kaputtzumachen
Für eine KI, die ein Repository mit mehreren Paketen bearbeitet. Sie klärt zuständiges Paket und Regeln, erhält bisheriges Verhalten und öffentliche Namen, ergänzt Tests und Dokumentation, fragt vor neuen Abhängigkeiten nach Genehmigung und berichtet Prüfungen und offene Risiken.
Diese KI-Regeln verwenden
## Vor dem Bearbeiten das zuständige Paket und seine Regeln klären
Bestimme vor der Bearbeitung das Stammverzeichnis des Quelltextbestands, das für das Verhalten zuständige Paket oder Teilsystem und die nächstgelegenen anwendbaren Anweisungen für Mitwirkende.
- Ordne die Arbeit dem kleinsten richtigen Geltungsbereich zu.
- Lies die für diesen Bereich benötigten Unterlagen zu lokaler Architektur, Konventionen, Erstellung und Prüfung.
- Verwende für ein einzelnes Symbol eine gezielte Suche und für dateiübergreifende Aufrufer, Importe, Auswirkungen von Umbenennungen oder einen großen Änderungsradius einen verfügbaren Abhängigkeitsgraphen.
- Bestätige Laufzeit- und Paketverwaltungsversionen, Arbeitsbereichsdefinitionen und Voraussetzungen für die Erstellung anhand der versionierten Konfiguration.
- Betrachte verknüpfte oder erzeugte Anweisungsdateien als Ansichten ihrer angegebenen maßgeblichen Quelle und bearbeite nur die Quelldatei.
Wenn Anweisungen einander widersprechen oder die Zuständigkeit unklar ist, halte vor dem Schreiben an und benenne den genauen Widerspruch. Ändere während der Untersuchung keine unbeteiligten Pakete.
## Bisheriges Verhalten und öffentliche Namen erhalten und die Architektur beachten
Vermeide Beeinträchtigungen bestehender Nutzer. Ändere keinen Vorgabewert und entferne keinen öffentlichen Namen, sofern die genehmigte Änderung dies nicht ausdrücklich verlangt. Halte bisherige Namen funktionsfähig und verbinde die Kennzeichnung als veraltet mit einem dokumentierten Übergang und Tests für das bisherige Verhalten.
Beachte die bereits im Quelltextbestand verankerte Architektur:
- halte Verhalten innerhalb der zuständigen Schicht oder Erweiterungsgrenze;
- bewahre die Funktionsgleichheit offizieller Adapter, wenn sich der Kernvertrag ändert;
- erhalte abgestufte Konfiguration und öffentliche Anpassungsverträge;
- bereinige nutzergesteuerte Inhalte und vermeide Verschmutzung des globalen Namensraums;
- unterstütze die festgelegten Anforderungen an Internationalisierung und Barrierefreiheit; und
- bevorzuge vorhandene Hilfsfunktionen und möglichst wenige Abhängigkeiten gegenüber parallelen Mechanismen.
Ist eine inkompatible Änderung unvermeidbar, weise deutlich darauf hin, erkläre den betroffenen Vertrag und biete einen Umstiegsweg an.
## Die kleinste Änderung vornehmen, mit Tests und Dokumentation
Nimm die kleinste zusammenhängende Änderung vor, die die Anforderung erfüllt. Befolge den im Paket etablierten Stil für Quelltext, Kommentare und Dokumentation.
Bei geändertem Verhalten:
1. Ergänze oder aktualisiere gezielte Einzeltests.
2. Ergänze passende Integrations-, Browser- oder durchgängige Systemtests, wenn das Verhalten eine Grenze überschreitet.
3. Führe erforderliche vorbereitende Erstellungsschritte vor den Tests abhängiger Pakete aus.
4. Führe die eng gefassten Befehle für Regel-, Typ-, Stil- und Funktionsprüfungen im betroffenen Bereich aus.
5. Aktualisiere öffentliche Leitfäden, Schnittstellenreferenzen, Beispiele, Umstiegshinweise oder Einträge im Änderungsprotokoll, wenn Nutzer die Änderung wahrnehmen können.
6. Aktualisiere bereichsbezogene Anweisungen für Mitwirkende nur dann, wenn die Änderung eine dauerhafte Konvention, einen Ort, eine Einschränkung oder eine wiederkehrende Stolperstelle schafft.
Behaupte keinen Abschluss, solange erforderliche Prüfabdeckung oder nutzergerichtete Dokumentation fehlt. Halte jede nicht ausführbare Prüfung und den konkreten Grund fest.
## Vor neuen Abhängigkeiten eine Genehmigung einholen und vor der Veröffentlichung prüfen
Hole vor dem Hinzufügen einer Abhängigkeit von Dritten die Genehmigung der für die Pflege zuständigen Person ein. Prüfe Lizenzen direkter und transitiver Abhängigkeiten, Pflegezustand, Sicherheitsfolgen, Bündel- oder Laufzeitkosten und ob der Quelltextbestand die Fähigkeit bereits bereitstellt.
Befolge die Konventionen des Quelltextbestands für Zweige, Änderungsanträge, Prüfungen und Änderungsprotokolle. Halte den Änderungsverlauf gut prüfbar, schreibe den gemeinsam genutzten Verlauf nicht um und trenne unbeteiligte Arbeiten. Bewahre bei mehrtägigen Arbeiten mit der genehmigten Zusammenarbeitsmethode des Quelltextbestands einen sichtbaren Zwischenstand.
Bestätige vor der Veröffentlichung, dass Kompatibilitätstests das alte und das neue Verhalten abdecken, die erforderliche Dokumentation vorhanden ist, erzeugte Ergebnisse aktuell sind und die vorgesehenen Paketvarianten oder Adapter geprüft wurden.
## Ausgeführte Tests und verbleibende Risiken berichten
Gib einen knappen Prüfbericht mit folgenden Punkten zurück:
- das geänderte Verhalten und seinen Umfang;
- betroffene Dateien oder Komponenten;
- ausgeführte Tests, Erstellungsschritte, Regel- und Typprüfungen mit ihren Ergebnissen;
- Überlegungen zu Kompatibilität und Sicherheit;
- Aktualisierungen an Dokumentation oder Änderungsprotokoll; und
- nicht ausgeführte Schritte, verbleibende Risiken und die nächste erforderliche Maßnahme.
Trenne bestätigte Ergebnisse von Annahmen. Hebe jede inkompatible Änderung oder unvollständige Pflichtprüfung vor nebensächlichen Einzelheiten hervor.