Site pessoal: design travado por referência, 1:1

Site Pessoal (Personal Website)

Regras Principais

Não vá direto para o código. Trate o site como um projeto orientado por imagens de referência em fases:

1. Bloqueio de Conteúdo e Estilo
2. Bloqueio de Imagens de Referência
3. Lista de Divisão de Ativos
4. Geração e Revisão de Ativos
5. Recriação Fiel e QA

O fluxo visível ao usuário tem quatro pontos de verificação bloqueantes por padrão:

1. Confirmar o brief completo de conteúdo e estilo, incluindo a forma do site, o planejamento das seções, a suficiência do conteúdo e a direção visual escolhida ou fornecida pelo usuário
2. Confirmar o grupo de imagens de referência após revisão de consistência, ritmo e exequibilidade
3. Confirmar a lista de divisão de ativos antes de gerar ou buscar novos ativos
4. Confirmar o brief de recriação e os ativos gerados/organizados antes da implementação do código da página

Após a confirmação do grupo de imagens de referência, não vá direto para a implementação. Primeiro, examine cada imagem de referência confirmada, produza uma lista de divisão de ativos para o usuário e aguarde a confirmação. Após a confirmação da lista, gere, busque ou organize apenas os ativos aprovados na lista. Quando os ativos estiverem prontos, liste os caminhos finais, os resultados da verificação e um breve brief de recriação; aguarde o usuário aceitar, solicitar regeneração ou modificar a divisão. Só depois dessa confirmação você pode iniciar a recriação fiel.

A antiga nota de design leve pré-construção é mesclada na saída de revisão de ativos, tornando-se um breve brief de recriação. Não é um ponto de verificação adicional independente: o usuário confirma os resultados dos ativos e o brief de recriação simultaneamente antes do código.

Não comprima as fases subsequentes em uma construção front-end comum. As imagens de referência confirmadas não são um moodboard. Antes de escrever código, cada imagem de referência deve ter um render contract confirmado e ser dividida em áreas de responsabilidade do código, cenas mescladas, mídias independentes, ativos de identidade/fonte real, âncoras visuais, e decisões finais de fonte e status.

Condição de parada rígida: Não crie ou modifique arquivos HTML, CSS, JS, React, rotas ou componentes antes que a lista de divisão de ativos seja confirmada, os ativos aprovados sejam gerados ou organizados, e a revisão de ativos e o brief de recriação sejam aceitos. Apenas dizer "Vou dividir as imagens de referência" em uma nota de progresso não conta como concluído.

Projetos refinados orientados por imagens de referência também executam uma condição de parada rígida de evidências: leia references/evidence-gate.md. Quando as evidências em disco necessárias estiverem faltando, o status só pode ser not verified, não pass. Se o usuário solicitar pular a pausa de confirmação, isso significa apenas continuar automaticamente após a aprovação do ponto; não significa aprovação automática, substituição silenciosa de imagens de referência, pular revisão ou conclusão sem evidências.

Se o usuário tiver apenas materiais parciais, primeiro examine as lacunas e sugira formas mais fáceis de entrada de dados, em vez de exigir imediatamente que o usuário escreva todo o conteúdo manualmente. Se o usuário já tiver conteúdo, imagens de referência e ativos confirmados, você pode pular diretamente para a revisão relevante, revisão de ativos ou fase de recriação, mas ainda mantenha os mesmos limites de confirmação antes do código.

Disciplina de Execução

Ao avançar entre as fases, explique a suposição atual, o próximo objetivo verificável e como verificá-lo. Se a solicitação tiver múltiplas interpretações, primeiro esclareça as opções e pergunte antes de prosseguir em uma direção específica.

Mantenha as modificações contidas:

• Não adicione seções, interações, conteúdo, rotas, tipos de ativos ou configurações que o usuário não solicitou ou confirmou
• Ao editar um projeto existente, altere apenas os arquivos necessários dentro do escopo confirmado e corresponda ao estilo existente do projeto
• Remova apenas código, ativos ou imports que se tornaram inúteis após a adição deste workflow; mencione código morto existente não relacionado, mas não o remova
• Priorize as menores notas de design, listas de ativos, grupos de prompts ou alterações de implementação que possam avançar a próxima fase de forma confiável
• Trabalho em várias etapas deve ter critérios de sucesso suficientemente específicos para evitar avançar por adivinhação
• Implemente e verifique apenas uma fatia de seção por vez; não declare múltiplas seções como aprovadas quando apenas parte de uma seção foi verificada

Expressão de Idioma e Localização

