Design system no Framer: o que pertence aos estilos, componentes e ao DESIGN.md

Uma decisão de design system pode aparecer em várias partes do Framer. Sua página oficial de IA afirma que o canvas pode refinar tipografia, componentes, breakpoints, espaçamento, cor, efeitos e layouts. A página também descreve componentes de código criados por IA e conexões com agentes externos. Em toda a plataforma, design, código, colaboração e publicação compartilham um único ambiente de trabalho.

Essas capacidades indicam o que pode ser editado. Por si sós, elas não decidem onde uma regra deve se originar ou qual prevalece quando duas camadas divergem. O modelo de responsabilidade e precedência abaixo é um contrato de trabalho para equipes, não um padrão nativo do Framer.

Escolha a autoridade com base no escopo da decisão. Uma regra que deva sobreviver a uma mudança de página, agente ou ferramenta de implementação pertence a orientações portáveis, como o DESIGN.md. Implemente um valor reutilizável dentro do projeto Framer como um estilo compartilhado. Quando uma decisão define uma unidade recorrente com estrutura ou comportamento, coloque essa implementação em um componente.

Um mapeamento não é uma segunda autoridade. Por exemplo, o DESIGN.md pode especificar que o texto suavizado (muted) utiliza um papel semântico de foreground. Um estilo de texto do Framer pode implementar esse papel sob um nome específico do projeto. A regra escrita detém o significado, enquanto o estilo do Framer detém o valor reutilizável local. O registro de handoff é o que os conecta.

Quando duas camadas divergem, não aceite aquela que for renderizada por último. Rastreie a decisão até sua autoridade declarada, verifique se o mapeamento subsequente está atualizado e classifique qualquer desvio como uma exceção aprovada ou um defeito.

1. Verifique a decisão autoritativa e seu escopo.
2. Verifique o mapeamento registrado para o estilo, componente, breakpoint ou componente de código do Framer.
3. Verifique se uma exceção mais restrita foi explicitamente permitida.
4. Se a autoridade for ambígua, pause a alteração e atribua-a antes de editar mais superfícies.
5. Atualize primeiro a camada proprietária, depois atualize os mapeamentos afetados e registre a evidência observada.

Um agente precisa de mais do que uma solicitação de design. Forneça a ele um breve registro de aceitação que nomeie a decisão autoritativa, os consumidores pretendidos, as superfícies não alteradas e as evidências necessárias para a revisão.

change_id: nav-muted-text
objective: Align secondary navigation text with the declared muted-text role.

source:
  authority: DESIGN.md > Color roles > Muted content
  owner: Design systems owner
  decision: Secondary navigation labels use the muted foreground role.

targets:
  framer_styles:
    - Secondary / Navigation
  components:
    - Site Header
    - Footer Navigation
  representative_pages:
    - Home
    - Pricing
  breakpoints:
    - Desktop
    - Smallest supported phone width

allowed_exceptions:
  - Active navigation item uses the primary foreground role.

must_remain_unchanged:
  - Primary navigation labels
  - Button labels
  - CMS article body text
  - Header spacing and interaction behavior

agent_context:
  include:
    - Relevant DESIGN.md color-role section
    - Target text style
    - Site Header and Footer Navigation components
    - Home and Pricing pages
  exclude:
    - Unrelated pages, CMS content, and global layout changes

evidence:
  intended_change:
    - Before and after capture for each representative page and breakpoint
  unrelated_drift:
    - Comparison of named unchanged surfaces
  unresolved:
    - Record any mapping or behavior that could not be inspected

disposition: pass | revise | block
reviewer:
reviewed_at:

O registro separa a intenção da observação. Um alvo listado em framer_styles tem a expectativa de ser alterado. Sua presença ali não é evidência de que o mapeamento existe ou de que o resultado corresponde à origem. Preencha a seção de evidências apenas após a inspeção.

Páginas representativas devem exercitar o uso real. Escolha pelo menos uma página onde o alvo seja proeminente e outra onde ele apareça em uma composição diferente. Para breakpoints, cubra a condição responsiva com maior probabilidade de alterar o componente, em vez de verificar cada largura arbitrária de canvas.

O Framer descreve o contexto do projeto, estilos e assets editáveis, conexões de agentes externos e alterações feitas por agentes. Mais contexto não significa automaticamente algo melhor. Um contexto delimitado facilita a visualização de se o agente seguiu a regra pretendida e se trabalhos não relacionados infiltraram-se na branch.

