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 Opus Growth
[nome do servidor], crie um site de produto escuro e com várias páginas para
[nome do produto], que conte a história do produto conforme o visitante rola a página. Produto:
[o que faz, para quem é]. Os três passos que um usuário segue no produto:
[três passos]. Principais recursos:
[4 a 6 recursos]. Contato:
[e-mail],
[telefone],
[número do WhatsApp],
[endereço, se houver]. Domínio:
[domínio]. Preferência de cor:
[cor ou "você escolhe"]. Capturas de tela ou fotos reais do produto:
[links ou "nenhuma"].
Páginas: início (/), produto (/urun/), sobre (/hakkimizda/), contato (/iletisim/), privacidade (/gizlilik/) e 404.html. Seções da página inicial, em ordem: hero (h1, descrição em duas frases, dois botões, imagem do produto), a história do produto como elemento de assinatura, recursos, para quem é, FAQ e uma chamada final para ação. Sem formulário na página de contato; use email, telefone e um link do WhatsApp com mensagem pré-preenchida, porque o servidor serve apenas arquivos estáticos.
Estilo: movimento escuro. Fundo escuro, uma única cor de destaque contida (não neon), uma fonte display grotesca compacta da Fontshare (por exemplo, Cabinet Grotesk) e uma fonte de texto calma (por exemplo, Switzer). Sem gradientes e sem WebGL; guarde a ousadia para a história do produto.
Regras de movimento (a parte mais difícil, siga-as à risca):
1. Bibliotecas: GSAP 3.13 core, ScrollTrigger, SplitText e Lenis. Baixe-as do jsdelivr para `assets/vendor/` com site_fetch e fixe a versão. Carregue-as apenas nas páginas inicial e de produto; as páginas sobre, contato e privacidade não levam nenhum script. Não carregue o Swiper.
2. Não anexe essas bibliotecas com `<script defer>`. Coloque um pequeno loader no final da página: depois do evento load, ele espera duas chamadas de requestAnimationFrame e então requestIdleCallback, adiciona os scripts em ordem com async=false e não baixa nada se `<html>` não tiver a classe `anim`. Na demonstração, as bibliotecas com defer levaram o LCP no mobile a 3,2 s e deixaram o Performance em 92; com esse loader chegou a 99.
3. 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". Defina os estados iniciais ocultos apenas sob `.anim`, para que o conteúdo fique visível desde o início com JS desativado ou para visitantes que preferem menos movimento, e as bibliotecas nunca sejam baixadas para eles. Como rede de segurança caso uma biblioteca falhe ao carregar, adicione uma animação CSS que torne visíveis todos os elementos ocultos após 2,5 s. Se o JS chegar depois disso, não oculte novamente o conteúdo visível; apenas monte a história fixada.
4. Entrada do título com SplitText: o h1 da primeira tela é o elemento LCP, nunca o comece oculto. O h1 começa visível em uma cor atenuada que ainda passa no contraste AA, e o SplitText leva suas linhas à cor total uma após a outra (opções mask e aria ativadas). Mantenha a entrada das linhas mascaradas, subindo, nos títulos h2 mais abaixo e execute-a na rolagem com ScrollTrigger.
5. Elemento de assinatura: na história do produto, use pin e scrub do ScrollTrigger por meio de gsap.matchMedia apenas a partir de 768 px de largura (scrub em torno de 0.6, end "+=180%"). À esquerda, os três passos ficam ativos um a um; à direita, a tela do produto se preenche passo a passo. Não esmaeça os passos inativos com opacity; mude apenas a cor do título e a linha da borda. Na demonstração, passos esmaecidos com opacity falharam no contraste no desktop e derrubaram a Acessibilidade para 95. No mobile não há pin; os passos aparecem no fluxo normal. Sem JS, a tela do produto mostra seu estado final.
6. Ative o Lenis apenas em dispositivos `(pointer: fine)` para que dispositivos de toque mantenham a rolagem nativa. Controle o Lenis pelo gsap.ticker e mova o foco para o destino depois de rolar até um link interno da página.
7. A tela do produto é uma figura decorativa com aria-hidden e uma figcaption que diz o que ela mostra. Toda interação funciona com o teclado e o anel de foco permanece visível.
Configuração e armadilhas conhecidas (cada uma reduziu uma pontuação nas medições 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 index.html e a pasta assets. Mostre uma prévia de scaffold_site com confirm=false e chame-o com confirm=true após a minha aprovação. Depois 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 em vez de carregá-lo pela CDN. Instale-o com site_run_command e background=true: `npm i -D tailwindcss@3`, e depois acompanhe com site_command_status. Os caminhos de content em `tailwind.config.js` devem cobrir todos os arquivos HTML, os templates e qualquer arquivo JS que escreva nomes de classes. `_src/tw.css` contém a 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 de todas as páginas e vincule apenas `/assets/site.css`. Recompile após cada alteração de HTML.
3. Hospede as fontes você mesmo. Leia o CSS das famílias da Fontshare que escolheu, baixe o arquivo woff2 de cada peso para `assets/fonts/` com site_fetch e escreva as regras @font-face com `font-display: swap` em `assets/app.css`; o design-check procura uma fonte personalizada ali. Confira o nome do font-family no CSS que você baixou, porque a Fontshare pode devolver outra família quando um peso não existe. Faça preload da fonte do título da primeira tela e da fonte do texto em todas as páginas com `<link rel="preload" as="font" type="font/woff2" crossorigin>`; na demonstração isso eliminou o deslocamento de layout causado pela troca de fonte (CLS de 0,024 para 0). A maioria das fontes da Fontshare não tem o glifo ₺, então escreva "TL" nos preços.
4. Faça o menu e o rodapé em 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 em site.config.js e carimbe `_src/header.tpl` e `_src/footer.tpl` entre os marcadores `<!-- nav:start --><!-- nav:end -->` e `<!-- footer:start --><!-- footer:end -->` de cada página, adicionando aria-current="page" ao link atual. Não dê aos templates a extensão .html e use marcadores como `
[[NAV]]` em vez de `{{...}}`, caso contrário o design-check e o seo-check os leem como páginas inacabadas. Construa o menu mobile sem JS usando `<details>`. Mantenha o nome da empresa, o endereço e o telefone no rodapé como texto simples.
5. Converta as imagens durante o download com site_fetch: grave a mesma foto em arquivos separados com resize="480x", "800x" e "1200x", image_format="webp", quality=65. Dê a cada `<img>` srcset, sizes, width e height. A imagem principal da primeira tela recebe fetchpriority="high" e nunca é lazy; as demais recebem loading="lazy" decoding="async". Se a imagem principal ocupa toda a tela do celular, sirva um recorte mais largo e menor no mobile com `<picture>` (na demonstração, o hero mobile caiu de 89 KB para 43 KB).
6. Crie um favicon PNG de 48 px a partir do logotipo com site_fetch e adicione `<link rel="icon">` a todas as páginas. Sem ele, o navegador registra um 404 e as Boas Práticas caem para 96.
7. Regras do validador de HTML: comece todo documento com `<!DOCTYPE html>` em maiúsculas (os arquivos iniciais do kit usam minúsculas), use ` ` nos espaços do texto visível dos links tel:, nunca use o atributo style="" e dê a todo botão type="button".
SEO, AEO e GEO:
1. Use URLs de diretório com barra final (/urun/, /hakkimizda/, /iletisim/, /gizlilik/). Preencha o bloco seo de site.config.js e execute `node seo-stamp.mjs`. Escreva o schema específico de cada página (início WebPage e FAQPage; produto SoftwareApplication e FAQPage; sobre AboutPage; contato ContactPage; BreadcrumbList nas páginas internas. Para uma empresa de software sem loja física, defina localBusiness:false em site.config.js) em blocos `<script type="application/ld+json">` separados e vincule-o ao grafo base com @id. Não esconda o BreadcrumbList dentro de um @graph; dê a ele seu próprio bloco, porque essa é a única forma de o seo-check o enxergar.
2. Títulos de 48 a 60 caracteres (o seo-check sinaliza como erro qualquer um acima de 65), descrições de 145 a 158 caracteres, um h1 por página. Toda página precisa de pelo menos 150 palavras de conteúdo principal; as 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 um FAQ específico da página com `<details>` e marque-o como FAQPage. Mostre a organização responsável pela publicação e uma data de "Última atualização" com `<time>`.
4. No robots.txt, escreva sua decisão com o motivo 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. O sitemap.xml traz datas lastmod reais. O llms.txt contém um resumo preciso do site em duas frases e a lista das páginas principais.
5. Não invente nada: nenhuma avaliação, nota, prêmio, número de clientes, certificado, horário de funcionamento, coordenada ou preço, a menos que eu os informe. Deixe campos desconhecidos fora do schema.
Critérios de aprovação (em ordem; não diga que terminou 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 todas as páginas com site_preview, view="mobile" e view="desktop". O site_preview captura a página com o movimento desativado (reduced-motion), então, se faltar conteúdo nessa imagem, o estado sem movimento está quebrado. Nas capturas de página inteira, imagens lazy mais abaixo podem aparecer vazias; isso não é erro, mas confira os caminhos delas.
3. Execute core_web_vitals em todas as páginas com strategy="mobile" e strategy="desktop". Aprovação: no mobile, Performance de pelo menos 95 e Acessibilidade, Boas Práticas e SEO 100; no desktop, as quatro de pelo menos 95. Em uma página que falhar, use resources=true para encontrar o arquivo que a atrasa, corrija e meça novamente. Depois execute seo_audit na página inicial com strategy="mobile" e runs=2. A lista de requisições de rede não pode conter nenhum host além do seu próprio domínio.
4. Sem rolagem horizontal nas larguras de 360, 390, 768 e 1440 px, alvos de toque de pelo menos 44 px, nenhum erro no console.
Verificação de movimento: o site_preview não consegue mostrar movimento, então descreva a seção fixada da página inicial e diga o que devo verificar no meu próprio navegador: no desktop, a história do produto deve ficar presa no topo enquanto os passos avançam com a rolagem; no celular, deve fluir sem ficar presa; e, com redução de movimento ativada no sistema operacional, nada deve se mover e tudo deve estar visível.
Depois de publicar: mostre 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í, renomeie os arquivos CSS ou JS quando mudarem (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. Termine com uma tabela de pontuação por página (página, quatro pontuações mobile, quatro pontuações desktop, LCP, CLS), os resultados dos critérios e a lista de correções aplicadas.