A orientação visível ao usuário deve corresponder ao idioma principal do usuário. Quando o usuário pergunta em chinês, use chinês para notas de progresso, transições de fase, solicitações de confirmação e rótulos de opções, por exemplo, Primeira Etapa / Bloqueio de Conteúdo e Estilo, Agora vou para a Segunda Etapa. Quando o usuário pergunta em inglês, use inglês, por exemplo, Step One / Content and style lock, Next I will move to Step Two. Se o diálogo for misturado, priorize a preferência explícita mais recente do usuário ou o idioma da solicitação substancial mais recente.

Notas voltadas ao usuário, transições de fase, solicitações de confirmação e rótulos de opções usam chinês por padrão; nomes de arquivo, comandos, nomes de campos e termos técnicos necessários permanecem em inglês para não alterar o contrato de execução.

Os nomes das fases também devem ser totalmente traduzidos. Usuários chineses devem ver Quinta Etapa / Recriação Fiel e QA, não Step Five / Build and QA ou rótulos mistos.

Skills Companheiros Integrados

Este skill possui referências companheiras integradas, portanto o workflow não depende que o usuário instale outros skills adicionais:

• references/imagegen-frontend-web.md: usado para o contrato rígido de geração de imagens de referência de site pessoal na segunda etapa
• references/visual-quality-gate.md: usado para revisão de significado real, hierarquia, espaço em branco, corte, sobreposição, autoria e contexto fresco na segunda e quinta etapas
• references/evidence-gate.md e scripts/verify_identity_run.py: usados para hashes de referência não sobrescritíveis, evidências de captura de tela por seção, atribuição topológica e verificação de conclusão determinística
• references/reference-asset-splitter.md e references/split-patterns.md: usados para a arbitragem de ativos de três eixos e exemplos de correção real na terceira etapa
• references/frontend-app-builder.md: usado para implementação de alta fidelidade e QA após a revisão de ativos

Na fase de geração de imagens de referência do site pessoal, independentemente de o imagegen-frontend-web independente estar instalado, references/imagegen-frontend-web.md deve ser lido. Quando o objetivo for refinado, profissional, com identidade ou de nível Awwwards, a segunda e quinta etapas também devem ler references/visual-quality-gate.md. Esses arquivos integrados são o contrato rígido deste workflow; skills independentes podem complementar um vocabulário criativo mais amplo, mas não podem substituir o brief confirmado, a impressão digital de estilo, o contrato de significado, o limite de qualidade visual, o orçamento de ativos e as regras de exequibilidade.

Na fase de arbitragem de ativos, se o reference-asset-splitter estiver instalado, use a versão instalada; caso contrário, use a versão integrada; ambos devem manter o mesmo conjunto de classificadores e exemplos. O brief confirmado do usuário e os limites rígidos de fase deste skill têm prioridade sobre as regras padrão dos companheiros. Na quinta etapa, ainda priorize o frontend-app-builder instalado, com a cópia integrada como fallback.

Se o skill companheiro não estiver instalado, não pare, não finja que a chamada @skill está disponível e não exija que o usuário instale para continuar o fluxo. Leia a referência companheira integrada deste pacote e use-a como o contrato mínimo de execução local.

Discuta a instalação separada de um skill companheiro apenas quando o usuário desejar explicitamente componentes instaláveis de forma independente. No caminho normal, instalar o identity-skill sozinho deve ser suficiente.

Se não houver nenhuma ferramenta de geração de imagens, escreva prompts copiáveis para o usuário colar no GPT web Image 2 ou outra ferramenta de imagem, ou peça ao usuário para fornecer suas próprias imagens de referência. Se o usuário pular totalmente as imagens de referência, trate a construção como de fidelidade mais baixa e indique claramente que o QA visual só pode ser feito contra o brief textual, não contra imagens de referência aceitas.

Protocolo de Notas de Fase

No final de cada fase visível ao usuário, forneça uma nota de progresso clara:

• Progresso atual: Primeira Etapa / Nome da Etapa
• Concluído: o resultado específico que acabou de ser produzido
• Ainda ausente ou em risco: liste apenas os pontos de bloqueio que realmente afetam o avanço
• O que o usuário pode fazer agora: confirmar, modificar uma parte nomeada, fornecer materiais ausentes ou escolher uma opção
• Próximo passo: explique o nome da próxima fase e o que acontecerá

Não deixe o usuário parado em um ponto de interrupção implícito. Se o fluxo continuar sem uma confirmação bloqueante, explique claramente que continuará e por quê.

Primeira Etapa: Bloqueio de Conteúdo e Estilo

Primeiro, decida qual rota de conteúdo se aplica. Não force o usuário a inserir manualmente informações que já podem ser lidas de arquivos, links, currículos, perfis, notas, amostras de escrita, documentos de projeto, capturas de tela ou sites existentes.

Rotas de Entrada de Dados

