site-consistency — QA de copy alinhada à oferta

Consistência do Site — Auditoria de Texto Alinhada à Oferta

Objetivo: todo texto no site conta a mesma história — a oferta declarada na página inicial — para o mesmo cliente, com a mesma promessa, nomes e termos. Audite primeiro; corrija apenas o que o usuário aprovar.

Dois limites rígidos:

1. Auditar antes de corrigir. A auditoria é somente leitura. Nenhum arquivo é modificado até que o usuário aprove linhas específicas da tabela de auditoria.
2. Somente texto. Esta habilidade altera palavras — nunca layout, estilos, componentes, imagens, rotas ou estrutura de página. Veja "Regras de Edição Apenas de Texto".

Idiomas

• Fale com o usuário no idioma que ele usa na conversa. O relatório, cabeçalhos da tabela, rótulos de severidade e a coluna "por quê" estão nesse idioma.
• Citações do texto atual são literais, no idioma original.
• O texto proposto para o site é escrito no idioma do texto que substitui, de forma nativa e idiomática (nunca uma tradução literal), mantendo a forma de tratamento do site (ex.: "tu"/"você") e o tom.
• Detecte o(s) idioma(s) do site a partir de <html lang>, configuração de i18n, arquivos de localidade e o texto visível. Em sites multilíngues, identifique a localidade principal; se não estiver claro quais localidades auditar, pergunte.

Fluxo de Trabalho

Siga as etapas em ordem. As etapas 1–6 nunca modificam arquivos.

Etapa 1 — Reconhecimento

Leia references/text-inventory.md. Estabeleça:

• a pilha e o roteamento (como URLs mapeiam para arquivos),
• onde o texto reside: componentes/templates, arquivos i18n, Markdown/MDX/coleções de conteúdo, metadados, templates de e-mail, CMS externo,
• localidades e o idioma principal do site,
• documentos de oferta existentes: docs/offer/offer-brief.md (escrito pela habilidade grand-slam-offer) ou qualquer documento de briefing/posicionamento em docs/.

Se a maior parte do texto estiver em um CMS externo e não houver nem exportação nem URL para ler o site renderizado, informe ao usuário o que pode e o que não pode ser auditado antes de continuar.

Etapa 2 — Extrair a oferta da página inicial

Leia a página inicial como um visitante de primeira viagem: herói primeiro, depois cada seção em ordem, além de <title>, descrição meta, cabeçalho e rodapé. Preencha a Declaração de Oferta:

Campo	O que responde
O que é vendido	produto/serviço e seu formato
Para quem	o cliente/avatar, segmento, mercado
Promessa principal	o resultado que o cliente obtém (+ prazo, se declarado)
Mecanismo / diferencial	como é entregue, por que isso em vez de alternativas
Nomes	grafia exata do nome da oferta, produto, método e pacotes
Termos-chave	preço/pacotes, garantia, escassez/prazos, tempo de entrega — apenas os declarados
Conversão primária	o CTA principal e o que acontece após clicar nele
Tom	tom, forma de tratamento, posicionamento (premium, econômico, especialista, amigável…)

Para cada campo, registre o valor e a fonte (citação + localização). Se um campo não estiver na página inicial, escreva "não declarado". Se existir um resumo da oferta, compare-o com a página inicial campo por campo.

Em um site com várias ofertas distintas (ex.: serviços separados para públicos diferentes), registre a oferta guarda-chuva da página inicial e liste as subofertas; cada página de suboferta será verificada em relação à sua própria oferta e à oferta guarda-chuva.

Etapa 3 — Portão de clareza da oferta

A oferta é clara quando todas as seguintes condições são verdadeiras:

1. "O que é vendido", "Para quem", "Promessa principal" e "Conversão primária" podem ser respondidos apenas pela página inicial.
2. A página inicial apresenta uma oferta principal (ou um guarda-chuva claro com subofertas) — sem ofertas concorrentes.
3. A página inicial não se contradiz (dois preços, dois públicos, duas promessas diferentes).
4. A página inicial não contradiz o resumo da oferta, se existir.

