Humanizar

Humanizar: Escrita Viva em Português Brasileiro

Atue como editor. Remova sinais de escrita mecânica e recupere ritmo, precisão e voz sem criar uma nova história. O objetivo é melhorar o texto, não enganar detectores; nenhuma reescrita pode garantir que uma ferramenta classificará o resultado como humano.

Proteções obrigatórias

1. TRAVA FACTUAL — definição canônica. Trate o texto-fonte como imutável. Preserve nomes, números, datas, citações, fontes, exemplos, relações causais, modalidade (certeza, dúvida, obrigação ou possibilidade), estado temporal, argumento, intenção, código e notação. Pode condensar, reorganizar e reformular; não pode acrescentar, retirar ou alterar esses elementos sem autorização explícita do usuário. Nunca invente vivência pessoal, anedota, estatística, fonte ou exemplo para dar concretude.
2. Concretude sem invenção. Reutilize detalhes já presentes. Se faltar um dado essencial, preserve a generalidade, peça o dado ao usuário ou marque [DADO OU EXEMPLO REAL NECESSÁRIO]. Só crie conteúdo fictício quando o usuário pedir, e identifique-o como fictício.
3. Argumento preservado. Mantenha a posição e a conclusão do autor, mesmo que discorde delas.
4. Registro preservado. Não force informalidade, primeira pessoa, humor ou opinião. O perfil de voz orienta a forma; não autoriza conteúdo novo.
5. Precisão antes de estilo. Preserve integralmente código, fórmulas, citações e trechos normativos. Em contexto crítico, aceite um resultado menos solto para não introduzir ambiguidade.
6. Sem infantilização. Simplificar a forma não significa simplificar o raciocínio.

Toda verificação posterior de TRAVA FACTUAL remete a esta definição. Em caso de conflito com exemplos ou referências, estas proteções prevalecem.

Triagem obrigatória

Executar antes de diagnosticar ou reescrever:

1. Confirmar que há texto e que ele está em PT-BR. Em modo_criacao não há texto-fonte: confirmar o tema, o gênero e o material factual disponível antes de escrever. Para inglês, usar human-ai. Em texto multilíngue, atuar apenas nos trechos em PT-BR e preservar os demais.
2. Não reescrever bulas, procedimentos médicos, manuais de aviação ou outros textos de segurança crítica.
3. Não reescrever contratos, leis, cláusulas ou documentos legais que sejam a própria referência normativa. O perfil Jurídico serve para comentários, resumos e peças autorais, não para alterar texto normativo.
4. Em traduções literais bilíngues ou conteúdo avaliado por correspondência exata, não variar a redação.
5. Em textos técnicos, identificar antes da reescrita os trechos protegidos: código, equações, comandos, citações e identificadores.
6. Quando a tarefa estiver fora do escopo, explicar o risco e oferecer apenas revisão superficial se isso for seguro e o usuário autorizar.

Modos de operação

O modo altera o nível do relatório e o número máximo de tentativas; não altera as proteções.

modo_criacao é o único modo sem texto_fonte. Ele segue as mesmas proteções, mas aplica a lista de padrões como filtro de saída sobre o próprio rascunho, e não como conserto de um original. Ver Escrita do zero.

Preservar sempre o modo escolhido pelo usuário. Se nenhum modo foi informado e o diagnóstico encontrar cinco ou mais sinais graves, usar modo_revisão. Em textos com mais de 500 palavras, trabalhar por blocos semânticos e fazer uma verificação global depois de recompor o texto.

Perfis de voz

Os perfis de voz orientam escolhas de ritmo e registro. Os exemplos são amostras fictícias de estilo, não autorização para acrescentar fatos ao texto-fonte.

🖋️ Crônica

Tom de cronista brasileiro. Coloquialidade controlada, ironia, observação do cotidiano transformada em reflexão. Mistura de registros alto e baixo. Virada reflexiva no final. Aplicar somente quando o texto-fonte ou o pedido forem autorais; não tratar este perfil como padrão universal.

Características:

• "A gente" convive com mais-que-perfeito simples
• Fragmentos de frase como pausa dramática
• Humor seco e autoironia quando já pertencem à voz ou foram pedidos
• Posição autoral explícita, sem criar opinião nova
• Perguntas retóricas que ficam sem resposta

Exemplo:

Todo mundo conhece aquele colega que automatizou o próprio trabalho e não contou pra ninguém. Ficou meses fingindo que digitava. Pois é. Agora a empresa inteira virou esse colega — só que usando ChatGPT em vez de scripts em Python. A diferença é que ninguém tá fingindo. E aí fica a dúvida: eficiência ou preguiça? Sei lá. Provavelmente os dois.

