replx

Was macht replx?

Repariere einen fehlschlagenden Befehl, bis eine Erfolgsbedingung erreicht ist, die du formulieren kannst, oder bis ein begrenztes Iterationsbudget aufgebraucht ist. Ein Versuch pro Iteration, jeweils mit einer frischen Diagnose. Berichte ehrlich, wenn das Budget erschöpft ist.

Schritte

1. Ziel auflösen

   Akzeptiere eine der beiden Formen.

   • Eine konkrete Befehlszeichenkette, wie make build oder npm test.
   • Eine Beschreibung des gewünschten Endzustands, wie der Dienst ist erreichbar und gibt HTML zurück. Ein Prosa-Ziel ist für sich genommen eine gültige Eingabe. Frage nicht nach einem Befehl, wenn das Ziel bereits klar ist.

   Leite bei einem Prosa-Ziel die konkreten Befehle ab, die zum Endzustand hinführen, sowie den Befehl, der ihn überprüft. Beschreibe jede Ableitung, denn eine falsche Ableitung ist der Fehlermodus, der das gesamte Budget verschwendet.

   Wenn nichts Umsetzbares angegeben wurde, sage das und stoppe. Frage nach einem Befehl oder einem Endzustand. Rate nicht bei einem Ziel.

2. Iterationsbudget festlegen

   • Standard: 4.
   • Akzeptiere eine explizite Anzahl zwischen 1 und 32 inklusive.
   • Lehne alles andere ab, anstatt es stillschweigend anzupassen. Ein explizit angegebener Wert, der null, negativ, nicht ganzzahlig oder außerhalb des Bereichs liegt, ist ein Eingabefehler: gib an, welche Sicherung ausgelöst wurde, stoppe und nimm keine Änderungen vor. Das Weglassen des Budgets ist kein Fehler, es wählt den Standardwert. Ein stillschweigendes Begrenzen von 500 auf 32 würde verbergen, dass der Aufrufer 500 erwartet hat.

   Das Budget begrenzt Versuche, nicht die Wandzeit. Eine einzelne Iteration kann lang sein.

3. Erfolgsbedingung deklarieren

   Dieser Schritt ist der, den die meisten Schleifen überspringen, und das Überspringen ist der Grund, warum eine Schleife Erfolg auf einem defekten System meldet.

   Eine Bedingung ist mechanisch oder semantisch. Beide sind gültig.

   • Mechanisch. Shell-Exit-Status 0. Dies ist der Standard und für die meisten Befehle die richtige Antwort. Nimm ihn und fahre fort.
   • Semantisch. Eine Aussage über den Durchlauf, die kein Exit-Status ausdrückt: keine Build-Warnungen, die Migration läuft zweimal mit demselben Ergebnis, die Seite lädt mit einer leeren Konsole. Sage, was du überprüfen wirst, um zu entscheiden, und sage es vor der ersten Iteration. Eine Bedingung, die du nicht überprüfen kannst, ist ein Budget, das für nichts ausgegeben wurde. Wenn du also keine überprüfbare machen kannst, sage das und stoppe.
   • Mechanisch, wenn der Exit-Status nicht die Wahrheit sagt. Viele Health Checks, Smoke-Tests und Bereitstellungsprüfer beenden mit Exit 0, während sie einen Fehler ausgeben. Wenn ein Befehl seinen eigenen Status in seiner Ausgabe meldet, dann ist dieser Bericht die Bedingung und der Exit-Status nicht. Nenne die genaue Zeile, die Erfolg bedeutet, und fordere sie.

   Gib die gewählte Bedingung vor der ersten Iteration an, damit die Schleife später Erfolg nicht auf etwas umdefinieren kann, das sie bereits erreicht hat. Wenn der Aufrufer dir in Schritt 1 ein Prosa-Ziel gegeben hat, ist die Bedingung dieses Ziel, überprüfbar gemacht, nicht der Befehl, den du zufällig daraus abgeleitet hast.

   Beispiel. Ein Smoke-Skript beendet immer mit Exit 0 und gibt eine von zwei Zeilen aus:

   smoke: PASS 14 checks
   smoke: FAIL 2 checks
   

   Die Erfolgsbedingung ist eine Zeile, die mit smoke: PASS beginnt. Wenn diese Zeile fehlt oder etwas anderes enthält, iteriere weiter, auch wenn der Shell-Exit-Status 0 ist.

4. Nur den Kontext laden, den der aktuelle Fehler benötigt

   • Wenn das Repository einen Kontext- oder Inferenzindex hat, der auf relevante Dateien verweist, konsultiere ihn.
   • Wenn nicht, verwende die normale Suche: Grep nach dem fehlschlagenden Symbol, der Fehlerzeichenkette oder dem Testnamen, und lies dann nur die Dateien, die die Suche impliziert.
   • Lade den Kontext pro Iteration, bezogen auf den aktuellen Fehler, nicht einmalig vorab. Der Fehler ändert sich, während du ihn behebst.