Use uma das seguintes rotas:

• Rota de Dados Suficientes: o usuário forneceu currículo, CV, LinkedIn, site pessoal, portfólio, links de projeto, documentos Notion/Markdown, biografia, kit de imprensa, página de rede social, arquivo de escrita ou materiais semelhantes. Leia o conteúdo acessível, extraia fatos confirmados, unidades de conteúdo utilizáveis para seções, links, ativos e lacunas. Faça apenas perguntas complementares que afetem a direção do site.
• Rota de Brief Leve: o usuário forneceu um objetivo ou identidade, mas com poucos materiais de suporte. Primeiro, convide o usuário a fornecer entradas mais fáceis, como currículo, apresentação existente, links de projeto, links de escrita, fotos, sites de referência ou capturas de tela. Se o usuário não quiser fornecer arquivos, use as perguntas orientadoras abaixo.
• Rota do Zero: o usuário não tem materiais ou deseja organizar do zero. Levante as perguntas orientadoras de uma vez, não em uma longa entrevista pergunta por pergunta.
• Rota de Demonstração Rápida: o usuário enfatiza velocidade ou protótipo bruto. Conteúdo fictício leve pode ser usado, mas todos os fatos inventados, projetos, citações, métricas, links ou detalhes de biografia devem ser marcados como conteúdo de espaço reservado e precisam ser substituídos antes da versão final.

As perguntas orientadoras devem ser coletadas de forma compacta:

• Objetivo: currículo, emprego, portfólio, criador/marca pessoal, consultor, fundador/página executiva, palestra/mídia ou outro propósito
• Público: quem visitará e o que você deseja que eles façam depois de ver
• Posicionamento: rótulo de identidade, frase que será lembrada, limites de tom
• Materiais de Prova: experiência, projetos, escrita, produtos, clientes, cobertura da mídia, palestras, prêmios ou outras evidências
• Detalhes do Projeto: contexto de cada projeto importante, sua função/ação, resultados, links/mídia e o que você quer que seja lembrado
• Ativos e Limites: foto de perfil, logotipo, capturas de tela, documentos, links, conteúdo indisponível ou sensível, e o que não pode ser gerado ou exagerado
• Preferências do Usuário: densidade de informações do site, preferência por página única ou múltipla, referências favoritas, estilos não apreciados, disposição para manutenção futura

Documento de Conteúdo e Forma do Site

Para sites pessoais refinados, sites de marca pessoal, portfólios, direção de nível Awwwards ou qualquer cenário onde a qualidade do design seja importante, produza um documento de conteúdo e forma do site antes de entrar na parte de imagens. Demonstrações rápidas podem manter a mesma estrutura, mas escritas de forma mais curta.

O documento deve incluir:

• Cobertura de Dados: quais arquivos, links, notas ou respostas do usuário foram usados
• Fatos Confirmados: escreva apenas fatos fornecidos ou suportados por fontes do usuário
• Conteúdo de Rascunho Não Confirmado: marque claramente o texto proposto pelo agente, exemplos, espaços reservados, alegações inferidas ou links ausentes
• Objetivo e Público do Site: o que este site deve realizar e para quem é
• Pontos de Memória do Visitante: uma a três coisas que o visitante deve lembrar
• Recomendação de Forma do Site: página única, currículo de uma página, página inicial com estudos de caso, portfólio de várias páginas, hub de criador, landing page de consultor ou outra forma
• Razão para a Recomendação: por que esta forma é adequada para o objetivo do usuário, volume de conteúdo, profundidade de prova e disposição para manutenção
• Alternativas Opcionais: estruturas mais leves ou mais completas viáveis, mas não tão boas quanto a principal recomendação
• Planejamento de Seções: propósito, conteúdo necessário, unidades de conteúdo, links/ativos e status (ready, needs detail, placeholder ou cut) de cada seção
• Riscos de Suficiência de Conteúdo: seções vagas, templates, falsas, lotadas, sem suporte ou que não valem a pena manter

A forma do site deve ser recomendada com base no objetivo e na densidade de dados do usuário, não com um padrão de cinco ou seis seções. Currículo ou propósito de emprego geralmente precisa apenas de uma página ou uma ou duas páginas. Portfólios profundos podem precisar de rota de estudo de caso. Sites de criadores, fundadores ou consultores só precisam de narrativa mais forte ou caminhos de conversão quando o conteúdo suporta.

Todo o conteúdo usado para imagens de referência deve vir do usuário ou ser explicitamente aprovado por ele. O agente pode propor conteúdo para preencher lacunas, mas esse conteúdo é apenas rascunho, não fato confirmado. Não trate o conteúdo proposto pelo agente como confirmado apenas porque parece razoável ou bom.

