Design system Google Stitch: diagnostique drift e verifique o handoff

O Google descreve o DESIGN.md como uma forma portátil de importar e exportar regras de design. Ele pode conter decisões compartilhadas sobre funções de cores, tipografia, espaçamento, princípios de layout, tratamento de componentes e restrições visuais. Essa portabilidade é fundamental: as regras podem transitar entre projetos e plataformas em vez de viverem apenas em uma conversa.

O arquivo tem uma função mais restrita. Ele define regras. Ele não prova que cada tela gerada as seguiu, que um prompt não as sobrescreveu ou que o código exportado as preservou. Tampouco certifica a conclusão de tarefas, acessibilidade, comportamento responsivo, qualidade do código gerado ou prontidão para produção. Isso requer verificações separadas.

O Stitch muda rapidamente, e os resultados de pesquisa misturam documentação do produto, tutoriais e relatos de usuários. Classifique cada alegação de fluxo de trabalho por classe de evidência. Isso evita que um tutorial confiante ou um relato de falha isolado se torne acidentalmente um contrato de produto.

Para qualquer capacidade relevante para o handoff, use a documentação oficial atual para estabelecer a disponibilidade e suas próprias observações registradas para estabelecer o comportamento. Mantenha instruções de terceiros como provisórias até que você as tenha reproduzido. Relatos da comunidade são ideias de teste, não previsões.

A consistência torna-se dispendiosa quando vários artefatos parecem autoritativos ao mesmo tempo. Um site de referência sugere uma escala tipográfica, o DESIGN.md define outra, uma tela gerada introduz uma terceira e alguém corrige manualmente o código exportado. Sem um registro de precedência, o resultado visível mais recente tende a prevalecer, mesmo quando não deveria.

Para cada conflito não resolvido, registre os valores conflitantes, a camada responsável, a pessoa que decide e a evidência de que ela precisa. Não resolva isso copiando qualquer valor que tenha aparecido na geração mais recente.

Antes de pedir ao Stitch para gerar mais telas, anote as decisões que devem permanecer estáveis. Use linguagem observável. "Mantenha a coesão" não é testável. "Use a mesma estrutura de navegação primária nas telas de conta, faturamento e análise" é.

• Navegação: estrutura, posicionamento, estado selecionado, comportamento de recolhimento e variações permitidas.
• Ícones: estilo da fonte, tratamento de traço ou preenchimento, regras de tamanho e onde os rótulos de texto são obrigatórios.
• Modo de cor: modos permitidos, modo padrão, papéis semânticos e se uma tela pode alternar independentemente.
• Tipografia: família por papel, pesos disponíveis, escala, intenção de altura de linha e tratamento de dados ou código.
• Espaçamento e layout: larguras de container, calhas, ritmo de seção, comportamento da grade e densidade.
• Componentes: tratamentos compartilhados de botão, input, card, tabela, feedback e foco.
• Exceções: a tela exata, estado, motivo, aprovador e limite de cada desvio.

Não verifique apenas a tela mais polida. Escolha um conjunto representativo que inclua a estrutura principal, uma tela de dados densos, um formulário, um estado de erro ou destrutivo e qualquer tela com uma exceção aprovada. Se mobile ou modo escuro estiverem no escopo, inclua esses estados explicitamente.

Quando duas telas divergem, encontre o primeiro ponto onde as evidências diferem. Regenerar todas as telas imediatamente pode ocultar a causa e introduzir novas alterações.

1. 1

   Verificar se a regra governante está completa

   Encontre a regra relevante no DESIGN.md. Se ela disser apenas "use navegação consistente", ela não define estrutura, estados ou exceções. Revise a regra na camada proprietária antes de corrigir as telas.

2. 2

   Comparar os prompts e as sugestões aceitas

   Registre o prompt original, as instruções de acompanhamento e quaisquer sugestões automáticas ou manuais. Uma instrução específica de tela pode ter sobrescrito a regra compartilhada. Remova ou restrinja essa sobrescrita e, em seguida, tente novamente apenas o caso afetado.

3. 3

   Verificar se há uma exceção aprovada

   Uma diferença legítima não é drift quando sua tela, estado, motivo e escopo foram aprovados. Se a exceção não estiver documentada, faça uma pausa e obtenha uma decisão de ownership em vez de normalizá-la a posteriori.

4. 4

   Localizar o primeiro artefato divergente

   Compare telas representativas do Stitch antes de inspecionar o código downstream. Se as telas concordam, mas a exportação difere, encaminhe a descoberta para a fronteira de exportação ou implementação. Se as telas já divergem, mantenha a correção upstream.

