LucasH1225/construtor-de-site-para-restaurante

Construtor de Demonstração de Restaurante

Construa uma demonstração de vendas baseada em evidências que faça o proprietário reconhecer seu próprio restaurante e torne óbvia a oportunidade online perdida. Trate a demonstração como uma primeira versão útil do site do restaurante, não como um tema genérico com o nome do restaurante colado.

Leia references/demo-playbook.md antes de pesquisa substancial, design, produção de imagem ou implementação. Use apenas as seções relevantes para a solicitação.

Escolha o Modo de Tarefa

Determine o modo solicitado antes de agir:

• Analisar: Retorne um conceito fundamentado, justificativa, estrutura da página, direção de imagem, plano de menu e lacunas de verificação. Não edite arquivos do projeto a menos que solicitado.
• Construir: Pesquise o restaurante, crie ou prepare os ativos apropriados, implemente a demonstração funcional, execute-a e verifique visualmente as visualizações desktop e mobile.
• Atualizar: Inspecione a demonstração existente e os fatos públicos atuais, depois atualize apenas o que está desatualizado ou fraco e execute novamente a verificação visual.

Peça esclarecimentos apenas quando várias empresas compartilharem o mesmo nome e a localização correta não puder ser inferida. Caso contrário, inspecione primeiro os dados de lead locais e as fontes públicas.

Trabalhe a Partir de Evidências

1. Inspecione o workspace atual antes de navegar. Pesquise exportações de lead, briefings, demonstrações existentes e ativos de design pelo nome do restaurante, localização, ID do local e URLs.
2. Verifique os fatos públicos atuais, pois as informações do restaurante mudam com frequência. Verifique o site próprio do restaurante e páginas sociais, listagem do Google ou dados do Maps, cardápio atual ou página de pedidos, avaliações recentes e páginas oficiais de turismo ou câmara de comércio relevantes.
3. Registre a fonte e a confiança para nome, endereço, telefone, horário, avaliação, número de avaliações, categorias, serviços, itens do cardápio, preços, eventos, pedidos online, links sociais e qualquer imagem do local ou fachada proposta para a demonstração.
4. Separe o conteúdo em três rótulos durante o trabalho:
   • Fato verificado: Diretamente apoiado por uma fonte atual.
   • Inferência razoável: Apoiado por padrões repetidos em avaliações ou contexto de localização.
   • Proposta criativa: Slogan, direção de arte, layout ou ideia de campanha criada para a demonstração.
5. Resolva fatos conflitantes com a fonte mais recente controlada pelo proprietário, quando possível. Coloque conflitos não resolvidos na lista de verificação do proprietário.
6. Pare a pesquisa quando a identidade do restaurante, o problema do site, a disponibilidade do cardápio, os detalhes de contato principais, a evidência do público primário e os temas de avaliação repetidos estiverem suficientemente estabelecidos. Para o modo de análise, prefira um pequeno conjunto de fontes fortes a uma varredura exaustiva de diretórios; liste os detalhes não resolvidos em vez de atrasar o briefing.

Nunca invente itens de cardápio, preços, horários, prêmios, descontos, delivery, reservas, pedidos, horários de eventos ou alegações de acessibilidade. Não adicione um botão de comando com aparência funcional a menos que seu destino e serviço sejam reais.

Defina Uma Posição Comercial

Escolha um público primário e um objetivo de conversão primário a partir das evidências. Públicos típicos incluem viajantes de passagem, famílias locais, frequentadores do café da manhã, clientes de bar esportivo e grupos noturnos. Objetivos típicos incluem visualizar o cardápio, obter direções, ligar ou fazer um pedido online verificado.

O primeiro viewport deve responder em cinco segundos:

1. Que restaurante é este?
2. Por que este visitante deve escolhê-lo?
3. Está aberto ou quando está aberto?
4. Como o visitante pode ver o cardápio ou chegar lá?

Use o nome do restaurante como H1. Coloque o posicionamento no texto de apoio. Prefira provas concretas, como períodos do dia, pratos emblemáticos, localização, horário, porções ou temas de avaliações, em vez de frases genéricas como "comida excelente" ou "ingredientes frescos".

Roteie o Design

Depois que as evidências do restaurante, público, ocasião e ação primária estiverem estabelecidas, leia references/design-routing.md. Crie um perfil de restaurante, execute scripts/select_recipe.py e salve o recipe-lock.json gerado com o registro da pesquisa da demonstração.

Leia apenas a Referência de Receita selecionada, depois copie o Starter de layout selecionado independentemente de assets/layouts/<layout-id>/:

• morning-regular: references/recipe-morning-regular.md
• hometown-table: references/recipe-hometown-table.md
• local-tavern: references/recipe-local-tavern.md
• occasion-dining: references/recipe-occasion-dining.md

Use references/layout-research-2026-07-v2.md apenas ao revisar as evidências estruturais por trás da biblioteca V2, expandir gramáticas de layout ou diagnosticar uma incompatibilidade de design. O arquivo anterior design-research-2026-07.md e assets/starters/ são histórico V1 e não participam do novo roteamento de demonstração. Não copie o código, fotografias, texto, logotipo, ilustração ou composição completa distinta de um restaurante de referência.

Trate a seleção de Receita e layout como restrições separadas. A Receita controla público, tom, funções e atitude visual; a gramática do layout controla o Hero, composição de mídia, formato de prova, geometria do menu, geometria das seções e transformação mobile. As evidências verificadas do restaurante continuam a controlar pedidos, reservas, eventos, horários, serviços, conteúdo do cardápio, avaliações e imagens. Nunca ignore manualmente o bloqueio V2: corrija o perfil, definição de compatibilidade ou impressão digital do histórico quando um resultado estiver errado.

Bloqueie a Paleta de Cores do Restaurante

Use $restaurant-brand-palette após o bloqueio da Receita e do layout, mas antes da estilização visual final, sempre que uma imagem de fachada, placa, logotipo, cardápio, embalagem ou interior fornecer evidências de cores de identidade utilizáveis. Salve o brand-palette.json validado e visualize ao lado de recipe-lock.json.

Trate paleta, Receita e layout como bloqueios separados. A paleta controla funções e proporções de cores CSS; ela não altera público, função, gramática do Hero ou geometria das seções. Exija o estágio handoff da skill de paleta antes de importar tokens. Mapeie os tokens validados em variáveis CSS e não introduza valores hexadecimais de substituição ad hoc durante a implementação.

Se nenhuma cor de marca confiável sobreviver à revisão de evidências, deixe a skill de paleta criar um fallback de Receita claramente rotulado. Não afirme que um fallback veio do restaurante. Revalide após qualquer alteração de token e inspecione o texto sobre fotografias separadamente.

Construa a Página Com Base em Decisões

Use esta sequência padrão quando a receita selecionada não especificar uma ordem melhor baseada em evidências. Remova qualquer seção que não tenha evidências:

1. Navegação compacta com Cardápio, Favoritos e Visite, mais um comando de alto valor.
2. Hero de sangria total com o nome do restaurante, uma proposta de valor concreta, Ver Cardápio e Obter Direções ou Ligar.
3. Faixa de prova com avaliação/número de avaliações verificados, horário, sinal de preço ou contexto de localização (centro).
4. Três a seis pratos em destaque usando nomes confirmados quando disponíveis; use uma categoria liderada por texto ou rótulo representativo quando um prato não tiver uma foto real verificada, em vez de inventar imagens de comida realistas.
5. Um menu HTML legível com navegação por categoria.
6. Seção de experiência ou período do dia apenas quando ela esclarecer o negócio, como café da manhã até tarde da noite, jantar em família, esportes ou eventos ao vivo.
7. Prova curta de avaliações com fonte que apoie o posicionamento escolhido.
8. Uma faixa de chegada ou exterior quando uma foto de fachada verificada melhorar materialmente o reconhecimento ou a orientação.
9. Seção de visita com endereço, horário atual, telefone, mapa/direções e links sociais próprios.
10. Ações fixas mobile para os comandos mais importantes.

Mantenha a experiência direta e útil. Evite um card decorativo para cada seção, formulários de reserva falsos, histórias genéricas de chefs, alegações não apoiadas de "melhor da cidade" e textos de marketing longos.

Crie um Sistema de Imagem Consistente

Use $restaurant-food-image-studio para auditoria real de referências de comida, geração de imagens, reparo, rastreamento de manifesto e folhas de contato fonte versus proposta. Em uma construção completa de demonstração, estabeleça aqui as evidências do restaurante e a direção comercial primeiro, depois passe a lista de pratos verificados e os requisitos de imagem para essa skill. Mantenha os princípios abaixo como o contrato de aceitação para o site final.

