Define gatilhos, destinatários, conteúdo, preferências, tempo, acessibilidade e controles do usuário para notificações agendadas. Estabelece limites de adoção e evidências observáveis de falhas, mantendo limites específicos do ambiente configuráveis.
Status do pacote: contexto de referência pronto para revisão humana. O contrato e os cenários de teste estão completos, mas não se afirma que uma implementação adotante os tenha aprovado.
Decisão
Para notificações agendadas, adote uma intenção de notificação durável identificada independentemente das tentativas do provedor. Defina uma jornada do usuário determinística com estado visível, escolhas reversíveis quando possível, entrada preservada e recuperação acessível. Este pacote é um contrato de referência: a equipe adotante deve escolher limites numéricos, provedores, jurisdições e responsáveis operacionais com base em evidências do seu próprio ambiente.
Escopo
- Os atores, entradas, saídas, estados, versões de política ou esquema e resultados visíveis externamente descritos por este bloco de UX de notificações agendadas.
- Interfaces primárias e alternativas, trabalho em segundo plano, caches, integrações, caminhos de suporte e evidências que podem exercer o mesmo limite.
- Configuração específica de adoção, implantação, recuperação e responsabilidades de verificação necessárias para aplicar a referência com segurança.
Fora deste bloco
- Escolher um fornecedor universal, framework, jurisdição, limite numérico, período de retenção ou objetivo de nível de serviço para todos os adotantes.
- Afirmar que os cenários empacotados foram executados contra uma implementação a jusante ou que esta referência concede certificação legal, de segurança ou acessibilidade.
Contrato
- Criar uma intenção de notificação com destinatário, propósito, versão do modelo, localidade, agendamento, sensibilidade e identidade de deduplicação.
- Aplicar estado verificado do destinatário, preferências de canal, horários silenciosos e supressões legais ou de produto imediatamente antes do envio.
- Rastrear estados distintos como enfileirado, tentado, aceito, entregue quando observável, falhado, suprimido e cancelado.
- Limitar tentativas por provedor e preservar a mesma identidade da intenção para que um canal de fallback não crie ações duplicadas do usuário.
- Mostrar progresso apenas enquanto o trabalho estiver realmente pendente e evitar ativação duplicada sem ocultar a intenção comprometida do usuário.
- Usar mensagens simples e específicas para ação que distingam validação, permissão, conectividade, conflito e falha terminal.
- Persistir horário local pretendido, instante resolvido, fuso horário, regra de recorrência, versão da política e próxima ocorrência separadamente.
- No envio, revalidar elegibilidade e preferências do destinatário; intenção cancelada ou obsoleta não pode ser revivida por mensagem atrasada da fila.
Orientações de implementação
- Prototipar os caminhos mais longos, vazios, lentos, offline, negados e de tecnologia assistiva antes de definir o layout do caminho feliz.
- Modelar entradas, saídas, atores, estados, invariantes, efeitos colaterais e evidências das notificações agendadas antes de selecionar detalhes de framework ou fornecedor.
- Armazenar a versão aplicável do contrato ou política de notificações agendadas com estado material para que migrações, reprodução e decisões de suporte permaneçam atribuíveis.
- Introduzir o caminho por trás de implantação controlada, comparar resultados esperados e observados, e manter uma rota de recuperação testada até que a evidência de adoção esteja completa.
Tratamento de falhas e salvaguardas
- Falhas permanentes de endereço ou política suprimem novas tentativas; falhas transitórias usam tentativas limitadas e depois um estado terminal visível ao operador.
- Estado inválido ou contraditório de notificações agendadas é rejeitado ou colocado em quarentena; a implementação nunca supõe um valor que amplie autoridade ou duplique efeito.
- Tentativas são limitadas e usam identidade durável; após esgotamento, o trabalho alcança um estado terminal inspecionável com um responsável contabilizável.
Verificação e operações
- Completar a jornada com teclado, toque, leitor de tela, viewport estreito, rede atrasada e erro recuperável do servidor.
- Monitorar sucesso, negação, falha de validação, falha de dependência, esgotamento de tentativas e recuperação de notificações agendadas por versão do contrato sem dimensões sensíveis do payload.
- Reexecutar fixtures positivos e negativos emparelhados após mudanças de política, esquema, dependência, migração ou limite e preservar a evidência resultante.
Suposições de adoção
- Nomes e valores no exemplo são um fixture concreto, não padrões universais; adotantes os substituem por meio de evidências documentadas e propriedade.
- O sistema adotante pode fornecer identidade autenticada, versões duráveis de operação ou registro, telemetria limitada e um caminho controlado para mudanças.
Os exemplos com aparência executável neste pacote são fixtures e contratos de aceitação. Execute o validador da coleção para verificar estrutura e metadados, depois traduza e execute os cenários no repositório alvo antes de registrar evidências da implementação.