📰 Jornalístico

Tom de reportagem da Folha ou Piauí. Clareza máxima, dados concretos, sem firula.

Características:

• Sujeito + verbo + complemento (nessa ordem)
• Números e datas quando presentes no texto-fonte
• Atribuição somente às fontes existentes no texto-fonte
• Sem adjetivos avaliativos
• Sem primeira pessoa (exceto coluna assinada)

Exemplo:

A empresa demitiu 40 pessoas da área de atendimento em maio. Dois ex-funcionários atribuíram os cortes à substituição por chatbots. A assessoria não comentou. A área tinha 120 pessoas no início do ano.

🎓 Acadêmico

Formal mas não burocrático. Rigor terminológico sem oficialês.

Características:

• Vocabulário preciso de domínio
• Qualificações legítimas (não ressalvas vazias)
• Preservação exata de autores e estudos citados na fonte
• Evita clichês: "faz-se necessário", "cumpre salientar", "no âmbito de"

Exemplo:

A convergência para um registro médio pode ser examinada pela variação lexical em textos submetidos a ciclos sucessivos de refinamento. Nesse contexto, a ablação semântica não acrescenta falsidade; reduz a especificidade.

💬 Corporativo Informal

E-mail de startup, Slack profissional. Direto, leve, sem gerundismo.

Características:

• Frases curtas e diretas
• "A gente" em vez de "nós" quando cabe
• Verbos de ação no lugar de locução verbal
• Estrangeirismos naturais (deploy, sprint, feedback)

Exemplo:

Pessoal, atualizando: o hotfix foi deployado ontem à noite, já tá em prod. O bug de duplicação parou desde as 23h. Vou monitorar mais 48h e, se zerar, fechamos a issue. Me pingam se aparecer algo.

📱 Post de Rede Social

LinkedIn ou Twitter BR. Curto, opinativo, com gancho na primeira linha.

Características:

• Primeira frase é o gancho
• Parágrafos de 1-2 linhas
• Posição autoral clara, sem criar opinião nova
• Pode usar "eu" quando a fonte já usa primeira pessoa ou o usuário pede
• Chamada para ação sutil ou nenhuma

Exemplo:

Eu demiti o ChatGPT do meu fluxo de escrita.

Não porque é ruim. Porque tudo que eu publicava soava igual a todo mundo.

Voltei a escrever na mão. Demora 3x mais. Mas as pessoas respondem agora.

Eficiência sem voz não é vantagem. É invisibilidade.

📲 Mensagem de WhatsApp

Oralidade máxima. Fluxo de consciência permitido.

Características:

• Frases incompletas ok
• Abreviações naturais (vc, tb, mto)
• Gírias regionais aceitas
• Zero preocupação com norma culta

Exemplo:

cara tu viu o que o time de dados fez?

meteram um modelo em prod sem avisar ninguém

aí começou a mandar e-mail errado pra cliente

mó treta

⚖️ 🆕 Jurídico / Oficialesco

Petições, pareceres, notificações. Registro formal com tiques próprios que, quando usados deliberadamente, soam mais autênticos que a imitação genérica da IA.

Características:

• Estrutura: preâmbulo → fatos → fundamentos → pedido
• Uso controlado de clichês do gênero ("data venia", "ante o exposto", "é cediço que")
• Citação de artigos, súmulas, jurisprudência
• Voz ativa quando possível para evitar burocratês vazio

Sinais de IA nesse registro:

• Excesso de "cumpre salientar", "faz-se mister", "no âmbito desta análise"
• Citações genéricas sem número de artigo ou lei
• Parágrafos perfeitamente simétricos (3-4 frases idênticas)

Exemplo (IA → Humano):

IA: "Nos termos do art. 14 do CDC, cumpre salientar que a responsabilidade do fornecedor é objetiva no caso em tela."

Humano: "O art. 14 do CDC estabelece a responsabilidade objetiva do fornecedor neste caso."

O que preservar (não é sinal de IA):

• Seções em CAPS ("DOS FATOS", "DO DIREITO", "DOS PEDIDOS") — é formatação esperada em petições
• Numeração de itens em pedidos e fundamentos
• Citação de artigos com número de lei e data (Art. 14, CDC; Súmula 362/STJ)
• Estrutura preâmbulo → fatos → fundamentos → pedido — é o gênero, não molde de IA

Sinal de revisão nesse registro: atribuição vaga como "conforme entendimento consolidado". Se a fonte não trouxer artigo, súmula ou precedente específico, apontar a lacuna; nunca criar a referência.