Clara → continue. A Declaração de Oferta é o padrão; ela vai no topo do relatório para que o usuário possa corrigi-la.

Não clara → pare e pergunte ao usuário sobre a oferta antes de auditar qualquer outra coisa. Nunca adivinhe a oferta para passar por este portão.

• Use a ferramenta AskUserQuestion se disponível (máx. 4 perguntas por rodada), com opções construídas a partir dos candidatos que você realmente encontrou no site, além de espaço para uma resposta personalizada. Caso contrário, pergunte no chat.
• Pergunte apenas sobre campos que estão ausentes ou conflitantes, ex.: "A página inicial vende tanto X quanto Y — qual é a oferta principal?", "O cliente principal é A (herói) ou B (seção de serviços)?", "O resumo diz garantia de 30 dias, a página inicial diz 14 dias — qual é o atual?". Para múltiplas ofertas, confirme a hierarquia (oferta principal vs. subofertas).
• Registre as respostas na Declaração de Oferta com a fonte "confirmado pelo usuário". O texto da página inicial pouco claro ou contraditório se torna então um achado — a página inicial é auditada em relação à oferta confirmada como qualquer outra página.

Etapa 4 — Inventário de páginas e texto

Liste tudo que um visitante pode ler (detalhes em references/text-inventory.md):

• cada rota/página, incluindo rotas dinâmicas e coleções de conteúdo,
• texto compartilhado: cabeçalho, navegação, rodapé, banners, modais/pop-ups, formulários (rótulos, placeholders, validação, mensagens de sucesso/erro), estados 404/500 e vazios,
• texto que os visitantes veem indiretamente: <title>, descrição meta, tags Open Graph/Twitter, campos de texto JSON-LD, alt, aria-label, nome/descrição do manifest da web,
• e-mails transacionais e notificações, se seus templates estiverem no repositório.

Atribua a cada página seu papel narrativo (veja references/consistency-checklist.md) — o papel decide o que "consistente" significa para essa página.

Sites grandes: audite cada página principal por completo. Para grandes coleções do mesmo tipo (ex.: mais de 20 postagens de blog ou produtos), audite o template compartilhado mais o título, descrição, introdução e CTA de cada item; diga no relatório exatamente o que foi coberto dessa forma e ofereça uma passagem completa. Se a ferramenta Agent estiver disponível, você pode dividir o inventário entre subagentes — dê a cada um a Declaração de Oferta confirmada, a lista de verificação e sua lista de páginas, depois mescle os achados em uma única tabela.

Etapa 5 — Auditoria

Leia references/consistency-checklist.md. Verifique cada unidade de texto em relação à Declaração de Oferta em todas as dimensões (D1–D10), no contexto do papel de sua página. Para cada achado, registre: localização, citação literal, dimensão, severidade, por que é um problema (vinculado a um campo específico da Declaração de Oferta), tipo de correção e o texto proposto.

• Construa primeiro a matriz de fatos (cada menção de preço, garantia, prazos, vagas, tempo de entrega, nomes — lado a lado) para que contradições entre páginas sejam percebidas sistematicamente, não por acaso.
• O texto proposto segue as Regras de Edição Apenas de Texto e nunca inventa fatos. Um fato ausente se torna um placeholder no idioma do site (ex.: [A PREENCHER: …], em português [A PREENCHER: …]).
• Fatos conflitantes onde a verdade não está estabelecida → tipo de correção Decisão: liste as opções, não escolha uma.
• Problemas que o texto não pode resolver (imagem mostrando um produto diferente, seção ou botão CTA faltando, página que não deveria existir, destino de link errado, slug de URL) vão para "Fora do escopo de texto" — relatados, nunca corrigidos por esta habilidade.

Etapa 6 — Relatório de auditoria, depois pare

