Notificação

Usuário × slug × canal, e a linha só existe quando difere do padrão. NotificationPreference grava exceção, não estado. Ausência de linha significa "o que o catálogo declarou", então slug novo entra ligado ou desligado conforme o próprio catálogo — sem migração, sem linha órfã, e sem o caso que sempre morde: o usuário que configurou as preferências em março e deixa de receber, em silêncio, o aviso publicado em agosto.

isMandatory com canal e motivo. O slug não some da tela e o canal que carrega o controle não desliga; canais adicionais ficam a critério do usuário. O motivo vem do catálogo e aparece ao lado do controle desabilitado, porque controle que a pessoa não entende vira ruído — e ruído acaba desligado por outro caminho. Obrigatória não significa todos os canais: push às duas da manhã para um controle que o e-mail já cumpre é como se ensina alguém a ignorar.

Resolvedor por tipo de audiência. O disparo manda audience: {type, params}; quem vira lista de pessoas é um IAudienceResolver registrado por tipo, e ele mora no módulo dono do conceito — o rollup de donos do nó é do centro de custo, não do módulo de notificação. A alternativa era cada consumidor entregar a lista pronta, e o preço seria o mesmo rollup reimplementado em três módulos, divergindo no primeiro bug. Foi a decisão mais cara das oito, e é a que evita que "notificação" vire o lugar onde regra de negócio de outros módulos se acumula.

Notificação é ponteiro, não relatório. O corpo carrega identificação, contexto não sensível e link — nunca valor sob permissão. A RN-O22 do Orçamento já dizia que sem read:budget-amounts os valores não vão "nem na API, nem no CSV, nem na notificação"; aqui isso deixa de ser regra do orçamento e vira regra do produto. O catálogo declara as variáveis de cada slug, e nenhuma delas pode ser sensível: a checagem acontece na semeadura, não em tempo de execução.

nexio.<entidade>.<verbo-no-passado>, e o AuditLog fecha junto. O slug é literalmente a ação da trilha com o prefixo do produto: a ação attachment.revoked tem o aviso nexio.attachment.revoked. Fecha na mesma conversa a convenção de nomes de ação que a spec de Anexo propôs e não fechou. O prefixo não é enfeite: NotificationTemplate é tabela global do framework, e vai conviver com os slugs do próximo produto Gryd.

Onde a ação mora, já que o AuditLog não tem coluna para ela. A convenção vale só para evento de negócio — o que se registra por IAuditLogService.RecordAsync, como "baixou o anexo" ou "aprovou o passo". Esses gravam a ação em AdditionalData, sob a chave fixa action, e a consulta por ação é filtro sobre esse metadado; índice sobre ele é decisão de infraestrutura, para quando o banco estiver escolhido. A entrada automática do interceptor de diff não tem ação: ela tem EntityType, EntityId e ChangeType, e é outra coisa — quem quer "o que mudou na linha" lê o diff, quem quer "o que a pessoa fez" lê a ação. Coluna própria Action no AuditLog é o lar definitivo e é spec de plataforma, no molde do GrydFiles; até lá nada no Nexio depende dela, porque a chave do metadado é contrato do produto.

v1 imediata com throttle; agrupamento declarado e não construído. O catálogo já nasce com digestEligible e throttleWindow. A v1 implementa só o throttle — a mesma tupla usuário + slug + entidade não repete dentro da janela —, que resolve barato o ruído de lembrete de SLA. O agrupador entra depois sem migração, porque os campos que ele precisa já existem e já estão preenchidos.

Usuário, depois tenant, depois o template global. Cascata de três, o mesmo desenho da resolução de taxa em Moeda e Câmbio e da herança de política em Orçamento. O campo Locale já existe no NotificationTemplate; o que faltava era dizer quem escolhe.

