# Forma sem magnitude

## Conteúdo

- 0. O mecanismo: placeholder sequencial fixo
- 1. A tabela renderiza / suprime
- 2. A tabela de placeholders, a heurística de escala e o que segue proibido
- 3. O placeholder no card de KPI
- 4. Placeholder semântico de texto
- 5. Os casos difíceis, honestamente
  - Parte-todo (donut)
  - Tabela
- 6. Perspectiva artística, não foto — e o banner de dados ilustrativos

Este arquivo é o dono do detalhe da convenção que o `SKILL.md` só mapeia. Se
você chegou aqui antes de tocar em eixo, rótulo, escala, célula de tabela ou
valor de KPI — está no lugar certo; leia até o fim antes de renderizar
qualquer coisa.

No momento do escopo, o time conhece a **forma**: o tipo de gráfico, as
categorias reais, a ordenação, a pergunta que a tela responde. **Não** conhece
nenhuma **magnitude**: escala do eixo, totais, o valor do KPI.

> **Renderize tudo que você sabe. Suprima tudo que você não sabe.**

Não é um nível numa régua de fidelidade — "capricha mais" ou "capricha menos"
não resolve nada aqui. É uma fronteira **epistêmica**: o lado de dentro é o
que o time efetivamente sabe hoje, o lado de fora é invenção, não importa
quão discreta. Uma barra ranqueada sem eixo Y numérico diz *"isto virá
ordenado por valor"* — o que é verdade, e é a decisão de design que está
sendo vendida. Um eixo de 0 a 1 milhão inventa o faturamento do cliente,
mesmo que ninguém tenha escrito o número 1.000.000 em lugar nenhum: a régua
já é a afirmação.

Não existe termo estabelecido na literatura para isto — pesquisa dedicada
(105 agentes, 23 fontes) refutou os candidatos óbvios (`greeking`, e usar
`skeleton screen` fora do sentido de estado-de-carregamento que já tem dono).
"Forma sem magnitude" é nome cunhado por esta skill; use-o sem hesitar, é a
etiqueta oficial da regra.

## 0. O mecanismo: placeholder sequencial fixo

Duas saídas óbvias falham, e entender por que elas falham é o que sustenta a
regra:

**Apagar o elemento** (`axis: null`, data label não emitido) mata a fidelidade:
o Horus BI sempre desenha eixo com gridline `#efefef` e sempre põe o data label
numa caixinha cinza, então o render deixa de parecer o produto.

**Trocar o número por uma faixa cinza** resolve a silhueta e carrega um problema
silencioso: a largura da faixa sai do comprimento do formato (`R$ 000.000,00`,
13 caracteres), ou seja, **ela já escolhe uma ordem de grandeza, só que
escondida.** Uma faixa de 90px afirma "centenas de milhares" com a mesma força
de escrever o número, e sem deixar ninguém auditar a escolha.

**A regra:**

> **O número aparece, em formato real, e é sempre o mesmo dentro do widget.**

`R$ 123.456,78`. `12,3%`. `1.234`. `1h 23m`. A sequência `1234567890` fatiada na
escala certa, repetida idêntica em toda barra, toda célula, todo card.

### Por que repetido é honesto, e variado não seria

É o mesmo motivo pelo qual o lorem ipsum funciona: **ele repete.** Uma frase de
latim solta no meio de um texto real lê como defeito; um bloco inteiro lê como
placeholder reconhecível. Vale igual para número.

Oito barras de alturas diferentes, todas rotuladas `R$ 123.456,78`, não podem
ser lidas como dado: o olho vê o padrão antes de ver o valor. As mesmas oito
barras com valores que variam junto com a altura seriam indistinguíveis de um
gráfico real, e aí sim a peça viraria promessa.

**Portanto o número nunca acompanha a forma.** A barra maior e a menor exibem o
mesmo rótulo. Isso parece errado à primeira vista e é exatamente o ponto: a
discrepância entre a altura e o rótulo é o que declara, sem legenda nenhuma,
que ali não há medição.

Comparado ao que veio antes, este formato ganha em três frentes:

1. **Ensina o formato real** que o widget vai ter: símbolo, separador de milhar,
   casas decimais, alinhamento. O slab escondia isso.
2. **Torna a ordem de grandeza auditável.** Ela continua sendo uma escolha, mas
   agora está escrita na tela e sujeita à heurística da §2b, em vez de embutida
   na largura de um retângulo.
