Vereinfachen der Änderung
Ein Bearbeitungsschritt durch den Autor der Änderung: Führe ihn auf deinem eigenen Branch aus, bevor du den PR öffnest, und erneut, bevor du große Reparaturen einschiebst. Er geht der Überprüfung voraus und ersetzt sie nie. Übernimmt den Umfang der Aufgabe und die Reparaturautorität; eine reine Überprüfungsanfrage erhält Ergebnisse anstelle von Bearbeitungen. Der gewählte Maintainer-Workflow besitzt die Veröffentlichung, Überprüfung und den Merge.
Der Diff ist ein Vorschlag. Bestandene Tests zeigen, dass er funktioniert, nicht dass seine Architektur oder jeder hinzugefügte Test notwendig ist.
Regeln: Der Abschnitt "Designprioritäten", "Ein Eigentümer, vollständige Umstellung", "Laufzeit- und Code-Sicherungen" und "Produkt und Validierung" von AGENTS.md im Stammverzeichnis sowie die nächstgelegene bereichsbezogene AGENTS.md. Die Schritte 2 und 3 wenden jede Regel auf jede geänderte Datei an.
1. Die kleinste vollständige Korrektur erneut ableiten
Lies das Ergebnis des Benutzers und den letzten Umfang, den vollständigen Diff gegen die Ziel-Merge-Basis und die beibehaltenen Nachweise. Verwende bereits gesammelten Sitzungskontext wieder. Frage dann:
Ausgehend von der Basis, was ist die kleinste vollständige Korrektur unter Verwendung der bereits vorhandenen Eigentümer? Würde ich diese Architektur immer noch einführen?
Prüfe zuerst die größten hinzugefügten Module, Zustände, Adapter und Testgerüste. Lies ihre direkten Aufrufer und relevante Historie: scheinbar redundantes Verhalten kann eine ausgelieferte Konfiguration oder eine frühere Regression schützen. Der Umfang ist das geänderte System und die Pfade, die es ersetzt.
Verfolge jeden geänderten Abschnitt bis zum genannten Ergebnis zurück. Ein Abschnitt, der einem anderen Ziel dient, verlässt diese Änderung: lösche ihn oder verschiebe ihn in einen eigenen PR.
Zähle die nicht-mechanischen geänderten Zeilen. Über etwa 800, oder etwa 500 für komplexe Logik, nenne die kleinste kohärente Stufe, die zuerst landen kann, und beschneide die Änderung auf diese Stufe.
Abgeschlossen, wenn du den Fehler, die erforderliche Invariante und die kleinste vollständige Korrektur jeweils in einem Satz angeben kannst, und jeder verbleibende Abschnitt dieser Korrektur dient.
2. Entferne unnötige Architektur
Wende jede unterstützte Vereinfachung im Diff an:
- Ein Entscheidungsverantwortlicher. Verschiebe wiederholte Aufruferseiten-Policy in die Operation, die die Entscheidung besitzt. Migriere betroffene Aufrufer und entferne die alten Implementierungen, Exporte und Reparaturzweige. Verschiedene Transporte können eine Entscheidung teilen, während sie ihre eigenen Lieferverträge behalten.
- Bestehenden Zustand zuerst. Stelle neue Schemata, Manager, Caches und kombinierte Darstellungen in Frage. Verwende einen bestehenden Eigentümer wieder, wenn seine Lebensdauer, Autorität, Atomizität und Bereinigung passen. Entferne einen vorgeschlagenen Migrationspfad nur, wenn er wirklich unnötig ist; behalte die Migration, die bestehende Konfiguration und Zustand nach dem Update funktionsfähig hält. Neuer Zustand gehört in ein Feld, das ihn bedeutet.
- Lösche den redundanten Pfad. Entferne parallele Renderer, duplizierte Parser, gefälschte Lebenszyklus-Operationen, die nur zum Erhalten eines Ergebnisses verwendet werden, abgeleiteten Zustand, den Aufrufer bereits erhalten können, und Wrapper, die nur weiterleiten oder umbenennen. Bevorzuge eine einfachere Darstellung gegenüber Fallback-Modi um die alte herum.
- Poliere zuletzt. Behalte in jedem geänderten Abschnitt nur das, was ein Maintainer der umgebenden Datei schreiben würde:
- Kommentare, die Eigentumsverhältnisse, Lebenszyklus, Reihenfolge oder Einschränkungen erklären;
- Prüfungen und
try/catch-Blöcke, die mit dem umgebenden Modul übereinstimmen und reale Zustände schützen; - echte Typen anstatt bereinigter Casts (
as any,as unknown as T, erweitern-dann-behaupten); - Variablen und Hilfsfunktionen, die Domänenbedeutung hinzufügen, Duplikation entfernen oder den Kontrollfluss vereinfachen;
- Shims, Aliase, Wiederholungen und Fallbacks, die durch einen benannten ausgelieferten Vertrag und Entfernungsplan abgesichert sind;
- Benennung, Kontrollfluss, Importe und Formatierung, die mit der umgebenden Datei übereinstimmen.
Behalte die angeforderte Korrektur und das unterstützte Verhalten bei, nicht das zufällige Design des Vorschlags. Behalte echte Domänenunterschiede und gerechtfertigte öffentliche Kompatibilität. Wenn die Historie (git log -p -S <symbol>) den Zweck eines Pfades unklar lässt, behalte ihn und melde ihn. Melde neue Produktentscheidungen, brechende Verträge, unrelated cleanup und destructive branch replacement als Ergebnisse für den Eigentümer.
3. Behalte Tests für Fehler
Nenne für jede hinzugefügte oder geänderte Testgruppe und ihre Setup-Hilfsmittel den eindeutigen beobachtbaren Fehler, den sie abfängt.
Behalte Regressionen für den tatsächlichen Fehler und eindeutige Grenzen: Reihenfolge, Abbruch, veraltete Autorität, Neustart, Zurückweisung, echte Fehler und betroffene Verbraucherunterschiede. Behalte statische Vertragsprüfungen, die unabhängig eine echte Grenze schützen. Entferne doppelte, gleichartige Fälle, Mock-Echos, zufällige Feldkopier- oder Formulierungsbehauptungen, Behauptungen über statisch definierte Werte, Tests, die nur beweisen, dass entfernte Logik weg ist, Tests obsoleter Implementierungen und Gerüste oder test-only production hooks. Konsolidiere nützliche Fälle in einer vorhandenen Eigentümer-Suite.
Das Entfernen von Tests schwächt nie die Behauptungen, die Abdeckung realer Grenzen oder die verbleibenden Baselines.
Abgeschlossen, wenn jede verbleibende Testgruppe einen benannten Fehler hat.
4. Beweise die kleinere Änderung und reiche sie weiter
Bündele die Bearbeitungen, führe dann die Reproduktion und fokussierte Prüfungen für die geänderten Verträge und betroffenen Verbraucher erneut aus. Verwende Nachweise wieder, deren Eingaben unverändert sind. Ein erhaltener Neustart-, Upgrade- oder Transportanspruch benötigt anwendbare Beweise. Der vorhandene Workflow wählt breitere Prüfungen aus.
Abgeschlossen, wenn der vollständige Diff geprüft ist, jede Regel ein Urteil für jede geänderte Datei hat, unterstützte Vereinfachungen angewendet wurden, ersetzte Pfade unerreichbar sind und betroffenes Verhalten noch Nachweise hat. Keine Änderung ist ein gültiges Ergebnis, wenn die bestehende Form gerechtfertigt ist. Ziele auf Netto-negative Code-Menge ab, nicht auf eine Löschquote.
Berichte im PR-Text oder in vorhandenen Aufgabenbeweisen: die Verantwortung oder Maschinerie, die verschwunden ist, das Verhalten, das noch geschützt wird, und Produktions-/Testdeltas gegen die Merge-Basis. Kennzeichne eine Reduktion gegenüber einer früheren Revision getrennt vom Delta der Gesamtänderung. Nenne jegliches notwendige verbleibende Wachstum oder ungelöste Entscheidung.
Öffne oder aktualisiere dann den PR. Nach späteren Reparaturen vereinfache nur die neuen Änderungen und die Eigentümer, die sie berühren, bevor du sie einschiebst.