Antes da confirmação da segunda etapa, fixe a estratégia de fonte de evidência para cada pessoa, empresa, produto, trabalho, publicação ou projeto identificável. Colete ativos utilizáveis do usuário ou ativos oficiais o mais cedo possível para que as imagens de referência componham em torno de evidências reais; não confirme primeiro uma composição de espaço reservado mais forte para depois planejar substituí-la por ativos oficiais com peso visual, proporção ou assunto diferentes após o bloqueio.

Recomendações de Estilo

Depois que o conteúdo e a forma do site estiverem claros o suficiente, com base no conteúdo, preferências do usuário, público, propósito do site e referências existentes, recomende no máximo três direções visuais. O usuário pode escolher uma, misturar várias opções ou fornecer sua própria direção visual/referência.

As opções de estilo devem ser conceitos visuais, não apenas rótulos de posicionamento. Não dê apenas "Currículo de Estudante Internacional", "Pesquisador de Produtos Fintech" ou "Portfólio de IA + Finanças" que apenas distinguem público ou narrativa de carreira. Esses rótulos podem explicar por que é adequado, mas a opção em si deve permitir que o usuário imagine como a página se parecerá antes de gerar imagens.

Cada opção de estilo deve cobrir brevemente:

• Nome do Conceito Visual: um rótulo curto que descreve a atmosfera visual, não apenas o papel pessoal
• Correspondência de Humor e Posicionamento
• Direção de Cor: 3-5 cores específicas ou funções de cor, com hex se necessário
• Personalidade da Fonte: personalidade da fonte display/body e contraste de peso
• Composição Acima da Dobra: como nome, headline, avatar/mídia, CTA e pistas de prova aparecem
• Densidade do Layout e Ritmo da Seção: página única contida, ritmo editorial, blocos de prova bento, profundidade de estudo de caso ou outro ritmo específico
• Tratamento de Imagens ou Ativos: corte de avatar, capturas de tela de projeto, cartões de documento, visualização de dados, fotos editoriais, fundos abstratos ou gráficos renderizados por código
• Sensação do Chrome e Navegação: densidade do cabeçalho, wordmark, forma do CTA, bordas, cantos arredondados, estilo de ícone e estado ativo
• Personalidade da Animação
• O que o Usuário Verá: uma frase que descreve a impressão visual imediata
• Por que é Adequado para Esta Pessoa e Forma de Site
• Principais Riscos ou Compensações

Se uma opção de estilo não puder ser descrita como uma imagem visível de site, reescreva-a antes de mostrá-la ao usuário. Se o objetivo do usuário for posicionamento de carreira, traduza o posicionamento em decisões visuais, em vez de deixar o título da opção carregar toda a expressão.

Quando necessário, use este formato compacto de opção de estilo:

Opção A — Currículo Editorial / Sensação de Papel Tinta
Cores: Branco Quente #F7F3EC, Preto Tinta #171717, Azul Acinzentado #6B7280, Azul Destaque #2563EB.
Fontes: serif display contido + sem serifa limpo para corpo; profissional, mas não decorativo.
Acima da Dobra: Nome e frase de posicionamento alinhados à esquerda em grande espaço em branco com sensação de papel; à direita, um avatar cortado silenciosamente ou foto estilo LinkedIn, com dois links de prova abaixo.
Ritmo: Fluxo de currículo de página única, seções calmas, provas de projeto em pequenos cartões.
Sensação Visual: Como um CV editorial de candidato internacional refinado, não uma landing page de startup.
Risco: Pode parecer com identidade fraca se o usuário quiser uma marca pessoal mais forte.

Não gere imagens de referência antes que o usuário confirme o brief completo de conteúdo e estilo. Se o usuário escolher uma opção de estilo e não se opuser ao documento de conteúdo, trate essa resposta como a primeira confirmação bloqueante apenas se sua dica disser explicitamente "Isso bloqueará o conteúdo e o estilo simultaneamente".

Use este formato de nota final da primeira etapa:

Progresso atual: Primeira Etapa / Bloqueio de Conteúdo e Estilo
Eu preparei: Resumo das fontes de dados, fatos confirmados, recomendação de forma do site, planejamento de seções, riscos de conteúdo e opções de estilo.
Por favor, confirme ou modifique:
1. Forma do site e planejamento de seções
2. Todo o conteúdo marcado como não confirmado
3. Direção visual: escolha uma opção, misture várias opções, modifique cores/layout ou forneça suas próprias referências
Após a confirmação, irei para a Segunda Etapa para gerar ou preparar imagens de referência para cada seção.

Segunda Etapa: Bloqueio de Imagens de Referência

Use imagens de referência no nível da seção como fonte visual de fato.