3. **Não parece nem valor real nem widget quebrado.** `R$ —` lê como erro,
   `9.999.999` lê como valor, e a faixa cinza lê como carregando.

O que continua desenhado exatamente como o produto: eixo, gridline `#efefef`,
caixinha `#f6f6f6aa` de raio 5 do data label, célula, coluna `#`, header, linha
`Total`, e o slot do valor no card na tipografia escalada do `KpiV2`.

**O slab não morreu de todo.** Ele continua sendo a saída quando não existe
âncora nenhuma para escolher escala com honestidade (§2b, último caso).

## 1. A tabela renderiza / suprime

| Renderiza | Substitui pelo placeholder |
| --- | --- |
| tipo de gráfico | o valor medido do rótulo de eixo |
| nomes reais das categorias (exceto instância sensível/não confirmada — critério em §4) | o valor medido do data label |
| ordenação e forma relativa | percentuais e totais concretos |
| título, pergunta, corte, filtro | o valor do KPI |
| legenda, séries de combo, layout | o conteúdo numérico da célula |
| o formato completo (`R$`, `%`, milhar, decimais) | a variação entre um número e outro |

A última linha é a que define tudo: **o formato é forma e aparece por inteiro; a
variação entre valores é magnitude e some.** Por isso o placeholder é o mesmo em
todo o widget.

Leia a tabela por coluna, não por linha: cada renderiza/suprime da mesma
linha não são opostos um do outro necessariamente — são os dois lados
completos da fronteira. "Tipo de gráfico" e "escala do eixo Y" convivem no
mesmo widget: você desenha a barra (forma), mas o eixo dela não tem números
(magnitude). Um widget que suprime tudo da coluna direita e ainda assim
mostra tudo da esquerda **é o alvo**, não um meio-termo.

Dúvida recorrente: "mas se eu suprimir demais não sobra nada pra mostrar?"
Sobra — sobra a coluna inteira da esquerda, que é justamente o que o cliente
está aprovando nesta fase: que tipo de pergunta o dashboard responde, com que
recorte, em que ordem. Magnitude é a parte que **ainda não existe** (o dado
real chega depois da assinatura). Suprimi-la é honestidade sobre o que já se
sabe, e não economia de esforço.

## 2. A tabela de placeholders

Todo placeholder é uma fatia da sequência `1234567890`, na ordem, formatada no
padrão brasileiro. A sequência é o que faz o olho reconhecer o padrão; o formato
é o que ensina como o widget vai ficar.

### 2a. Monetário

| Escala | Placeholder |
| --- | --- |
| centenas | `R$ 123,45` |
| milhares | `R$ 1.234,56` |
| dezenas de milhares | `R$ 12.345,67` |
| centenas de milhares | `R$ 123.456,78` |
| milhões | `R$ 1.234.567,89` |
| dezenas de milhões | `R$ 12.345.678,90` |
| centenas de milhões | `R$ 123.456.789,01` |

### 2b. A heurística de escala

**Primeiro, o tipo decide se há escala a escolher:**

| Tipo | Placeholder | Escolhe escala? |
| --- | --- | --- |
| percentual | `12,3%` | não |
| percentual que passa de 100% (atingimento de meta) | `123,4%` | não |
| tempo em horas | `1h 23m` | não |
| tempo em minutos | `12m 34s` | não |
| tempo em dias | `1d 2h 34m` | não |
| contagem | `1.234` (sem decimal) | sim |
| monetário | tabela 2a | sim |

**Depois, para os dois que escolhem, use a âncora se ela existir.** Âncora é o
faturamento mensal aproximado do cliente, um número que o comercial já tem antes
de qualquer levantamento. Com ela:

| Métrica | Escala |
| --- | --- |
| receita ou custo no período da tela | a mesma ordem da âncora |
| a mesma métrica no ano | uma ordem acima |
| valor por unidade (ticket médio, valor por NF) | três ordens abaixo |
| contagem de documento no período | duas ordens abaixo |

**Sem âncora declarada, o default por tipo de métrica:**

| Métrica | Escala | Placeholder |
| --- | --- | --- |
| faturamento ou receita mensal | centenas de milhares | `R$ 123.456,78` |
| faturamento anual | milhões | `R$ 1.234.567,89` |
| custo ou despesa mensal | dezenas de milhares | `R$ 12.345,67` |
| ticket médio | centenas | `R$ 123,45` |
| preço unitário | dezenas | `R$ 12,34` |
| contagem de documento por mês | milhares | `1.234` |
| contagem de cliente ou fornecedor | centenas | `123` |