Trate a validação demo do Manifesto V3 do Food Image Studio como o limite de integração. Não copie um ativo de alimento reestilizado por IA para o site a menos que ele tenha uma foto de prato servido real, única e registrada do mesmo restaurante, a foto real foi fornecida como entrada de imagem, a fonte foi roteada para um Sistema de Fotografia voltado ao cliente bloqueado, ambas as folhas de evidência canônicas estão protegidas por hash, todas as cinco portas de QA passam e o manifesto atual passa em <food-image-skill>/scripts/validate_manifest.py --stage demo. Execute esse validador imediatamente antes de copiar cada saída e novamente durante o QA final da demonstração. Se a fonte, Sistema de Fotografia, registro de evidência ou qualquer porta de QA estiver faltando, mantenha o slot liderado por texto ou use um ativo não alimentar verificado separadamente. Nunca ignore esta porta com uma descrição de cardápio, foto de banco de imagens, imagem de estilo sintético ou renderização representative-concept.

Prefira imagens reais de propriedade do restaurante, pois a identidade do prato e o ambiente são evidências. Para uma demonstração de vendas privada, fotografias reais públicas do Maps, páginas sociais, plataformas de avaliação, diretórios e páginas de cardápio podem servir como referências temporárias de fato ou composição, mesmo quando o uploader for desconhecido. Registre a fonte e a incerteza, não implique que os direitos de referência foram liberados e obtenha aprovação ou ativos de substituição antes do lançamento público.

Use portas separadas. Na porta de fonte, retenha automaticamente a fonte real única do prato, avaliação da câmera de origem, rota, proveniência e hashes. Na porta de Demonstração privada, retenha a comparação fonte versus foto projetada, tempo de geração, ângulo de saída registrado e as cinco portas: fidelidade, consistência de estilo, otimização do apetite, sinais de IA e prontidão para o site. O usuário pode inspecionar qualquer artefato posteriormente e solicitar alterações. A identidade do uploader não é necessária quando uma foto pública real está credivelmente anexada ao restaurante correto. Na porta de lançamento público, exija uma substituição liberada ou a permissão do detentor de direitos relevante, mais a confirmação do proprietário da precisão factual. Não implique que um uso privado ou individual registrado concede direitos de publicação.

Quando não existir um cardápio digital atual, peça a $restaurant-food-image-studio para executar seu fallback baseado no Google Maps. Agrupe fotos reais repetidas de pratos, corrobore-as com fotografias de cardápio, posts sociais, legendas e menções em avaliações, depois selecione três a seis candidatos em destaque. Repetição é um sinal de seleção, não prova de volume de vendas: use Em Destaque por padrão e reserve Popular, Mais Popular, Campeão de Vendas ou nomes exatos de pratos para alegações apoiadas.

Use IA como uma camada de direção de arte e restauração:

• Inspecione cada fonte real e classifique sua visão de câmera antes de gerar.
• Preserve o tipo de prato, ingredientes, porção, método de cozimento, acompanhamentos e recipiente de servir; trate a fonte como verdade alimentar, não como uma composição final obrigatória.
• Bloqueie uma família principal de câmera voltada ao cliente, tolerância de ângulo, escala do assunto, corte, fundo, direção de iluminação, gradação, sensação de lente e política de adereços para o conjunto do restaurante.
• Roteie uma fonte que não se encaixa nesse sistema para reference-restage; nunca preserve um ângulo inadequado de vista superior ou snapshot casual apenas por ser real.
• Melhore exposição, balanço de branco e dicas de apetite apoiadas pela fonte, como pão dourado natural ou douramento visível, sem alterar o ponto de cozimento, marcas, porção ou ingredientes.
• Rejeite brilho plástico, textura cerosa, repetição, geometria perfeita, efeitos impossíveis e outros sinais visíveis de IA.
• Use uma imagem ampla para o hero e uma família consistente 4:3 para alimentos em destaque.
• Gere apenas três a seis imagens de alimentos em destaque; deixe o cardápio completo permanecer liderado por texto.
• Marque saída incerta como imagem conceitual e inclua-a no conjunto de verificação do proprietário.
• Mantenha capturas de tela do Google Maps e outras originais de terceiros fora da página de demonstração; registre-as apenas no manifesto interno e na folha de contato.

Não rotule uma imagem gerada como um item exato do cardápio quando a referência não provar seus ingredientes. Evite guarnições impossíveis, vapor exagerado ou puxões de queijo, logotipos falsos, texto de cardápio gerado, perfeição excessiva e polimento de banco de imagens que contradiz o restaurante.

Use $restaurant-exterior-image-studio para auditoria real da fonte de fachada, planejamento de preservação, restauração assistida por IA ou recriação baseada em referência, rastreamento de manifesto, registro, comparação e QA de seis partes. Em uma construção completa de demonstração, decida aqui o propósito da imagem de chegada e o slot primeiro, depois passe a proporção, ponto focal, colocação pretendida e requisito de orientação para essa skill.