Apresente o relatório exatamente como no "Formato de Saída". O relatório sempre termina com a tabela de achados. A única coisa permitida após a tabela é a pergunta de aprovação. Em seguida, pare e aguarde — não modifique nenhum arquivo nesta rodada.

Pergunta de aprovação (use AskUserQuestion se disponível):

• Aplicar tudo
• Aplicar apenas Críticos e Maiores
• Aplicar linhas selecionadas (o usuário lista os # e pode editar qualquer proposta)
• Não aplicar — apenas auditoria

Cada linha de Decisão que o usuário queira aplicar precisa de uma resposta; peça por elas na mesma rodada quando possível.

Etapa 7 — Aplicar correções aprovadas

• Aplique apenas as linhas aprovadas, com as edições do usuário, seguindo as Regras de Edição Apenas de Texto.
• Antes de alterar uma string, verifique onde mais ela é renderizada (chave i18n compartilhada, componente compartilhado, partial Markdown reutilizado). Se o novo texto não se encaixar em um desses contextos, pare e pergunte.
• Se uma correção aprovada exigir uma alteração não textual, ou não puder ser aplicada como aprovada, pule-a e relate-a. Não improvise uma correção diferente.
• Texto armazenado em um CMS externo: não tente editá-lo; prepare uma lista de copiar-e-colar (entrada/campo do CMS | texto atual | novo texto).

Etapa 8 — Verificar e relatar

• Releia cada passagem alterada com o texto ao redor — deve soar natural no contexto.
• Procure por resquícios das variantes antigas (nomes antigos, termos antigos, promessa antiga) dentro do escopo aprovado.
• Valide arquivos alterados: parse JSON/YAML, arquivos de localidade mantenham as mesmas chaves, variáveis de interopleação intactas. Execute o lint/typecheck/build do projeto se disponível e rápido.
• Multilíngue: liste as outras localidades cujas strings precisam de uma atualização correspondente, a menos que o usuário aprove atualizá-las também.
• Finalize com a tabela de resumo: # | Onde | Status (Aplicado / Pulado — motivo / Precisa de atualização no CMS) | Mudança (breve). Não faça commit a menos que solicitado.

Regras de Edição Apenas de Texto

Permitido:

• conteúdo de string visível ao usuário: nós de texto em JSX/templates, literais de string renderizados para usuários, valores i18n, prosa Markdown/MDX, campos de texto de frontmatter (título, descrição), arquivos de conteúdo/CMS no repositório,
• atributos e metadados textuais: alt, title, aria-label, placeholder, <title>, descrição meta, texto OG/Twitter, valores de texto JSON-LD, nome/descrição do manifest,
• mensagens de formulário, sistema e template de e-mail,
• reescrever, encurtar ou excluir frases dentro de um elemento de texto existente.

Não permitido (relate como "Fora do escopo de texto"):

• adicionar, remover, reordenar ou reestilizar elementos, seções ou componentes; alterar marcação, classes, CSS ou props não textuais,
• esvaziar um elemento — um elemento vazio é uma alteração de layout; reescreva-o,
• chaves i18n, nomes de variáveis, nomes de arquivo, rotas, slugs de URL, âncoras (slugs são texto, mas alterá-los quebra links e SEO),
• destinos de link (href) — apenas o texto do link pode mudar,
• imagens, ícones, vídeo e outras mídias,
• lógica de código, condições, busca de dados.

Ao editar:

• Preserve interpolação e sintaxe: {name}, {{count}}, %s, :attribute, plural/seleção ICU, entidades HTML, tags inline dentro de strings (<strong>, <br>, <0>…</0>), formatação Markdown e escaping (aspas em JSX/JSON, apóstrofos em strings PHP).
• Mantenha o comprimento próximo ao original (aproximadamente ±30%) porque o layout não está mudando. Se uma correção precisar de muito mais texto, diga isso na proposta.
• Corresponda às convenções tipográficas do site (aspas, travessões, espaços inseparáveis).

Regras Obrigatórias

• R1. Auditoria somente leitura. Nenhuma edição e nenhuma escrita de arquivo (incluindo arquivos de relatório, a menos que o usuário solicite) antes da aprovação explícita. A aprovação cobre apenas as linhas aprovadas.
• R2. Somente texto. Tudo fora das Regras de Edição Apenas de Texto é relatado, nunca alterado.
• R3. Padrão primeiro. Nunca audite contra uma oferta adivinhada: a Declaração de Oferta é clara a partir da página inicial ou confirmada pelo usuário.
• R4. Evidência. Cada achado cita o texto atual literalmente e fornece uma localização precisa (arquivo:linha ou chave i18n).
• R5. A tabela sempre vem por último. Todo relatório de auditoria termina com a tabela de achados, também quando não há achados — nesse caso termina com uma tabela de cobertura (Página | Papel | Verdicto).
• R6. Nenhum fato inventado. Propostas nunca adicionam números, resultados, depoimentos, garantias ou termos que o usuário não forneceu ou que o site já não declara consistentemente. Conflito → Decisão. Ausente → placeholder.
• R7. Consistência, não uniformidade. Não cole a promessa do herói em todo lugar nem force um discurso de vendas em todas as páginas. Sinalize apenas texto que contradiz, dilui, desvia ou distrai da oferta, dado o papel da página. Páginas legais nunca são reescritas por narrativa — apenas seus conflitos factuais com o texto de marketing são sinalizados, com uma recomendação de revisão do texto legal.
• R8. Alinhe à oferta, não a redesenhe. Esta habilidade alinha o site com a oferta confirmada. Se a própria oferta for fraca (promessa vaga, sem prova, focada em preço), diga em uma linha do resumo e sugira a habilidade grand-slam-offer; não reconstrua a oferta aqui.
• R9. Idioma. Comunicação no idioma da conversa; texto proposto para o site no idioma do texto que substitui.

Formato de Saída

Relatório de auditoria

Seções nesta ordem, escritas no idioma da conversa:

1. Oferta de referência — a Declaração de Oferta (tabela compacta) + sua fonte (página inicial / resumo da oferta / confirmado pelo usuário).
2. Escopo — páginas e fontes de texto auditadas (contagem + lista ou agrupamento), localidades, o que foi coberto por amostragem, o que está fora do repositório e não foi auditado.
3. Resumo — contagem de achados por severidade; os 2–3 maiores problemas narrativos, uma frase cada; opcionalmente uma linha sobre a própria oferta (R8).
4. Reescritas completas (apenas se necessário) — propostas com mais de ~40 palavras, na íntegra, rotuladas com o # do achado.
5. Fora do escopo de texto (apenas se houver) — marcadores curtos; esta habilidade não os corrigirá.
6. Tabela de achados — o último elemento do relatório.

Tabela de achados — cabeçalhos traduzidos para o idioma da conversa:

#	Onde	Severidade	Como está hoje	Por que não deveria ser assim	Correção proposta

• # — ID estável usado para aprovação.
• Onde — página · seção · arquivo:linha ou chave i18n.
• Severidade — Crítico / Maior / Menor (veja lista de verificação).
• Como está hoje — citação literal do fragmento relevante; encurte com "…" acima de ~25 palavras.
• Por que não deveria ser assim — o conflito concreto com o padrão, ex.: "página inicial: para clínicas odontológicas; aqui: para qualquer negócio".
• Correção proposta — o novo texto exato no idioma do site, "veja Reescritas completas #N", ou DECISÃO: A) … / B) ….

Ordene por severidade, depois pela ordem de página do inventário.

Por exemplo, em uma conversa em português, os três cabeçalhos principais se tornam "Como está hoje", "Por que não deveria ser assim", "Correção proposta".

Exemplo de linhas (site em inglês, conversa em inglês):

#	Where	Severity	Today	Why it shouldn't be like this	Proposed fix

…

[truncado para tradução]