Não. Uma aplicação gerada aqui não envia e-mails, SMS nem notificações push, isto é verificável no pacote entregue: nenhuma das dependências declaradas é um cliente de mensagens, e a palavra-passe temporária de uma conta criada é exibida UMA ÚNICA VEZ no ecrã, em vez de ser enviada por e-mail. O que ela faz em vez disso é diferente, e muitas vezes suficiente: coloca à sua frente, no momento em que abre a aplicação, tudo o que está em atraso, uma faixa «em atraso» no topo das listas relevantes, um ícone de campainha e uma página de notificações, uma vista de calendário. E para o lembrete que realmente toca, delega essa tarefa no seu próprio calendário: um botão «Adicionar ao calendário» gera um ficheiro de evento padrão (.ics) que o seu dispositivo abre, o evento é então adicionado ao seu calendário habitual (telemóvel, Outlook ou Google Calendar), que é o que realmente toca. Se o envio automático for indispensável para si, o código da aplicação é seu e pode ser adaptado por um programador, esta página explica o que isso implica.
O que ela NÃO envia, e como verificar por si mesmo
Uma aplicação produzida aqui é um projeto Next.js e Prisma cuja lista de dependências está fixa e acessível: vinte e dois pacotes, quatro ferramentas de desenvolvimento, e nenhum cliente de e-mail, SMS ou notificações push. Renderização, base de dados, mapas, gráficos e Markdown estão todos presentes; o envio, não. Trata-se de uma ausência intencional, não de uma omissão descoberta apenas com o uso, é simplesmente uma linha que falta num ficheiro que pode abrir à vontade: o `package.json` viaja dentro do arquivo.
O pormenor que melhor confirma isto encontra-se noutro lugar, e é mais revelador do que qualquer lista: quando um administrador cria uma conta para um colega, a aplicação mostra a palavra-passe temporária no ecrã, uma única vez, e nunca a exibe novamente. Um produto capaz de enviar um e-mail teria feito precisamente isso, é o primeiro reflexo de qualquer software multiutilizador. Aqui, a instrução é copiar essa palavra-passe e transmiti-la pessoalmente. A restrição torna-se evidente logo na primeira conta criada, não seis meses depois.
Porque é que esta ausência resulta de uma escolha consciente, e não de um esquecimento: enviar um e-mail não se resume a uma linha de código. É preciso ter uma conta junto de um fornecedor de serviços de envio, um domínio autorizado a enviar em seu nome, registos DNS que o comprovem, e alguém para monitorizar as mensagens que falham. Uma aplicação entregue sem estes elementos enviaria mensagens que acabariam na pasta de lixo, o que é pior do que não enviar nada, pois dá a falsa impressão de que o destinatário foi avisado.
O que ela faz em vez disso: a data de vencimento vem até si à abertura
O princípio é invertido: em vez de procurar o utilizador, a aplicação coloca em destaque, logo à chegada, o que está em atraso. Quando uma entidade tem uma data de vencimento, uma intervenção a realizar, uma fatura a cobrar, um contrato a expirar, uma tarefa com data marcada, a lista correspondente exibe, no topo, uma faixa que indica quantos itens estão em atraso, antes da tabela e dos filtros. A pergunta «o que tenho de tratar hoje?» obtém resposta imediata, sem que seja necessário procurá-la.
Juntam-se-lhe duas superfícies mais convencionais. Um ícone de campainha no cabeçalho e uma página «Notificações» reúnem os registos a acompanhar, com o respetivo estado atual, lidos diretamente nos seus próprios dados, nunca num registo à parte. E, sempre que o contexto profissional o justifique, uma vista de calendário mostra os eventos na sua posição correta, por dia, por semana ou por mês (com vista mensal ao abrir), seguida, abaixo da grelha, de uma lista ordenada das próximas datas de vencimento. É a mesma pergunta formulada duas vezes, para quem prefere ler uma lista a interpretar um calendário.
O limite é real e merece ser mencionado: tudo isto pressupõe que alguém abra a aplicação. É o regime certo para uma ferramenta consultada diariamente, um planeamento de oficina, um caderno de intervenções, um acompanhamento de processos. É o regime errado para uma data de vencimento rara e distante, como «recontactar este cliente daqui a onze meses», que só será visível se aceder à aplicação nesse dia exato.
O lembrete que realmente toca: passar pelo seu calendário
É exatamente esse cenário que o botão «Adicionar ao calendário» resolve. Na ficha de um registo com data associada, a aplicação gera o ficheiro de evento padrão (.ics) que todos os calendários sabem ler, o mesmo formato usado nas convites recebidas por e-mail como anexo, e o seu dispositivo abre-o localmente. O evento integra então o seu calendário habitual, seja no telemóvel, no Outlook ou no Google Calendar, e é esse calendário que tocará, com o lembrete que já configurou.
A divisão de responsabilidades é clara, e é isso que a torna robusta: a aplicação gere os dados profissionais, o seu calendário gere o lembrete. Ela não precisa de saber a que horas quer ser avisado, em que dispositivo, ou se está de férias, tudo isso o seu calendário já sabe e faz melhor. O botão só aparece onde faz sentido: exclusivamente nas fichas cujos dados incluem efetivamente uma data.
A contrapartida é honesta: trata-se de um gesto pontual, não de uma subscrição contínua. Envie UM evento de cada vez, no momento em que consulta a ficha; a aplicação não envia nada automaticamente e não atualiza o seu calendário caso a data venha a ser alterada posteriormente. Para um pequeno número de datas de vencimento realmente críticas, isto é mais do que suficiente e não depende de nenhum serviço externo. Para um fluxo contínuo de dezenas de compromissos por semana, esta não é a ferramenta adequada, e é melhor saber isso desde o início.
Se o envio automático for indispensável para si
Existem dois caminhos possíveis, com esforços distintos. O primeiro não requer alterações ao código: cada lista inclui um botão de exportação que gera um ficheiro CSV das linhas exibidas, ou seja, filtradas exatamente como acabou de filtrá-las, não a tabela inteira. O ficheiro abre diretamente numa folha de cálculo, com separador e codificação já configurados, alimentando o mesmo sistema que já envia os seus e-mails. Filtrar «em atraso», exportar, fazer mala direta: é uma rotina semanal de cinco minutos que não cria novas dependências.
O segundo caminho é literalmente seu: o código da aplicação pertence-lhe, pode ser recuperado como arquivo ou num repositório Git, e corresponde a um projeto Next.js e Prisma convencional. Adicionar funcionalidade de envio de e-mails é um trabalho de desenvolvimento bem documentado, ligar um fornecedor de envios, redigir a mensagem, acionar a tarefa. O que custa não é o código: é configurar o domínio de envio, criar a conta junto do fornecedor e designar alguém para monitorizar as mensagens que falham. Uma agência ou um programador independente realiza esta tarefa rotineiramente.
O conselho válido para ambos os casos: comece por medir quantos lembretes enviaria efetivamente por semana. Muitas equipas descobrem que a faixa «em atraso», vista todas as manhãs, resolve cerca de noventa por cento da necessidade, e que as poucas datas remanescentes cabem facilmente num calendário partilhado. O envio automático é infraestrutura: justifica-se quando o volume o exige, não por princípio.