Notificações

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. Faça login como membro de teste e abra Configurações → Notificações para revisar as preferências de canais disponíveis.

2. Use dois membros de teste em uma área de trabalho e acione um evento de teste local, como um convite, com EMAIL_PROVIDER=local.

3. Confirme se apenas membros qualificados e canais habilitados recebem uma notificação no aplicativo ou na caixa de saída local. Não envie mensagens de teste para membros reais.

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

Use o pipeline de eventos do produto

notification-events.ts mapeia eventos de faturamento, orçamento, convite, associação e contas conectadas para cópias localizadas e planos de entrega por membro. O API e os clientes do aplicativo leem as notificações do espaço de trabalho conectado; as preferências controlam os canais elegíveis.

Alguns eventos permanecem intencionalmente no aplicativo. As falhas de atualização de contas conectadas, por exemplo, não devem expor detalhes do token ou acionar emails não solicitados.

Respeite as preferências do destinatário

Use o planejador de entrega existente, as preferências padrão e as opções de exclusão de atores, em vez de enviar uma mensagem de forma independente para cada membro. O email transacional ainda usa o provedor configurado e registra seu próprio resultado de entrega.

Verifique os destinatários e o estado

Teste uma preferência desabilitada, ator excluído, membro removido, comportamento não lido/lido e outro espaço de trabalho. Mantenha as atualizações dinâmicas acessíveis e verifique as mensagens localizadas.

• Entrega de e-mail
• Dicionários de notificação

Instalação e configuração

O serviço de notificações (notification-service.ts) armazena registos in-app com scope de workspace; GET /api/notifications lista-os para o membro autenticado e a rota mark-read atualiza o estado. Flags de preferência por utilizador controlam categorias como atualizações de produto e alertas de segurança.

Os membros gerem as preferências em /settings/notifications. Os anúncios de plataforma são redigidos através de announcement-actions e entregues pelo mesmo pipeline.

GET   /api/notifications
PATCH /api/notifications   (mark-read)

Emitted on mutations, e.g.:
  member.left
  member.role_changed

Fluxo de implementação

Emite uma notificação após uma mutação bem-sucedida — nunca antes da escrita ser confirmada. Mantém os payloads estruturados (tipo, workspace, referências) para que a interface os possa renderizar e encaminhar sem fazer parse de prosa.

Verifica o flag de preferência antes de entregar uma categoria desativável; os avisos relevantes para a segurança (nova sessão, alterações de chave) devem permanecer obrigatórios.

Verificação e resolução de problemas

Verifica que uma preferência desativada suprime a entrega, que mark-read persiste entre sessões, que outro workspace não consegue listar os registos e que os anúncios chegam aos membros previstos. Mantém o fan-out de notificações fora do caminho crítico do pedido à medida que o volume cresce.