Agentes de IA — funil comercial

Regras que valem para todos os agentes desta página:

• O modelo escreve, o código decide. Preço, estágio, dono do Lead e envio ao lead nunca saem do texto do modelo: o código valida cada campo contra um vocabulário fechado e descarta o resto.
• Custo registrado. Toda chamada ao modelo grava uma linha em ia_chamadas (rótulo, modelo, tokens, US$), que soma no uso de IA do mês da Organização.
• Limite de IA da Organização (ADR-0009). Nenhum agente chama o modelo com a Organização no limite mensal: chamarClaude e o SDR, que monta a chamada no SDK, conferem iaBloqueada() antes e registram o evento limite_ia_atingido.
• Contexto da Organização (ADR-0011). Os agentes falam como a Organização em que rodam, não como a Witbiz. contextoOrganizacional(env, secoes, limite) (src/perfil/contexto.ts) lê o perfil de IA publicado e devolve o nome, o texto das seções que aquele agente consome (SECOES_*), a versão e a confiança. O system prompt passa a ser identidadeDoAgente(papel, ctx) ("Você é o … de {Organização} ({resumo do negócio})") + as regras fixas do código + blocoPerfil(ctx). O bloco do perfil diz que as regras do código prevalecem e que preço só vem do catálogo; aiInstructions e organizationalKnowledge entram delimitados como dados. Sem perfil gravado, a Witbiz (organização 1) usa o perfil importado do código e as demais recebem só a identidade com o nome delas. Onde o hash existe, a versão do perfil entra nele: perfil novo → análise refeita. Usam o perfil: SDR, leitura do site, resumo, próxima ação, estratégia, detalhamento, briefing, rascunho e Reunião→CRM (os dois últimos desde 12/10/2026: identidadeDoAgente com SECOES_ESTRATEGIA e SECOES_RESUMO; nenhum prompt do funil diz mais "da Witbiz" fixo).
• Vocabulário proibido. Na próxima ação e na estratégia, limparSaida tira da saída os termos de forbiddenVocabulary do perfil (com as flexões) e registra o evento vocabulario_proibido_removido com o agente e os termos.
• Condições comerciais. Parcelas, desconto à vista e validade vêm do perfil (pricingRules, proposalRules) quando a Organização os definiu; senão, de CONDICOES_COMERCIAIS do código (condicoesDoPerfil / condicoesDaOrganizacao, src/perfil/condicoes.ts).
• Contexto documental (ADR-0010, fase 1). promptDocumental(area) (src/conhecimento/contexto.ts) anexa ao system prompt a seção "Regras de negócio" do documento funcional da área, e versaoDocumental(area) põe a versão do documento no hash. Neste funil, só a estratégia usa (área propostas). Desde a fase 3, entram também as regras comerciais que a própria organização escreveu (documentos do tipo regras), delimitadas como dados depois das regras fixas, e a versão delas vai no mesmo hash — regra revisada, estratégia refeita.
• Ações do Consultor na página do lead. POST /radar/lead/:id (reler o site, atualizar o resumo, gerar a próxima ação, a estratégia ou o rascunho, registrar reunião) só roda se o lead existe na Organização da sessão; senão, responde 404 "Lead não encontrado" antes de qualquer escrita ou chamada ao modelo.
• Modelos. MODELO = 'claude-sonnet-5' (padrão, em src/claude.ts); MODELO_PROXIMA_ACAO e MODELO_ESTRATEGIA = 'claude-opus-5'. Orquestração, cache e limite de IA estão em [Orquestração, memória e contexto dos agentes](ia/orquestracao).

Agente SDR (triagem no site)

Rótulo técnico: sdr — src/agente.ts.