5. 5

   Alterar uma variável controlada pelo proprietário

   Aplique uma alteração de regra pontual, como o modo de cor padrão ou o tratamento de seleção de navegação. Não agrupe revisões de tipografia, espaçamento e componentes no mesmo teste.

6. 6

   Atribuir uma disposição

   Aprove (Pass) quando a alteração pretendida aparecer onde era esperado, sem drift material não relacionado. Revise (Revise) quando a regra governante ou o prompt estiverem incompletos. Bloqueie (Block) quando o ownership, a evidência ou a paridade downstream permanecerem não resolvidos.

Uma alteração controlada testa se uma regra declarada chega aos locais onde deveria. É mais restrita do que uma revisão visual geral. Escolha uma regra com um resultado observável, nomeie as telas e a superfície de exportação no escopo e, então, capture os efeitos pretendidos e não pretendidos.

Controlled change

Project:
Observed date:
Reviewer:

Governing layer:
Rule identifier:
Current rule:
Proposed rule:
Reason for change:
Owner and approver:

Representative screens:
- Screen / state:
  Expected change:
  Actual observation:
  Evidence reference:
- Screen / state:
  Expected change:
  Actual observation:
  Evidence reference:

Approved exceptions:
- Screen / state:
  Exception and reason:
  Expected to remain unchanged: yes / no

Exported artifact:
Artifact and version:
Expected change:
Actual observation:
Evidence reference:

Unrelated drift:
- Navigation:
- Icons:
- Color mode:
- Typography:
- Spacing and layout:
- Component treatment:

Unresolved conflicts:
Owner:
Next evidence required:

Disposition: pass / revise / block
Disposition reason:

"Nenhum drift não relacionado observado" é válido apenas para as telas e o artefato nomeados. Isso não significa que todo o projeto esteja consistente. Onde seu fluxo de trabalho permitir, anexe referências a screenshots, versões de tela, texto de prompt, revisões do DESIGN.md e commits ou arquivos exportados.

Este registro de entrada mostra como trazer uma fonte delimitada para o processo sem inventar resultados do Stitch. O Ambient Sage é um kit gratuito e publicado da Identity Forge. Sua tipografia documentada usa Plus Jakarta Sans para funções de corpo e título nos pesos 400, 500, 600 e 700, além de JetBrains Mono para a função mono nos pesos 400, 500 e 700. A escala publicada é compact-product.

Artifact intake: Ambient Sage

Source state
- Public kit page: documented
- Kit access: free and published
- Typography roles: documented
- Body and heading family: Plus Jakarta Sans
- Body and heading weights: 400, 500, 600, 700
- Mono family: JetBrains Mono
- Mono weights: 400, 500, 700
- Typography scale: compact-product
- DESIGN.md: available
- Semantic light and dark tokens: available
- Delivery formats: shadcn, Tailwind, CSS, and DTCG

Stitch evidence state
- DESIGN.md imported into Stitch: not tested
- Import warnings or transformations: not tested
- Generated-screen adherence: not tested
- Navigation consistency: not tested
- Icon consistency: not tested
- Light and dark mode behavior: not tested
- Typography and spacing parity: not tested
- Exported-artifact parity: not tested
- Controlled-change result: not tested

Handoff disposition
- Status: block pending evidence
- Reason: the source artifact is documented, but no Stitch-specific behavior or source-to-export parity has been observed
- Next action: import through the currently documented Stitch workflow, capture any transformation, then run one controlled change across representative screens and the chosen export

Entregue juntos o DESIGN.md governante, os tokens legíveis por máquina ou artefatos de implementação, o registro de exceções, o registro de alterações controladas e o código exportado. Atribua a cada item uma versão ou referência de evidência estável. O desenvolvedor deve ser capaz de rastrear um valor visível até uma função semântica ou regra escrita e ver quais diferenças foram aprovadas.

• Nomear a revisão do DESIGN.md e o artefato de token usados para a geração.
• Listar telas representativas e seus estados registrados.
• Incluir exceções aprovadas exatas e conflitos não resolvidos.
• Registrar o método de exportação e a versão do artefato resultante.
• Separar a paridade verificada das áreas que não foram testadas.
• Encaminhar correções downstream de volta para a regra proprietária quando representarem decisões de design compartilhadas.

