A camada de layout que o canvas costumava esconder

Uma resposta útil da comunidade não pede um botão maior. Ela nomeia a camada que falta.

Foi isso que aconteceu na discussão do Open Design 0.8.0-preview. A thread de lançamento defendia duas mudanças: parar de tratar o canvas como a unidade primária de trabalho e fazer do agente o trabalhador de design de primeira classe. Uma resposta concordou com a direção e então apontou a parte difícil: quando o canvas desaparece, os usuários ainda precisam de um jeito de entender o que o agente fez antes de poder editá-lo com confiança.

A expressão na resposta foi “Camada de Compreensão de Layout” (Layout Understanding Layer). É um bom nome porque recusa a resposta preguiçosa. Design agent-native não pode significar “confie no screenshot.” Ele precisa de um modelo legível do artefato: seções, intenção, partes editáveis, referências estáveis e movimentos de edição sugeridos. Este post é uma tentativa de levar essa resposta a sério — de esboçar o que tal camada poderia carregar, onde ela deveria viver no Open Design e por que ela é um caminho de contribuição, não uma promessa de roadmap.

O canvas dava aos designers confiança espacial

O canvas do Figma não é só uma superfície de desenho. É também uma superfície de explicação. Você pode dar zoom-out, ver a hierarquia da página, clicar num frame, inspecionar constraints, renomear layers e entender onde uma parte do trabalho termina e outra começa.

O que você de fato perde quando o canvas vai embora

Essa compreensão é fácil de subestimar até que ela some. Uma landing page gerada pode parecer correta em uma prévia em sandbox e ainda assim ser difícil de dirigir. O problema não são os pixels — é a ausência de um vocabulário compartilhado entre o humano e o agente.

“Deixe o hero mais confiante” só é útil se o agente e o humano concordarem sobre o que é o hero. “Aperte a seção de preços” só funciona se o artefato carregar uma identidade de seção estável entre revisões. Sem isso, toda instrução degenera em apontar: o designer descreve uma região pela sua posição (“o segundo bloco de cima para baixo”), o agente adivinha a partir da saída renderizada, e a próxima regeneração silenciosamente renumera tudo. O canvas costumava absorver esse custo silenciosamente. Ele nomeava as partes para você, mantinha esses nomes estáveis enquanto você trabalhava e deixava você selecionar uma sem descrevê-la.

A clareza vale a pena manter mesmo que a unidade esteja errada

Esta é a parte do argumento do #DeFigma que precisa de cuidado. O canvas pode ser a unidade errada de trabalho para um sistema agent-native — ele pressupõe um humano arrastando retângulos, não um agente escrevendo arquivos — mas a clareza que as pessoas obtinham do canvas ainda é valiosa. O erro seria tratar “abandonar o canvas” e “abandonar a compreensão que o canvas fornecia” como a mesma decisão. Não são. O Open Design precisa mover essa clareza para o modelo do artefato, não jogá-la fora. A camada de layout é o nome dessa realocação.

O Open Design já tem as primitivas certas

A razão pela qual esta proposta encaixa no Open Design é que o projeto já é construído em torno de contratos explícitos. Uma skill é um arquivo SKILL.md. Um design system é um arquivo DESIGN.md. Um plugin adiciona um sidecar open-design.json. Nada no sistema é um blob binário que você precise fazer engenharia reversa; os contratos são texto, e texto é algo que tanto um agente quanto um humano podem ler. A mecânica está coberta em 31 skills, 72 sistemas: como funciona a biblioteca do Open Design, e o argumento de produto está em Por que construímos o Open Design como uma camada de skills, não um produto.

A camada de layout deveria seguir o mesmo padrão. Deveria ser texto que o agente possa ler, estado que a UI possa renderizar e metadados que outro agente possa reutilizar. Se não conseguir satisfazer as três coisas ao mesmo tempo, está com o formato errado.

Em termos de repositório, isso aponta para três superfícies:

Superfície	O que deveria carregar
Manifesto do artefato	IDs estáveis para seções, componentes, ativos e arquivos gerados
Snapshot do plugin	Qual skill, design system, entradas e estágios de pipeline produziram o artefato
UI de revisão / saída headless	Um mapa de layout, aspectos editáveis e intenções de edição sugeridas

A restrição importante: a camada não deveria virar um segundo canvas proprietário. O modo de falha a evitar é reconstruir o scene graph do Figma com um novo nome — uma estrutura rica e específica do app que só a UI do Open Design consegue renderizar e que morre no momento em que você sai do app. A camada de layout deveria ser, em vez disso, um mapa de artefato simples que viaja com os arquivos, para que um contribuidor possa lê-lo em um editor de texto e um agente diferente possa consumi-lo sem um SDK.

