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 um site de apresentação (landing site) para o aplicativo móvel
[nome do app]. App:
[o que faz, para quem é], plataformas e versões mínimas:
[versões do iOS e do Android]. Os quatro recursos principais e o que cada tela mostra:
[recurso, descrição em uma frase, itens na tela]. Planos e preços: [nome do plano, preço, período, recursos incluídos, duração do teste; impostos incluídos ou não]. Links das lojas:
[link da App Store],
[link do Google Play]. Perguntas de suporte: [respostas reais sobre exclusão de conta, cancelamento, exportação de dados e assim por diante]. Empresa e contato:
[nome da empresa],
[endereço],
[e-mail de suporte],
[telefone]. Domínio:
[domínio]. Capturas de tela reais:
[links ou "nenhuma, desenhe-as em HTML"].
Páginas: início (/: hero, apresentação dos recursos conduzida pelo celular #ozellikler, quem usa, preços #fiyatlar, FAQ, chamada para download #indir), suporte (/destek/: perguntas frequentes e contato de suporte), privacidade e KVKK (/gizlilik/: cobrindo o app e o site; as lojas pedem a URL de uma política de privacidade) e 404.html. A seção de preços tem cards de planos e, abaixo deles, uma comparação em `<table>` real; não dê min-width à tabela, porque na demonstração uma largura mínima fixa empurrou colunas para fora da tela em celulares.
Estilo: uma landing page de app acolhedora e confiável. Fundo creme, uma cor de marca escura e um único destaque vibrante usado apenas como fundo. Uma fonte de exibição arredondada e amigável da Fontshare (por exemplo, Chillax) e uma fonte de texto legível (por exemplo, Manrope). Desenhe a moldura do celular em CSS (aspect-ratio 9/19, cantos arredondados, um notch) e construa as telas em HTML e CSS em vez de arquivos de imagem; os cards de tela são decoração com aria-hidden e o texto ao lado descreve o recurso. Para um app real, baixe os selos oficiais da Apple e do Google para o seu próprio servidor para os botões das lojas e siga as diretrizes deles; adicione a nota de marca registrada ao rodapé.
Regras de movimento (a parte mais difícil, siga-as à risca):
1. Bibliotecas: somente o núcleo do GSAP 3.13 e o ScrollTrigger, somente na página inicial. Lenis, SplitText, Swiper, Lottie e vídeo NÃO são carregados; nenhum script nas páginas de suporte e privacidade.
2. Cada seção de recurso traz no HTML o seu próprio celular pequeno e a sua tela. Em celulares, sem JS e com movimento reduzido, cada recurso aparece com a sua própria tela, empilhados (lado a lado em telas maiores); esse estado deve ser completo por si só.
3. A partir de 1024 px, quando o movimento é permitido, o JS copia as telas das seções para o único celular na coluna da direita, adiciona uma classe `has-phone` à seção e oculta os celulares pequenos. Não escreva as telas duas vezes no HTML. Como a seção de recursos fica abaixo da primeira dobra, essa mudança de classe não conta como mudança de layout; a demonstração mediu CLS 0.
4. Mantenha o celular no lugar com `position: sticky` em CSS (top: calc(50vh - metade da altura do celular)) em vez de um pin do ScrollTrigger. Nenhum pin-spacer é adicionado, funciona sem JS e a página não dá saltos.
5. Troca de tela: para cada seção de recurso use ScrollTrigger.create com start "top 55%", end "bottom 55%" e onToggle; mostre a tela ativa com autoAlpha do gsap e oculte a anterior com autoAlpha 0. Não use apenas opacity; as telas ocultas devem estar com visibility:hidden para que a auditoria de acessibilidade não as leia. O título da seção ativa muda de cor (sem esmaecer com opacity), e pontos ao lado do celular mostram qual recurso está ativo.
6. Cards e caixas de preços aparecem com data-reveal, deslizando 20 px para cima ao rolar; limpe as telas copiadas na função de reversão do matchMedia para que o layout não quebre quando a janela for estreitada.
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. Veja a prévia de scaffold_site com confirm=false e chame 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, grade, elemento marcante, linguagem de movimento e as bibliotecas que NÃO serão carregadas) em um ART.md curto fora de assets e mostre-o para mim.
2. Compile o Tailwind, não o carregue pela CDN. Instale `npm i -D tailwindcss@3` com site_run_command e 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 que você escolher 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 cada página 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 na demonstração o preload de um terceiro peso 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. 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 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 cada página, adicionando aria-current="page" ao link ativo. Os templates não devem terminar em .html e devem usar marcadores como `
[[NAV]]` em vez de `{{...}}`. Construa o menu móvel 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 ao baixá-las 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 e width e height que correspondam à 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 preencher a tela no celular, sirva um recorte menor com `<picture>`.
6. Escreva a versão SVG do logotipo 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 `<!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 do 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 inicial. Não use `<script defer>`; coloque um pequeno loader no fim da página que espere o evento load, duas chamadas de requestAnimationFrame e depois requestIdleCallback, e anexe 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 mediram de 99 a 100. Dê o nome data-reveal ao atributo dos elementos revelados na rolagem; o design-check só reconhece movimento por esse nome.
SEO, AEO e GEO:
1. Use URLs em estilo de diretório com barra final (/destek/, /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, MobileApplication (operatingSystem, applicationCategory, as duas URLs das lojas como downloadUrl, os planos que eu informei como offers com preços em TRY; NÃO adicione aggregateRating, porque a nota de uma loja não é uma avaliação coletada no seu site) e FAQPage; suporte: WebPage e FAQPage; privacidade: WebPage; BreadcrumbList nas páginas internas. Para uma empresa de software sem loja física, localBusiness:false em site.config.js) em blocos `<script type="application/ld+json">` separados e vincule-os ao grafo base por @id. Não aninhe BreadcrumbList dentro de @graph; mantenha-o em seu próprio bloco, pois essa é 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 a 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úmeros de clientes, certificados, horários de funcionamento, coordenadas nem preços sem me perguntar. Deixe totalmente 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`, a compilação 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 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 da 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 todas as páginas. Critério de aceitação: no celular, Performance de pelo menos 95 e Acessibilidade, Práticas recomendadas e SEO 100; no desktop, as quatro 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 permanecer 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, ao chegar à seção de Recursos, o celular deve ficar fixo no meio da tela, à direita, a tela dele deve mudar para cada recurso conforme o título chega ao meio, o título deve ganhar cor e o ponto ao lado dele deve avançar. Em um celular e com movimento reduzido ativado, cada recurso mostra a sua própria tela pequena e nada fica fixo no lugar. Os botões das lojas devem abrir a loja certa.
Depois de publicar: veja 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 que você aplicou.