O prompt das imagens de referência deve ser baseado no brief confirmado de conteúdo e estilo: conteúdo aprovado, forma de site aprovada, direção visual escolhida ou fornecida pelo usuário, regras globais de chrome e unidades de conteúdo específicas de cada seção. Ao esperar sites pessoais de alta qualidade, não gere imagens de referência com base em um brief fino ou conteúdo não aprovado proposto pelo agente.

Sempre leia references/imagegen-frontend-web.md nesta fase. Se imagegen-frontend-web independente estiver disponível, use-o para complementar uma direção de arte mais ampla sob o contrato rígido do site pessoal integrado. O grupo de imagens de referência deve ter uma imagem horizontal por seção confirmada, composição forte, mundo de marca pessoal unificado e uma topologia de imagem que pode realmente ser implementada.

Se o usuário preferir GPT web Image 2, escreva prompts copiáveis para o usuário, em vez de gerar imagens diretamente.

Plano de Geração de Imagens de Referência

Antes de gerar qualquer seção, prepare um plano conciso de geração de imagens de referência. Ele é um artefato interno da segunda etapa e não adiciona uma nova porta de confirmação do usuário. Se houver um diretório de projeto existente, escreva-o no documento de restauração ou em um pequeno docs/reference-production-plan.md; se não houver diretório, mantenha-o na saída de trabalho da segunda etapa.

Primeiro, fixe a impressão digital de estilo (style fingerprint) compartilhada por todo o grupo:

• Funções de cor precisas e valores hex
• Funções de fonte display/body/label/nav e tamanhos relativos
• Geometria global do chrome, linguagem de borda/canto arredondado/sombra e família de CTA
• Material, iluminação, textura, paleta de fotos, linguagem de ilustração/ícone
• Faixa de densidade, ritmo de espaçamento, proporção da tela e, no máximo, um motivo de assinatura opcional
• Constantes que não podem variar e uma ou duas dimensões por seção que podem variar

Em seguida, especifique um render contract para cada seção:

• C0 code-only: fontes, layout e geometria simples, sem necessidade de ativos raster
• C1 integrated-scene: código UI sobreposto a uma cena mesclada; a cena pode ser full-bleed ou uma ilha visual com bordas
• C2 independent-media: casca de código com um a três fotos, capturas de tela, capas ou mocks de produto com significado independente
• C3 scene-plus-identity: uma cena mesclada, mais uma foto de perfil, logotipo ou imagem de produto oficial de fonte real ou a ser substituído depois

Cada render contract deve especificar: o conteúdo de responsabilidade do código, materiais compartilhados do site permitidos, limites da cena mesclada, slots de mídia independente, ativos de identidade/fonte real, itens proibidos de fusão, comportamento responsivo, área segura de texto, orçamento de ativos e atribuição topológica (section-specific ou estrutura compartilhada nomeada com justificativa). Para alvos de alta qualidade, também deve preencher o campo de significado de references/visual-quality-gate.md: informações de três segundos, evidência pessoal, ação de design autoral, hierarquia de foco, caminho de leitura, mapa de espaço em branco, significado de formas gráficas, lista de sobreposições, área de exclusão fechada e payload acima da dobra. C0 code-only significa 0 ativos raster específicos da seção; se papel ou digitalizações fazem parte da impressão digital fixada, um ou dois materiais de site compartilhados explicitamente declarados podem ser reutilizados. Mas não significa que uma seção com conteúdo insuficiente e apenas preenchida com grandes fontes esteja concluída: além de grandes fontes, deve haver uma segunda decisão de design do conteúdo; caso contrário, encurte, mescle ou redesenhe a seção. Cada material compartilhado é gerado apenas uma vez e contado apenas uma vez no site. Por padrão, cada seção tem um foco visual principal, no máximo uma cena mesclada e não mais que três unidades raster específicas da seção; só pode exceder isso se o usuário aprovar explicitamente a direção de parede de evidência densa.

Primeiro, gere a seção âncora que melhor define a identidade, geralmente o Hero. As seções subsequentes são geradas no mesmo lote; quando a ferramenta de imagem suportar entrada de referência, use a âncora como guia visual; caso contrário, reutilize a mesma impressão digital de estilo palavra por palavra. Não adicione portas de confirmação extras entre a âncora e as imagens subsequentes.

Saída padrão:

• Uma imagem de referência horizontal por seção
• Nada de colagens verticais longas de página inteira
• Nada de quadros de múltiplas seções fragmentados e difíceis de ler
• Todas as seções mantêm uma visão de mundo de marca pessoal consistente
• As imagens de referência devem parecer capturas de tela reais de site, não pôsteres
• O texto e os controles de responsabilidade do código devem poder ser limpos e separados dos materiais raster
• As cenas mescladas estáticas permanecem como uma unidade visual completa; slots de mídia independente não devem compartilhar sombras, reflexos ou oclusões entre limites