Trate a validação demo do Exterior Image Studio como o limite de integração. Não copie uma fachada assistida por IA para o site a menos que fontes reais atuais provem a placa, entrada, geometria da fachada, cores da fachada e características fixas; todas as regiões voltadas para a saída sejam suportadas ou cortadas; o contrato de preservação esteja completo; todas as seis portas de QA passem; e <exterior-skill>/scripts/validate_manifest.py --stage demo seja bem-sucedido imediatamente antes da integração.

Mantenha um hero liderado por comida quando o apetite for a conversão primária; coloque o exterior perto da seção Visita, a menos que o próprio edifício seja a atração verificada. Mantenha os originais de plataformas públicas internos, rotule uma saída de demonstração privada como uma proposta de foto e preserve portas separadas de precisão do proprietário e direitos de publicação. O Street View permanece apenas para pesquisa, exceto para um embed ou link oficial.

Leia a seção Exterior And Arrival Imagery em references/demo-playbook.md antes de planejar ou colocar o ativo; deixe a Skill especializada controlar os detalhes de produção.

Torne o Cardápio a Utilidade Central

Construa o cardápio como conteúdo de página estruturado, não como um PDF ou imagem. Use marcação HTML semântica com headings (<h2>, <h3>), listas (<ul>, <li>) e dados estruturados para itens, descrições e preços quando verificados.

Organize o cardápio em categorias lógicas (Entradas, Pratos Principais, Bebidas, Sobremesas) baseadas no cardápio real do restaurante. Inclua links de âncora para cada categoria.

Para cada item do cardápio, inclua:

• Nome: O nome do prato, como aparece no cardápio verificado.
• Descrição: Uma breve descrição, se disponível e verificada.
• Preço: O preço, se verificado. Caso contrário, omita ou marque como "Sob consulta".
• Imagem: Apenas se uma foto real do prato estiver disponível e for usada no site. Caso contrário, nenhuma imagem.

Nunca invente preços, itens ou descrições. Se o cardápio não puder ser verificado, use uma mensagem como "Cardápio disponível no restaurante" com um link para a página do Google Maps ou Facebook do restaurante, se disponível.

Verifique Visualmente Antes de Concluir

Antes de marcar a tarefa como concluída:

1. Execute a demonstração em um servidor local ou visualizador.
2. Verifique a visualização desktop (largura mínima de 1024px):
   • O H1 mostra o nome correto do restaurante?
   • O hero tem uma imagem apropriada e posicionamento claro?
   • A faixa de prova está visível e correta?
   • O cardápio está legível e bem formatado?
   • A seção Visita tem endereço, telefone e mapa precisos?
3. Verifique a visualização mobile (largura de 375px):
   • O layout se adapta bem? Não há overflow horizontal?
   • O menu de navegação é utilizável?
   • Os botões de ação fixos (Ligar, Direções, Cardápio) estão presentes e funcionais?
   • O hero e as imagens redimensionam corretamente?
   • O cardápio é legível sem zoom?
4. Verifique a consistência das imagens:
   • As imagens de comida têm uma aparência consistente (proporção, estilo)?
   • As imagens de fachada são precisas e úteis para orientação?
   • As imagens são otimizadas para web (não excessivamente grandes)?
5. Verifique acessibilidade básica:
   • Contraste de cores suficiente?
   • Texto alternativo (alt) para imagens?
   • Navegação por teclado funciona?
6. Verifique os links:
   • Links para cardápio online, pedidos, reservas funcionam?
   • Links sociais estão corretos?
   • O mapa ou link de direções está preciso?

Se algum problema for encontrado, corrija-o antes de finalizar. A demonstração deve ser uma representação funcional e precisa do restaurante, mostrando o potencial de um site bem projetado.

Requisitos de Integração

Esta skill é projetada para ser usada com as seguintes skills complementares:

• restaurant-food-image-studio: Para produção de imagens de comida baseadas em evidências.
• restaurant-exterior-image-studio: Para produção de imagens de fachada baseadas em evidências.
• restaurant-brand-palette: Para extração de paleta de cores de fotos do restaurante.

Siga o fluxo de integração documentado em references/demo-playbook.md para garantir que todos os ativos estejam prontos e validados antes da implementação final.

Notas Finais

• Priorize a precisão factual sobre a estética. Uma demonstração honesta e útil é mais convincente do que uma bela e falsa.
• Documente todas as fontes e incertezas no registro de pesquisa da demonstração.
• Obtenha aprovação do proprietário antes de usar qualquer ativo público ou gerado em um contexto público.
• Esta skill é para demonstrações de vendas privadas. Não publique sem as devidas autorizações.

Para dúvidas ou problemas, consulte a documentação de referência ou entre em contato com o mantenedor da skill.