**E quando não existe âncora nem a métrica cai em nenhuma linha da tabela**, aí
não há escolha honesta de escala. Use o slab (a faixa cinza `#E2E8F0` de raio 5)
e registre a incógnita como pergunta para o cliente, via
[`marcadores-confianca.md`](marcadores-confianca.md). É melhor um widget com
faixa cinza e uma pergunta anexada do que uma escala inventada.

### 2c. Coerência dentro da tela

Duas regras que evitam que a peça se contradiga sozinha:

1. **Total fica uma escala acima das linhas.** Uma tabela cujas linhas mostram
   `R$ 12.345,67` e cujo rodapé `Total` mostra o mesmo valor lê como erro de
   soma. Com o total em `R$ 123.456,78`, a hierarquia se sustenta. A mesma regra
   vale para a `Matrix`: cada nível pai fica uma escala acima dos filhos.
2. **A mesma métrica usa a mesma escala em toda a tela.** Se "Receita" aparece
   num KPI, num gráfico e numa tabela, os três usam o mesmo placeholder. Escalas
   diferentes para a mesma métrica sugerem recortes que ninguém definiu.

### 2d. O que continua proibido

| Contexto | Veredito |
| --- | --- |
| placeholder da tabela 2a, repetido igual no widget | **é a regra** |
| valor que **varia** entre barras, linhas ou células | **proibido**: vira gráfico real |
| `9.999.999`, `000.000` ou qualquer cadeia de dígito repetido | **proibido**: lê como erro, e não ensina formato |
| `R$ ——.———` ou `R$ ###.###` | **proibido**: contar posição já afirma grandeza |
| `R$ —` ou `0` sozinho | **proibido**: lê como widget quebrado (§3) |
| número "orgânico" (`R$ 147.892,33`) | **proibido**: é dado aparente |

## 3. O placeholder no card de KPI

O big number de um KPI é o lugar de maior risco: é o primeiro elemento que o
olho ancora numa tela executiva, e é onde um valor plausível vira o número que
alguém vai cobrar depois.

Três soluções óbvias não servem:

- **Travessão nu (`—`) sozinho** lê como **quebrado**, e não como "pendente".
  Quem olha um card com `R$ —` acha que o widget deu erro. Some a massa visual
  que faz o layout comunicar hierarquia.
- **`9.999.999`** e qualquer cadeia de dígito repetido: a §2d fecha isso.
- **Faixa cinza sozinha** resolve a honestidade e perde a informação de
  formato, além de ler como "carregando" num print sem contexto.

### A fonte que pedia isto desde o começo

Vale registrar que a prescrição da IDEO, citada nas versões anteriores deste
arquivo como uma **divergência assumida**, hoje é convergência. Eles
recomendavam, para este mesmo problema, glifos com **massa visual de dígito**
(algo que ocupa o espaço como um número ocuparia) e rejeitavam explicitamente
zero e branco como placeholder, porque isso *"leave[s] nothing to
visualize"*.

A skill divergia disso por medo de que imitar dígito reintroduzisse a afirmação
de magnitude. O `R$ 123.456,78` repetido resolve os dois lados de uma vez: é
massa visual de dígito de verdade, com o formato completo, e ao mesmo tempo não
afirma magnitude nenhuma, porque **um número que não varia não mede nada**. O
que era divergência deliberada virou aplicação direta.

### O card segue o `KpiV2` do produto

O produto tem uma estrutura de KPI própria (`KpiV2.svelte:1279-1341`), e é ela
que o cliente vai receber. O template de conteúdo desta skill mapeia nos slots
| Slot do `KpiV2` | O que a skill põe ali | Quando |
|---|---|---|
| `overline` (`text-xs uppercase opacity-70`) | nome de negócio da métrica + recorte: `Receita Líquida — mês corrente` | sempre |
| valor (`font-medium`, 20 a 48px) | o **placeholder** da escala escolhida em §2b: `R$ 123.456,78` | sempre |
| `subtitle` (`text-xs opacity-80`) | direção, **sem número**: `▲ vs mês anterior` | só se a `mensagem:` da ficha declarar a direção |
| `helper` (`text-[10px] opacity-60`) | marcador de confiança em linguagem de cliente | conforme `marcadores-confianca.md` |
| sparkline | linha sem eixo e sem ponto rotulado | só se `relacao: tendencia-inline` |
| ring de progresso | não usar no mockup | nunca (ring codifica proporção medida, ver §5) |

