Use minha conexão com o Opus Growth para isso. Se você não encontrar a ferramenta de que precisa, procure entre as ferramentas do Opus Growth (com search_tools, se estiver na sua lista); se não conseguir acessar as ferramentas de forma alguma, não adivinhe, me avise.
No meu servidor de hospedagem do Opus Growth
[nome do servidor], crie o relatório de impacto de
[ano] de
[nome da organização] como um site que conta sua história conforme a pessoa rola a página. Organização:
[o que faz, onde, ano de fundação]. A mensagem principal do relatório:
[uma frase]. Os quatro números de destaque:
[número, unidade, explicação em uma frase]. Dados dos gráficos:
[para cada gráfico, título, períodos e valores]. Orçamento:
[fontes de receita e linhas de despesa, valores e percentuais]. Capítulos:
[nomes dos capítulos e o texto ou as anotações de cada um]. Plano do próximo ano:
[itens]. De onde vêm os números e quais são seus limites:
[quais registros, como os dados ausentes foram tratados]. Elaborado por e data de publicação:
[nome do editor, data]. Contato:
[e-mail],
[telefone],
[endereço]. Domínio:
[domínio]. Fotos:
[links; sem rostos de crianças ou beneficiários].
Páginas: relatório (/: título da capa, parágrafo de resumo com a resposta logo no início, autor e data, imagem de capa, navegação fixa por capítulos e, nesta ordem, resumo do ano, capítulos, orçamento, plano do próximo ano e perguntas sobre o relatório), metodologia (/yontem/: a fonte e os limites de cada número), organização e contato (/dernek/ ou um nome que combine com a sua organização), privacidade e KVKK (/gizlilik/) e 404.html. Escreva os gráficos como SVG estático gerado a partir dos valores que informei, sem Chart.js nem D3; não arredonde os valores e confira se os totais fecham. Mostre o orçamento como uma `<table>` sem nenhuma largura mínima, não como gráfico.
Estilo: uma leitura longa, como uma reportagem de dados de jornal. Fundo na cor de papel, uma fonte serifada da Fontshare para os títulos (por exemplo, Bespoke Serif) e uma fonte de texto legível que suporte tabular-nums (por exemplo, Epilogue), com no máximo duas cores nos gráficos. No desktop, uma lista fixa de capítulos de 220 px à esquerda; no celular, uma faixa de capítulos com rolagem horizontal que fica fixa no topo, com uma linha fina de progresso de leitura abaixo dela.
Regras de movimento (a parte mais difícil, siga à risca):
1. Bibliotecas: apenas o núcleo do GSAP 3.13 e o ScrollTrigger, somente na página do relatório. O Lenis NÃO é carregado, porque a rolagem nativa é mais confortável para uma leitura longa; SplitText e bibliotecas de gráficos também não são carregados. Nenhum script nas páginas de metodologia, organização e privacidade.
2. Gráficos de linha: cada linha é um `<path pathLength="1">` e já vem totalmente desenhada no HTML. O JS define strokeDasharray 1 e strokeDashoffset 1 apenas nos gráficos que estão abaixo da tela no carregamento e leva o offset a 0 com ScrollTrigger scrub (start "top 75%", end "bottom 65%"); os pontos de dados surgem conforme a linha passa por eles. Faça o texto do SVG ter pelo menos 22 unidades em um viewBox de 600 unidades, para que fique acima de 12 px no celular, e deixe pelo menos 40 unidades à direita para que o último rótulo do eixo não seja cortado.
3. Todo gráfico é um `<svg role="img" aria-labelledby>` com title e desc que informa todos os valores em uma frase; a figcaption mostra a fonte e aponta para a nota de metodologia e, LOGO APÓS a figure, um `<details>` com o rótulo "Ver os dados em tabela" traz uma `<table>` de verdade. Essa tabela é a versão em texto dos dados, tanto para acessibilidade quanto para busca com IA.
4. Contadores: o valor final é escrito no HTML no formato turco (como 31.540). O número visual fica em um span com aria-hidden e o mesmo valor fica em um span sr-only para leitores de tela. O JS zera apenas os contadores que estão abaixo da tela no carregamento e os faz contar com Intl.NumberFormat("tr-TR") quando entram na tela; nunca volte a zero um número que já está visível. Aplique tabular-nums ao número e uma largura mínima igual ao número de caracteres do valor final (com uma classe do Tailwind, não um atributo style) para que a linha não se mova durante a contagem.
5. Navegação por capítulos: os links são âncoras que funcionam sem JS. O JS usa um ScrollTrigger por capítulo para encontrar o ativo, define aria-current="true" no link dele e rola a faixa do celular na horizontal para que o link ativo fique visível (a faixa, não a página). Coloque o comportamento fixo na barra lateral (aside) que é filha direta do grid que ocupa todo o relatório, não no nav interno; na demonstração, o sticky no nav interno nunca funcionou no celular.
6. Nenhum outro movimento além da linha de progresso de leitura e das imagens que aparecem com data-reveal.
Configuração e armadilhas conhecidas (cada uma custou pontos ou quebrou algo na medição da demonstração, não pule nenhuma):
1. Se já houver um site no ar no servidor, avise-me primeiro, porque a configuração sobrescreve o index.html e a pasta assets. Mostre a prévia do scaffold_site com confirm=false e chame confirm=true depois da minha aprovação. Em seguida, leia site_design_guide e site_seo_guide. Antes de escrever código, coloque a direção de design (tipografia, cor, grid, elemento de assinatura, linguagem de movimento e as bibliotecas que NÃO serão carregadas) em um ART.md curto fora de assets e mostre para mim.
2. Compile o Tailwind, não o carregue pela CDN. Instale com `npm i -D tailwindcss@3` usando site_run_command com background=true e acompanhe com site_command_status. Os caminhos de content em `tailwind.config.js` devem cobrir todos os arquivos HTML, todos os templates e todos os arquivos JS que escrevem classes. `_src/tw.css` contém uma linha `@import "../assets/app.css";` e as três linhas `@tailwind`; compile-o em um único arquivo com `npx tailwindcss -c tailwind.config.js -i _src/tw.css -o assets/site.css --minify`. Remova o script cdn.tailwindcss.com e o tailwind.config inline das páginas e vincule apenas `/assets/site.css`. Recompile após cada alteração no HTML.
3. Hospede as fontes você mesmo. Primeiro verifique se a família da Fontshare escolhida tem as letras turcas (ş, ğ, ı, İ, ç, ö, ü): na demonstração, a Tanker não tinha o ı sem ponto e a Outfit não tinha ş, ğ nem İ, então essas letras cairiam em outra fonte nos títulos. Baixe o woff2 de cada peso separadamente com site_fetch para `assets/fonts/`, escreva as regras @font-face com `font-display: swap` em `assets/app.css` (o design-check procura a fonte personalizada ali) e confira o nome do font-family no CSS que você baixou. Faça preload das fontes de título e de texto usadas acima da dobra em todas as páginas com `<link rel="preload" as="font" type="font/woff2" crossorigin>`, antes da folha de estilo; não faça preload de mais de dois arquivos, porque o preload de um terceiro peso na demonstração aumentou o LCP no celular em 0,2 segundo. A maioria das fontes da Fontshare não tem o símbolo ₺, então escreva "TL" nos preços.
4. Deixe o menu e o rodapé como HTML estático. Não carregue chrome.js nem site.config.js nas páginas. Escreva um pequeno `chrome-stamp.mjs` que leia a lista de navegação de site.config.js e carimbe `_src/header.tpl` e `_src/footer.tpl` entre os marcadores `<!-- nav:start --><!-- nav:end -->` e `<!-- footer:start --><!-- footer:end -->` em todas as páginas, adicionando aria-current="page" ao link ativo. Os templates não devem terminar em .html e devem usar placeholders como `
[[NAV]]` em vez de `{{...}}`. Construa o menu mobile sem JS usando `<details>`. Mantenha o nome da organização, o endereço e o telefone como texto simples no rodapé e faça todo alvo de toque ter pelo menos 44x44 px, incluindo os links do rodapé e do breadcrumb.
5. Converta as imagens durante o download com site_fetch: grave a mesma foto com resize="480x", "800x" e "1200x", image_format="webp", quality=65 em arquivos separados. O site_fetch nunca recorta; quando uma foto do Unsplash precisar de outra proporção, baixe a versão recortada adicionando parâmetros como `?w=1600&h=1200&fit=crop` à URL. Dê a todo `<img>` srcset, sizes, além de width e height compatíveis com a proporção real. A imagem principal acima da dobra recebe fetchpriority="high" e não é lazy; as demais recebem loading="lazy" decoding="async". Se a imagem principal ocupar a tela inteira no celular, sirva um recorte menor com `<picture>`.
6. Escreva a versão SVG do logo como favicon.svg com site_write_file e adicione `<link rel="icon" href="/favicon.svg" type="image/svg+xml">` a todas as páginas. Sem favicon, o navegador registra um 404 e as Práticas Recomendadas caem para 96.
7. Regras do validador de HTML: comece com um `<!DOCTYPE html>` em maiúsculas, use ` ` nos espaços do texto visível dos links tel:, nunca use o atributo style="", dê type="button" a todo botão e não coloque um `<details>` dentro de uma `<figure>` depois da figcaption.
8. Baixe as bibliotecas de movimento (GSAP, ScrollTrigger) do jsdelivr para `assets/vendor/` com site_fetch, fixe a versão e carregue-as somente na página do relatório. Não use `<script defer>`; coloque um pequeno loader no final da página que espere o evento load, duas chamadas de requestAnimationFrame e depois requestIdleCallback, e acrescente os scripts em ordem com async=false. Um script de uma linha no `<head>` adiciona a classe `js` ao `<html>` e a classe `anim`, a menos que prefers-reduced-motion seja "reduce"; sem `anim`, o loader não baixa nada. Defina os estados iniciais ocultos somente sob `.anim` e adicione uma animação CSS de segurança que revele todos os elementos ocultos após 2,5 segundos, caso a biblioteca nunca chegue. Em demonstrações anteriores, bibliotecas com defer levaram o LCP no celular a 3,2 segundos; com este loader, as páginas ficaram entre 99 e 100. Chame o atributo dos elementos revelados na rolagem de data-reveal; o design-check só reconhece movimento por esse nome.
SEO, AEO e GEO:
1. Use URLs em estilo de diretório com barra final (/yontem/, /dernek/, /gizlilik/). Preencha o bloco seo de site.config.js e execute `node seo-stamp.mjs`. Escreva o schema específico de cada página (página do relatório: WebPage com um Report como mainEntity, incluindo headline, datePublished, dateModified, image, author (Person, o editor) e publisher, além de FAQPage; metodologia: Article; página da organização: AboutPage com um subtipo adequado à organização (por exemplo, NGO); BreadcrumbList nas páginas internas. Se não houver um escritório que as pessoas visitem, defina localBusiness:false em site.config.js) em blocos `<script type="application/ld+json">` separados e conecte-os ao grafo base por @id. Não aninhe BreadcrumbList dentro de @graph; mantenha-o em um bloco próprio, porque é a única forma de o seo-check enxergá-lo.
2. Mantenha os títulos com 60 caracteres ou menos (o seo-check marca como erro qualquer um acima de 65), as descrições entre 120 e 158 caracteres, um h1 por página e nenhum nível de título pulado (um h3 logo após o h1 derrubou a acessibilidade para 98). Toda página precisa de pelo menos 150 palavras de conteúdo principal; páginas de contato e privacidade costumam ficar abaixo disso.
3. O primeiro parágrafo de cada página responde diretamente à pergunta da página. Escreva FAQs específicas de cada página com `<details>` e marque-as como FAQPage. Mostre a organização que publica e uma data de "Última atualização" em `<time>`.
4. No robots.txt, registre e justifique sua decisão para GPTBot, OAI-SearchBot, ChatGPT-User, ClaudeBot, Claude-User, Claude-SearchBot, PerplexityBot, Perplexity-User, Google-Extended, Applebot-Extended, Bingbot e CCBot, e aponte para o sitemap. Dê ao sitemap.xml datas lastmod reais. O llms.txt traz um resumo preciso do site em duas frases, os fatos principais e uma lista das páginas importantes.
5. Sem invenção: não escreva avaliações, notas, prêmios, número de clientes, certificados, horários de funcionamento, coordenadas nem preços sem me perguntar. Deixe de fora do schema qualquer campo que você não conheça.
Portões de qualidade (em ordem; não diga "pronto" até que todos passem):
1. Com site_run_command, execute `node chrome-stamp.mjs`, o build do Tailwind, `node seo-stamp.mjs`, `node seo-check.mjs` (0 erros, 0 avisos), `node design-check.mjs` (0 erros; justifique qualquer aviso restante) e `npx html-validate "**/*.html"` (0 erros).
2. Veja cada página com site_preview usando view="mobile" e view="desktop". O site_preview captura a página com o movimento desligado (reduced-motion); se faltar conteúdo nessa captura, o estado sem movimento está quebrado. Imagens lazy mais abaixo podem aparecer em branco na captura de página inteira; não conte isso como erro, mas confira os caminhos delas.
3. Execute core_web_vitals com strategy="mobile" e strategy="desktop" para cada página. Critério de aceitação: no celular, Performance de pelo menos 95 e Acessibilidade, Práticas Recomendadas e SEO em 100; no desktop, as quatro notas de pelo menos 95. Para uma página que não atingir, encontre o arquivo lento com resources=true, corrija e meça de novo. Depois, execute seo_audit na página inicial com strategy="mobile" e runs=2. Nenhum endereço fora do seu próprio domínio pode restar na lista de requisições de rede.
4. Sem rolagem horizontal em 360, 390, 768 e 1440 px, alvos de toque de pelo menos 44 px e nenhum erro no console. O site também deve ficar impecável dentro de um quadro de 390x790 e de 1440x898, como nas páginas de prompts.
Verificação de movimento: o site_preview não consegue mostrar movimento, então diga-me o que observar no meu próprio navegador. No desktop, os contadores devem contar de zero até o valor final quando entrarem na tela, as linhas dos gráficos devem ser desenhadas da esquerda para a direita conforme a rolagem, com os pontos surgindo um a um, e a lista de capítulos à esquerda deve marcar o capítulo que está sendo lido. No celular, a faixa de capítulos deve ficar fixa no topo e deslizar o capítulo ativo para a vista. Com movimento reduzido ativado e com o JavaScript desligado, todo número mostra o valor final e todo gráfico aparece totalmente desenhado; as tabelas de dados podem ser abertas.
Depois de publicar: faça a prévia da regra `/assets/* Cache-Control: public, max-age=31536000, immutable` com site_headers e aplique-a após a minha aprovação; a partir daí, versione o nome do arquivo sempre que o CSS ou o JS mudar (site-v2.css e assim por diante). Envie o sitemap.xml com gsc_submit_sitemap e verifique a página inicial com gsc_url_inspect. Por fim, entregue-me: uma tabela de notas por página (página, quatro notas no celular, quatro notas no desktop, LCP, CLS), os resultados dos portões, o resultado das interações que você testou em um navegador e a lista das correções aplicadas.
