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 /es/docs/web/notifications.md (or send Accept: text/markdown).

Notificaciones

Avisos in-app, preferencias por usuario y anuncios de administrador.

Preguntar sobre esta guía

Guía paso a paso para principiantes

Requisitos previos: lea las dos guías para principiantes a continuación, finalice la configuración local web y abra este monorepo en la raíz de su editor. La configuración web pertenece a apps/web/.env.local; Next.js no lee la raíz .env. /dashboard en el modo falso predeterminado es una demostración sin base de datos; /auth necesita una base de datos migrada.

Términos breves: un espacio de trabajo son los usuarios, datos y configuraciones separados de un equipo. El servidor es el backend confiable; Mantenga las claves del proveedor fuera del código del navegador y del teléfono. Una migración es un cambio de base de datos versionada que crea o actualiza tablas. Un modelo de IA es el motor que responde; el catálogo de modelos es la lista del servidor de ID de modelos disponibles y precios. Un proveedor es un servicio externo, como inteligencia artificial, correo electrónico o servicio de facturación. Un derecho es una concesión que permite que un espacio de trabajo utilice una función. Un webhook es un mensaje que un servicio envía al URL de otro servicio.

1. Inicie sesión como miembro de prueba y abra Configuración → Notificaciones para revisar las preferencias de canales disponibles.

2. Utilice dos miembros de prueba en un espacio de trabajo y active un evento de prueba local, como una invitación, con EMAIL_PROVIDER=local.

3. Confirme que solo los miembros elegibles y los canales habilitados reciban una notificación en la aplicación o en la bandeja de salida local. No envíe mensajes de prueba a miembros reales.

Para obtener código personalizado, comience con el prompts/README.md proporcionado y copie el mensaje más cercano: prompts/new-app-screen.md para una pantalla de aplicación o prompts/new-landing-page.md para una página pública. Para trabajos de servidor, base de datos o proveedor, asigne a su agente de codificación la tarea de esta guía y pídale que lea AGENTS.md, .ai/PROJECT_CONTEXT.md y los espejos .ai/ correspondientes; inspeccionar los archivos fuente exactos nombrados aquí; enumerar archivos y verificaciones antes de editarlos; preservar la propiedad del espacio de trabajo y los secretos exclusivos del servidor; y mostrarte la diferencia. Dígale el comportamiento que desea, los campos de entrada y salida, los roles permitidos, los éxitos y errores esperados y la cuenta, proveedor o dispositivo de prueba. Utilice valores de muestra; Nunca pegues un verdadero secreto.

Usa el flujo de eventos del producto

notification-events.ts asigna eventos de facturación, presupuesto, invitación, membresía y cuenta conectada a texto localizado y planes de entrega por miembro. La API y los clientes de la aplicación leen las notificaciones del espacio de trabajo en el que inició sesión la persona; las preferencias controlan los canales disponibles.

Algunos eventos se mantienen intencionadamente dentro de la aplicación. Por ejemplo, los fallos al actualizar una cuenta conectada no deben exponer detalles de tokens ni activar correos no solicitados.

Respeta las preferencias de los destinatarios

Usa el planificador de entregas existente, las preferencias predeterminadas y las opciones para excluir al actor, en lugar de enviar un mensaje independiente a cada miembro. El correo transaccional sigue usando el proveedor configurado y registra su propio resultado de entrega.

Verifica los destinatarios y el estado

Prueba una preferencia deshabilitada, un actor excluido, un miembro eliminado, el comportamiento de lectura/no lectura y otro espacio de trabajo. Mantén accesibles las actualizaciones dinámicas y verifica los mensajes localizados.

Configuración y ajustes

El servicio de notificaciones (notification-service.ts) almacena registros in-app con scope de workspace; GET /api/notifications los lista para el miembro conectado y la ruta mark-read actualiza el estado. Los flags de preferencia por usuario controlan categorías como actualizaciones de producto y alertas de seguridad.

Los miembros gestionan las preferencias en /settings/notifications. Los anuncios de plataforma se redactan a través de announcement-actions y se entregan por el mismo pipeline.

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

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

Flujo de implementación

Emite una notificación tras una mutación exitosa — nunca antes de que la escritura se confirme. Mantén los payloads estructurados (tipo, workspace, referencias) para que la interfaz pueda renderizarlos y enrutarlos sin parsear prosa.

Comprueba el flag de preferencia antes de entregar una categoría deshabilitable; los avisos relevantes para la seguridad (nueva sesión, cambios de clave) deben seguir siendo obligatorios.

Verificación y solución de problemas

Verifica que una preferencia deshabilitada suprime la entrega, que mark-read persiste entre sesiones, que otro workspace no puede listar los registros y que los anuncios llegan a los miembros previstos. Mantén el fan-out de notificaciones fuera del camino crítico de la petición cuando el volumen crece.