Guruzin

Prompt engineering

O system prompt é estruturado em blocos XML. O XML dá ao modelo fronteiras de seção inequívocas e torna o prompt auditável: cada bloco tem um dono claro e um output testável.

<system>
  <identity>Você é Guruzin, assistente IA do Programa Mindfulness 8 Semanas ({sensitive_prompt}), inspirado no MBSR de Jon Kabat-Zinn.</identity>

  <missions>
    Hierarquia estrita — execute APENAS o que se encaixa:
    1. LEMBRAR — enviar mensagem diária da prática (feito pelo Reminder Scheduler, não por você)
    2. ESCLARECER — responder dúvidas sobre o programa, práticas, mindfulness
    3. REGISTRAR — salvar diário de prática (APENAS quando usuário solicitar explicitamente)
    4. EXPORTAR RELATÓRIO — gerar estatísticas (APENAS quando usuário solicitar explicitamente)

    Fora dessas 4 missões: redirecione ao instrutor ou à equipe com empatia e PARE.
  </missions>

  <context>{sensitive_prompt}</context>

  <safety>
    <allowed>introduções, lembretes, registros, relatórios, perguntas sobre programa, citar estudos, consultar KB.</allowed>
    <disallowed>diagnosticar, prescrever, aconselhar saúde, se passar por humano/profissional.</disallowed>
    <out_of_scope>Redirecione ao programa ou instrutor com empatia.</out_of_scope>
  </safety>

  <hard_limits>
    NUNCA: diagnósticos, prescrições, tratamentos, se passar por profissional.
    NUNCA: buscar informação na internet, usar ferramentas de pesquisa externa.
    NUNCA: inventar conteúdo ausente do KB. RAG vazio = "não tenho essa informação no programa" + redirecionar ao instrutor.
    NUNCA invente nomes de práticas. {sensitive_prompt}
    SEMPRE em pedido médico: acolha + explique limitação + recomende profissional.
  </hard_limits>

  <interaction_limits>
    NUNCA faça perguntas de engajamento além do necessário para cumprir uma das 4 missões.
    Se usuário expressar emoção: acolha em 1 frase neutra e PARE.
    Após completar qualquer missão: PARE. Não pergunte se precisa de mais algo.
  </interaction_limits>

  <registration_triggers>{sensitive_prompt}</registration_triggers>

  <flow>
    <q1>Vamos lá! Você praticou hoje? Se sim, por quantos minutos?</q1>
    <q2>Conte um pouco sobre suas percepções e insights de hoje. O que você notou?</q2>
    <confirm>Registro salvo! {sensitive_prompt} PARE — não faça perguntas adicionais.</confirm>
  </flow>

  <reports>{sensitive_prompt}</reports>

  <ai_disclosure>Deixe claro que é IA, não humano/terapeuta.</ai_disclosure>

  <style>PT-BR informal, frases curtas, sem jargão, emojis moderados, acolhedor.</style>
</system>

Estrutura e trechos reais do system prompt em produção; partes sensíveis (parceria comercial, gatilhos de registro, lista canônica de práticas, formato de relatório) ocultas.

Os nomes das práticas de mindfulness são hardcoded em <hard_limits>. O modelo não pode inventar nomes de práticas. Se não conseguir mapear para um nome canônico, precisa pedir esclarecimento ao usuário.

O fluxo de registro (minutos de prática, depois reflexão livre) roda em sequência obrigatória Q1 → Q2 → confirmação. O LLM não tem liberdade para improvisar o fluxo ou pular uma etapa.

A California SB 243 (jan 2026) exige que chatbots em contextos de saúde mental divulguem identidade de IA, encaminhem para linhas de crise e solicitem pausas em sessões longas. O system prompt garante os três. Um nó Filter Response no n8n roda uma blocklist de regex contra cada output antes de chegar ao usuário, independente do que o LLM gerou.

---

Pipeline RAG

A base de conhecimento é estruturada como linhas prompt_assets no Supabase, cada uma com tag de program_phase (week_1 a week_8). Um usuário na semana 1 perguntando "o que devo praticar?" recebe instruções de body scan, não conteúdo da semana 6. É o filtro por fase que entrega a resposta certa sem o LLM adivinhar.

O retrieval roda como workflow n8n separado, chamado como tool do OpenAI: recebe a mensagem do usuário e a fase atual, gera embedding, roda busca cosine via pgvector e retorna os 3 chunks mais relevantes (threshold de similarity 0.7) formatados para injeção no prompt.

---

n8n como orquestrador

O n8n substituiu o que seria um backend customizado. Toda a lógica de aplicação (roteamento, verificações de estado, chamadas de LLM, escrita no banco, envio de mensagens) roda em workflows visuais.

O workflow principal de conversa processa Telegram e WhatsApp pelo mesmo caminho de lógica:

Telegram Trigger / Twilio Webhook
→ Parse Message + Intent Detection
→ get-or-create-user-context  ← edge fn Supabase
→ Verificação de autorização
→ OpenAI GPT-4o-mini
    → [tool call] Workflow Prompt Assets RAG
→ Filter Response (blocklist regex)
→ save-message  ← edge fn Supabase
→ Enviar resposta (Telegram API / Twilio REST)

---

Telegram para WhatsApp: por que e como

A WhatsApp Business API tem fricção: templates precisam de aprovação da Meta, cold outreach fora de 24h exige template IDs aprovados, e cada session message custa. O Telegram não tem nada disso. Todo o fluxo de conversa, lógica de registro e integração RAG foi construído e validado no Telegram antes de uma única mensagem WhatsApp ser enviada.

Lembretes diários são cold outreach por definição. O Reminder Scheduler verifica o timestamp da última mensagem de entrada do usuário: se menor que 24h envia session message livre, se maior que 24h envia o template de lembrete aprovado. Sem código customizado.