# Anti-portfólio, e como vestir hipótese pro cliente

## Conteúdo

- Como vestir hipótese pro cliente
- Anti-portfólio — casos que geraram as regras

Duas referências curtas e distintas. **Anti-portfólio**: casos reais de "o que
NÃO fazer" — o custo concreto de um atalho que já foi tomado, para embasar uma
recomendação com "isso já aconteceu" em vez de "é a regra". **Vestir
hipótese**: como uma decisão ainda em `hipótese`/`a-perguntar`
(`references/incognitas.md`) aparece pro cliente sem virar jargão interno nem
parecer trabalho inacabado — sem confronto, sem sermão, na linha de
`references/entrevista.md` (opinionada, argumenta uma vez, registra e segue).

## Como vestir hipótese pro cliente

A etiqueta de confiança (`confianca: hipótese`, `confianca: a-perguntar`) é
vocabulário do bundle — útil para o analista e para o lumo-cli, ilegível para
o cliente. Regra 1 relaxada permite construir em cima de hipótese; o que muda
pro cliente é a roupa, e não o conteúdo: a etiqueta crua nunca atravessa para
o wireframe ou o PDF sem virar linguagem de negócio — o vocabulário e a forma
exata do marcador vestido (por nível de confiança e por vista) são da
`lumo-mockup` (`lumo-mockup:references/marcadores-confianca.md`); este
arquivo só ensina o padrão de frase pro cliente.

**Nunca mostre a etiqueta crua.** `confianca: hipótese`/`a-perguntar` não
aparece, literalmente, no material que o cliente lê — nem sequer como o
colchete `[hipótese: churn = cancelamentos/base ativa]` (convenção antiga já
aposentada). No material que o cliente lê, a mesma informação vira algo como
*"Proposta inicial de definição de churn: cancelamentos sobre base ativa — a
validar com você"*. A etiqueta `a-perguntar` vira uma pergunta explícita
endereçada ao cliente, nunca um espaço em branco nem um placeholder mudo.

**Padrão de frase, três peças:**
1. O que a skill está assumindo, em linguagem de negócio (sem sigla, sem termo
   Kimball).
2. Que é ponto de partida, não fato fechado — "proposta inicial", "sugestão
   para validação", "a confirmar com você" no lugar de "hipótese".
3. Onde/como isso se confirma, quando fizer sentido dizer (call de validação,
   exemplo real, etc.) — sem prometer prazo que a skill não controla.

**Exemplos:**
- Cru (bundle): `grain: { frase: "um item de cada pedido", confianca:
  hipótese, origem: "padrão do vertical varejo" }`
  Vestido (cliente): *"Sugerimos tratar cada item de pedido como a menor
  unidade analisada (proposta inicial, comum no varejo) — confirmamos isso com
  vocês antes de fechar o desenho."*
- Cru (bundle): métrica com `confianca: a-perguntar`, `pergunta_cliente: "Um
  pedido cancelado deve contar na receita?"`
  Vestido (cliente): a mesma pergunta, verbatim, numa lista de "Pontos a
  confirmar com você" — nunca escondida dentro de uma fórmula já fechada.

**O que NÃO fazer:** apresentar hipótese como se fosse fato validado (o
cliente assina sem saber que é suposição); ou, no sentido oposto, encher o
documento de ressalvas técnicas ("confiança: hipótese, origem: destilação
heurística") que soam a desculpa em vez de proposta. O tom é sempre de quem
já pensou no problema e está checando, não de quem está com dúvida.

A mecânica de onde essa "roupa" entra no documento (bundle OKF vs PDF do
cliente) vive em `references/documento-template.md`.

## Anti-portfólio — casos que geraram as regras

Cite ao recuar uma racionalização: "isso já aconteceu" pesa mais que "é a
regra". Append-only; adicione casos novos com a mesma estrutura (o que foi
pulado → o que quebrou → custo → regra que gerou).