Um esqueleto de layout em wireframe se erguendo como sua própria camada selecionável acima de um canvas em branco, em uma moldura verde sobre um fundo editorial quase branco — A camada de layout é a estrutura que o canvas mantinha implícita — extraída para onde um agente e um humano possam ambos lê-la.

Um formato prático para a camada de layout

Aqui está a menor versão que tornaria o design agent-native menos opaco:

Cada artefato gerado recebe IDs semânticos estáveis: hero, proof-strip, pricing, faq, final-cta.
Cada ID carrega uma frase de intenção: “Explicar a promessa do produto em uma tela”, não “seção do topo”.
Cada seção lista aspectos editáveis: texto, densidade, layout, cor, mídia, movimento, fonte de dados.
Cada arquivo gerado faz referência de volta ao ID da seção que o produziu.
Cada passada de revisão emite intenções de edição sugeridas: “encurtar o título do hero”, “aumentar o contraste nos cards de preços”, “dividir o bloco de depoimentos”.
A UI renderiza isso como um navegador, enquanto usuários headless recebem a mesma estrutura como JSON ou Markdown.

Como um manifesto poderia realmente parecer

O sentido de escrevê-lo é que a estrutura é nada notável — que é exatamente por que ela pode ser um contrato público em vez de um truque privado. Um manifesto para uma landing page gerada poderia se ler assim:

{
  "artifact": "landing/index.html",
  "producedBy": { "skill": "magazine-poster", "system": "linear", "stage": "compose" },
  "sections": [
    {
      "id": "hero",
      "intent": "Explain the product promise in one screen",
      "editable": ["copy", "density", "media"],
      "files": ["landing/index.html#hero", "landing/hero.css"]
    },
    {
      "id": "pricing",
      "intent": "Let a visitor self-select a plan without scrolling back",
      "editable": ["copy", "layout", "data-source"],
      "files": ["landing/index.html#pricing", "landing/pricing.json"]
    }
  ],
  "suggestedEdits": [
    { "target": "hero", "intent": "shorten headline to one line" },
    { "target": "pricing", "intent": "drop from three plans to two" }
  ]
}

Nenhuma dessas chaves é exótica. sections é uma lista, editable é um enum, files é uma referência de volta. O valor não está na esperteza do schema — está no fato de que os IDs sobrevivem a uma regeneração, de modo que o mesmo bloco pricing ainda é pricing depois que o agente o reescreve duas vezes.

Isso é suficiente para deixar um designer dizer “Mude pricing de três planos para dois”, e suficiente para deixar um agente de código corrigir o arquivo certo sem adivinhar a partir dos pixels. A instrução resolve para um ID de seção, o ID de seção resolve para um conjunto de arquivos, e a edição aterrissa onde foi destinada.

Por que isso é um caminho de contribuição, não um pedido de recurso

Isso também dá à comunidade um caminho de contribuição limpo. Um contribuidor não precisa redesenhar o produto para ajudar aqui. Ele pode escrever uma skill que emite um manifesto para um tipo de artefato, um átomo de revisão que propõe intenções de edição, uma extensão de manifesto que adiciona um campo que outras skills possam ler, ou um caso de teste que afirma que os IDs de seção permanecem estáveis ao longo de uma regeneração. Cada um deles é uma mudança pequena e mergeável que torna uma saída menos opaca — e como a camada é texto puro, dois contribuidores trabalhando em um deck e numa tela mobile não precisam coordenar um formato binário compartilhado. A camada de layout vira um contrato público, não uma capacidade privada enterrada dentro do app.

O que fazer a seguir

Se esse é o tipo de problema em que você quer trabalhar, contribua com uma pequena skill ou plugin que torne um artefato mais fácil de inspecionar. Comece com uma saída concreta: uma landing page, um deck ou uma tela mobile. Adicione IDs de seção estáveis, descreva os aspectos editáveis, emita-os como JSON ou Markdown junto ao artefato e abra o PR com um artefato de antes/depois para que um revisor possa ver a diferença que uma camada inspecionável faz.

Isso ainda é uma direção, não um recurso entregue — o valor de nomeá-la agora é que as primitivas já existem, então o trabalho é aditivo em vez de uma reescrita.

Contribua com uma skill.

Leitura relacionada

31 skills, 72 sistemas: como funciona a biblioteca do Open Design — as primitivas atuais orientadas a arquivo por baixo da proposta
Por que construímos o Open Design como uma camada de skills, não um produto — o formato de produto que torna possíveis os contratos públicos de artefato
A alternativa open-source ao Figma — onde “abandonar o canvas” aterrissa contra o incumbente que tornou o canvas central