Antes de enviar o grupo de imagens de referência para confirmação do usuário, execute uma revisão quádrupla:

1. Revisão de Significado Visual: Execute todos os limites rígidos de references/visual-quality-gate.md, incluindo transmissão em três segundos, foco único e primário, lista de elementos com propósito, especificidade pessoal, composição concluída, limites superior e inferior de densidade, espaço em branco significativo, semântica gráfica, integridade de corte, segurança de sobreposição e payload responsivo acima da dobra. Uma seção ainda falha se for bonita ou viável, mas com ideia, evidência ou composição fracas.
2. Revisão de Consistência: Compare cada imagem com a impressão digital de estilo precisa, verificando navegação global, funções de fonte, paleta de cores, espaçamento, linguagem de moldura, paleta de imagens, motivo e lógica móvel. Deve ser óbvio que pertencem ao mesmo site.
3. Revisão de Ritmo: Liste o esqueleto da composição de cada seção e verifique o envelope de variação. Pode haver variação controlada na tarefa, escala, alinhamento, corte ou densidade da seção, mas não force cada tela a se tornar um novo conceito visual. Execute o teste de bloco cinza: depois que as fotos se tornam blocos cinzas, pelo menos metade das seções ainda deve manter uma sensação de design por meio de fontes, layout, cores e estrutura.
4. Revisão de Exequibilidade: Compare cada imagem com o render contract. Se o texto do código e os materiais raster não podem ser separados, materiais independentes compartilham sombras/oclusões duras, ativos de identidade são fundidos na cena gerada, o rearranjo responsivo requer mover pixels dentro de uma única imagem, o orçamento de ativos é excedido sem aprovação, ou ilhas de imagem não planejadas aparecem, a seção falha.

Quando a topologia da imagem de referência falhar, use redesign-required: mantenha a impressão digital de estilo do site, regenere apenas a seção com falha e envie para confirmação do usuário. Não force imagens de referência inexequíveis na terceira etapa, remendando com fatias frágeis ou código de baixa fidelidade.

Após a confirmação do grupo de referência revisado, copie-o para um novo diretório não sobrescritível, como references/locked/v1/, e escreva o SHA-256 de cada imagem em docs/identity-evidence.json. Não sobrescreva arquivos bloqueados; a regeneração ou reestruturação deve criar novas versões e reexecutar as revisões afetadas da segunda etapa.

Quando a qualidade do design for importante, ou o usuário solicitar orientação de gosto, leia também references/taste-calibration.md e references/visual-quality-gate.md. As amostras de gosto calibram o mundo visual opcional, enquanto o limite de qualidade julga se esse mundo é realmente expresso e o design concluído.

Use este formato de nota final da segunda etapa:

Progresso atual: Segunda Etapa / Bloqueio de Imagens de Referência
Eu preparei: Impressão digital de estilo do site, significado e render contract de cada seção, imagens de referência e revisão de significado visual/consistência/ritmo/exequibilidade.
Por favor, confirme ou modifique:
1. Aceitar essas imagens como alvo de construção
2. Especificar seções para regenerar
3. Ajustar a direção visual antes da construção
Após a confirmação das imagens, irei para a Terceira Etapa para produzir formalmente a lista de divisão de ativos: o que permanece no código, o que é uma cena mesclada, o que é mídia independente, o que deve usar fonte real, o que precisa ser bloqueado, substituído depois ou redesenhado. Aguardarei sua confirmação antes de gerar ou buscar novos ativos.

Terceira Etapa: Lista de Divisão de Ativos

Após a confirmação do grupo de imagens de referência, primeiro examine as imagens de referência aceitas; não gere ativos nem escreva código. Esta fase produz uma lista de divisão de ativos para o usuário e para para aguardar confirmação.

Antes de produzir a lista, se reference-asset-splitter estiver instalado, leia-o e references/split-patterns.md; caso contrário, leia references/reference-asset-splitter.md e references/split-patterns.md integrados. Execute o classificador de três eixos em ordem: granularidade de limite, meio de renderização, camada de imagem. Não comprima três coisas em uma frase "parece complexo".

Use a prioridade fixa de conflito: ativos de identidade/fonte real; conteúdo semântico vivo e acessibilidade; interação/substituição/atualização/reorganização responsiva independente; lista de permissões de código vs. sinais raster; relação de fusão; orçamento de ativos; e, finalmente, preferência estética. A complexidade visual por si só não pode forçar uma divisão fina nem provar que o código pode recriar com alta fidelidade.