### #grain-descartado — caso real (anonimizado)
**Pulado:** decisão de quais chaves de negócio da origem sobrevivem ao ETL — a
dimensão de estabelecimentos nasceu só com `ID` surrogate; `EST_ID` da origem
foi descartado.
**Quebrou:** no primeiro join para widget, descobriu-se que a chave não existia;
schema congelado na criação.
**Custo:** descartar a tabela e reconstruir o flow do zero.
**Regra:** `chave_negocio` obrigatória em tabelas/*.md + grain check com
evidência (fase de fonte).

### #encoding-nunca-especificado — caso real (anonimizado)
**Pulado:** datalabels, legenda e formato dos widgets nunca especificados; o
dashboard foi declarado "pronto" só com preview de dados.
**Quebrou:** o usuário rejeitou na hora ao VER o gráfico ("tá muito feio,
melhore com datalabels, legenda etc").
**Custo:** ciclo de correção pós-entrega + "push especulativo" de ~10 configs
sem documentação para descobrir o que o servidor aceitava.
**Regra:** `encoding` obrigatório em toda ficha de widget; vazio é achado
Crítico na revisão / no checkpoint (Gate B).

### #acao-sem-contrato — caso real (anonimizado)
**Pulado:** não havia escopo escrito delimitando o que fazer a seguir.
**Quebrou:** o agente publicou flows e exportou sem ninguém pedir — na ausência
de contrato, "decidiu sozinho" o próximo passo.
**Custo:** recursos publicados (readonly, compartilhados) sem decisão humana.
**Regra:** o bundle aprovado é a referência que a execução consulta antes de
qualquer ação expansiva; publish nunca é iniciativa do agente.

### #constellation — caso real (anonimizado, reconstruído)
**Pulado:** limite de relacionamentos por app — a modelagem virou
"todas-com-todas": 58-61 relationships sobre 25-27 tabelas (2,3 por tabela),
uma dimensão central ligada a 20 tabelas e o Calendário fazendo ponte entre 5
fatos.
**Quebrou:** o gerador automático de queries propagou filtros com fanout —
números inesperados sem nenhum erro na tela; 11 versões do mesmo app tentando
consertar na camada errada.
**Custo:** reconstrução completa — um fato mestre (44 colunas: 3 processos
unificados por UNION com coluna de estado, denominadores de razão como colunas,
flags de dedup, KPIs canônicos como expressions da tabela). A geração nova roda
com 1,0 relacionamento por tabela.
**Regra:** `limites-horus.md` — teste do grafo (fato-hub, dimensão grau 1) +
sinais de fato mestre na entrevista; o checkpoint (Gate A/B), se acionado,
checa a topologia.

### #metricas-de-catalogo — padrão observado em teste controlado (baseline desta skill)
**Pulado:** elicitação; o agente atendeu "monta o padrão de dashboard de vendas".
**Quebrou:** 16-19 métricas inventadas com fórmula, cronograma fictício de "12
dias úteis" e "FATURADO como padrão" em nota de rodapé — documento inteiro
pronto para o cliente assinar sem UMA pergunta feita.
**Custo (evitado):** cliente assinando números que ninguém definiu.
**Regra:** tabela de racionalizações do SKILL.md + elicitação antes de
qualquer documento.

### #estetica-junto — padrão observado em teste controlado (baseline desta skill)
**Pulado:** separação estrutura/estética; "aprovar layout e estética de uma vez
pra não voltar nisso".
**Quebrou:** mockup dark com dourado, gauge e pizzas, com campo de assinatura —
diretoria aprovaria um visual que a lumo-design ainda não desenhou sobre dados
reais, e números "internamente consistentes" que virariam promessa.
**Custo (evitado):** renegociação política de algo "já aprovado".
**Regra:** mockup com forma sem magnitude (gráfico Vega-Lite sóbrio, tema
institucional Horus — skill `lumo-mockup`) e KPI em slab neutra; a estética
do DASHBOARD ENTREGUE, com dado real, continua sendo fase da lumo-design,
decidida depois; assinatura só no documento de escopo completo.
