# Exemplo canônico — Distribuidora Vale Sul (fictícia)

**"Distribuidora Vale Sul" não existe.** É uma empresa fictícia de atacado/
distribuição (ERP Sankhya, também fictício no papel de fonte) criada só para
este exemplo. Nenhum dado, nome ou número aqui é de cliente real.

Não é um projeto pra copiar campo por campo — é a **régua de densidade**. Antes
de considerar um artefato pronto, compare o que você escreveu com o arquivo
equivalente aqui. Se o seu arquivo tem menos densidade que o equivalente, ele
não está pronto — não é estilo, é o piso de qualidade que esta skill exige.

Este gabarito demonstra a **camada de confiança** (`confianca: confirmado |
hipótese | a-perguntar`, ver `../incognitas.md`) e o **registro de incógnita**
— não o antigo fluxo de 5 fases com gates bloqueantes. É um documento vivo
propositalmente incompleto: nem todo campo estrutural é `confirmado`, e as
lacunas que restam viram registro rastreável em `escopo/incognitas.md`, nunca
`[TBD]` solto ou nota de rodapé.

| Você terminou... | Compare com | O que procurar |
|---|---|---|
| um grain de processo | `escopo/processos/faturamento.md` | é uma FRASE testável, com "por que este grain"; o `grain:` do frontmatter é objeto (`frase`/`confianca`/rastro), não string solta |
| dimensões com confiança mista | `escopo/processos/faturamento.md` | 2 de 5 dimensões `confirmado` (com `validado_por`/`validado_em`/`canal`/`evidencia`), 3 em `hipótese` (com `origem`) — mix realista, não 100% validado |
| um bloco de evidência | `escopo/tabelas/fact_pedido_item.md` | formato Decisão → Teste → Resultado → Status, nunca só "validado" solto; `confianca: confirmado` no frontmatter aponta pra essa tabela como rastro |
| um KPI card aditivo | `escopo/metricas/receita-liquida.md` | todos os campos do template atual preenchidos (`decisao_associada`, `camada`, `mask`, `aviso_apos`/`sla_cliente`), `owner` é PESSOA nomeada, `confianca: confirmado` com os 4 subcampos de rastro |
| um KPI card não-aditivo | `escopo/metricas/ticket-medio.md` | par didático da receita — note a seção `# Notas` avisando a armadilha de somar razão |
| um registro de incógnita | `escopo/incognitas.md` | 8 campos fixos preenchidos por registro; mistura `dono: cliente` (vira `pergunta_cliente`) e `dono: precisa-acesso-banco` (resolve por profiling, nunca pergunta ao cliente) |
| uma lineage | `escopo/lineage.md` | mermaid table-level + STM coluna a coluna, só dos CDEs (não o schema inteiro); coluna com incógnita aberta aponta pro registro em `incognitas.md` |
| um app (o cubo) | `escopo/apps/vendas.md` | `relationships` copiados de `lineage.md` — mas só 4 de 5 batem 1:1 no STM (calendário é inferido por convenção, sem chave explícita no lineage, e vira registro em `incognitas.md`; ver bloco "Evidência do cubo" com as duas linhas separadas); `razao_rel_tabela` calculada por extenso (0,83 — 5 relationships / 6 tabelas), não um número solto; a estratégia `star` justificada contra os sinais de escalada de `limites-horus.md`, não afirmada sem prova; confiança mista — `confirmado` com bloco de evidência do cubo + 1 `hipótese` com `origem` sobre migrar para `fato-mestre` se "Estoque/ruptura" virar 2º fato |
| uma ficha de widget | `escopo/dashboards/vendas-executivo.md` | `encoding`/`mensagem` nunca vazios; cada ficha tem `confianca:` (widget 4 fica `hipótese` de propósito — critério de top-N ainda não fechado); ficha 2 mostra `tendencia-inline` (sparkline no KPI); ficha 5 mostra a skill flagrando e corrigindo um pedido inválido |
| um wireframe | `escopo/wireframes/vendas-executivo.html` | segue o kit da skill `lumo-mockup` à risca: banner de dados ilustrativos, trilho de anotações, selo SVG por `relacao` no cabeçalho (não mais o conteúdo do corpo), corpo do widget = gráfico Vega-Lite real com o tema Horus (ou slab neutra pro KPI — nunca `R$ —` nem valor plausível); ver `llms/lumo-mockup/references/wireframe-kit.md` para o kit completo |
| uma linha de fora-de-escopo | `escopo/fora-de-escopo.md` | motivo + custo em tiers, nunca só "não incluído" |
| um item de aceite | `escopo/aceite.md` | termina em comando `lumo` real, nunca "dados devem bater"; pendência de RLS aponta pro registro em `incognitas.md`, nunca um `[A CONFIRMAR]` solto |

## Como usar

1. Ao terminar um artefato do bundle real do cliente, abra o arquivo equivalente
   aqui lado a lado.
2. Pergunte: "o meu tem a mesma densidade de campo, ou só tecnicamente tem os
   campos?" Um `owner: "o comercial"` passa num checklist binário; não passa
   aqui. Mesma pergunta vale pra confiança: um campo `hipótese` sem `origem`,
   ou um `confirmado` sem os 4 subcampos de rastro, não passa aqui.
3. Este bundle é deliberadamente pequeno (1 processo, 1 dashboard, 2 métricas,
   5 incógnitas) — a régua é sobre profundidade por artefato, não sobre
   cobertura do projeto inteiro.

Ver `../../SKILL.md` e as demais `references/` para o processo completo que
produz um bundle como este — não há mais fases numeradas com gate bloqueante;
o checkpoint de revisão adversarial em `validacao-adversarial.md` é opcional.