O objetivo é prático, não superespecificação: diga ao usuário quais partes visíveis devem permanecer no código, quais precisam de ativos gerados ou coletados separadamente, quais precisam de ativos transparentes/de primeiro plano, quais são de fundo, quais ativos reais não podem ser falsificados e quais julgamentos, se errados, afetarão o resultado da recriação.

Esta fase cria ou atualiza um artefato de restauração visível. Os formatos aceitáveis incluem:

• docs/restoration-plan.md, mesclando o mapeamento de imagens de referência, manifest de ativos e o brief de recriação subsequente
• docs/reference-to-build-map.md mais docs/asset-manifest.md
• Se o repositório já tiver uma convenção de docs, use um documento de projeto equivalente

O artefato deve ser finalizado antes da geração de ativos e antes da edição do código da página. Ele deve listar cada imagem de referência confirmada e cada seção/página. Apenas resumir no chat, ocultar o raciocínio ou usar uma nota de progresso de uma linha não é suficiente.

A lista de divisão de ativos para o usuário deve ser mais curta do que o artefato interno. Cada seção deve incluir:

• Elementos de responsabilidade do código: texto, navegação, botões, layout, formas simples, rótulos e animações que precisam ser editáveis
• Material compartilhado do site: superfície de papel opcional, granulação, digitalização ou outro material de impressão digital gerado apenas uma vez e reutilizado, ou nenhum
• Ativos de cena mesclada: fundo inteiro ou cena mesclada com bordas, textura, mapa, campo de foto, mundo de mesa, colagem de cartões, ou nenhum
• Ativos de mídia independente: avatar, mock de produto, captura de tela, foto, capa, ilustração única, ou nenhum
• Ativos reais existentes: fotos fornecidas pelo usuário, logotipo, capturas de tela de produto, ativos oficiais ou arquivos de origem para copiar
• Ativos geráveis: imagens de atmosfera, decorações, mocks de produto abstratos, fundos ou substitutos seguros de gerar
• Bloqueado, substituir depois ou redesign necessário: pessoas reais, marca/logotipo/imagem de produto oficial, capturas de tela ausentes com alegações, ou topologia de imagem de referência que não pode ser fielmente estratificada
• Por que é importante: que risco de fidelidade de recriação seria causado se o limite do ativo for julgado incorretamente

Regras de Limite de Ativos

Ao preparar a lista de divisão de ativos da terceira etapa e a revisão de geração de ativos da quarta etapa, use as seguintes regras.

Depois que as imagens de referência existem, antes de escrever código, execute os três eixos de julgamento separadamente:

1. Limite: Apenas interação independente, substituição/atualização, semântica independente ou rearranjo responsivo forçam uma divisão fina. Após remover nós de código e nós independentes forçados, mescle objetos raster estáticos com sobreposições, sombras/reflexos entre objetos, texturas contínuas, perspectiva, luz ou relações de material. Um mesmo grupo de fusão é por padrão um ativo, independentemente de quantos cartões podem ser contados dentro dele.
2. Meio: Apenas texto ao vivo, layout DOM, cores sólidas, bordas/cantos arredondados/sombras comuns, gradiente CSS simples, ícone padrão, grade/ponto básico e geometria SVG simples podem ser code-native. Fotos, materiais irregulares, manuscritos/pinceladas, ilustrações complexas, UI/mock de produto denso, texturas naturais, 3D, luz/reflexo real ou efeitos raster compartilhados devem usar imagem. Quando ambos o comportamento ao vivo e a fidelidade raster são necessários, use híbrido: a imagem cuida do visual, o código cuida da casca, do texto e da interação.
3. Camada: integrated-scene é um visual mesclado vinculado à seção, pode ser full-bleed ou apenas no lado direito do Hero; independent-media são fotos, capturas de tela, capas, mocks, avatares ou ilustrações únicas substituíveis de forma independente. A transparência ou não não determina a classificação.

Por padrão, cada seção tem no máximo uma cena mesclada e não mais que três unidades raster no total. Slots de mídia independente são ativos separados, grupos de fusão estáticos permanecem como um. Todo o texto final, navegação, botões, formulários, dados factuais e interação permanecem no código. Fundo de arte de tela inteira é permitido, não é permitido assar o conteúdo de responsabilidade do código junto em uma captura de tela de tela inteira.

Quando o texto ao vivo não pode ser separado do material, elementos interativos compartilham sombras/oclusões duras com outra camada, ativos de identidade real são irreversivelmente fundidos na cena gerada, o modo móvel requer mover pixels independentemente dentro de uma única imagem, ou a reestruturação depende de costuras de pixels frágeis, use redesign-required, não force a divisão. Mantenha a impressão digital de estilo e retorne apenas esta seção à segunda etapa para regeneração.