1. 1

   Selecione a decisão de origem

   Forneça a seção relevante do DESIGN.md ou outra autoridade declarada. Não envie uma biblioteca inteira quando apenas um papel de cor ou regra de componente estiver no escopo.

2. 2

   Nomeie os consumidores do Framer

   Identifique os estilos compartilhados, componentes, páginas, camadas e breakpoints que devem implementar a decisão. Marque mapeamentos desconhecidos como desconhecidos em vez de adivinhar seus nomes.

3. 3

   Declare os não-objetivos

   Liste as superfícies próximas que o agente não deve redesenhar, renomear, reestruturar ou reestilizar. Inclua componentes não relacionados que compartilham a página.

4. 4

   Defina a aceitação observável

   Descreva o que o revisor deve ver em páginas representativas e em breakpoints pequenos. Nomeie as superfícies não relacionadas que devem permanecer inalteradas.

5. 5

   Abrir uma alteração de branch delimitada

   Solicite apenas a alteração nomeada. Se o agente encontrar um mapeamento ausente ou uma autoridade ambígua, exija que ele reporte a lacuna em vez de inventar um novo sistema.

Um canvas de desktop com boa aparência é uma evidência fraca. Revise a alteração pretendida em todos os locais onde ela é reutilizada, inspecione um breakpoint menor e verifique superfícies não relacionadas para detectar drift. O objetivo é a rastreabilidade, e não a afirmação de que uma única revisão certifica todo o site.

1. 1

   Confirme a origem e o mapeamento

   Verifique se o brief da branch aponta para a decisão autoritativa atual e para os consumidores pretendidos no Framer. Se algum deles estiver faltando, revise o brief antes de julgar a renderização.

2. 2

   Inspecione a página representativa primária

   Verifique o estilo ou componente pretendido na página onde seu efeito seja mais fácil de visualizar. Registre o que mudou em vez de confiar na memória.

3. 3

   Inspecione outro consumidor real

   Abra uma segunda página ou composição representativa que utilize o mesmo estilo ou componente. Uma divergência geralmente revela um valor local desvinculado ou um componente duplicado.

4. 4

   Verifique a adaptação responsiva

   Inspecione o menor breakpoint nomeado e qualquer breakpoint onde o arranjo, a visibilidade ou o dimensionamento mudem intencionalmente. Confirme se a regra base ainda se mantém, a menos que o brief permita uma adaptação.

5. 5

   Procure por drift não relacionado

   Compare as superfícies listadas em must_remain_unchanged. Verifique os valores de estilo, a estrutura do componente, o layout, o conteúdo e as interações relevantes ao escopo da branch.

6. 6

   Atribua uma disposição

   Aprove quando os mapeamentos pretendidos coincidirem e não houver drift no escopo. Revise em caso de incompatibilidade corrigível. Bloqueie quando a autoridade for ambígua, as evidências necessárias estiverem indisponíveis ou a branch alterar non-goals protegidos.

Quando uma página do Framer parece inconsistente, outro prompt genérico geralmente torna a evidência mais difícil de interpretar. Percorra as camadas na ordem de propriedade e pare no primeiro mapeamento não suportado ou contraditório.

1. Decisão de origem: A role ou regra pretendida é explícita, atual e possui um proprietário?
2. Contexto selecionado: O agente recebeu a regra, os alvos, as exceções e os non-goals relevantes?
3. Mapeamento de estilo compartilhado: O elemento de destino usa o estilo do Framer mapeado para a role de origem?
4. Uso de componente: A página está usando o componente compartilhado e a variante pretendida, ou uma cópia desvinculada?
5. Adaptação de breakpoint: Um override responsivo altera intencionalmente o valor ou a estrutura?
6. Código gerado: Um componente de código contém um valor ou comportamento duplicado que conflita com a origem?
7. Override ao nível de página: Existe um valor local mascarando a implementação compartilhada?

Corrija a camada proprietária, não o primeiro sintoma visível. Se um componente usa o estilo compartilhado errado, corrija o mapeamento do componente. Se a regra de origem estiver genuinamente errada, altere-a através do processo normal de design system da equipe e, então, atualize todos os consumidores afetados. Não reescreva a origem apenas para legitimar um valor local acidental.

O kit público Ambient Sage serve como exemplo porque seus fatos de origem são inspecionáveis. Sua página publicada fornece um DESIGN.md, design tokens semânticos para temas claro e escuro, uma paleta de 31 cores e funções de tipografia. A Plus Jakarta Sans é utilizada para títulos e corpo de texto, enquanto a JetBrains Mono assume a função mono. O kit também descreve superfícies em tom sage quente, cards tonais e um destaque amarelo discreto.