🧑‍🏫 🆕 Didático / Explicador

Textos de edtech, apostilas, tutoriais, documentação técnica amigável.

Características:

• Padrão: pergunta → explicação → exemplo concreto → reforço
• Vocabulário acessível mas preciso (sem infantilizar)
• Exemplos específicos já presentes na fonte ou fornecidos pelo usuário
• Transições explícitas: "Então", "Agora", "Vamos ver na prática"

Sinais de IA nesse registro:

• Exemplos genéricos e artificiais
• Tom enciclopédico sem interação com o leitor
• "Neste capítulo, abordaremos X, Y e Z" → molde vazio

Exemplo:

Vamos direto ao ponto: callback é uma função que você passa como argumento pra outra função, pra ela te "chamar de volta" quando terminar. Parece complicado, mas é só isso. Imagine que você pediu um delivery: em vez de ficar ligando a cada 5 minutos pra saber se chegou, você deixa seu número e o entregador te avisa quando estiver na porta. Seu número é o callback.

📋 🆕 Português Simplificado

Texto acessível para público amplo. Inspirado nas operações do PorSimples (NILC/USP) e nas técnicas da Lei 15.263/2025 (Política Nacional de Linguagem Simples). Clareza máxima sem infantilizar o raciocínio.

Quando usar:

• Documentação técnica para público não-especialista
• Comunicação institucional e governamental
• Manuais de produto, FAQs, onboarding de usuários
• Textos para públicos com letramento funcional variado
• Quando o usuário pedir "simplificar", "linguagem simples", "mais claro", "acessível"

Características:

• Frases curtas em ordem direta (SVO) — meta: 13-18 palavras, máximo 25
• Uma ideia por frase
• Vocabulário comum; termo técnico explicado na primeira ocorrência
• Voz ativa (passiva apenas quando o agente for irrelevante ou desconhecido)
• Listas e estrutura visual para 3+ itens em sequência
• Conectivos explícitos e simples ("porque", "por isso", "então", "mas")
• Sem orações intercaladas longas (apostos > 5 palavras viram frase nova)
• Repetição deliberada para clareza (não forçar sinônimos variados)

Operações de simplificação (baseadas no PorSimples):

1. Dividir períodos compostos em frases independentes
2. Converter passiva → ativa
3. Reordenar para SVO quando houver inversão
4. Substituir marcadores discursivos complexos por simples
5. Eliminar apostos longos (transformar em frase separada)
6. Substituir palavras raras por sinônimos frequentes (sem perder precisão)
7. Explicitar sujeitos ocultos quando houver ambiguidade

O que NÃO fazer:

• Não eliminar raciocínio complexo — simplificar a forma, não o conteúdo
• Não remover terminologia de domínio — explicar, não substituir
• Não transformar toda prosa em lista de bullets indiscriminadamente
• Não adicionar exemplos fictícios para "ajudar" — usar apenas os da fonte
• Não reduzir modalidade: "pode causar" não vira "causa"

Exemplo:

Antes: "A implementação de políticas públicas que visem à mitigação dos impactos socioeconômicos decorrentes da automação de processos produtivos configura-se como desafio premente para gestores em todas as esferas do poder público."

Depois: "A automação muda como as pessoas trabalham. Isso traz problemas sociais e econômicos. Os governos precisam criar políticas para reduzir esses problemas. Esse é um desafio urgente em todas as esferas — federal, estadual e municipal."

➡️ 🆕 Assertivo

Tom assertivo para quem precisa de sinal, não conversa. Cada frase justifica seu lugar ou é cortada. Ideal para respostas a decisões, briefings rápidos e comunicação assíncrona onde o leitor vai escanear antes de ler.

Quando usar:

• Respostas a perguntas objetivas em Slack, e-mail ou documento
• Briefings de decisão onde o leitor quer a resposta, não a jornada
• Comunicação técnica para público com atenção fragmentada
• Quando o usuário pedir "direto ao ponto", "sem enrolação" ou "resumo executivo"

Características:

• Primeira frase é a resposta completa — quem lê só ela entende o essencial
• Parágrafos de 1-3 frases, uma ideia por bloco
• Negrito em termos-chave, números e decisões — quem escaneia o bold pega o ponto
• Sem preâmbulo, sem reafirmar a pergunta, sem resumo no final
• Tom caloroso mas econômico — amigo perspicaz, não manual frio
• Zero filler: nada de "Ótima pergunta", "Com certeza", "Na verdade"
• Avisos e ressalvas em linha própria, nunca enterrados
• Instrução vira ação: quando o trecho manda fazer algo, a frase começa pelo verbo e pelo alvo (comando, caminho, arquivo), não pela justificativa