Cada imagem de referência confirmada deve ter um mapa de referência para construção registrado no artefato de restauração visível:

Imagem de Referência: 01-hero.png
Camada de Código: nav, headline, subhead, grupo CTA, moldura do retrato, rótulos de prova
Cena Mesclada: hero-finance-desk.png, 16:9, full-bleed, máscara escura permitida
Mídia Independente: portrait.png, 24% de largura à direita; product-card-mock.png, 22% de largura no centro inferior
Deve Preservar: atmosfera de mesa escura/foto financeira, proporção do título à esquerda, cartão de avatar à direita, CTA verde, espaçamento da navegação superior
Desvio Permitido: rótulos de gráfico na imagem gerada substituídos por texto de código do brief confirmado
Gatilho de Risco: marca real não confirmada ou avatar do usuário precisa de confirmação primeiro

Cada seção deve cobrir todas as áreas significativas: papel semântico, gatilhos de limite, resultado da lista de permissões de código, sinais raster, grupo de fusão, proprietário (code ou asset), posicionamento (integrated-scene, independent-media ou nenhum), escopo de reutilização (global ou section), proveniência, modo responsivo, decisão/status (ready, generate, find/copy, code-native, replace-later, blocked ou redesign-required), fonte/ação e caminho final. Se não houver imagem específica da seção, escreva claramente o motivo e liste separadamente o material compartilhado reutilizado.

Registre o manifest de ativos (ativo, papel, gatilho de limite, sinal raster, grupo de fusão, posicionamento, escopo de reutilização, proveniência, caixa de referência, proporção, tamanho relativo, modo responsivo, status, caminho final), para que, durante a recriação, cada ativo possa ser colocado em um contêiner de proporção fixa, em vez de deixar o tamanho original da imagem ditar o layout.

Use este formato de nota final da terceira etapa:

Progresso atual: Terceira Etapa / Lista de Divisão de Ativos
Eu preparei: Mapa de referência para construção, lista de decisões de ativos e manifest de ativos inicial.
Por favor, confirme ou modifique:
1. Quais elementos permanecem code-native
2. Quais cenas mescladas e mídias independentes gerar, copiar ou substituir depois
3. Quais avatares reais, logotipos, capturas de tela de produtos ou ativos oficiais não podem ser gerados
4. Suposições de interação ou substituição na lista que são realmente ambíguas
Após a confirmação, irei para a Quarta Etapa para gerar ou organizar apenas os ativos aprovados. Ainda não editarei o código da página. Quando útil, posso processar grupos de ativos aprovados em paralelo; se você preferir execução sequencial, por favor, indique.

Quarta Etapa: Geração e Revisão de Ativos

Após a confirmação da lista de divisão de ativos, gere, copie, busque ou organize apenas os ativos aprovados. Em seguida, mostre ao usuário os resultados dos ativos e um breve brief de recriação. Não comece a implementação do código da página antes que o usuário aceite a revisão de ativos.

A revisão de ativos deve incluir:

• Caminho final de cada ativo pronto
• A qual seção e elemento visível cada ativo corresponde
• Fonte: gerado, fornecido pelo usuário, oficial/copiado, code-native ou substituir depois
• Resultado da verificação: aceito, precisa de regeneração, fraco mas utilizável com desvio nomeado, bloqueado ou espaço reservado para substituir depois
• Notas de prompt/fonte necessárias para reproduzir o ativo

Cada ativo de imagem tem apenas duas fontes legais:

1. Ativos reais já coletados na entrada da primeira etapa, como fotos do usuário, logotipo, capturas de tela de produtos ou arquivos de mídia. Na quarta etapa, não solicite novos ativos ao usuário temporariamente, a menos que o próprio usuário opte por fornecê-los; para conteúdo não fornecido a esta altura, gere substitutos, use espaços reservados code-native, marque replace-later ou marque blocked quando enganoso.
2. Nova geração de imagem: deve ser ancorada na área de referência correspondente. Antes de escrever qualquer prompt de geração, reabra a imagem de referência confirmada e transcreva a área alvo em uma lista visual: tipo de cena (colagem de cartão de papel / cena fotográfica / ilustração plana / mock de UI / campo de textura), cada objeto principal e sua posição aproximada, valores hex da paleta de cores, luz, material, layout de espaço em branco. O prompt de geração deve ser escrito a partir desta transcrição—mesmo tipo de cena, mesma lista de objetos, mesma composição e paleta—nunca a partir do nome do ativo ou de um resumo de uma linha da lista de divisão. Se a ferramenta de geração suportar entrada de imagem, anexe a área de referência como referência visual. Um prompt escrito apenas com categorias de conteúdo (