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], construa um site de portfólio com rolagem horizontal para
[nome do escritório ou do fotógrafo]. O que eu faço: [arquitetura, design de interiores ou fotografia; que tipo de trabalho], cidade:
[cidade, bairro], ano de fundação e equipe:
[ano, número de pessoas, nome do fundador]. Projetos: [para cada um, nome, local, ano, status, área construída ou tipo de ensaio, resumo em uma frase, questão, abordagem, processo, materiais ou técnica, pelo menos dois links de fotos]. Trabalhos em andamento:
[nome, local, ano, uma frase]. Registro profissional:
[se houver]. Contato:
[e-mail],
[telefone],
[número de WhatsApp],
[endereço]. Domínio:
[domínio].
Páginas: home (/: hero, galeria horizontal de projetos, abordagem, FAQ), uma página por projeto (/projeler/
[nome-do-projeto]/: imagem em largura total, ficha técnica, questão, abordagem, processo, materiais, uma segunda imagem, link para o próximo projeto), escritório e contato (/ofis/, com a seção de contato na âncora #iletisim), privacidade e KVKK (/gizlilik/) e 404.html. Sem formulário; e-mail, telefone e um link de WhatsApp com mensagem pré-preenchida bastam. Se um projeto em andamento não tiver página de detalhes, não transforme o card dele em link.
Estilo: um portfólio calmo, com cara de galeria. Fundo cor de calcário, texto escuro, cantos retos e linhas finas; a cor de destaque aparece apenas no hover e no foco. Uma fonte display serifada da Fontshare (por exemplo Erode) e uma fonte de texto grotesca simples (por exemplo Archivo). No desktop, o hero ocupa a tela inteira, então a galeria começa abaixo da primeira dobra.
Regras de movimento (a parte mais difícil, siga ao pé da letra):
1. Bibliotecas: GSAP 3.13 core, ScrollTrigger e Lenis, na home e nas páginas de projeto. SplitText e Swiper NÃO são carregados; nenhum script nas páginas de escritório e de privacidade.
2. O HTML e o CSS padrão é uma pilha vertical: uma coluna no celular, uma grade de duas colunas no desktop. Sem JS, com movimento reduzido e no celular, a galeria continua assim.
3. Deixe o CSS, e não o JS, montar o layout horizontal: a partir de 768 px e quando a classe `.anim` estiver presente, a trilha é `display:flex`, `width:max-content` e `height:calc(100vh - altura do header)` desde a primeira renderização, e o wrapper rola sozinho com `overflow-x:auto`. Assim o layout não muda quando o JS chega (CLS 0), e se a biblioteca nunca chegar a galeria ainda pode ser rolada para os lados.
4. Com gsap.matchMedia, apenas para `(min-width: 768px)`, fixe o wrapper com ScrollTrigger, scrub 0.8, um end igual ao excedente da trilha ("+=" + (track.scrollWidth - innerWidth)) e invalidateOnRefresh ativado; adicione uma classe que dê `overflow:hidden` ao wrapper. Uma linha fina de progresso avança com scaleX.
5. Revelação das imagens: as imagens da galeria se abrem da esquerda para a direita com containerAnimation, de clip-path `inset(0 100% 0 0)` para `inset(0)`. Nunca esconda o painel visível na primeira dobra nem a imagem do hero. No celular e nas páginas de projeto, apenas as imagens que estão abaixo da tela no carregamento se abrem para cima com clip-path.
6. Teclado: quando o Tab chega a um card que está fora da tela na trilha, o navegador rola o wrapper internamente e o card desaparece. No focusin, zere o scrollLeft do wrapper e role a página até a posição vertical em que o card entra na tela (scrollTrigger.start + (end - start) * deslocamento à esquerda do card / excedente total). Sem esse passo, o terceiro card alcançado com Tab ficou fora da tela na demo.
7. Ative o Lenis apenas em dispositivos `(pointer: fine)` e conecte-o ao ScrollTrigger.update; em links internos como #projeler, mova o foco para o destino após a rolagem.
Configuração e armadilhas conhecidas (cada uma custou pontos ou quebrou algo na medição da demo, 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 do 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 para mim.
2. Compile o Tailwind, não carregue pelo 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 escolhida tem as letras turcas (ş, ğ, ı, İ, ç, ö, ü): na demo 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 demo 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 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 enquanto as baixa 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 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 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 Best Practices cai 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, Lenis) do jsdelivr para `assets/vendor/` com site_fetch, fixe a versão e carregue-as apenas na home e nas páginas de projeto. Não use `<script defer>`; coloque um pequeno loader no final da página que espere o evento load, dois 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 apenas 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 demos 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 (/projeler/
[nome-do-projeto]/, /ofis/, /gizlilik/). Preencha o bloco seo de site.config.js e execute `node seo-stamp.mjs`. Escreva o schema específico de cada página (home: WebPage e FAQPage; cada página de projeto: WebPage com um CreativeWork como mainEntity, incluindo dateCreated, locationCreated e image; escritório: AboutPage com uma Person para o fundador; BreadcrumbList nas páginas internas. Para um estúdio de arquitetura ou fotografia com escritório, businessType ProfessionalService) em blocos `<script type="application/ld+json">` separados e vincule-os ao grafo base por @id. Não aninhe o BreadcrumbList dentro do @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 tudo 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; as páginas de contato e de 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 responsável pela publicação e uma data de "Última atualização" em `<time>`.
4. No robots.txt, escreva 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ções: 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 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`, 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 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 cada página. Critério de aceitação: no celular, Performance de pelo menos 95 e Accessibility, Best Practices 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 home 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 frame de 390x790 e de um 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, a galeria deve ficar fixa no topo quando você chegar à seção Projetos, os cards devem fluir para a esquerda conforme você rola para baixo, as imagens devem se abrir da esquerda para a direita e a linha de progresso deve se preencher; depois do último card a página volta ao fluxo normal. Ao navegar entre os cards com Tab, o card em foco deve estar sempre na tela. No celular e com movimento reduzido ativado, a galeria é uma pilha de cards e nada fica fixo.
Depois de publicar: mostre uma 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 home com gsc_url_inspect. Por fim, entregue-me: uma tabela de notas por página (página, as quatro notas no celular, as 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.