Se um desenvolvedor alterar uma cor compartilhada, um valor de espaçamento ou o tratamento de um componente apenas no código exportado, trate isso como drift downstream até que a fonte governante aceite a alteração. Se for um detalhe de implementação sem consequência para o design system, mantenha-o no código e explique por que ele não precisa subir para o upstream.

Aprove o handoff do design system quando a regra governante e o proprietário estiverem claros, as telas representativas mostrarem o resultado esperado, as exceções aprovadas permanecerem delimitadas, o artefato exportado preservar a alteração verificada e não houver drift material irrelevante no escopo.

Escolha revise quando as evidências indicarem que a regra no DESIGN.md está incompleta, que houve um override de prompt abrangente ou que existe uma exceção mal definida que o proprietário atual possa corrigir. Escolha block quando as fontes estiverem em conflito sem um proprietário definido, quando o comportamento específico do Stitch não tiver sido observado, quando o artefato exportado violar uma regra governante ou quando o registro de evidências for insuficiente para reproduzir a decisão.

Para um novo projeto, preencha o registro de autoridade de quatro camadas antes de gerar outra tela. Para um projeto existente, escolha uma inconsistência visível, direcione-a para a camada proprietária e execute a planilha de alteração controlada antes de aceitar ou regenerar o restante.

• O formato DESIGN.md do Stitch agora é open-source para que você possa utilizá-lo em diversas plataformas: o Google documenta o DESIGN.md como um formato portátil para importar e exportar regras de design entre projetos e plataformas.
• Apresentando o "vibe design" com o Stitch: o Google descreve o fluxo de trabalho atual do Stitch como a combinação de um canvas nativo de IA, um agente de design, suporte ao DESIGN.md, iteração e superfícies de entrega para desenvolvedores.
• Da ideia ao app: Apresentando o Stitch, uma nova maneira de projetar UIs: O artigo de lançamento do Google documenta a geração a partir de texto ou imagens, o refinamento interativo, a transferência para o Figma e a exportação de código frontend.
• Design system ou diretriz de design em projeto Stitch: Uma thread da comunidade relata ícones, navegação e modo de cor inconsistentes entre telas geradas. Uma resposta assinada pelo Google recomenda prompts mais explícitos e a proteção de elementos selecionados.
• Como usar o Google Stitch para criar um design system de website em minutos: Este tutorial de terceiros descreve a extração de URL, a geração de protótipos de várias páginas, a iteração e a exportação, mas suas alegações não constituem um contrato oficial do produto.
• Ambient Sage Design Kit: O kit público Ambient Sage oferece um exemplo de design delimitado por fonte com DESIGN.md, artefatos de entrega legíveis por máquina, papéis tipográficos documentados e um sistema visual compacto e orientado ao produto.
• Checklist de revisão de UI com IA: teste interfaces geradas antes do lançamento: A checklist de revisão publicada pelo Identity Forge separa a conformidade com o design system da prontidão geral e utiliza estados representativos, alterações controladas, registros de evidências e disposições explícitas.

• Stitch's DESIGN.md format is now open-source so you can use it across platforms: O Google documenta o DESIGN.md como um formato portátil para importar e exportar regras de design entre projetos e plataformas.
• Introducing "vibe design" with Stitch: O Google descreve o fluxo de trabalho atual do Stitch como uma combinação de um canvas nativo de IA, um agente de design, suporte ao DESIGN.md, iteração e superfícies de entrega para desenvolvedores.
• From idea to app: Introducing Stitch, a new way to design UIs: O artigo de lançamento do Google documenta a geração a partir de texto ou imagens, o refinamento interativo, a transferência para o Figma e a exportação de código frontend.
• Design system or design guideline on Stitch project: Uma thread da comunidade relata ícones, navegação e modo de cor inconsistentes entre telas geradas. Uma resposta assinada pelo Google recomenda prompts mais explícitos e a proteção de elementos selecionados.
• How to Use Google Stitch to Build a Website Design System in Minutes: Este tutorial de terceiros descreve a extração de URL, a geração de protótipos de várias páginas, a iteração e a exportação, mas suas alegações não constituem um contrato oficial do produto.
• Ambient Sage Design Kit: O kit público Ambient Sage oferece um exemplo de design com escopo definido por fonte, incluindo o DESIGN.md, artefatos de entrega legíveis por máquina, funções de tipografia documentadas e um sistema visual compacto e orientado ao produto.
• AI UI review checklist: test generated interfaces before you ship: A checklist de revisão publicada pelo Identity Forge separa a conformidade com o design system da prontidão geral e utiliza estados representativos, alterações controladas, registros de evidências e disposições explícitas.