Ограничения полей и ошибки валидации

Проверка карточки переговорной

Roomly — система для управления рабочими пространствами, которой пользуются офис-менеджеры, чтобы поддерживать актуальный каталог переговорных комнат. При проверке описания комнаты название и вместимость должны отвечать определённым правилам, заложенным в систему заранее. Эти правила одинаковы для всех комнат и не зависят от того, кто и когда заполняет карточку.

Офис-менеджер передаёт описание переговорной и рассчитывает получить чёткий ответ: принято ли оно или нет. Ошибки при ручном заполнении неизбежны — можно случайно указать недопустимое название, ввести некорректное значение вместимости или сразу допустить оба промаха. Поэтому важно, чтобы система не просто отвергла описание, а точно указала, что именно и по какой причине не прошло проверку: менеджер должен понимать, какое поле нужно скорректировать и какое правило оно нарушает.

Если описание удовлетворяет всем правилам, система подтверждает его допустимость. Если нет — возвращает информативный отказ, охватывающий все найденные нарушения сразу, а не только первое из них. При этом проверка не вносит никаких изменений в каталог: она лишь сообщает об итоге контроля, оставляя исправление и повторную передачу данных на стороне менеджера.

Что уже дано

В самостоятельном файле уже есть app, модель RoomIn и работающий POST-обработчик. Но сейчас модель принимает имя из одного символа, нулевую вместимость и запрос без вместимости. Исправьте этот файл, сохранив форму успешного ответа.

Служебный переходник проверки запускается перед вашим файлом, но не создаёт приложение или данные. Менять его не нужно.

Что нужно сделать

Исправьте входную модель RoomIn с помощью Field, чтобы оба поля были обязательными: name — строка длиной от 2 до 50 символов включительно, capacity — целое число от 1 до 50 включительно.

Маршрут POST /api/rooms получает эту модель из JSON-тела. Для допустимого описания ответ — статус 200 и объект ровно с полями accepted_name и capacity, содержащими принятые значения.

Неверное описание должно получать стандартный ответ FastAPI 422. Каждый элемент detail содержит путь loc к полю тела, машинный type и объяснение msg; если нарушены оба поля, сообщаются оба нарушения. Не исправляйте входные значения и не заменяйте отсутствующие поля значениями по умолчанию. Каталог и хранилище не нужны.

Ввод и вывод

stdin не используется. Печатать через print в stdout ничего не нужно. После выполнения файла проверяющая система обращается к верхнеуровневому объекту app: служебный переходник отправляет HTTP-запросы через TestClient внутри процесса приложения и передаёт результаты скрытой проверке. Запускать Uvicorn или сетевой сервер не нужно.

POST /api/rooms с {"name": "Кедр", "capacity": 6} получает 200 и {"accepted_name": "Кедр", "capacity": 6}. Для {"name": "К", "capacity": 0} нужен 422 с ошибками по loc: ["body", "name"] и loc: ["body", "capacity"].