Consola de administração

Passo a passo para iniciantes

Pré-requisitos: Leia os dois guias para iniciantes abaixo, conclua a configuração local da Web e abra este monorepo na raiz do seu editor. As configurações da Web pertencem a apps/web/.env.local; Next.js não lê a raiz .env. /dashboard no modo falso padrão é uma demonstração sem banco de dados; /auth precisa de um banco de dados migrado.

Termos rápidos: um espaço de trabalho consiste em usuários, dados e configurações separados de uma equipe. O servidor é o back-end confiável; mantenha as chaves do provedor fora do navegador e do código do telefone. Uma migração é uma alteração de versão do banco de dados que cria ou atualiza tabelas. Um modelo de IA é o mecanismo que responde; o catálogo de modelos é a lista do servidor de IDs e preços de modelos disponíveis. Um provedor é um serviço externo, como IA, e-mail ou serviço de cobrança. Um direito é uma concessão que permite que um espaço de trabalho use um recurso. Um webhook é uma mensagem que um serviço envia para o URL de outro serviço.

1. Antes de criar uma conta de teste local, adicione seu próprio endereço à lista ADMIN_EMAILS somente do servidor e reinicie o aplicativo.

2. Cadastre-se no banco de dados de testes migrado e abra /admin; inspecione as páginas disponíveis do usuário e da organização.

3. Isso concede ao administrador da plataforma, não à propriedade do espaço de trabalho. Se o acesso for negado, verifique a configuração exata do e-mail e do servidor; não eleve usuários arbitrários nem teste em relação à produção.

Para código personalizado, comece com o prompts/README.md fornecido e copie o prompt mais próximo: prompts/new-app-screen.md para uma tela de aplicativo ou prompts/new-landing-page.md para uma página pública. Para trabalho de servidor, banco de dados ou provedor, dê ao seu agente de codificação a tarefa deste guia e peça-lhe para ler AGENTS.md, .ai/PROJECT_CONTEXT.md e espelhos .ai/ correspondentes; inspecione os arquivos de origem exatos nomeados aqui; listar arquivos e verificações antes de editar; preservar a propriedade do espaço de trabalho e os segredos apenas do servidor; e mostrar a diferença. Informe o comportamento desejado, campos de entrada e saída, funções permitidas, sucessos e erros esperados e a conta de teste, provedor ou dispositivo. Use valores de amostra; nunca cole um segredo real.

• Antes de começar
• Noções básicas sobre terminais
• Configuração local da Web
• Avisos do agente e memória do projeto

Crie o limite do administrador

ADMIN_EMAILS é uma lista de bootstrap separada por vírgula somente para servidor. Os usuários listados recebem a função de administrador da plataforma na inscrição. Sem ele, conceda acesso por meio de um caminho de banco de dados/administrador autorizado; não transforme o primeiro visitante arbitrário em administrador.

O administrador da plataforma é diferente do proprietário/administrador do espaço de trabalho. /admin e suas páginas de usuário, organização, sinalizador, anúncio e lista de espera verificam a função da plataforma.

Use os controles implementados

O mecanismo Better Auth padrão fornece gerenciamento de usuários administradores, banimentos e representação. O aplicativo compõe visualizações de plataforma com trilhas de auditoria. Restrinja a representação ao acesso de administrador verificado, torne seu estado visível e restaure a sessão de administrador original ao sair.

Auth.js não herda automaticamente os plug-ins de administração Better Auth. Revise o comportamento de admin.ts, admin-actions.ts e do provedor de autenticação antes de trocar de mecanismo.

Verifique ações privilegiadas

Teste a negação de não administradores, o acesso de administrador, sessões de usuários banidos, início/parada de representação e as ações que você habilita. Mantenha todas as rotas administrativas fora da indexação pública.

• Sinalizadores de recursos
• Anúncios
• Administração da lista de espera

Instalação e configuração

A superfície /admin é a vista de inspeção do operador sobre workspaces, membros e estado do produto. ADMIN_EMAILS (ou a configuração do plugin admin no produto consumidor) decide quem lá chega; cada rota admin volta a verificar a autorização no servidor.

Os feature flags (feature-flag-runtime.ts) desativam por predefinição tudo o que não está configurado — um flag ausente nunca pode ativar silenciosamente uma superfície — e os overrides por flag vivem na tabela featureFlagOverride.

/admin                    operator dashboard
announcement-actions.ts   broadcast in-app notices
resolveFeatureFlags(...)  bulk flag resolution for a caller context

Fluxo de implementação

Usa as ações admin para inspeção e operações de suporte (pesquisa de workspace, gestão de membros, broadcast de anúncios). Mantém as mutações auditadas e a autorização verificada na fronteira da ação, não na navegação.

Lança funcionalidades atrás de flags: envia código em dark, ativa-o por workspace ou globalmente, e retira o flag quando a superfície for permanente. A impersonação de plataforma permanece congelada a menos que o PRODUCT.md do produto a autorize explicitamente.

Verificação e resolução de problemas

Verifica que um não-admin é negado, que um flag desativado oculta a sua superfície de ponta a ponta (nav, rota, ação), que um override se resolve apenas para o seu alvo e que os anúncios chegam ao público previsto. Os testes admin devem cobrir primeiro o caminho negado.