For AI agents: fetch the complete documentation index at /llms.txt, the full documentation corpus at /llms-full.txt, the agent skill at /skill.md, or this page as Markdown at /ru/docs/tanstack/admin.md (or send Accept: text/markdown).
Консоль администратора
Инспекция платформы, объявления и feature flags.
Прохождение для начинающих
Предварительные требования: прочтите два приведенных ниже руководства для начинающих, завершите локальную веб-настройку и откройте этот монорепозиторий в корневой папке вашего редактора. Веб-настройки принадлежат apps/web-tanstack/.env.local; TanStack Start не читает корень .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/; проверьте точные исходные файлы, указанные здесь; список файлов и проверки перед редактированием; сохранять права собственности на рабочую область и секреты, доступные только серверу; и покажу вам разницу. Сообщите ему желаемое поведение, поля ввода и вывода, разрешенные роли, ожидаемые успехи и ошибки, а также тестовую учетную запись, поставщика или устройство. Используйте выборочные значения; никогда не вставляйте настоящий секрет.
Создайте административную границу
ADMIN_EMAILS — это список начальной загрузки, разделенный запятыми, предназначенный только для сервера. Перечисленные пользователи получают роль администратора платформы при регистрации. Без этого предоставьте доступ через авторизованную базу данных/путь администратора; не делайте первого произвольного посетителя администратором.
Администратор платформы отличается от владельца/администратора рабочей области. /admin и его страницы пользователя, организации, флага, объявлений и списка ожидания проверяют роль платформы.
Используйте реализованные элементы управления
Механизм Better Auth по умолчанию обеспечивает административное управление пользователями, баны и выдачу себя за другое лицо. Приложение формирует представления платформы с журналами аудита. Ограничьте выдачу себя за другое лицо подтвержденным доступом администратора, сделайте его состояние видимым и восстановите исходный сеанс администратора при выходе.
Auth.js не наследует автоматически плагины администратора Better Auth. Прежде чем переключать механизмы, просмотрите admin.ts, admin-actions.ts и поведение провайдера аутентификации.
Проверка привилегированных действий
Проверьте отказ без прав администратора, доступ администратора, сеансы заблокированных пользователей, запуск/остановку олицетворения и действия, которые вы включаете. Держите все административные маршруты вне общедоступного индексирования.
Настройка и конфигурация
Поверхность /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-тесты должны сначала покрывать путь отказа.