laravel-new-featurelisted

# Новая функциональность в Laravel Порядок здесь не косметический. Тест, написанный после реализации, проверяет то, что получилось, а не то, что требовалось, — и как надзорный слой бесполезен. ## 1. Сформулируй критерий приёмки до кода Одним абзацем: кто, что делает, что получает, что происходит при отказе. Покажи пользователю и получи подтверждение. Если критерий неверен, вся пирамида проверок ниже охраняет неправильное поведение. Обязательно перечисли несчастливые пути: нет прав, невалидный ввод, повтор операции, внешний сервис недоступен. ## 2. Напиши падающий тест Feature-тест по критерию из шага 1. Запусти и **убедись, что он падает** по нужной причине. Тест, который зелёный до реализации, не проверяет ничего. ## 3. Реализуй - Бизнес-логика — в Action (один публичный метод `handle`), не в контроллере. - Валидация — FormRequest. - Ответ — API Resource. - Внешние обращения — через свой клиент с таймаутом и ретраями, без «голого» curl. ## 4. Прогони гейты — все, не выборочно ```bash php artisan test --filter=<НовыйТест> # целевой тест php artisan test # регрессия ./vendor/bin/pint --test # стиль ./vendor/bin/phpstan analyse # статический анализ ``` Красный гейт — работа не сделана. Не «почти готово». ## 5. Отдельно скажи, что должен посмотреть человек Перечисли явно, если в изменениях есть: - миграции и любые изменения схемы; - изменения существующего API-контракта; - новые зависим��сти; - всё, связанное с день