• Objetivo: conduzir a Triagem no chat do site até a Pré-proposta e o Handoff. Registra o que descobre sobre o Lead, mas não negocia preço, não fecha contrato e não promete resultado.
• Gatilho: POST /api/chat, uma chamada por mensagem do visitante. A primeira abertura devolve uma saudação fixa sem chamar o modelo. Limite por IP (binding + KV) e teto de 30 mensagens do visitante por conversa (MAX_MENSAGENS). Passando disso, a conversa é encerrada com o e-mail de contato.
• Entradas: o system prompt (montarSistemaDaOrganizacao → montarSistema(env, ctx): roteiro em 7 blocos, regras de escopo, catálogo com ids e faixas de catalogoParaPrompt() — só itens ativos na Organização —, condições comerciais do perfil e o bloco do perfil com SECOES_SDR, até 3.500 caracteres) e a transcrição inteira de conversas.transcricao. O que muda por Organização:
• Witbiz (organização 1): a identidade de sempre ("Agente de Qualificação da Witbiz…"), o handoff para Alberto ou Carolina com os links de agenda (AGENDA_*) e a lista do que a Witbiz não faz.
• Demais: identidadeDoAgente('Agente de Qualificação', ctx); o handoff diz que um Consultor da Organização continua e pede dia e horário, sem nomes nem links de agenda; o "não faz" vem de proposalRules.naoIncluirPadrao do perfil (omitido se vazio).
• Saudação (fixa, sem modelo): a Witbiz mantém "Sou a IA da Witbiz…"; as demais recebem "Sou a assistente de {Organização}…" (saudacao).
• Saídas: texto em streaming (SSE) para o visitante, mais o estado pela ferramenta atualizar_estado (tool use, tool_choice: auto), chamada ao fim de toda resposta. Campos: ficha do lead, vertical, momento, porte_classe, origem, consentimento, qualificado, handoff, motivo_handoff, pre_proposta (ids do catálogo + motivo + fase) e encerrar. O estado nunca aparece para o visitante. Grava em leads, conversas, pre_propostas (e espelha como versão 0 da Proposta CPQ, espelharPre) e eventos.
• Modelo e versão do prompt: MODELO (claude-sonnet-5), max_tokens: 2048, cache de prompt no system. Não há constante de versão do prompt.
• Validação em código:
• Cada campo é aparado a 500 caracteres. vertical, momento, porte_classe e origem só entram se estiverem no vocabulário.
• E-mail em minúsculas; e-mail já conhecido reaproveita o lead existente (evento lead_reaproveitado).
• O link de captação não sobrescreve uma origem já registrada.
• O preço nunca vem do modelo. montarPreProposta (src/catalogo.ts) descarta ids fora do catálogo, agrupa 2+ agentes da mesma máquina em suíte e 4+ módulos em implantação completa, e precifica pelo porte. O bloco de investimento é anexado pelo código ao texto.
• Só gera uma Pré-proposta nova se não houver outra vigente. A validade (valido_ate) usa a validade das condições da Organização.
• O bloco de investimento anexado ao texto e o e-mail da Pré-proposta ainda escrevem o desconto e a validade de CONDICOES_COMERCIAIS do código, e montarPreProposta parcela pelo código.
• Fallback: recusa ou resposta vazia vira um texto fixo pedindo um consultor humano, com handoff: true e motivo refusal. Erro da API vira {erro: 'ia'} no stream. Sem regra determinística para conduzir a conversa.
• Limite de IA da Organização: antes de cada turno, iaBloqueada(env, 'sdr'). No limite, o modelo não é chamado e o visitante não vê erro técnico: recebe um texto fixo (mensagemSemIa) com o formulário de contato (/#contato) e contato@witbiz.com.br, e a conversa se encerra. Se o visitante já virou lead, ele passa ao estágio handoff com o motivo limite_ia, ganha dono pela Vertical e os Consultores recebem o e-mail de sempre. A cadeia:handoff não é disparada, porque os agentes dela também estariam sem IA.
• Handoff humano: handoff: true passa o lead para o estágio handoff, dá dono pela Vertical (consultorParaVertical), manda e-mail e grava o evento handoff. Destino do e-mail (notificarConsultores): na Witbiz, EMAIL_ALBERTO (Tech, ambos ou sem vertical) e/ou EMAIL_CAROLINA (Growth, ambos); nas demais Organizações, o e-mail do dono do lead (emailDoConsultor) ou, sem ele, os admins dela (emailsDeAviso) — nunca a Witbiz; sem destinatário, só um aviso no log. Pedido de desconto, reclamação, jurídico, imprensa ou pedido de humano geram handoff imediato. Com handoff ou encerrar, o código dispara a cadeia:handoff (site → embedding → resumo → próxima ação).

Leitura do site

Rótulo técnico: site — src/site.ts.

• Objetivo: enriquecer o lead com o que o site da empresa mostra, sem substituir o que o lead disse.
• Gatilho: primeiro elo da cadeia:handoff. Também o botão "Reler o site" na página do lead (POST /radar/lead/:id, ação ler_site, com forcar).
• Entradas: o HTML da página inicial de leads.site_empresa (URL normalizada; localhost e IP recusados; até 400 KB; timeout de 10 s). O modelo recebe título, descrição, até 12.000 caracteres de texto limpo e o que o lead disse (empresa, setor, porte, dor). O system diz que a leitura é para os Consultores da Organização e leva o bloco do perfil (SECOES_SITE: resumo do negócio e cliente ideal, até 1.200 caracteres).
• Saídas: analises_ia tipo site, com {url, titulo, descricao, sinais, fatos[3–5], erro?} e evento site_lido. siteParaPrompt() injeta o resultado nos prompts do resumo, da próxima ação, do rascunho, da estratégia e do detalhamento.
• Modelo e versão do prompt: MODELO, maxTokens: 700, thinking: 'disabled', VERSAO_PROMPT_SITE = 'site-v1'.
• Validação em código: os sinais técnicos (GA4, GTM, pixel Meta, CRM, plataforma, WhatsApp, chat, formulário, JSON-LD, idioma) saem de regex no HTML (sinaisDoSite), não do modelo. Dos fatos, só as linhas em bullet entram, no máximo 5. A leitura é idempotente por hash de {versão, url} (a versão do perfil não entra: perfil novo não relê o site).
• Fallback: falha de rede ou página vazia grava uma análise com erro, para ninguém tentar de novo em loop. Modelo sem resposta também grava com erro (modelo indisponível ou modelo não resumiu); os sinais por regex continuam valendo.
• Handoff humano: nenhum. É só leitura, exibida no cartão "Sobre a empresa".

Resumo do lead

Rótulo técnico: resumo — src/resumo.ts.

• Objetivo: resumir o lead em 4 linhas para o Consultor: Quem · Dor · Recomendado · Situação.
• Gatilho: cadeia:handoff, depois do site e do embedding. Também o botão "Atualizar" na página do lead (ação resumo, com forcar).
• Entradas: a ficha do lead, a última Pré-proposta (itens, total, status, aberturas, validade), os 12 últimos eventos, a leitura do site e a transcrição da Triagem. System com identidadeDoAgente('resumidor de leads da Radhr AI', ctx) e o bloco do perfil (SECOES_RESUMO, até 2.500 caracteres).
• Saídas: analises_ia tipo resumo, com {quem, dor, recomendado, situacao, texto?}, uma linha em ia_chamadas (rótulo resumo, com o lead) e o evento resumo_gerado. É lido pela próxima ação, pela estratégia, pelo contrato, pelo escopo, pela expansão e pelo Copiloto (ler_lead).
• Modelo e versão do prompt: MODELO, maxTokens: 600, VERSAO_PROMPT_RESUMO = 'resumo-v1'.
• Validação em código: separarLinhas procura os quatro rótulos. Se faltar algum, guarda o texto bruto em texto. Idempotente por hash (versão do perfil, ficha, tamanho da transcrição, pré-proposta, último evento, site).
• Fallback: nenhum. Sem resposta do modelo, devolve null.
• Handoff humano: nenhum.
• Custo: fica em analises_ia.custo_usd e em ia_chamadas, e por isso entra no uso de IA do mês da Organização (até 25/09/2026, o resumo ficava fora). A chamada é registrada mesmo quando o texto vem vazio. Quando o hash repete, a análise é reaproveitada sem custo.

Próxima ação

Rótulo técnico: proxima_acao — src/proxima-acao.ts.

• Objetivo: dizer ao Consultor a única ação que mais aumenta a chance de conversão agora, com o e-mail ou a mensagem já escritos. Também lê o risco do negócio no texto (Deal Risk, camada 2).
• Gatilho:
• pela fila (com retentativa quando o binding FILA existe):
• cadeia:handoff (último elo);
• cadeia:abertura: abertura da Pré-proposta (GET /p/:codigo) e da Proposta (/pp, origem proposta_aberta);
• cadeia:detalhamento_fechado: fechamento da etapa 2 (POST /d/:codigo/fechar, com forcar);
• direto, porque o resultado é usado na hora ou é um gatilho avulso:
• aceite da Proposta;
• reunião registrada ou marcada (o Consultor volta à página esperando a ação nova);
• WhatsApp recebido;
• webhooks de e-mail do Resend;
• formulário de contato;
• cron horário de silêncio (rodarCronSilencio; o e-mail leva a sugestão);
• botão do Consultor (ação gerar_proxima).

Sem forcar, não gera outra enquanto houver uma pendente com menos de 6 h (INTERVALO_MINIMO_H).

• Entradas: system com identidadeDoAgente('motor de próxima ação da Radhr AI', ctx), as regras da Organização e o bloco do perfil (SECOES_PROXIMA_ACAO: playbook, objeções, tom, vocabulário, instruções; até 3.000 caracteres). Na mensagem: data de hoje, o Consultor que assina (nome, vertical, link de agenda; sem dono, "Consultor de {Organização}"), as condições publicadas da Organização, a ficha (sem o e-mail e o telefone em si, só "sim/não"), o resumo, a Pré-proposta com link, a leitura do site, os 15 últimos eventos (com o texto das notas, o motivo de ações dispensadas e o assunto de e-mails) e as 8 últimas mensagens da Triagem.
• Saídas: JSON de uma linha {acao, titulo, porque, urgencia, assunto, rascunho, alternativa, confianca, risco}. Grava em recomendacoes_ia (tipo proxima_acao, status pendente; as pendentes anteriores do lead viram expirada). O risco vai para analises_ia tipo risco. Grava também o evento proxima_acao_gerada.
• Modelo e versão do prompt: MODELO_PROXIMA_ACAO = 'claude-opus-5', maxTokens: 1500, VERSAO_PROMPT_ACAO = 'proxima-acao-v1'.
• **Validação em código (interpretarSaida):**
• acao só do vocabulário ACOES (enviar_email, enviar_whatsapp, ligar, propor_horario, ajustar_pre_proposta, gerar_proposta, aguardar, marcar_perdido).
• titulo e porque são obrigatórios.
• E-mail, WhatsApp e propor horário exigem rascunho.
• urgencia fora do vocabulário vira hoje; confianca fica entre 0 e 1; risco.nivel só baixo/medio/alto.
• Quebras de linha cruas dentro de strings são escapadas.
• Uma ação que depende de um canal que o lead não tem é trocada, para nunca virar botão morto: sem e-mail → WhatsApp ou ligar; sem telefone → e-mail ou aguardar.
• Idempotente por hash (versão do perfil, ficha, resumo, pré-proposta, último evento, dono). Um estado já decidido não gera de novo.
• Vocabulário proibido do perfil sai de titulo, assunto, rascunho e porque (evento vocabulario_proibido_removido).
• interpretarSaida tem casos fixos em test/avaliacao/proxima_acao.json, rodados no CI sem modelo.
• Lead fechado (ganho/perdido) não recebe próxima ação.
• Fallback: nenhum no modelo. Saída inválida ou erro devolvem null (nunca lançam) e a Home segue com as regras próprias (hoje.ts).
• Handoff humano: a ação nunca é executada sozinha. O Consultor envia (texto igual → executada; texto alterado → editada) ou dispensa com motivo (dispensada), por resolverRecomendacao. O desfecho fica registrado como dado de treino.

Rascunho da proposta (legado)

Rótulo técnico: rascunho — src/radar/lead.ts (gerarRascunho).

• Objetivo: escrever em markdown o rascunho da proposta formal (estrutura aprovada em 5 partes), para o Consultor revisar. Está em desuso desde o editor CPQ (F1).
• Gatilho: só manual, pelo botão "Gerar rascunho com IA" (POST /radar/lead/:id, ação gerar_rascunho).
• Entradas: o lead inteiro (JSON.stringify(lead)), a última Pré-proposta com o motivo de ajuste do Consultor, as 10 últimas notas, a leitura do site, a estratégia e a transcrição da Triagem.
• Saídas: uma linha nova em propostas_rascunho (as versões anteriores são mantidas) e o evento rascunho_gerado.
• Modelo e versão do prompt: MODELO (padrão de chamarClaude), maxTokens: 8000. Sem constante de versão.
• Contexto da Organização: identidadeDoAgente('consultor sênior', ctx) com SECOES_ESTRATEGIA (limite 1.500 caracteres); o título do texto é "# Proposta {Organização} — <empresa>" (Witbiz só quando não há contexto). A estratégia, as notas e o site continuam entrando como antes.
• Validação em código: só limparMarkdown, que tira a cerca de código e o preâmbulo antes do título. O valor não é validado. O prompt manda partir do Valor de referência da Pré-proposta e nunca inventar desconto.
• Fallback: nenhum. Resposta vazia mostra o aviso "Falha ao gerar o rascunho".
• Handoff humano: total. O Consultor edita, aprova e envia (salvar_rascunho, aprovar_rascunho, enviar_proposta). Nada vai ao lead sem essa ação.

Proposal Strategist

Rótulo técnico: estrategia — src/estrategia.ts.

• Objetivo: antes da proposta formal, entregar ao Consultor a estratégia do negócio: posicionamento do valor, objeções com resposta, argumentos, riscos, uma alternativa de escopo, as condições e a frase de abertura.
• Gatilho: botão na página do lead (ação gerar_estrategia, com forcar). A fila tem um executor estrategia, mas nenhuma cadeia o chama hoje.
• Entradas:
• a ficha do lead;
• a Pré-proposta (com a marca de etapa 2, se houver);
• o resumo e o risco lido pela IA;
• a leitura do site e a última reunião;
• as 10 últimas notas;
• leads fechados parecidos (regra por setor/momento/porte de leadsParecidos, sem vetores);
• as 14 últimas mensagens da Triagem;
• no system: identidadeDoAgente('estrategista de propostas', ctx), as condições da Organização (parcelas e desconto à vista do perfil ou do código), o bloco do perfil (SECOES_ESTRATEGIA: posicionamento, proposta de valor, diferenciais, playbook, objeções, negociação, regras de preço, tom; até 3.500 caracteres) e as regras de negócio do documento funcional de propostas (promptDocumental('propostas')).
• Saídas: analises_ia tipo estrategia e evento estrategia_gerada. Aparece na página do lead e entra no prompt do rascunho (estrategiaParaPrompt).
• Modelo e versão do prompt: MODELO_ESTRATEGIA = 'claude-opus-5', maxTokens: 4000, VERSAO_PROMPT_ESTRATEGIA = 'estrategia-v1'.
• Validação em código: interpretarEstrategia exige posicionamento e condicoes, corta os tamanhos, aceita até 5 objeções completas e até 6 argumentos e riscos. As condições vêm fixadas no prompt (parcelamento e desconto à vista da Organização), mas o texto não é conferido contra elas. Vocabulário proibido do perfil sai de todos os campos (evento vocabulario_proibido_removido). Idempotente por hash (versão do prompt, versão do perfil, lead, pré-proposta, resumo, site, reunião, última nota e versão do documento de propostas). Casos fixos em test/avaliacao/estrategia.json.
• Fallback: nenhum. Saída inválida devolve null.
• Handoff humano: é material de apoio. Quem define preço e condições é o Consultor no editor da Proposta.

Detalhamento (etapa 2 do diagnóstico)

Rótulo técnico: detalhamento — src/detalhar.ts.

• Objetivo: ler as respostas do questionário guiado da etapa 2 e a conversa da etapa 1, e recomendar itens de todo o catálogo (módulos, Sprint, os 15 agentes e os adicionais), com o porquê de cada um.
• Gatilho: POST /d/:codigo/recomendar, público (a chave é o código da Pré-proposta), com limite por IP. O fechamento (POST /d/:codigo/fechar) não chama o modelo.
• Entradas:
• a ficha do lead;
• a Pré-proposta da etapa 1;
• as respostas em texto e os sinais derivados;
• a sugestão da regra;
• a leitura do site;
• o catálogo com faixas e "quando" e os agentes com sinais — só o que está ativo no catálogo da Organização (itemAtivo/agenteAtivo);
• a transcrição da etapa 1;
• no system: identidadeDoAgente('consultor sênior', ctx) e o bloco do perfil (SECOES_ETAPA2, até 2.500 caracteres).
• Saídas: {leitura, itens[{id, agente?, motivo, fase}], ia} devolvido à página e gravado em analises_ia tipo detalhamento. No fechamento, a escolha do visitante vira uma nova Pré-proposta (evento pre_proposta_detalhada), é espelhada no CPQ (etapa2) e dispara a próxima ação com forcar.
• Modelo e versão do prompt: MODELO, maxTokens: 4000, thinking: 'disabled', VERSAO_PROMPT_DETALHAMENTO = 'detalhamento-v1'.
• Validação em código:
• interpretarLeitura aceita só ids existentes no catálogo e ativos na Organização; a regra também descarta os inativos.
• ai.agente sem agente válido é descartado.
• fase só 1 ou 2; motivo até 300 caracteres.
• JSON cortado pelo max_tokens é aproveitado até o último item completo.
• No fechamento, montarPreProposta precifica: o modelo nunca dá valor.
• Cache: idempotente por hash de {versão, pré-proposta, respostas}; a versão do perfil não entra.
• Página e e-mail: /d/:codigo usa a identidade pública da Organização (identidadeDaOrganizacao: logo, nome, rodapé e CSS) e as condições dela (parcelas, desconto, validade); a soma no navegador só agrupa em suíte ou implantação completa se o item agrupado estiver ativo. No fechamento, a validade da nova Pré-proposta vem das condições da Organização e o assunto do e-mail leva o nome curto dela.
• Fallback: recomendarPorRegra, uma regra determinística pelos sinais. Ela é a base do prompt e também a resposta quando o modelo falha. A falha grava o evento detalhamento_ia_falhou, com o início e o fim do texto bruto, e não fica em cache.
• Handoff humano: o visitante liga e desliga itens. A página diz que um Consultor confirma tudo antes da proposta formal.

Reunião → CRM

Rótulo técnico: reuniao — src/reuniao.ts.

• Objetivo: transformar anotações ou a transcrição de uma reunião em registro na Radhr AI: resumo, decisões, compromissos com prazo, campos do lead e estágio sugerido.
• Gatilho: o Consultor cola o texto na página do lead (POST /radar/lead/:id, ação registrar_reuniao, mínimo de 20 caracteres, até 30.000).
• Entradas: a identidade da Organização (identidadeDoAgente com SECOES_RESUMO, limite 1.200 caracteres; antes o prompt era fixo da Witbiz), a data de hoje (Brasília), a ficha resumida do lead (nome, empresa, cargo, estágio, dor, orçamento, urgência), o nome do Consultor e o texto. Compromissos "de: witbiz" significam "da contratada" (valor do enum, não a marca).
• Saídas:
• analises_ia tipo reuniao, com a saída, o texto, as tarefas criadas, os campos preenchidos e quem registrou;
• tarefas em tarefas (origem ia; compromissos do cliente viram "Cobrar: …");
• o evento reuniao_registrada;
• uma nova próxima ação com forcar.
• Modelo e versão do prompt: MODELO, maxTokens: 2500, thinking: 'disabled', VERSAO_PROMPT_REUNIAO = 'reuniao-v1'.
• **Validação em código (interpretarReuniao):**
• resumo é obrigatório.
• Datas só no formato AAAA-MM-DD. Prazo vazio ou no passado vira hoje.
• No máximo 8 compromissos. de só witbiz/cliente.
• Campos só da lista CAMPOS_LEAD, e só preenchem o que estava vazio: o que o Consultor já registrou vence.
• estagio_sugerido só do vocabulário.
• Fallback: sem leitura do modelo, o texto não se perde: vira um evento nota com o prefixo "[reunião, sem leitura da IA]".
• Handoff humano: o estágio nunca muda sozinho. A sugestão aparece no aviso e o Consultor decide no seletor.

Briefing da Home

Rótulo técnico: briefing — src/briefing.ts.

• Objetivo: um parágrafo de 2 a 3 frases (até 320 caracteres) no topo da Home (AI Command Center), narrando o que pesa hoje na fila do Consultor.
• Gatilho: abrir a Home (GET /radar/). Não roda se a fila não tiver ações nem riscos — nem quando a Home redireciona o primeiro acesso para as boas-vindas (ADR-0013).
• Entradas: o system cita o Consultor e a Organização e leva o bloco do perfil (SECOES_BRIEFING: resumo do negócio, tom, vocabulário, metas; até 1.500 caracteres). Na mensagem, só o que a fila já mostra (entradaDoBriefing): o dia, as ações (quem, título, urgência, valor, se é da IA ou tarefa), os riscos, as chegadas, o pipeline, os leads abertos, as tarefas atrasadas e a carteira.
• Saídas: analises_ia tipo briefing com alvo usuario. Mesmos dados e mesma versão do perfil no mesmo dia (hash) não chamam o modelo de novo.
• Modelo e versão do prompt: MODELO, maxTokens: 220, thinking: 'disabled', versão 'briefing-v1' (constante local VERSAO_PROMPT).
• Validação em código: espaços normalizados, corte em 400 caracteres, e recusa descartada. O custo só é registrado quando há texto.
• Fallback: a Home usa a frase determinística quando o modelo falha, recusa ou a fila está vazia.
• Handoff humano: nenhum (só leitura).