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 várias páginas para
[nome da empresa] que não carregue nenhum JavaScript e faça suas animações e transições de página com os recursos de CSS do próprio navegador. Negócio:
[o que faz, para quem], cidade:
[cidade, bairro]. Serviços ou produtos:
[lista]. Trabalhos: [para cada um: nome, material ou escopo, duração, problema resolvido, link da imagem]. Contato:
[e-mail],
[telefone],
[número de WhatsApp],
[endereço]. Domínio:
[domínio].
Páginas: início (hero, trabalhos recentes, processo, FAQ), trabalhos (/isler/), sobre (/hakkimizda/), contato (/iletisim/, sem formulário), privacidade (/gizlilik/) e 404.html.
Estilo: editorial e natural. Uma fonte serifada de destaque (por exemplo Zodiak) com uma fonte de texto discreta (por exemplo Switzer), fundo em tom de linho, um único acento escuro, muito espaço. Guarde a ousadia para os cards de trabalho.
Regras de CSS moderno (aprimoramento progressivo; em um navegador sem suporte, a página deve ficar estática, mas completa):
1. Não carregue nenhum arquivo JavaScript; nada de GSAP, Lenis ou Swiper. O menu mobile funciona com `<details>`.
2. Transições de página (View Transitions entre páginas da mesma origem): escreva `@media (prefers-reduced-motion: no-preference) { @view-transition { navigation: auto; } }` e mantenha a duração em torno de 0,35 s. Dê à barra superior o view-transition-name: site-header. Dê à imagem de um card de trabalho na página inicial e à mesma imagem na página de trabalhos o mesmo view-transition-name único, para que a imagem cresça até o seu lugar na nova página. Use cada nome apenas uma vez por página.
3. Animações guiadas por rolagem: uma linha de progresso no topo que cresce com scaleX em `animation-timeline: scroll(root)` (display:none por padrão, visível apenas com suporte); em cards e títulos de seção, `animation-timeline: view()` com `animation-range: entry 0% entry 70%` usando apenas translateY; na imagem do hero, uma escala e um deslocamento suaves enquanto ela está em vista. Não use opacity: elementos esmaecidos abaixo da tela reprovam na checagem de contraste do Lighthouse. Coloque todas essas regras dentro de `@supports (animation-timeline: scroll())` e `prefers-reduced-motion: no-preference`.
4. Container queries: transforme o card de trabalho em um componente com `container-type: inline-size`. Com `@container (min-width: 34rem)`, a imagem fica em cima em um contêiner estreito e ao lado do texto em um contêiner largo. O mesmo card é estreito em uma grade de três colunas na página inicial e largo em uma única coluna na página de trabalhos. O núcleo do Tailwind 3 não tem classes de container query; escreva essas regras como CSS puro em app.css.
5. O nível de título do card deve se adequar à página em que ele está: na página de trabalhos, coloque um h2 entre o h1 e os títulos h3 dos cards. Quando isso faltou na demonstração, Acessibilidade caiu para 98 por causa de heading-order.
6. Na página de trabalhos, a primeira imagem de card que entra na primeira tela não usa lazy e recebe fetchpriority="high".
Configuração e armadilhas conhecidas (cada uma reduziu uma nota 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 o index.html e a pasta assets. Mostre a prévia de scaffold_site com confirm=false e chame 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, 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 em vez de carregá-lo pelo CDN. Instale com site_run_command e background=true: `npm i -D tailwindcss@3`, e em seguida 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 no HTML.
3. Hospede as fontes você mesmo. Leia o CSS das famílias Fontshare escolhidas, baixe o arquivo woff2 de cada peso em `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 retornar 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 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 ao baixá-las 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 preencher a tela do celular, sirva um recorte mais largo e menor no mobile com `<picture>` (na demonstração, o hero mobile passou de 89 KB para 43 KB).
6. Crie um favicon PNG de 48 px a partir do logo com site_fetch e adicione `<link rel="icon">` a todas as páginas. Sem ele, o navegador registra um 404 e Boas Práticas cai para 96.
7. Regras do validador de HTML: comece cada 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 (/isler/, /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; trabalhos: CollectionPage com um CreativeWork por peça em hasPart (com material, se conhecido); sobre: AboutPage; contato: ContactPage; BreadcrumbList nas páginas internas. O subtipo de LocalBusiness mais específico 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 um bloco próprio, pois é a única forma de o seo-check enxergá-lo.
2. Títulos de 48 a 60 caracteres (o seo-check marca como erro tudo acima de 65), descrições de 145 a 158 caracteres, um h1 por página. Cada 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: nada de avaliações, notas, prêmios, números de clientes, certificados, horários de funcionamento, coordenadas ou preços, a menos que eu os informe. Deixe os 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`, 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, 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. Em 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 para cada página com strategy="mobile" e strategy="desktop". Para passar: no mobile, Desempenho de pelo menos 95 e Acessibilidade, Boas Práticas e SEO em 100; no desktop, as quatro notas de pelo menos 95. Em uma página que falhar, use resources=true para encontrar o arquivo que a atrasa, corrija e meça de novo. Depois execute seo_audit na página inicial com strategy="mobile" e runs=2. A lista de requisições de rede não deve 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, sem erros no console.
Verificação de suporte: o site_preview captura com o movimento desligado, então não consegue mostrar as transições. Explique como conferir no Chrome que a imagem cresce até o seu lugar quando clico em uma peça na página inicial, que a linha do topo se preenche conforme eu rolo, que o card muda de layout conforme estreito e alargo a janela, e que a página abre completa em um navegador sem esses recursos.
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 notas por página (página, quatro notas mobile, quatro notas desktop, LCP, CLS), os resultados dos critérios e a lista das correções aplicadas.