Aviso e fila, com a fila opcional a cada tentativa. Fecha o que a spec de Anexo deixou declarado em aberto. Quem tenta submeter um documento com anexo em Scanning escolhe entre ser avisado quando liberar ou deixar a submissão acontecer sozinha. Auto-submissão é ato com consequência — dispara aprovação e movimenta orçamento —, então ela é pedida, é cancelável, e desiste sozinha se o veredito do antivírus não for limpo.

Em lugar nenhum do catálogo — e é isso que ele prova. AssignmentRole = Watcher do Centro de Custo existe só para receber notificação e nunca aprova. Ele não é um slug, é um parâmetro do resolvedor: CostCenterOwners aceita includeWatchers, e os dois avisos de orçamento o ligam. Destinatário e decisor são eixos diferentes, e confundi-los é como se acaba mandando aviso só para quem tem alçada.

Nenhum slug de "documento criado", "campo alterado" ou "status mudou". Aviso de mudança de estado sem consequência para quem recebe é exatamente o que faz um usuário desligar a categoria inteira — e junto com ela o aviso que importava. A trilha do GrydAudit já responde "o que aconteceu com este documento"; notificação responde "você precisa fazer alguma coisa, ou alguém precisa saber agora".

Papel é do tenant: quem cria, renomeia e povoa é o cliente, e o produto não tem como saber que a controladoria dele se chama "Governança & Compliance". Por isso o Nexio semeia três papéis funcionais no TenantCreated, com chave estável e rótulo editável — Controladoria, Compras e Catalogo —, e é a chave que o catálogo de slugs cita. O cliente muda o rótulo, escolhe quem está em cada um e acrescenta os papéis que quiser; o que ele não faz é apagar a chave. É a mesma mecânica de semente com sobreposição já usada em NotificationTemplate, AttachmentType e ReasonCode — a quarta repetição dela no acervo. Novo em v1.8

Até 08/09/2026 seis slugs diziam TenantRole e nenhum dizia qual papel, e a definição não tinha campo para dizer. Consequência medida na validação: approval-step.authority_exceeded e budget.approval_requirement_unmet — os dois avisos criados exatamente para dizer "o controle não rodou" — entregavam a zero pessoas, sem erro. Um aviso de governança que não chega é pior do que não existir, porque alguém acredita que ele existe.

A alternativa era marcar variáveis como sensíveis e montar um corpo por pessoa, cortando o que ela não pode ver. Custa renderizar N vezes por notificação, resolver permissão fora do contexto de uma requisição — onde o token não existe — e ainda assim não resolve nada: o e-mail correto, entregue à pessoa certa, é encaminhado no dia seguinte para quem não podia ver. Um controle que depende de o destinatário não repassar não é controle.

Cada variável da definição declara a sua classe — Identifier, Label, DateOrCount, Link —, e o confronto com o RequiredVariables do template semeado acontece na inicialização. Variável sem classe, ou de classe fora das quatro, não sobe; a lista de nomes proibidos continua, agora como segunda malha e não como a única. É a diferença entre "não deixe passar total" e "só deixe passar o que se sabe classificar" — a primeira depende de alguém prever o nome errado, a segunda não. Assim a regra é verificada uma vez por deploy, e não vinte vezes por dia em tempo de execução.

digestEligible e entityKey em todas as vinte e sete definições, NotificationThrottle registrando o que já saiu, e o INotificationScheduler do framework. O que falta da v2 é a janela por usuário, o template de resumo e a decisão de o que fazer com um aviso obrigatório dentro de um agrupado — e essa última é a razão principal de não fazer agora.

Agrupamento é mais spec do que este documento inteiro, e o produto ainda não tem um cliente para dizer qual é a janela certa. O throttle resolve a maior parte do ruído por um custo de uma tabela de quatro colunas. Fazer o digest antes de existir volume é desenhar a solução com números inventados.

Dezenove linhas agrupadas pelas seis categorias, três colunas de canal com toggle. O que a categoria faz é agrupar, não desligar em bloco — não há interruptor de categoria, porque ele juntaria a sanção de fornecedor com o lembrete de cadastro.