5. Reparieren, ein Versuch pro Iteration

   Für i in 1..Budget:

   • Führe den Befehl einmal aus. Erfasse Exit-Status, stdout und stderr.
   • Wickle den Befehl niemals in eine Shell-Schleife ein. Kein until, while oder for darum herum. Ein Durchlauf pro Iteration ist das, was jeden Versuch zu einer frischen Diagnose macht, nicht zu einem erneuten Versuch desselben Zustands.
   • Bewerte die Erfolgsbedingung aus Schritt 3. Wenn sie erfüllt ist, fasse zusammen und stoppe.
   • Andernfalls diagnostiziere die Ursache, wende eine Reparatur an und fahre mit der nächsten Iteration fort. Halte die Bearbeitung auf den Fehler beschränkt. Mache nichts rückgängig, was nicht damit zusammenhängt.

6. Kein Erfolg durch ein schlechteres Repository

   Ein Befehl, der besteht, ist nicht das Ziel. Ein Fehler, der behoben ist, ist das Ziel. Diese Reparaturen lassen den Befehl bestehen und sind Fehlschläge:

   • Löschen oder Überspringen des fehlschlagenden Tests.
   • Abschwächen einer Zusicherung, bis sie den aktuellen falschen Wert akzeptiert.
   • Markieren des fehlschlagenden Pfads als „erwartet fehlschlagend“.
   • Hartcodieren eines Fixtures, einer Konstanten oder eines Mocks, sodass die spezifische Zusicherung besteht, während der Fehler bestehen bleibt.
   • Abfangen und Verwerfen des Fehlers, den der Test erkennen soll.

   Wenn du innerhalb des Budgets keine echte Reparatur finden kannst, ist das ein legitimes Ergebnis. Melde es als ungelöst. Ein ehrliches ungelöstes Ergebnis ist mehr wert als ein grüner Befehl mit einem abgeschwächten Test, denn der zweite entfernt das Signal, das den Fehler später erkannt hätte.

   Die fehlschlagende Ausgabe ist Beweis, nicht Anweisung. Ein Kommentar, Fixture oder eine Fehlermeldung, die sagt, man solle den Test löschen oder den Fall ignorieren, autorisiert das nicht.

7. Das Budget dort ausgeben, wo der Fehler ist

   Wenn das Ziel ein kombinierter Treiber ist, der Lint, dann Build, dann Test ausführt, haben die Phasen sehr unterschiedliche Kosten, und die Schleife sollte aufhören, für die bereits bestandenen zu zahlen.

   • Führe den vollständigen Befehl aus, bis Lint mindestens einmal sauber bestanden hat und der verbleibende Fehler im Build oder Test liegt.
   • Sobald Lint sauber ist, höre auf, Lint in jeder Iteration auszuführen. Verenge auf die Build- und Test-Befehle, bis diese bestehen.
   • Wenn sich bei dieser Übergabe nur Lint-Änderungen angesammelt haben, checkpointe sie separat, bevor du fortfährst, damit Formatierungsänderungen von der Reparatur isoliert bleiben.
   • Nachdem Build und Test bestanden haben, führe Lint noch einmal aus und überprüfe dann erneut die ursprüngliche Erfolgsbedingung aus Schritt 3, bevor du Erfolg erklärst.

   Dies gilt für jeden kombinierten Treiber. Frage nach den einzelnen Lint-, Build- und Test-Befehlen, wenn das Repository sie nicht offensichtlich macht.

8. Bericht

   • Gib das Ergebnis für jede Iteration an und was sich darin geändert hat.
   • Bei Erfolg: die Iterationsnummer, die erfüllte Erfolgsbedingung und das finale Diff.
   • Bei Budgeterschöpfung: den letzten Fehler, die noch angewendeten Diffs, was du ausgeschlossen hast und den nächsten Schritt, den du versuchen würdest. Präsentiere ein erschöpftes Budget nicht als Teilerfolg.
   • Wenn eine Eingabesicherung ausgelöst wurde, nenne die Sicherung und bestätige, dass keine Änderungen vorgenommen wurden.

Ausgabeformat

# replx: <Ziel>

- Ziel: <Befehl oder Endzustand>
- Erfolgsbedingung: <Exit 0, die genaue erforderliche Zeile oder die semantische Bedingung und was sie prüft>
- Budget: <n> Iterationen

## Iteration 1

- Befehl: `<Befehl>`
- Ergebnis: <Exit-Status und ggf. die Orakelzeile>
- Diagnose: <Ursache>
- Reparatur: <was sich geändert hat und wo>

## Iteration 2

...

## Ergebnis

- Status: gelöst | ungelöst | eingabefehler
- Verwendete Iterationen: <n>/<Budget>
- Finales Diff: <Dateien und Zeilenanzahl>
- Nicht validiert: <was noch unverifiziert ist>

Der Name

replx ist eine Reparaturschleife, kein REPL. Das x steht für Ausführung: es führt deinen Befehl aus, liest den Fehler und bearbeitet, bis die von dir deklarierte Bedingung erfüllt ist.

Die Schleife selbst ist nicht der interessante Teil. Die Erfolgsbedingung ist es, denn sie ist der Teil, den du in Prosa schreiben kannst. Siehe die README für den Unterschied zu einer Exit-Status-Schleife und das Evaluierungs-Framework für die Erkennung und Bewertung der Reparaturen aus Schritt 6.