Um handoff poderia mapear a função de background do kit para um estilo de cor do Framer, sua função de body para um estilo de texto usando Plus Jakarta Sans e sua orientação de tonal-card para um componente de card reutilizável. Estes são mapeamentos de exemplo, não fatos sobre um projeto Framer existente. O proprietário do projeto deve escolher os nomes reais e verificar as páginas resultantes.

O mapa de responsabilidades e o registro de branch melhoram a rastreabilidade. Eles não substituem a revisão de um especialista nem provam que o resultado é bom. Uma implementação consistente ainda pode aplicar consistentemente uma decisão de design ruim.

• Não certifica a conformidade de acessibilidade, incluindo contraste, comportamento de teclado, tratamento de foco, semântica ou suporte a tecnologias assistivas.
• Não prova que cada página, estado de conteúdo, localidade ou viewport seja responsivo.
• Não avalia a qualidade do código gerado, comportamento em tempo de execução, performance, segurança ou manutenibilidade fora da alteração declarada.
• Não prova que um artefato de origem foi importado automaticamente ou reproduzido com paridade visual.
• Não autoriza a publicação. A branch ainda precisa do processo normal de revisão e release do projeto.

Mantenha trilhas de evidências separadas quando o risco exigir. A conformidade do design system questiona se a implementação segue sua fonte declarada. Acessibilidade, resiliência, comportamento e prontidão para produção exigem suas próprias verificações.

Escolha uma decisão existente que apareça em mais de uma página do Framer, como o texto de navegação suavizado ou a cor da superfície de um card. Declare sua fonte autoritativa, registre o mapeamento exato do estilo ou componente do Framer, nomeie duas páginas representativas e um breakpoint pequeno, e então teste uma alteração delimitada em branch. Expanda o sistema apenas quando o registro estiver claro o suficiente para que outro revisor possa reproduzi-lo.

• AI Website Builder for Designers & Teams | Framer: O Framer documenta páginas editáveis criadas por IA e a capacidade de refinar layouts, tipografia, componentes, breakpoints, espaçamento, cores, efeitos e componentes de código dentro do projeto.
• Framer: AI website builder for professional sites: O Framer apresenta agentes, design, código, colaboração e publicação como partes da mesma plataforma de construção de sites.
• Web Design Tools in Framer: A visão geral de design capturada descreve estilização de camadas, grids, stacks, adaptação de tela responsiva, fontes integradas e superfícies de colaboração orientadas a breakpoints.
• Ambient Sage Design Kit: O kit público Ambient Sage fornece um DESIGN.md, design tokens semânticos para temas claro e escuro, tipografia Plus Jakarta Sans, JetBrains Mono e diversos formatos de exportação para desenvolvedores.
• Como gerar um DESIGN.md (e o que ele é): O Identity Forge define o DESIGN.md como um brief de design escrito que abrange a intenção, design tokens, tipografia, layout, tratamento de componentes, motivos e regras explícitas de uso para agentes de código.
• AI UI review checklist: test generated interfaces before you ship: O guia de revisão separa evidências de tarefa, design system, resiliência e acessibilidade, e recomenda testar estados representativos e alterações controladas antes do release.

• AI Website Builder for Designers & Teams | Framer: O Framer documenta páginas editáveis criadas por IA e a capacidade de refinar layouts, tipografia, componentes, breakpoints, espaçamento, cores, efeitos e componentes de código dentro do projeto.
• Framer: AI website builder for professional sites: O Framer apresenta agentes, design, código, colaboração e publicação como partes da mesma plataforma de construção de sites.
• Web Design Tools in Framer: A visão geral de design capturada descreve estilização de camadas, grids, stacks, adaptação de tela responsiva, fontes integradas e superfícies de colaboração orientadas a breakpoints.
• Ambient Sage Design Kit: O kit público Ambient Sage fornece um DESIGN.md, design tokens semânticos para temas claro e escuro, tipografia Plus Jakarta Sans, JetBrains Mono e diversos formatos de exportação para desenvolvedores.
• How to generate a DESIGN.md (and what it is): O Identity Forge define o DESIGN.md como um brief de design escrito que abrange a intenção, design tokens, tipografia, layout, tratamentos de componentes, motivos e regras explícitas de uso para agentes de código.
• AI UI review checklist: test generated interfaces before you ship: O guia de revisão separa evidências de tarefa, design system, resiliência e acessibilidade, e recomenda testar estados representativos e alterações controladas antes do release.