Vivelebacon/demo-website

Site de demonstração

Uma execução leva um prospecto de "sim, gostaria de ver" até um redesign ao vivo e uma resposta aguardando em Rascunhos. O usuário cola uma URL ou um nome; todo o resto é encontrado, não perguntado. A direção criativa é delegada para toda a execução: não pare para obter respostas de entrevista ou aprovações.

Construção de referência: depois de enviar uma demonstração com a qual você está satisfeito, mantenha-a como referência. Leia seu BRIEF.md e copie sua estrutura (site.css, site.js, pages.css, home.css, home.js, lab/) como o esqueleto inicial. Nunca copie seu design: a porta da impressão digital o proíbe.

Regras fixas para cada demonstração

• Manter: o logotipo, cada fotografia, cada palavra do texto, cada página e a ordem das seções dentro de cada página. Erros de digitação permanecem. Rótulos de navegação permanecem. Rótulos de CTA permanecem.
• Alterar: tudo visual. Layout, tipografia, uso de cores, movimento, interação.
• Cada página é reformulada, não apenas a página inicial. Um arquivo HTML por página original, mesmos slugs (cleanUrls mantém /services funcionando).
• Adições permitidas: apenas microcópias de UI mínimas (linhas de status de formulário, um placeholder de entrada, rótulos aria). Nenhum novo texto de marketing, nenhum número inventado.
• As regras internas prevalecem sobre qualquer referência (edite esta lista ao seu gosto): paleta clara com o tom de destaque do cliente, marca + foto do proprietário + todos os serviços visíveis no hero, cabeçalho fixo sempre visível, clique no logotipo retorna ao topo (rolagem suave na página inicial), sem barra lateral, sem travessões visíveis em lugar nenhum, apenas fotos próprias do cliente (sem geração, a menos que o usuário peça).
• Implante na produção do Vercel e faça commit sem perguntar. E-mails são apenas rascunhos.

Passo 0 · Identificar o prospecto

1. Se o usuário forneceu um nome, não uma URL, e você mantém um CRM: procure o prospecto lá para obter site, cidade, idioma, a caixa de e-mail de onde o e-mail inicial foi enviado e o estado da resposta. Se o prospecto não estiver em um CRM, trabalhe a partir da URL e não pergunte nada; a etapa de rascunho dirá qual caixa de e-mail é necessária.
2. Slug: o núcleo do domínio, ex. acmecoaching. Pasta de construção: demos/<slug>-scrollcraft/. Projeto Vercel: <slug>-redesign. URL de demonstração: https://<slug>-redesign.vercel.app (hífen, nunca um ponto: um subdomínio com ponto não existe, e um link morto é o erro mais caro neste pipeline).
3. Primeiro nome para o e-mail: da assinatura de e-mail do prospecto, da página sobre/contato do site ou do domínio ("janecoaching" → Jane). Se realmente desconhecido, omita ("Olá," / "Hi,").

Passo 1 · Capturar todo o site existente

Tudo vai para <build>/_src/ (assets brutos) e <build>/lab/ (notas, capturas).

1. Busque a página inicial e leia os links de navegação + rodapé para listar cada página. Busque cada página.
2. Extraia por página, em ordem: seções, títulos, parágrafos (com spans em negrito/itálico), listas, botões e seus destinos, imagens (URLs em resolução total; para Squarespace anexe ?format=2500w, para Wix remova a transformação /v1/fill/...), formulários (rótulos de campos, flags obrigatórias, rótulo de envio, mensagem de sucesso), vídeo incorporado. Squarespace mantém definições de formulário em data-block-json / formFields.
3. Baixe o logotipo (todas as variantes: escuro, claro, favicon), cada foto, cada textura. Vetorize um logotipo geométrico simples para SVG com cv2.findContours + approxPolyDP em seu canal alfa; mantenha o PNG para marcas complexas.
4. Tokens de marca: tom de destaque/tinta/fundo das variáveis CSS do site, faces de título e corpo. Escolha a fonte Google mais próxima quando a face for Typekit ou personalizada.
5. Capturas de tela de página inteira de cada página ativa (scripts/full.mjs <live-url> 1440 900 lab/live <pages>) e leia-as: essa é a estrutura que você deve manter.