O `subtitle` é onde o card falha na prática, porque parece pedir um número e
não pede. Se você está prestes a escrever variação percentual, delta, meta,
valor absoluto ou `+8% vs jun`, pare: **o que falta ali é medição, e não
espaço.** A seta já carrega tudo que a ficha autoriza afirmar; o número seria
invenção sua. E a direção não é sua para escolher — ela vem da `mensagem:` que
o analista escreveu, nunca do que ficaria bonito no card.

O ring de progresso fica de fora pelo motivo do parte-todo (§5): um arco
preenchido até certo ângulo **é** a magnitude, e esconder o número não desfaz
a afirmação.

### O risco que este formato assume, declarado

Um placeholder em formato perfeito **pode** ser lido como dado real por quem vê
um print isolado, sem o banner e sem o resto da tela. É um risco que a faixa
cinza não tinha, e ele é assumido em troca da fidelidade e da informação de
formato.

Três coisas seguram esse risco, e as três precisam estar presentes:

1. **A repetição**, que é a defesa principal. O mesmo número em toda barra e
   toda célula não sobrevive a dois segundos de leitura como dado.
2. **O banner** de dados ilustrativos, obrigatório em toda peça (§6).
3. **O marcador de confiança** por widget, em linguagem de cliente
   ([`marcadores-confianca.md`](marcadores-confianca.md)).

Um render que perca qualquer um dos três volta a ser promessa.

Uma ressalva contra o raciocínio "então quanto mais realista, melhor":
**Sauer & Sonderegger** (*Applied Ergonomics*, 2009, n=60) mediram que
avaliadores **superestimam** as qualidades de protótipos de baixa fidelidade, o
"deficiency compensation effect". O rascunho não é punido por parecer
inacabado. Ou seja: mais fidelidade numérica não é remédio contra
aprovação-carimbo, e não é essa a razão de o placeholder existir. Ele existe
para não parecer **quebrado** e para ensinar o **formato**, nunca para parecer
**real**.

**Alerta metodológico**, porque é fácil emprestar a estas duas fontes mais
autoridade do que elas têm: tanto a IDEO quanto Sauer & Sonderegger medem
**detecção de problema de usabilidade em teste com usuário** — nunca
**aprovação comercial vinculante por um cliente pagante**, que é o que
acontece na assinatura do termo. Extrapolar "isto ajuda a achar problema de
usabilidade" para "isto obtém aprovação vinculante" é **falso por
construção** — são fenômenos diferentes, medidos em populações diferentes, e
nenhuma das duas fontes cobre o segundo. O placeholder numérico e o semântico são
decisões de design desta skill, apenas *informadas* por essas fontes — não
replicações do que elas mediram.

Na `lumo-mockup`, único render do processo (a `lumo-scope` só escreve a ficha de
widget, nunca produz artefato visual algum), a mesma forma se materializa como
`mark: "text"` no spec Vega-Lite, com o placeholder como valor constante. O
mapeamento exato fica em [`ficha-para-vega.md`](ficha-para-vega.md).

## 4. Placeholder semântico de texto

Texto de célula (nome de fornecedor, cliente, produto, cidade) segue a mesma
lógica do número, com um ajuste: **placeholder semântico, não lorem ipsum.**

`Fornecedor A`, `Fornecedor B`, `Fornecedor C` é tão inconfundível quanto
latim solto — ninguém lê aquilo como o nome real de uma empresa — **e ainda
ensina o que a coluna contém.** Lorem ipsum não ensina nada sobre o domínio;
"Fornecedor A" ensina que a linha representa um fornecedor, o que ajuda o
cliente a validar a estrutura da tabela sem nenhum dado real na frente.

O contra-exemplo vem de uma tentativa real de mockup dentro do Lumo:
`Deutsche Schliesstechnik` apareceu numa célula de "fornecedor". É um nome de
empresa plausível — soa a fabricante alemã real, do tipo que aparece em uma
carteira de fornecedores de indústria — e **nome plausível vira dado
aparente**, exatamente a mesma falha do número plausível. Ninguém escreveu
"isto é fictício" em lugar nenhum daquela célula; o nome fez esse trabalho
sozinho, na direção errada. Regra geral: se o nome poderia estar num CNPJ de
verdade, ele já afirma dado demais para esta fase — troque por
`Fornecedor A`/`Cliente B`/`Produto C`, sempre com letra ou número
sequencial, nunca com um nome que soe a entidade real do mundo.