Linha obrigatória mostra cada canal travado com cadeado e o mandatoryReason ao lado, em texto normal — não em tooltip. Os demais canais dessa linha continuam clicáveis.

Nada de "salvar": cada toggle é um PUT. E o rodapé diz a frase que evita o chamado mais comum: "avisos novos entram ligados ou desligados conforme o padrão do produto; o que você mudou aqui continua valendo."

Somente leitura, com read:notification-catalogs. Uma linha por slug com audiência, canais, janela, obrigatoriedade e as variáveis declaradas. Existe para responder, sem abrir código, as duas perguntas que o suporte recebe: "por que o fulano recebeu isso?" e "por que ninguém recebeu?".

A segunda pergunta é a que a coluna de audiência responde: nó sem Owner vigente entrega a zero pessoas, e isso é configuração do cliente, não defeito.

Aparece quando existe DeferredSubmission viva: "será enviado assim que a verificação terminar", com o que falta e um cancelar. É a única presença desta spec dentro de um documento transacional, e ela é uma faixa e um botão.

Depois de Abandoned, a faixa vira o motivo, com a ação que resolve — trocar o anexo infectado, ou pedir de novo.

Não existe tela de composição, de envio manual, de reenvio nem de caixa de saída. A caixa in-app é do UserNotification, que é do framework e já tem a sua. Escrever uma segunda seria o começo de um cliente de e-mail dentro de um sistema de compras.

ServiceNow, Jira e Oracle Fusion tratam a notificação como um registro de produto — evento, destinatário e template declarados —, não como uma chamada de e-mail espalhada pelo código. É a diferença entre conseguir responder "quais avisos este sistema emite?" abrindo uma tela e ter que rodar uma busca no repositório.

O notification scheme do Jira amarra evento a papel, e é excelente — até o cliente ter oito esquemas parecidos e ninguém saber qual projeto usa qual. A lição aplicada aqui: a audiência é do slug, não de um esquema configurável por tenant. Flexibilidade de destinatário é a origem mais comum de "não sei por que fulano recebeu".

Ariba e Coupa mandam lembrete de aprovação pendente e escalonam por tempo — e é justamente aí que aparece a fadiga de e-mail que faz o comprador criar uma regra de caixa de entrada. Daí vir o throttle na v1 e o digest declarado: o problema é conhecido antes de o produto ter o primeiro cliente.

GitHub, Slack e as suítes de RH convergiram no mesmo desenho: o padrão vem do produto, o usuário ajusta o que incomoda, e uma minoria mexe. É a razão de a tabela guardar exceção — e de a tela ter vinte linhas em vez de um assistente de configuração.

• Canal, entrega, retry e caixa in-app. Tudo do GrydNotifications: e-mail, push, in-app, tentativas, agendador e provedores.
• Template e renderização. Incluindo o override por tenant, que já funciona por TenantId no NotificationTemplate.
• Alerta de operador. Infraestrutura, fila de scan, base de assinaturas: da plataforma, e não passa por este catálogo.
• Editor de template. O texto se altera por semeadura ou por override, não por WYSIWYG dentro do produto.

• Digest. digestEligible, entityKey e o agendador já existem; falta janela por usuário, template de resumo e o tratamento do obrigatório dentro do agrupado. Entra sem migração.
• Horário de silêncio. "Nada de push entre 20h e 7h" é preferência de canal com janela, e cabe na mesma tabela — depois de existir push em uso real.
• SMS e WhatsApp. Canal novo é do framework. Aqui custaria uma linha em allowedChannels, e é isso que o enum de canal está preparado para receber.
• Notificação ao fornecedor pelo portal. Hoje só o controle bancário fala com quem está de fora. O resto depende da decisão sobre portal, que é a maior de escopo em aberto.
• Locale do fornecedor estrangeiro. SupplierType = Foreign poderia carregar o dele; a cascata já tem onde encaixar.