> ## Documentation Index > Fetch the complete documentation index at: https://supastack.dev/llms.txt > Use this file to discover all available pages before exploring further. > For the full documentation corpus in one file, fetch: https://supastack.dev/llms-full.txt # Консоль администратора Инспекция платформы, объявления и feature flags. ## Прохождение для начинающих Предварительные требования: прочтите два приведенных ниже руководства для начинающих, завершите локальную веб-настройку и откройте этот монорепозиторий в корневой папке вашего редактора. Веб-настройки принадлежат `apps/web/.env.local`; Next.js не читает корень `.env`. `/dashboard` в поддельном режиме по умолчанию представляет собой демонстрацию без базы данных; `/auth` требуется перенесенная база данных. Вкратце: рабочее пространство — это отдельные пользователи, данные и настройки одной команды. Сервер является доверенным сервером; не допускайте попадания ключей провайдера в код браузера и телефона. Миграция — это изменение версии базы данных, при котором создаются или обновляются таблицы. Модель ИИ — это механизм, который отвечает; Каталог моделей — это список доступных идентификаторов моделей и цен на сервере. Поставщик — это внешняя служба, такая как служба искусственного интеллекта, электронной почты или службы выставления счетов. Право — это грант, который позволяет рабочей области использовать функцию. Вебхук — это сообщение, которое одна служба отправляет на URL другой службы. 1. Прежде чем создавать локальную тестовую учетную запись, добавьте свой собственный адрес в список `ADMIN_EMAILS` только для сервера и перезапустите приложение. 2. Зарегистрируйтесь в перенесенной тестовой базе данных и откройте `/admin`; проверьте доступные страницы пользователей и организаций. 3. Это дает право администратора платформы, а не права владения рабочим пространством. Если доступ запрещен, проверьте точную электронную почту и конфигурацию сервера; не повышайте права произвольных пользователей и не тестируйте их на рабочей среде. Для пользовательского кода начните с предоставленного `prompts/README.md` и скопируйте ближайшее приглашение: `prompts/new-app-screen.md` для экрана приложения или `prompts/new-landing-page.md` для общедоступной страницы. Для работы с сервером, базой данных или провайдером дайте своему агенту кодирования задание из этого руководства и попросите его прочитать `AGENTS.md`, `.ai/PROJECT_CONTEXT.md` и соответствующие зеркала `.ai/`; проверьте точные исходные файлы, указанные здесь; список файлов и проверки перед редактированием; сохранять права собственности на рабочую область и секреты, доступные только серверу; и покажу вам разницу. Сообщите ему желаемое поведение, поля ввода и вывода, разрешенные роли, ожидаемые успехи и ошибки, а также тестовую учетную запись, поставщика или устройство. Используйте выборочные значения; никогда не вставляйте настоящий секрет. [Прежде чем начать](https://supastack.dev/ru/docs/web/before-you-start.md) [Основные сведения о терминале](https://supastack.dev/ru/docs/web/terminal-basics.md) [Локальная веб-настройка](https://supastack.dev/ru/docs/web/ship-in-5-minutes.md) [Подсказки агента и память проекта](https://supastack.dev/ru/docs/web/agents.md) ## Создайте административную границу `ADMIN_EMAILS` — это список начальной загрузки, разделенный запятыми, предназначенный только для сервера. Перечисленные пользователи получают роль администратора платформы при регистрации. Без этого предоставьте доступ через авторизованную базу данных/путь администратора; не делайте первого произвольного посетителя администратором. Администратор платформы отличается от владельца/администратора рабочей области. `/admin` и его страницы пользователя, организации, флага, объявлений и списка ожидания проверяют роль платформы. ## Используйте реализованные элементы управления Механизм Better Auth по умолчанию обеспечивает административное управление пользователями, баны и выдачу себя за другое лицо. Приложение формирует представления платформы с журналами аудита. Ограничьте выдачу себя за другое лицо подтвержденным доступом администратора, сделайте его состояние видимым и восстановите исходный сеанс администратора при выходе. Auth.js не наследует автоматически плагины администратора Better Auth. Прежде чем переключать механизмы, просмотрите `admin.ts`, `admin-actions.ts` и поведение провайдера аутентификации. ## Проверка привилегированных действий Проверьте отказ без прав администратора, доступ администратора, сеансы заблокированных пользователей, запуск/остановку олицетворения и действия, которые вы включаете. Держите все административные маршруты вне общедоступного индексирования. [Флаги функций](https://supastack.dev/ru/docs/web/feature-flags.md) [Объявления](https://supastack.dev/ru/docs/web/project-structure.md) [Администрирование списка ожидания](https://supastack.dev/ru/docs/web/setup-ai.md) ## Настройка и конфигурация Поверхность /admin — операторский вид инспекции пространств, участников и состояния продукта. ADMIN_EMAILS (или конфигурация admin-плагина в потребляющем продукте) решает, кто попадает; каждый admin-маршрут перепроверяет авторизацию на сервере. Feature flags (feature-flag-runtime.ts) по умолчанию выключают всё ненастроенное — отсутствующий флаг никогда не может тихо включить поверхность — а переопределения по флагам живут в таблице featureFlagOverride. ``` /admin operator dashboard announcement-actions.ts broadcast in-app notices resolveFeatureFlags(...) bulk flag resolution for a caller context ``` ## Рабочий процесс внедрения Используйте admin-действия для инспекции и операций поддержки (поиск пространства, управление участниками, рассылка объявлений). Держите мутации аудируемыми, а авторизацию проверяемой на границе действия, а не в навигации. Раскатывайте функции за флагами: поставляйте код в тёмном режиме, включайте по пространству или глобально и снимайте флаг, когда поверхность становится постоянной. Платформенный имперсонейшн остаётся замороженным, если PRODUCT.md продукта не разрешает его явно. ## Проверка и устранение неполадок Проверьте, что не-администратор отклоняется, что выключенный флаг скрывает свою поверхность end-to-end (навигация, маршрут, действие), что переопределение разрешается только для своей цели и что объявления доходят до предполагаемой аудитории. Admin-тесты должны сначала покрывать путь отказа. ## Вперёд [Стратегия тестирования](https://supastack.dev/ru/docs/web/testing.md)