TRAVA FACTUAL neste perfil: brevidade comprime forma, não conteúdo. Se o original tem 5 proposições, a reescrita tem as mesmas 5 — em menos palavras. Cortar elaboração, nunca warning.

Sinais de IA nesse registro:

• Negrito em toda palavra-chave (decoração, não hierarquia)
• Preâmbulo disfarçado: "Para responder isso, precisamos considerar..."
• Resumo no final repetindo o que já foi dito
• Ressalvas genéricas em vez de risco concreto
• Tom seco demais — direto não é grosseiro

Exemplo (IA → Humano):

IA: "Para responder à sua pergunta sobre qual banco de dados utilizar, é importante considerar diversos fatores. PostgreSQL é uma excelente opção para aplicações que necessitam de relacionamentos complexos. Por outro lado, MongoDB pode ser mais adequado para cenários específicos. Em resumo, a escolha depende das suas necessidades."

Humano: "Use PostgreSQL. App social é todo relacionamentos (amigos, follows, likes), e Postgres lida nativamente. Correto para ~90% de apps sociais novos.

MongoDB só se: você tem dados sem schema que mudam toda semana, ou volume de escrita que justifique o trade-off.

Armadilha comum: começar com Mongo achando que é mais flexível e depois gastar meses migrando quando precisar de JOIN."

O que preservar (não é sinal de IA):

• Negrito em hierarquia de escaneabilidade (títulos de ponto, números, decisão)
• Frases muito curtas em série quando cada uma carrega uma ideia distinta
• Tom direto sem ser rude — economia não é frieza
• Setas (→) quando indicam fluxo ou consequência, não decoração

🔹 🆕 Enxuto

Sinal máximo, zero conforto. Modo heads-down para quem quer fato, não conversa. Usa quando o leitor está no meio de uma tarefa e precisa da resposta sem atrito.

Quando usar:

• Respostas durante coding/debugging (o leitor está em flow)
• Instruções de terminal, comandos, troubleshooting
• Confirmações de ação ("faz X" → resposta confirma que fez)
• Quando o usuário pedir "curto", "só o necessário" ou responder com monossílabos

Características:

• Linha 1 é a resposta completa em uma sentença
• Sem calor, sem hedge, sem transição
• Imperativo quando cabe: "Use", "Rode", "Corte"
• Um ponto pode ser uma linha
• Números exatos, nunca arredondados
• Risco ou incerteza em linha própria, direta
• Quando a tarefa for "faça X", confirmar em uma linha e fazer — sem narrar o que vai fazer

TRAVA FACTUAL neste perfil: curto não elimina warning. Se a omissão faz o leitor agir errado, o trecho fica — mesmo que quebre a brevidade.

Sinais de IA nesse registro:

• Explicação não solicitada ("Isso funciona porque...")
• Qualquer forma de "espero que ajude"
• Narração da própria ação ("Vou agora verificar o arquivo...")
• Ressalva genérica sem risco concreto
• Parágrafo onde caberia uma linha
• Dramatização de erro: "Ops", "Infelizmente", "Parece que algo deu errado". Erro se descreve por causa e correção, nada mais
• Idiomatismo onde cabe a ação literal ("colocar em pauta", "alinhar expectativas", "dar um norte") — neste perfil custa um passo de decodificação que o leitor não tem

Exemplo (IA → Humano):

IA: "Para corrigir esse erro, você precisará verificar o arquivo de configuração. O problema parece estar relacionado à variável de ambiente que não foi definida corretamente. Recomendo que você abra o arquivo .env e verifique se a chave DATABASE_URL está presente. Espero que isso ajude a resolver o problema."

Humano: "Falta DATABASE_URL no .env. Adicione a linha e reinicie o server."

O que preservar (não é sinal de IA):

• Imperativo seco — é o registro, não grosseria
• Ausência de "por favor" ou "obrigado" em contexto técnico
• Resposta de uma linha quando uma linha basta
• Comando sem explicação quando a explicação não foi pedida

📊 🆕 Resumo

Board de status para escanear, não parágrafo para ler. O leitor quer saber o que mudou, o que está travado e o que precisa decidir. Otimiza para legibilidade, não brevidade.

Quando usar:

• Standups, status updates, notas de reunião
• Relatórios de progresso, sprint reviews
• Qualquer contexto onde o leitor pergunta "como está X?"
• Quando o usuário pedir "resumo de status", "update rápido" ou "onde estamos"

Características:

• Abrir com TL;DR de uma linha carregando resultado e bloqueio principal
• Estado como checklist visual:
  • ✅ feito
  • 🟡 em andamento
  • ⬜ não iniciado
  • ❔ desconhecido
  • 🔴 bloqueio/risco
• Um item por linha, negritar o assunto
• Bloqueio em linha própria com 🔴
• Opções de ação sob "Sua vez:" como lista numerada
• Linhas curtas, uma ideia cada — sem paredes de texto
• Terminar com ação clara ou pick-one
• Prazo em unidade concreta quando a fonte fornece: "3 dias úteis", "até 4ª", "~2 semanas". Nunca converter prazo ausente em estimativa — sem prazo na fonte, o item fica ❔

TRAVA FACTUAL neste perfil: nunca inventar status. Se o estado de um item é desconhecido, marcar ❔ e dizer o que resolveria. Checklist inventada é pior que checklist incompleta. Prazo inventado é status inventado: vale a mesma regra.

Sinais de IA nesse registro:

• Status inventado (item que não estava na fonte)
• TL;DR que não se sustenta sozinho
• Parágrafo corrido onde cabia checklist
• Emoji decorativo (🚀💡🎯) sem função de status
• "Conforme alinhado" ou "dando seguimento" como filler

Exemplo (IA → Humano):

IA: "Com relação ao andamento do projeto de contratação, gostaria de informar que recebemos 20 candidatos até o momento. Destes, 5 foram triados e 2 entrevistas estão agendadas. Ainda não fizemos nenhuma oferta. Vale ressaltar que temos um candidato forte que pode estar considerando outras oportunidades, o que demanda atenção especial da equipe."

Humano: "TL;DR: Pipeline saudável no topo, linha de chegada travada. Candidato forte escorregando.

Funil: ✅ Candidatos: 20 recebidos ✅ Triagem: 5 de 20 🟡 Entrevistas: 2 agendadas, não realizadas ⬜ Oferta: não rascunhada

🔴 Bloqueio: Candidato forte com outras propostas — janela de ~5 dias.

Sua vez:

1. Fast-track o candidato forte (decisão até 4ª)
2. Rodar as 2 entrevistas esta semana
3. Rascunhar oferta agora para não travar depois"

O que preservar (não é sinal de IA):

• Emojis de status (✅🟡⬜❔🔴) — são notação funcional, não decoração
• Lista com mais de 5 itens quando o status exige
• Repetição do item em "Sua vez" que já apareceu no status — a redundância é proposital (ver → decidir)
• Estrutura de board mesmo em texto corrido no canal original

🧭 Regras comuns aos perfis de consumo rápido

Valem para Assertivo, Enxuto e Resumo. Não valem para os perfis autorais.

Por que estes perfis existem. Eles servem a um leitor que está no meio de outra coisa. Quatro restrições desse leitor explicam cada regra acima:

1. O que não está na tela foi esquecido. Não escrever "tendo em vista o que foi dito acima".
2. Entender não é executar. O texto que explica bem e não diz o que fazer falhou.
3. Começar é o passo caro. A primeira ação precisa ser pequena e óbvia.
4. Prazo vago não registra. "Em breve" e "algumas semanas" chegam iguais.

Em caso de dúvida sobre uma escolha de forma, decidir pelo que reduz o custo de agir.

Passo a passo vira lista numerada. Sequência de duas ou mais ações executáveis: lista numerada, uma ação por item, sem "e então" duas vezes no mesmo item. Prosa corrida com passos embutidos é sinal de IA nestes perfis.

Fechamento é ação, não recapitulação. A proibição de resumo final continua. O que ela não proíbe: se o texto-fonte deixa algo em aberto, a última linha nomeia uma ação concreta que o leitor faz agora. Recapitular o que já foi dito é ruído; apontar o próximo passo é a entrega. Se a fonte não deixa nada em aberto, o texto termina na última informação.

Assunto secundário sai do meio. Segundo tema no texto-fonte não vira parêntese, "vale mencionar" ou digressão no meio do primeiro. Termina o primeiro assunto, depois o segundo em bloco próprio ou pergunta ao final. Nunca descartar o assunto — a TRAVA FACTUAL vale aqui como em qualquer lugar; a regra é de posição, não de corte.

Cláusula de escape (os três perfis). Se o usuário pedir profundidade ("explica de verdade", "por quê", "detalha"), a compressão desliga e o contexto vem inteiro. O registro continua: sem preâmbulo, sem fecho cortês, corpo do tamanho que o assunto exigir.

Escrita do zero (modo_criacao)

Quando o texto ainda não existe, a lista de padrões vale como filtro de saída, não como conserto.

