Notifiche

Procedura dettagliata per principianti

Prerequisiti: leggi le due guide per principianti di seguito, completa la configurazione locale del Web e apri questo monorepo alla radice nel tuo editor. Le impostazioni Web appartengono a apps/web/.env.local; Next.js non legge la radice .env. /dashboard nella modalità falsa predefinita è una demo senza database; /auth necessita di un database migrato.

Termini rapidi: uno spazio di lavoro è costituito da utenti, dati e impostazioni separati di un team. Il server è il backend affidabile; mantenere le chiavi del provider fuori dal browser e dal codice del telefono. Una migrazione è una modifica del database con versione che crea o aggiorna tabelle. Un modello AI è il motore che risponde; il catalogo dei modelli è l'elenco del server degli ID e dei prezzi dei modelli disponibili. Un fornitore è un servizio esterno come un servizio di intelligenza artificiale, posta elettronica o fatturazione. Un diritto è una concessione che consente a un'area di lavoro di utilizzare una funzionalità. Un webhook è un messaggio che un servizio invia allo URL di un altro servizio.

1. Accedi come membro di prova e apri Impostazioni → Notifiche per verificare le preferenze dei canali disponibili.

2. Utilizza due membri del test in uno spazio di lavoro e attiva un evento di test locale, come un invito, con EMAIL_PROVIDER=local.

3. Conferma che solo i membri idonei e i canali abilitati ricevono una notifica nell'app o nella posta in uscita locale. Non inviare messaggi di prova a membri reali.

Per il codice personalizzato, inizia con prompts/README.md in dotazione e copia il prompt più vicino: prompts/new-app-screen.md per la schermata di un'app o prompts/new-landing-page.md per una pagina pubblica. Per il lavoro su server, database o provider, assegna al tuo agente di codifica il compito di questa guida e chiedigli di leggere AGENTS.md, .ai/PROJECT_CONTEXT.md e i mirror .ai/ corrispondenti; controllare gli esatti file sorgente nominati qui; elencare file e controlli prima della modifica; preservare la proprietà dello spazio di lavoro e i segreti solo del server; e mostrarti la differenza. Indicagli il comportamento desiderato, i campi di input e output, i ruoli consentiti, i successi e gli errori previsti e l'account, il fornitore o il dispositivo di prova. Utilizzare valori campione; non incollare mai un vero segreto.

• Prima di iniziare
• Nozioni di base sui terminali
• Configurazione locale Web
• Messaggi dell'agente e memoria del progetto

Utilizza la pipeline degli eventi del prodotto

notification-events.ts mappa gli eventi di fatturazione, budget, invito, iscrizione e account collegati a copie localizzate e piani di consegna per membro. API e i client dell'app leggono le notifiche dell'area di lavoro a cui è stato effettuato l'accesso; le preferenze controllano i canali idonei.

Alcuni eventi rimangono intenzionalmente nell'app. Gli errori di aggiornamento dell'account connesso, ad esempio, non devono esporre i dettagli del token o attivare e-mail non richieste.

Rispettare le preferenze del destinatario

Utilizza il pianificatore di consegna esistente, le preferenze predefinite e le opzioni di esclusione degli attori anziché inviare un messaggio in modo indipendente a ogni membro. La posta elettronica transazionale utilizza ancora il provider configurato e registra il proprio esito di consegna.

Verificare i destinatari e lo stato

Testare una preferenza disabilitata, un attore escluso, un membro rimosso, un comportamento non letto/letto e un altro spazio di lavoro. Mantieni accessibili gli aggiornamenti dinamici e verifica i messaggi localizzati.

• Consegna e-mail
• Dizionari di notifica

Installazione e configurazione

Il servizio di notifiche (notification-service.ts) archivia record in-app con scope workspace; GET /api/notifications li elenca per il membro connesso e la route mark-read aggiorna lo stato. Flag di preferenza per utente controllano categorie come aggiornamenti prodotto e avvisi di sicurezza.

I membri gestiscono le preferenze sotto /settings/notifications. Gli annunci di piattaforma sono scritti tramite announcement-actions e consegnati tramite la stessa pipeline.

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

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

Flusso di implementazione

Emetti una notifica dopo una mutazione riuscita — mai prima che la scrittura sia committata. Mantieni i payload strutturati (tipo, workspace, riferimenti) così l'interfaccia può renderizzarli e instradarli senza parsare prosa.

Controlla il flag di preferenza prima di consegnare una categoria disabilitabile; gli avvisi rilevanti per la sicurezza (nuova sessione, cambi di chiave) dovrebbero restare obbligatori.

Verifica e risoluzione dei problemi

Verifica che una preferenza disabilitata sopprima la consegna, che mark-read persista tra sessioni, che un altro workspace non possa elencare i record e che gli annunci raggiungano i membri previsti. Mantieni il fan-out delle notifiche fuori dal percorso critico della richiesta man mano che il volume cresce.