Passo 2 · Projetar com scroll-craft

Carregue sua skill de pesquisa de design, se tiver uma, depois scroll-craft (https://github.com/nateherkai/scroll-craft) e siga scroll-craft do início ao fim com estas substituições:

• O briefing é autoral sob delegação criativa explícita (a instrução permanente do usuário é esta skill). Escreva BRIEF.md com: as regras fixas acima, as evidências do Passo 1, os oito tópicos autorais, uma gramática nomeada com restrições reais, a curva de sentimento, o pico único, a frase "conte a alguém", o movimento característico, a tabela de pontuação e um breve plano para cada página interna.
• Execute o portão de impressão digital contra seu espaço de trabalho scroll-craft FINGERPRINTS.md (4 de 6 contra cada linha). Leia a linha "O que a próxima construção deve evitar" de cada linha recente. O movimento característico deve vir desta marca (sua geometria do logotipo, seu slogan, sua própria foto), não da última construção.
• A estrutura é fixada pelo cliente, portanto a gramática e os dispositivos mudam como as mesmas seções se comportam, nunca quais seções existem.
• Mecanismo Vanilla (scrollcraft.js/.css copiados intactos), HTML simples de várias páginas, JS local para cenas personalizadas.

Passo 3 · Construir

• Compartilhados: site.css (tokens, cabeçalho, menu, rodapé, botões, quadros, entradas), site.js (monta o mecanismo, estado do cabeçalho, menu, logotipo-ao-topo, entradas, formulário), pages.css para páginas internas, home.css/home.js para as cenas personalizadas da página inicial.
• Andaimes para páginas internas a partir de um script único é aceitável; depois disso, os arquivos HTML são a fonte. Diga isso em BRIEF.md.
• Formulários de contato: entrega mailto: para o endereço do cliente com method="post", validação e uma linha de status que diz claramente que o aplicativo de e-mail abre e nada é enviado até que eles pressionem enviar. Nunca finja um sucesso.
• Lojas e ferramentas de agendamento: vincule às páginas de produtos/agendamento existentes do cliente.

Armadilhas que já custaram uma rodada

• Nunca defina position em um elemento [data-sc-stage]. O mecanismo o torna sticky; position: relative no seu CSS silenciosamente mata todos os pins.
• O pico deve manter o maior data-sc-span na página. Se o hero crescer, cresça o pico junto.
• Hero em camadas a partir de uma foto: trace cada silhueta com um caminho de borda DP (gradiente grosseiro primeiro, depois refine no fino), reconstrua cada placa sob a próxima silhueta (céu: gradiente vertical ajustado; névoa distante: cor plana por coluna; encostas texturizadas: espelho-azulejo ~110px), limpe manchas escuras restantes acima das linhas traçadas, então olhe para a posição final de rolagem: costuras só aparecem no final do percurso.
• Recortes de pessoas: rembg u2net_human_seg, eroda o matte ~2px e descontamine as cores de borda, ou a parede original aparece como um halo. Corte onde um plano de primeiro plano ou faixa base esconde o corte.
• Qualquer coisa com white-space: nowrap dentro de uma grade quebra layouts de telefone; deixe os botões quebrarem abaixo de 520px e use minmax(0, 1fr).
• Blocos decorativos inclinados transbordam a viewport em telefones: overflow-x: clip na seção deles.
• Uma imagem substituída mantém seus bytes antigos em telefones por uma semana (cabeçalho de cache /assets): nova arte recebe um novo nome de arquivo (-v2).
• .prose p { margin: 0 } vence .prose > * + *; escreva a regra de espaçamento como .prose > * { margin: 0 } .prose > * + * { margin-top }.

Passo 4 · Verificar

Sirva localmente (node <scroll-craft>/scripts/serve.mjs --root . --port 4610) e use scripts/snap.mjs / scripts/full.mjs desta skill. Ambos resolvem playwright-core da pasta em que você os executa ou de qualquer pasta pai, então um npm i playwright-core na raiz do projeto cobre todas as construções abaixo dela.

• Desktop 1440x900 em várias posições dentro de cada ato fixado, telefone 390x844 e 360x640, movimento reduzido. Leia cada folha; corrija e refaça a captura.
• Capturas de página inteira de cada página interna em 1440 e 390: sem overflow, sem texto cortado, sem células de grade vazias.
• Estrutura scroll-craft: sem rolagem morta, sem erros de console, sem solicitações falhadas.
• Contraste de texto sobre imagens medido em pixels compostos (oculte o texto, leia os pixels abaixo dele); corpo 4.5:1, grande 3:1.
• Funcional: a interação característica de ponta a ponta, mensagens de validação de formulário, menu abrir/Escape/foco, logotipo ao topo, âncoras dos serviços do hero.
• Grep na construção por travessões em e meios-travessões (U+2014, U+2013): zero visível.

Passo 5 · Implantar

1. vercel.json: cleanUrls, buildCommand: null, outputDirectory: ".", cache de 7 dias em /assets. .vercelignore: lab/ _src/ node_modules/ BRIEF.md.
2. vercel link --yes --project <slug>-redesign em seguida vercel deploy --prod --yes.
3. Teste de fumaça na URL exata que você enviará: cada página 200, assets principais 200, lab/ e BRIEF.md 404, um carregamento ao vivo do navegador sem erros de console.
4. Repositório Git na construção (git init -b main), commit com -F <file> (nunca um here-string do PowerShell), gh repo create <github-user>/<slug>-redesign --private --source . --push, vercel git connect --yes. Edições posteriores: commit e push para main, que reimplanta. Mantenha o repositório de demonstração privado: ele contém o logotipo, fotos e texto do prospecto.
5. Anexe a linha de impressão digital ao seu espaço de trabalho FINGERPRINTS.md (todas as seis dimensões, mundo, porta, paleta, tipo, o que compartilha, o que a próxima construção deve evitar).

Passo 6 · Rascunhar a resposta

python scripts/draft_demo_reply.py <prospect-email> --mailbox <alias> --url https://<slug>-redesign.vercel.app --first-name <FirstName>

Ele verifica se a URL responde, encontra o e-mail mais recente do prospecto na caixa de saída, renderiza o modelo "aqui está a demonstração" no idioma do contato (--lang fr|en) com a assinatura dessa caixa de e-mail, salva um rascunho encadeado na pasta Rascunhos dessa caixa de e-mail e o lê de volta. Ele nunca envia. Execute com --dry-run primeiro se algo sobre o thread parecer incomum. As caixas de e-mail são configuradas em .env (veja .env.example).

Quando o prospecto respondeu de outro endereço diferente daquele para o qual você escreveu (uma caixa de e-mail pessoal em vez de info@), passe com --to <their-address>: a resposta é procurada a partir desse remetente e o rascunho vai para ele. Alguns servidores IMAP só correspondem a uma pesquisa FROM no endereço completo; um fragmento de domínio não retorna nada.

Com um CRM conectado (DEMO_CRM_DIR, veja o README), <prospect-email> pode ser qualquer coisa que o CRM resolva, a caixa de e-mail e o idioma vêm do contato, e o script registra a resposta do prospecto e a URL de demonstração.

Mostre o texto do rascunho na mensagem final. Diga ao usuário para avisar quando for enviado para que a demonstração possa ser marcada como enviada.

Relatório final (curto)

URL ativa (a exata) · páginas reconstruídas · a ideia de design em duas linhas · o movimento característico em uma · as poucas adições de microcópia · o que foi verificado e o que não foi (telefone real, Safari) · o rascunho (caixa de e-mail, thread, texto completo) · caminho local da pasta de construção.