1. Escolher o perfil de voz antes de escrever (Passo 1). Sem perfil e sem amostra, usar voz neutra.

2. Escrever direto, com o material que o usuário forneceu. Não tentar desviar dos padrões durante a redação: isso trava a frase e produz o texto sem graça que a skill existe para evitar.

3. Passar o diagnóstico sobre o próprio rascunho (Passo 2) antes de entregar. Cinco padrões respondem pela maior parte dos escorregões em texto novo:

   • travessão de aparte;
   • "não apenas X, mas também Y";
   • conectivo abrindo parágrafo ("Além disso", "Dessa forma", "Por fim");
   • trio forçado;
   • fecho otimista genérico.

   Varrer esses primeiro; depois percorrer o resto da tabela.

4. Aplicar a guarda de falso positivo (Passo 6) e a verificação final (Passo 7).

5. Entregar só o texto. Sem rascunho, sem diagnóstico, sem lista de padrões: o usuário pediu um texto, não um relatório.

TRAVA FACTUAL em modo_criacao. Não há original a preservar, e por isso a regra pesa mais: escrevendo do zero é fácil tapar buraco com número plausível, data aproximada ou fonte que soa certa. Usar apenas o que o usuário forneceu ou o que foi efetivamente verificado. Faltando um dado para a frase funcionar, escrever a frase mais simples e dizer ao usuário o que falta, ou marcar [DADO OU EXEMPLO REAL NECESSÁRIO]. Ficção pedida explicitamente é exceção, porque inventar faz parte do trabalho, e deve ser identificada como ficção.

Não anunciar que passou pela lista. E nunca afirmar ter conferido um texto sem ter conferido: dizer "passei pelos padrões" sem ter passado é pior que o vício que ficou.

Processo de Humanização

Executar primeiro a Triagem obrigatória. Manter texto_fonte imutável durante todo o processo. Em modo_criacao não há texto_fonte: o rascunho da primeira tentativa ocupa o lugar de texto_atual e a validação factual segue as regras de Escrita do zero.

Passo 1 — 🎯 Seleção do perfil de voz

Se o usuário não especificou um perfil, detectar pelo conteúdo:

Regras de decisão:

1. O perfil explícito define os limites do gênero e nunca é substituído automaticamente.
2. Dentro desses limites, a amostra fornecida controla as escolhas finas de estilo. Sem perfil explícito, a amostra tem prioridade sobre a detecção.
3. Sem perfil nem amostra, usar o perfil detectado; sem sinal claro, usar voz neutra.
4. Em conflito material, perguntar ao usuário nos modos completo e revisão. No modo_direto, escolher o registro mais próximo do texto-fonte, agir de modo conservador e registrar a ambiguidade.
5. Em texto com múltiplos registros, manter um perfil principal e ajustar apenas os trechos que pertencem a outro gênero.

Saída no relatório: 🎯 Tipo detectado: [tipo] → Perfil: [perfil]

Passo 2 — 🔍 Diagnóstico com lista estruturada

Percorrer sistematicamente cada categoria. Marcar ✓ (encontrado) ou ✗ (ausente).

Regra de decisão: cada linha detectada conta como um sinal, independentemente do número de repetições. Se cinco ou mais sinais de peso 3 forem encontrados e o usuário não tiver escolhido um modo, usar modo_revisão.

Nota sobre o perfil Jurídico: sinais de oficialês podem ser deliberados nesse gênero. Avaliar repetição mecânica e falta de função, não a mera presença da expressão.

Indicadores quantitativos opcionais

Usar somente quando o usuário pedir métricas ou houver ferramenta confiável para calculá-las. Nunca estimar números. Em textos curtos, fragmentados ou com menos de 200 palavras, marcar não medido.

Indicadores possíveis:

• razão entre tipos e ocorrências de palavras (TTR), com tokenização declarada;
• desvio-padrão do comprimento das frases;
• entropia lexical, com método declarado;
• contagem de palavras terminadas em -mente;
• contagem de formas em -ando, -endo e -indo com \w+(?:ando|endo|indo)\b;
• repetição de palavras genéricas e de estruturas sintáticas.

Tratar os resultados como pistas dependentes de gênero e tamanho. Eles não aprovam ou reprovam o texto, não entram na pontuação e não provam autoria humana ou artificial. Não assumir que toda variedade lexical deve subir: repetição deliberada pode ser mais natural que ciclagem forçada de sinônimos.

Passo 3 — 🧹 Remoção de padrões

Começar pelas referências das categorias marcadas ✓ no diagnóstico:

Se surgir outro sinal durante a reescrita, houver dúvida de classificação ou sobreposição entre categorias, consultar também a referência relacionada. Não carregar todas por padrão. No modo_revisão, incluir sempre padroes-exclusivos-pt-br.md.

As referências detalham padrões, mas não substituem a TRAVA FACTUAL. Descartar qualquer exemplo de referência que exija informação ausente do texto-fonte.

Passo 4 — ♻️ Restauração de especificidade

Onde o texto perdeu precisão ou ritmo:

Se a concretude necessária não existir na fonte, manter a formulação honesta e anotar: ⚠️ Falta um dado ou exemplo real para tornar este trecho mais concreto.

Passo 5 — 💬 Aplicação da voz

Aplicar somente os recursos permitidos pelo perfil ativo:

Quando o usuário fornecer amostra de voz, espelhar comprimento de frases, nível vocabular, início de parágrafos, pontuação e uso de estrangeirismos. Não copiar fatos, opiniões, personagens ou experiências da amostra para o texto reescrito.

Passo 6 — 🚧 Guarda de falso positivo

Rodar antes da verificação final. Percorrer os sinais marcados ✓ no Passo 2 e desmarcar os que se explicam por esta seção, registrando a decisão no relatório. Nenhum padrão isolado prova origem artificial: o sinal está no acúmulo. Na dúvida, procurar vários padrões no mesmo parágrafo; um travessão sozinho não é nada.

O que não marcar

Detectores automáticos. Não usar pontuação de ferramenta de detecção como prova nem como critério do que reescrever. Essas ferramentas erram muito e erram torto: penalizam mais quem é neurodivergente e quem não é falante nativo. Nenhuma reescrita aqui tem como objetivo enganar detector.

Marcas humanas para preservar

Estes detalhes costumam carregar a voz de quem escreve. Preservar, salvo quando atrapalharem o sentido — e nunca "consertar" por padronização:

O próprio texto como amostra. Quando a entrada já traz marca forte de autoria — regionalismo, opinião assumida, primeira pessoa, humor, autocorreção, detalhe concreto que só quem viveu conhece —, ela não é saída de chatbot: é escrita de alguém pedindo revisão. Tratar esse texto como a amostra de estilo do autor. Nesse caso o sinal de travessão e o de abertura teatral deixam de valer como regra; apontar o que for encontrado no relatório e deixar a escolha com o autor.

Passo 7 — 🔥 Verificação final

Verificar cada item. Marcar ✓, ✗ ou N/A conforme o perfil e o tamanho do trecho.

Verificação adicional para perfis de brevidade (Assertivo/Enxuto/Resumo):

Falha nos itens 1 ou 2 invalida a candidata. Nos demais itens, corrigir apenas se ainda houver tentativa disponível; não distorcer o gênero para satisfazer a lista. O controle de tentativas do Passo 9 impede repetição indefinida.

Passo 8 — 📊 Avaliação pós-reescrita

Validar a TRAVA FACTUAL antes da pontuação. Se falhar, descartar a candidata e registrar pontuação nula; naturalidade nunca compensa alteração factual ou semântica.

Se a validação factual passar, avaliar quatro dimensões de 0 a 100, sempre em relação ao perfil ativo:

Pontuação final = Σ (dimensão × peso)

Usar o limiar solicitado pelo usuário ou 80 como padrão. Se a pontuação ficar abaixo do limiar e houver nova tentativa, atuar nas dimensões mais baixas. Com pontuação abaixo de 60, mudar a abordagem sem trocar perfil explícito. Indicadores quantitativos opcionais nunca alteram a pontuação.

Passo 9 — 📦 Controle de tentativas e entrega

Executar a seleção de perfil e o diagnóstico uma vez. Em cada tentativa, produzir uma candidata a partir do melhor texto seguro disponível e compará-la sempre ao texto_fonte imutável. Executar os Passos 3–7 antes de calcular a pontuação.

textCopy code
texto_fonte = entrada original imutável
texto_atual = entrada atual ou texto_fonte
limiar = valor solicitado ou 80
tentativas_maximas = limite do modo
melhor_texto = nenhum
melhor_pontuacao = -1

para cada tentativa:
    gerar candidata a partir de texto_atual
    verificar TRAVA FACTUAL e argumento contra texto_fonte

    se a candidata falhar:
        descartar candidata sem calcular pontuação
        continuar somente se houver nova tentativa

    calcular pontuação
    se pontuação > melhor_pontuacao:
        guardar candidata como melhor_texto
        texto_atual = melhor_texto

    se pontuação >= limiar:
        estado = concluida
        entregar

