Análise das variações: o destinatário e o prazo exato são sempre obrigatórios. A etapa do lembrete e a resposta anterior alteram a abertura e não devem ser presumidas. O status do prazo determina se o e-mail pode confirmar uma nova data ou apenas reiterar o prazo atual. A oferta de suporte e o URL podem ser combinados em um único campo estruturado opcional.
Esquema mínimo: recipient (texto, obrigatório, não vazio); deadline (texto, obrigatório, deve incluir data, horário quando relevante e fuso horário); reminder_context (texto multilinha, obrigatório, indicar primeiro/segundo lembrete, resposta anterior e se alguma alteração foi aprovada; sem valor padrão); support_option (texto semelhante a objeto, opcional, indicar rótulo e URL HTTPS ou “nenhum”). Rejeitar personalidade do remetente, “amigável” e formato de saída como variáveis, pois são regras estáveis do modelo; rejeitar ID da conta e conteúdo do relatório por serem desnecessários.
Prompt revisado: “Redija um e-mail de lembrete em texto simples, amigável e direto. Destinatário: (recipient). Prazo atualmente aprovado: (deadline). Contexto do lembrete e resposta anterior: (reminder context). Opção de suporte opcional: (support option). Use somente os fatos fornecidos. Nunca sugira prorrogação ou aprovação que não esteja explicitamente declarada. Se faltarem o destinatário, o prazo ou o status de aprovação após uma solicitação de alteração, retorne uma lista de campos ausentes em vez de um e-mail. Inclua o suporte somente quando fornecido. Retorne o assunto e o corpo.”
Exemplo preenchido: recipient “Amira”; deadline “4 de setembro de 2026, 17:00 Europe/London”; context “primeiro lembrete; sem resposta anterior; prazo inalterado”; support “Horário de atendimento opcional — https://example.org/office”. Caso ausente: se o contexto disser “prorrogação solicitada”, mas omitir a aprovação, retornar “Ausente: status de aprovação da prorrogação”. Migração: manter recipient e deadline; mapear link válido para support_option; exigir o novo reminder_context.