A mesma regra vale para qualquer coluna categórica de texto — cidade, SKU,
centro de custo, vendedor: prefira `Cidade A`, `SKU-001`, `Vendedor B` a
qualquer nome que passe no teste "isto poderia aparecer, sem alteração, numa
planilha real de um cliente deste setor".

**O critério que decide entre nome real e placeholder** (fecha a aparente
tensão com a linha "nomes reais das categorias" da tabela do §1): não é
"é texto ou é número" — é se a instância da categoria identifica uma
entidade específica, sensível ou ainda não confirmada. Categoria cuja
instância é conhecida, pública e não liga a uma pessoa física — nome de
loja, cidade, canal de venda, categoria de produto — renderiza o nome real;
é forma tanto quanto o tipo de gráfico (`wireframe-kit.md` já pede "nomes
de negócio REAIS em todo título"). Categoria cuja instância identificaria
uma pessoa física, um cliente ou fornecedor nomeado, ou que ainda não foi
confirmada com o cliente, usa placeholder semântico — mesmo que a dimensão
em si (`dim_vendedor.nome`) seja perfeitamente conhecida; o que muda não é
a dimensão, é a sensibilidade/individualidade da instância. No gabarito
canônico da `lumo-scope`
(`exemplo-canonico/escopo/dashboards/vendas-executivo.md`): `Loja Sul`,
`Loja Centro`... são nomes reais (loja é canal público, mesma lógica que
libera nome de local em `ficha-para-vega.md` §1.9); `Vendedor A`,
`Vendedor B`... são placeholder (nome de vendedor identifica pessoa
física).

## 5. Os casos difíceis, honestamente

### Parte-todo (donut)

Este é o caso onde a fronteira dói mais, porque a supressão de rótulo **não
basta**. Um donut sem data label ainda tem um ângulo — e o ângulo, por
construção, é a magnitude. Diferente de uma barra ranqueada (onde comprimento
sem eixo numérico só afirma ordem relativa, que é forma), o gráfico de
parte-todo **codifica proporção na própria geometria**: tirar o número não
tira a afirmação, só esconde de que número exatamente se trata.

A trava que resolve isso é numérica e vem do escopo, não do gosto:

> **Até 4 categorias → `Pie` com `innerSize: "60%"`. Sempre donut, nunca
> pizza sólida.**
> **5 ou mais → `Barline` horizontal ordenada.**

Sem exceção, nem quando o dashboard de referência do cliente usa pizza. Os
prints de produção justificam a trava sozinhos: "Vendas por Tipo" tem 16
fatias e "Faturamento por Ramo" tem 12, ambos ilegíveis mesmo com os números
todos na tela.

Como a trava resolve a fronteira nos dois lados:

1. **Com até 4 fatias**, o ângulo ainda afirma proporção, então o widget entra
   marcado como ilustrativo (banner da seção 6, mais o marcador de confiança do
   widget). Isso é aceitável porque o que se vende ali é "existe uma repartição
   entre estas quatro categorias", nunca "esta fatia vale tanto". Com quatro
   fatias o cliente lê categorias, e não medida.
2. **Com 5 ou mais**, a barra horizontal é forma pura: comprimento relativo
   comunica ordem sem comprometer valor, porque nada obriga o olho a
   interpretar o comprimento como fração de um todo específico. O eixo de
   magnitude leva o placeholder no rótulo, como todo o resto.

O gate roda contra o número de categorias que a `lumo-scope` já escreveu na
ficha, então não depende de dado real nenhum.

### Tabela

A tabela estressa a fronteira em duas dimensões ao mesmo tempo — colunas
numéricas e colunas de texto — e é fácil resolver uma e esquecer a outra.
A combinação das seções 2 e 4 fecha o caso por completo:

- **Colunas numéricas**: o mesmo placeholder em todas as linhas da coluna. A
  repetição é o que faz o olho ler "coluna de valores pendentes" em vez de
  "valores"; valor variando linha a linha reintroduziria magnitude relativa pela
  porta dos fundos.
- **Colunas de texto**: placeholder semântico sequencial (`Fornecedor A`,
  `Fornecedor B`...), nunca nome plausível.
- **Coluna `#`, header e linha `Total`**: continuam desenhados normalmente. A
  numeração sequencial da coluna `#` é forma (ela existe na tabela real e não
  reporta nada sobre o dado). O valor do `Total` usa o placeholder **uma escala
  acima** do das linhas (§2c), senão a tabela lê como erro de soma.
- **Coluna de razão não tem `Total` somável.** Percentual, margem, ticket médio
  e conversão não somam: o rodapé daquela coluna leva o placeholder da **mesma**
  escala das linhas (porque o total é recomposto dos componentes, não somado),
  ou fica vazio se a ficha não declara total para ela. Um rodapé `Total` com
  `123,4%` embaixo de uma coluna de percentuais promete uma agregação que a
  plataforma não vai fazer, e é a versão em mockup do erro que
  `lumo-design:references/aditividade.md` existe para impedir. A classe vem do
  campo `aditividade:` da ficha da métrica.
- **Heatmap de célula**: o produto pinta a célula em escala azul conforme a
  magnitude (`Gerencial`, `Rastreamento Veicular`). Isso **é** magnitude
  codificada em cor, então no mockup a célula fica sem preenchimento. Se a
  ficha quer vender o heatmap como recurso, use a `mensagem:` do widget para
  dizer isso em texto.
- **Ordenação das linhas**: pode — e deve — ser real, se a ordenação for a
  forma que está sendo vendida (ex.: "esta tabela vem ordenada por maior
  valor primeiro"). Ordenação é forma (seção 1, coluna esquerda), não
  magnitude; o que não pode acompanhar a ordenação real são os valores reais
  que a justificariam.
- **Contagem de linhas**: mostre um número pequeno e representativo (o
  bastante para preencher o espaço do grid), nunca um número que pareça
  reportar o volume real de linhas do cliente — 5 linhas de exemplo não
  afirmam "a tabela final terá 5 linhas", mas escolher exatamente a contagem
  real conhecida (se por acaso for conhecida) já seria vazamento de
  magnitude por outra porta.

Widget de KPI dentro de tabela (ex.: uma coluna "variação %") segue a seção 3,
não esta seção — é big number, não célula.

## 6. Perspectiva artística, não foto — e o banner de dados ilustrativos

A analogia que fecha o conceito vem de arquitetura e incorporação, indústria
que resolveu este mesmo conflito há décadas: um render de apartamento é
lindo, vende a unidade, e ninguém acha que está comprando aqueles móveis
específicos — porque existe convenção explícita, sempre visível na peça:
*"perspectiva artística ilustrada"*, *"móveis não inclusos"*. **É a convenção
que libera o artefato para ser bonito sem virar promessa.**

O mockup desta skill é uma perspectiva artística, não uma foto do dashboard
final. Isso não é a segunda etapa de um fluxo em duas fases — não existe mais
um wireframe grayscale anterior a este render: a `lumo-scope` só escreve a
ficha de widget (`dashboards/*.md`), nunca produz artefato visual algum, e o
único render do processo é este, desde o início.

A `lumo-mockup` produz um render bonito, com marca, tipografia e gráfico de
verdade — porque a peça que sai daqui alimenta uma proposta comercial e,
adiante, um termo que alguém **assina**. Um documento que vai ser assinado
não pode parecer provisório; a tese de que "estética rascunhada gera crítica
melhor" é anedótica por confissão dos próprios autores que a formularam
(Landay & Myers, SILK, CHI '95, chamam o próprio argumento de *"anecdotal
evidence"*) e não se sustenta aqui.

Ou seja: esta skill não pede desculpas pela beleza do render, nem tenta
parecer inacabada para convidar crítica. A honestidade sobre o que ainda não
se sabe não vem de deixar o artefato feio — vem da convenção explícita: todo
artefato desta skill carrega um marcador visível, análogo à legenda do
apartamento, dizendo que a forma é real e a magnitude não é. Em termos
práticos, isso é um banner (ou equivalente) sempre presente no artefato,
declarando algo como *"dados ilustrativos — a forma reflete a proposta, os
valores não refletem o cliente"*, na mesma família do `.wf-banner` /
`.wf-fictitious` já usados no exemplo canônico da `lumo-scope`, adaptado ao
registro comercial/termo desta skill (linguagem de cliente, nunca a etiqueta
técnica crua — ver `references/marcadores-confianca.md` §4 para o
vocabulário exato).

Este banner é também o que sustenta, mais adiante no processo, a regra de
que **o que vincula é a especificação da ficha, não a figura do render**:
ajuste de forma decorrente do dado real, quando o projeto avança, não é
mudança de escopo. Essa redação de contrato mora no termo de abertura da
`lumo-scope`; aqui o que importa é que o banner é a peça que torna aquela
cláusula plausível — sem ele, qualquer aumento de fidelidade visual viraria
dívida de expectativa.