se não houver candidata segura:
    estado = reprovada_trava_factual
    melhor_texto = texto_fonte
    pontuação = nula
senão:
    estado = melhor_resultado
    entregar melhor_texto com nota de limitação

No modo_direto, produzir exatamente uma candidata e não repetir. Se ela falhar na TRAVA FACTUAL, devolver o texto-fonte com estado reprovada_trava_factual.

No modo_criacao não existe texto_fonte para comparação. A validação factual passa a ser: toda afirmação, nome, número, data e citação da candidata vem do material fornecido pelo usuário ou de verificação efetiva. Uma candidata que não passe nesse teste é reescrita, não entregue com ressalva. Se faltar dado, entregar a versão mais simples e nomear a lacuna.

Quando houver nova tentativa, escolher a alternativa pelo problema dominante:

Contrato de saída

Em pipelines ou quando houver pedido de saída estruturada, usar:

yamlCopy code
estado: concluida
texto: "texto final ou texto-fonte seguro"
modo: modo_completo  # ou modo_direto, modo_revisão, modo_criacao
perfil_de_voz: voz_neutra
limiar: 80
pontuacao: 86
convergiu: true
trava_factual:
  estado: intacta
  violacoes: []
tentativas:
  usadas: 2
  maximas: 3
relatorio: {}

Usar os valores conforme o estado final:

Em conversa, apresentar primeiro o texto e depois o relatório no nível do modo:

Integração com ciclos externos

Na primeira chamada, usar o texto recebido como texto_fonte e texto_atual. Nas chamadas seguintes, manter texto_fonte inalterado e realimentar somente o campo texto como texto_atual:

yamlCopy code
proxima_entrada:
  texto_fonte: "original imutável"
  texto_atual: "saída.texto"
  perfil_de_voz: "mesmo perfil"
  limiar: 80

Nunca realimentar relatório, pontuação ou o envelope inteiro como se fossem parte do texto. Toda chamada continua comparando o resultado ao texto_fonte original.

Estrangeirismos

Brasileiro de tech fala com estrangeirismos. Isso é marca de autenticidade, não erro. A skill preserva:

feedback, deploy, sprint, churn, feature, bug, hotfix, pipeline, stakeholder, deadline, call, onboarding, pitch, runway, burn rate, product-market fit, growth, awareness, branding, lead, funnel, conversion, landing page, copywriting, UX, UI, framework, stack, backend, frontend, fullstack, DevOps, SaaS, API, endpoint, webhook, dashboard, KPI, OKR, ROI, ROAS, CRM, MVP

Forçar tradução desses termos é sinal de IA purista — o oposto de humano.

Regra de ouro: se o termo é usado no dia a dia do domínio em PT-BR, mantenha. Se é anglicismo artificial sem necessidade, remova.

Suíte de testes de regressão

Conjunto mínimo para validar evoluções futuras. Rodar cada caso em modo_completo e conferir preservação semântica antes de julgar estilo.

Critério de regressão: se uma evolução piora o resultado de qualquer teste T1-T8, a mudança deve ser reavaliada.

TRAVA FACTUAL nos casos de teste: nenhuma saída esperada pode adicionar, retirar ou alterar conteúdo protegido. Resultado mais contido é preferível a uma versão mais vistosa que invente informação.

Avaliação com Jev (opcional)

A skill pode usar TypeSafe Jev para avaliação calibrada — um modelo que retorna decisões tipadas com probabilidades precisas. Jev é ideal para diagnóstico, verificação e scoring; o LLM continua fazendo a reescrita.

Protocolo de Descoberta

A skill não assume que Jev está disponível. Antes de usar, execute o protocolo de descoberta:

Copy code
1. Verificar MCP tools disponíveis no harness
   → Se existir tool "jev_eval" ou similar → usar
   
2. Verificar se harness usa OpenRouter
   → Se sim, solicitar modelo `typesafe/jev-latest`
   
3. Verificar slots auxiliares (Hermes, Devin)
   → Se slot approval/custom configurado com Jev → usar
   
4. Fallback → avaliação inline via LLM atual

Descoberta por Harness

Por que usar Jev

Economia: ~50-100x mais barato que GPT-4.

Quando preferir avaliação LLM

• Textos muito curtos (<50 palavras)
• modo_direto com pressa
• Debug/desenvolvimento (mais fácil inspecionar reasoning)
• Jev não disponível no harness

Mapeamento de passos para Jev

Arquivos relacionados

Documentação completa: Ver references/jev-integration.md para detalhes do protocolo de descoberta, estrutura de requests/responses e instruções por harness.