# Entrevista — elicitação por hipótese, 4 modos de interação, KPI card

## Quando não há ninguém do outro lado

Os 4 modos abaixo pressupõem alguém respondendo em tempo real. Boa parte do
trabalho começa antes disso: uma anotação de call já encerrada, uma transcrição,
uma proposta antiga, um e-mail. Nessa situação **nenhum dos 4 modos se aplica**,
e forçar um deles produz pergunta que ninguém vai ler.

O protocolo para material morto:

1. **Esgote o insumo primeiro** (`ingestao.md`): tudo que o material prova entra
   como `confirmado`, com a citação como evidência.
2. **O que o material sugere mas não prova vira `hipótese`**, com a inferência
   escrita. "Ele falou em custo por viagem" prova que existe uma noção de custo
   por viagem; não prova o grão, nem a fonte, nem a fórmula.
3. **O que falta vira `a-perguntar` com dono-pessoa nomeado**, e alimenta a lista
   de Perguntas para o Cliente. É aqui que os 4 modos voltam a valer: eles
   descrevem *como* perguntar quando a próxima conversa acontecer.
4. **O grão é sempre o primeiro `a-perguntar`**, mesmo quando o material sugere
   um. Grão errado descobre-se tarde e caro.

Um bundle que sai de material morto é legítimo e útil: ele é a pauta da próxima
call, não um rascunho pela metade. O que o desqualifica é hipótese fingindo ser
fato, não a quantidade de `a-perguntar`.

## Conteúdo

- O que este arquivo aposenta
- Os 4 modos de interação, escolhidos por risco
- Elicitação por exemplo primeiro
- Regra de campo de pessoa — texto livre, nunca `AskUserQuestion`
- Ordem sugerida — não é fase que bloqueia
  - Contexto de negócio
  - Por processo de negócio — o motor Kimball
- KPI card (`metricas/<nome>.md`, um arquivo por métrica)
- Recap antes da aprovação — nunca só "abre e olha"
- Taxonomia de armadilhas de BI — checklist de qualidade opcional

Este arquivo entra em cena **depois** da ingestão (`ingestao.md`): a skill já
esgotou documentos e pesquisa web, já rotulou tudo que conseguiu hipotetizar
sozinha, e ainda sobra alguma coisa que só o analista responde. O que segue
não é um roteiro de perguntas lido de cima a baixo — é um contrato de
interação com 4 modos, escolhidos por risco, mais a ordem sugerida de
elicitação por processo de negócio (Kimball). Consome o vocabulário de
`incognitas.md` (`confirmado`/`hipótese`/`a-perguntar` + schema do registro
de incógnita) — leia aquele arquivo primeiro se ainda não leu.

## O que este arquivo aposenta

Esta é uma reescrita total do roteiro inquisidor anterior. Comparado à
versão antiga deste arquivo, ficam explicitamente fora:

- **Protocolo anti-vago com script de confronto e no máximo 2 tentativas** —
  resposta vaga não dispara mais um script de confronto nem duas rodadas de
  reformulação/contraexemplo; vira `hipótese` ou `a-perguntar` direto (modo
  REGISTRA e anda, abaixo).
- **Reabertura retroativa de vagos** ("vago antigo não prescreve") — pedir
  para acelerar ou seguir para o mockup não reabre as respostas vagas de
  rodadas anteriores; elas já viraram registro, e registro não se cobra de
  novo, se atualiza.
- **Contagem das 14 armadilhas como condição de fechamento** — a taxonomia
  de armadilhas de BI continua útil, mas vira checklist de qualidade
  *opcional*, no fim deste arquivo — nunca uma contagem que precisa bater
  para a sessão seguir.
- **Linguagem de "não fecha o processo" / "trava a fase"** — nenhuma
  resposta, vaga, ausente ou parcial, impede a sessão de continuar. O que
  muda é a etiqueta de confiança do campo, nunca o andamento da conversa.
- **`[A CONFIRMAR]` como bloco YAML próprio com orçamento** (≤1 decisão
  estrutural por processo, ≤30% do inventário) — substituído pelo registro
  de incógnita sem orçamento de `incognitas.md`.
- **Exigir `porque_serve:` do analista a cada aceite de recomendação** — a
  skill não pergunta mais "por que essa opção serve pro seu caso?" toda vez
  que o analista aceita uma sugestão (isso era interrogatório de aceite
  performático). O valor original — não deixar "ok, pode ser essa mesmo"
  virar decisão estrutural sem textura — sobrevive só nas decisões PERGUNTA
  de verdade (grão/chave/tipo de carga/RLS, abaixo): ali a própria skill
  **redige** a linha `porque_serve:`, não pergunta de volta.

## Os 4 modos de interação, escolhidos por risco

A skill não pergunta tudo do mesmo jeito. A cada campo que falta, ela
escolhe um dos 4 modos — pelo risco de errar, não pela fase em que está:

**AGE + MOSTRA (default).** Para a maioria dos campos, a skill escreve a
hipótese direto no bundle e mostra para reação, em vez de abrir uma
pergunta: *"assumi SCD2 aqui porque a métrica é reportada por período —
confere ou corrijo?"*. É reação a um rascunho concreto — sempre mais rápida
de responder que uma pergunta aberta — e o campo já nasce com
`confianca: hipótese` e uma `origem:` (o porquê da suposição), então o
documento anda mesmo sem resposta imediata.

**PERGUNTA de verdade.** Reservada para o que é **caro de errar E não tem
default defensável** — grão, chave de negócio, tipo de carga (load type),
RLS. São as decisões que congelam schema de tabela DW: errar aqui é
drop+recreate+reload, não um ajuste de rascunho. Só nesses casos a skill
insiste de verdade, com pergunta objetiva e a recomendação já declarada
(`calibracao-qualidade.md`) — mas insistir é reformular ou trazer o custo
concreto de errar, nunca é confrontar. Quando a resposta fecha uma dessas
decisões estruturais, **a skill mesma redige** a linha
`porque_serve:` no campo — uma frase curta de por que
aquela escolha serve PRO CASO deste cliente, não a genérica — a partir do
que o analista respondeu; não é uma pergunta extra de volta pra ele.

**SEGUE A DEIXA.** A skill nunca recusa um pedido de avançar por causa de
uma pendência. "Pula pro mockup" → ela pula, com as hipóteses que já tem,
cada widget renderizado com o marcador de confiança vestido do mockup —
nunca a etiqueta crua, sempre visível, nunca escondido (forma do marcador
por nível/vista em `lumo-mockup:references/marcadores-confianca.md`).
"Isso a gente vê depois" → vira registro `a-perguntar` em `incognitas.md`
(com `dono` e `gatilho`) e a conversa segue para o próximo assunto. Pedir
para acelerar produz aceleração, não uma lista de motivos pelos quais ainda
não dá.

**REGISTRA e anda.** Resposta vaga não é resposta, mas também não é convite
a insistir: vira `hipótese` (se dá pra defender um valor plausível) ou
`a-perguntar` (se não dá), com uma frase curta explicando por que ficou
vaga, e a conversa segue. Termos-gatilho de resposta vaga — "visibilidade",
"eficiência", "o de sempre", "tanto faz", "você decide", "usa o padrão",
"sei lá", "tudo que for válido", "nada especial", "a diretoria", "o
comercial", "TI" — continuam úteis como sinal de que o campo ainda não virou
decisão; a diferença é o que a skill faz ao notar um: registra e segue, não
dispara um roteiro pra arrancar mais precisão. Admissão honesta de incógnita
— "não sei ainda", "não sei / preciso confirmar", "marca como pendência",
"realmente não sei" — é o caso mais limpo de `a-perguntar` (a resposta não
existe ainda, ninguém sabe): registra com `dono` + `gatilho` e segue na
hora, sem uma única repergunta — foi este loop de reperguntar o "não sei"
que esgotou a sessão real que originou este redesenho. Réplicas prontas para
pushback do analista (reconhecer a intenção, dar o custo concreto, oferecer
o caminho rápido — nunca sermão): `objecoes.md`. **Confusão ≠ vago**: se o
termo genérico vem de não entender a pergunta ("não sei o que é isso", "por
que isso importa?"), ensine primeiro (`didatica.md`, ≤5 linhas) antes de
registrar — clareza vale mais que registro apressado.

O opinativo continua de pé nos 4 modos: a skill recomenda com o porquê,
argumenta uma vez se o analista diverge de uma escolha ruim, e então registra
a divergência (`recomendacao_dada`/`escolha_analista`/
`divergencia_da_recomendacao`, ver `calibracao-qualidade.md`) e segue — o
que sai é o poder de travar a conversa, não a opinião.

## Elicitação por exemplo primeiro

Antes de pedir para o analista formular grão e dimensões em abstrato —
exercício que emperra até analista experiente — peça um caso real:

> "Me conta UM [evento de negócio] real e recente, com nomes e números de
> verdade: quem participou, o quê, quando, onde, quanto, por quê, e como
> vocês identificam esse registro no sistema?"

A resposta é narrativa, não formulário — e dela a skill **deriva** grão e
dimensões como hipóteses (modo AGE + MOSTRA), em vez de exigir que o
analista já chegue com a frase de grão pronta: *"pelo que você contou, uma
linha = um item do pedido — é isso, ou vocês pensam por pedido inteiro?"*.
O checklist quem/o-quê/onde/quando/quanto/por-quê vira verificação de
**lacuna** no que a narrativa não cobriu — nunca uma segunda rodada de
perguntas fechadas —, incluindo "quem MAIS participa: aprovou, indicou,
recebeu?" (papéis que uma pergunta fechada sobre um único ator não revela).
Para cada papel candidato a dimensão, o teste de multivalor continua
valendo como mecânica de detecção, sem virar interrogatório: "este papel
tem 1 valor por linha do fato, ou vários (ex.: 2 vendedores na mesma
venda)?" — se vários, é relação N:N e vira hipótese de bridge table com
campo `peso`, mostrada, não perguntada em aberto.

Os defaults por trás de cada hipótese derivada (grão mais atômico que a
fonte aguenta, reuso de dimensão conformada, SCD2 quando o atributo muda e
participa de métrica por período, RLS restritivo por omissão) já estão
descritos com o porquê em `calibracao-qualidade.md` — este arquivo não os
repete, só define que eles chegam ao analista como hipótese mostrada, nunca
como pergunta em aberto.

## Regra de campo de pessoa — texto livre, nunca `AskUserQuestion`

Todo campo de pessoa do bundle (owner de métrica, aprovador, dono de
incógnita, RACI) **exige nome próprio**, e esse nome se captura em **texto
livre**, nunca com `AskUserQuestion` — a ferramenta exige ≥2 opções, e nome
próprio não tem opções: é o único bug de implementação que este arquivo
corrige (caso real, PADO: a skill inventou opções falsas pra preencher o
menu obrigatório e gastou 4 rodadas / ~7 min pra capturar um nome que o
analista já sabia de cabeça). A pergunta certa é aberta e simples: "quem é o
dono disso — nome e cargo?". Se a resposta vier genérica ("o comercial", "a
diretoria", "o cliente"), isso é resposta vaga, não campo preenchido: modo
REGISTRA e anda, vira `a-perguntar` com `dono` apontando pra quem resolve.

## Ordem sugerida — não é fase que bloqueia

A ordem abaixo é o roteiro Kimball que a skill segue **quando não há
sinalização em contrário**; SEGUE A DEIXA pode pular, reordenar ou compactar
a qualquer momento — a ordem organiza a conversa, não a trava.

### Contexto de negócio

Poucas perguntas de baixo atrito, cada uma pelo modo que o risco pedir — a
maioria já chega pré-preenchida como hipótese pela ingestão (`ingestao.md`)
e só precisa de reação (AGE + MOSTRA):

- Cliente e segmento → carrega o pacote de `verticais/index.md` (soma
  armadilhas, nunca substitui a taxonomia genérica).
- Existe relatório/planilha hoje? A resposta se cruza depois com o schema
  real na fase de fonte — view com cara de relatório não mencionada aqui
  vira hipótese a revalidar, não bloqueio.
- Qual dor de negócio justifica o projeto — pergunta de verdade, porque não
  tem default: sem ela o resto do escopo não tem pra onde apontar. Resposta
  vaga aqui é candidata natural a REGISTRA e anda (os termos-gatilho da
  seção de modos), não a insistência repetida.
- Quem aprova o escopo — PESSOA e cargo, sempre texto livre (regra acima).
  Vale testar a força do patrocínio no mesmo fio: "você fala direto com ele
  ou por intermediário? Ele já bancou uma decisão sozinho neste projeto?" —
  sinal fraco vira risco registrado (Kimball: ~60% do peso de prontidão de
  um projeto de BI), nunca bloqueio.
- Quantos dashboards e o público de cada um (executivo/operacional/analista
  → `arquetipos-dashboards.md`), incluindo acessibilidade (baixa visão,
  daltonismo, leitor de tela, tela fixa) — se o cliente for órgão público
  com requisito legal (LBI) e pedir para tirar isso do escopo, é risco
  LEGAL a registrar, não preferência estética.

O modo de trabalho do analista — transcrevendo o que já sabe, preparando
call (a saída vira roteiro de perguntas), ou híbrido — é uma pergunta de
calibração, não uma etapa: não a use pra adiar a conversa real. No modo
"preparando call", o roteiro entregue segue o rodapé de condução Kimball:
não manda a lista inteira antes (só o tema, 3 linhas); começa pela gerência
intermediária, não pelo topo nem pela base; executivo sozinho na sala; no
máx. 3-4 sessões por dia; fecha perguntando "o que tornaria isso um sucesso
pra você", em termos mensuráveis.

### Por processo de negócio — o motor Kimball

Um processo por vez (uma linha do bus matrix). Se a dor de negócio já
mencionou prazo/atraso/SLA/lead time/ciclo, pergunte antes do grão: "esse
evento acontece num momento só, ou passa por etapas com data própria cada
uma (pedido→separação→faturamento→entrega)?" — evoluindo por etapas, monte
a Timeline de marcos (nome + coluna de data candidata) e proponha (AGE +
MOSTRA) `tipo_fato: snapshot-acumulativo`; sem marcos nomeados, acumulativo
é grão-lista disfarçada.

1. **Processo** — "que evento de negócio estamos medindo?". Descrição
   misturando dois processos vira duas linhas do bus matrix — mostre a
   divisão como hipótese, não pergunta.
2. **Grão** — deriva da elicitação por exemplo acima; a skill mostra a
   frase (*"uma linha = um item de cupom fiscal"*) para confirmação. Grão é
   PERGUNTA de verdade quando a narrativa não dá pra derivar sozinha — é a
   decisão mais cara de errar de todo o processo (grão declarado é
   contrato; mudar depois é reconstruir a tabela).
3. **Dimensões** — emergem da narrativa (seção acima); reuso de conformada
   é o default mostrado primeiro (`lumo list table`/`lumo columns` antes de
   propor tabela nova). Cada dimensão carrega sua própria `confianca`/`origem`
   — nunca um bloco único "dimensões do template" em `hipótese` coletiva (o
   `exemplo-canonico/escopo/processos/faturamento.md` mostra 2 de 5
   confirmadas, 3 hipótese, cada uma justificada). Dimensão confirmada num
   fato do bus matrix é candidata a reuso conformado nos fatos irmãos — ver
   `calibracao-qualidade.md`.
4. **Métricas** — card completo por métrica (seção KPI card abaixo);
   decomposição sempre visível: `pergunta de negócio → decisão que muda com
   o número → fato → dimensões → filtros → ordenação/top-N`.
5. **Exclusão ativa** — pra cada inclusão, vale mostrar a simétrica como
   hipótese: "vendas por região entra; drill até vendedor fica fora, a não
   ser que você me diga o contrário" → registrado em `fora-de-escopo.md`
   com motivo e custo, sem exigir isso pra considerar o processo maduro.

**Sinais de fato mestre.** Olhando o processo de fora: KPI que é razão
entre dois processos (ocupação, conversão), o cliente descrevendo o ciclo
de vida da MESMA entidade em estados diferentes (pedido→separação→entrega),
ou 2+ fatos com 3+ dimensões em comum — são sinal de fanout se cada
processo virar tabela própria ligada por relationships. Proponha (AGE +
MOSTRA, com o custo concreto se o analista contrariar) consolidar no
TRATAMENTO como fato mestre em vez de modelar processos separados — ver
`limites-horus.md`.

## KPI card (`metricas/<nome>.md`, um arquivo por métrica)

O card continua sendo o formato de referência — o que muda é a etiqueta de
confiança no lugar do antigo `status: a-confirmar`, e a origem de cada
campo (hipótese derivada, ou confirmada com os 4 subcampos de
`incognitas.md`):

```yaml
type: metric
nome: "Receita Líquida"               # nome de negócio estável, único no projeto
pergunta: "quanto vendemos de fato, tirando devoluções e cancelamentos?"
decisao_associada: "pauta da reunião comercial de segunda — corta ação de desconto se cair"
                         # sem decisão associada, a métrica é candidata a data-vanity — mostre a
                         # hipótese ("acho que é só pra acompanhar") e, se ninguém emenda depois de
                         # argumentada uma vez, registra como fora-de-escopo com custo, não bloqueia
magnitude_estimada: "desconto mal calibrado custa ~1 semana de margem"  # OPCIONAL —
                         # custo DIRECIONAL de decidir tarde/errado, nunca preço/hora
formula_negocio: "soma do valor dos itens vendidos, menos descontos e devoluções"
formula_lumo: 'SUM([fact_vendas]."VALOR_LIQUIDO")'   # sintaxe expression Horus
camada: tabela           # tabela (reusável, métrica em 2+ dashboards) | dashboard (local,
                         #   só este app — a única camada com sintaxe {FILTER|COLUMN=...})
mask: MOEDA              # MOEDA|N0|N1|N2|N3|PCT0|PCT1|PCT2|DATA
aditividade: aditiva     # semi-aditiva (saldo): no Horus = SUM(CASE WHEN <corte temporal>
                         #   THEN valor ELSE 0 END) — sem LAST() nativo; declare a condição de
                         #   corte (ver limites-horus.md) | nao-aditiva (razão/%): componentes
                         #   aditivos, divide após agregar
inclusoes: "STATUSNOTA='L' (faturado)"          # valores de DOMÍNIO reais quando existem
exclusoes: "'A','C'; TIPMOV='B' (bonificação)"  # "nada especial" é resposta vaga (REGISTRA e anda)
coluna_data: DATA_EMISSAO
grao_temporal: dia
meta_threshold: "R$ X/mês; abaixo → <ação de quem?>"   # ou "sem meta" + onde a meta vive
owner: "Marcos Aurélio — Diretor Comercial"     # PESSOA nomeada, texto livre (regra acima)
aviso_apos: "D-1 08h"    # corte INTERNO — mais apertado
sla_cliente: "D-1 até 12h"  # compromisso com o CLIENTE — mais frouxo, com folga sobre aviso_apos
teste_reconciliacao: 'lumo app query ... --fields <m>:SUM vs lumo credential query ... "SELECT SUM(...)"'
                         # nasce aqui, copiado literal pra aceite.md, rerodado a cada mudança
fonte: "lineage.md#receita-liquida"
confianca: hipótese      # confirmado exige validado_por/validado_em/canal/evidencia (ver incognitas.md)
origem: "destilado da proposta comercial (insumos/proposta.pdf)"  # par obrigatório de
                         # confianca: hipótese/a-perguntar — mesma convenção de incognitas.md;
                         # confirmado troca origem pelos 4 subcampos (validado_por/validado_em/
                         # canal/evidencia)
```

Vale comparar a densidade com `exemplo-canonico/escopo/metricas/` antes de
considerar o card maduro — campo tecnicamente preenchido ≠ preenchido bem
(`calibracao-qualidade.md`).

## Recap antes da aprovação — nunca só "abre e olha"

O render (`lumo-mockup`, `lumo-mockup:references/wireframe-kit.md`) e
o live view (`lumo-mockup`, `lumo-mockup:references/wireframe-companion.md`) cuidam do HTML e do
gesto de aprovar por dashboard; o que falta ali é a fala que precede o gesto:

**Antes de pedir "aprova?", recapitule em TEXTO na conversa** os KPIs e widgets
daquele dashboard, cada um com sua etiqueta de confiança em linguagem de negócio
(confirmado / proposta a validar / a perguntar). Abrir o HTML com `open` e mandar
"dá uma olhada" delega a revisão a um artefato fora da conversa e produz
aprovação-carimbo (sessão PADO: 5 "confere" monossilábicos, zero correção). O
recap dá ao analista o que escrutinar sem sair do fluxo.

O recap não é gate: é "recapitule antes de pedir aprovação", nunca "não peça
aprovação até que…". Se o analista disser "pula, já vi" ou "pode aprovar" sem
esperar o recap, SEGUE A DEIXA se aplica igual a qualquer outro pedido de
acelerar (modo acima) — a skill segue sem insistir; o recap é o padrão da
conversa, não uma condição bloqueante do "aprova?".

## Taxonomia de armadilhas de BI — checklist de qualidade opcional

As 14 armadilhas abaixo não são mais contadas como condição pra seguir —
são um checklist pra passar o olho antes de considerar um processo maduro,
igual quem revisa uma lista de bugs conhecidos antes de um release: útil
pra não esquecer o óbvio, sem travar nada se alguma ficar em `a-perguntar`.
O vertical do cliente soma as armadilhas dele (`verticais/index.md`) às
genéricas daqui.

| Armadilha | Pergunta |
|---|---|
| Status que conta | "'Aberto' e 'cancelado' entram? Qual status é venda de verdade?" |
| Bruto vs líquido | "Com ou sem desconto/frete/imposto/devolução?" |
| Data de referência | "Conta na data do pedido, do faturamento ou da entrega?" |
| Devolução/estorno | "Abate no mês da venda original ou no mês da devolução?" |
| Duplicidade na fonte | "Registro pode aparecer 2x (reemissão/integração)? Como achar o vigente?" |
| Hierarquia | "Produto→grupo→seção: quantos níveis? Mudam com o tempo?" |
| Meta existe? | "Meta em sistema ou planilha? Quem mantém (PESSOA)?" — sem fonte, widget sai do escopo |
| Janela de histórico | "Quanto histórico na carga inicial? (esforço e volumetria)" |
| Frescor | "D-1 às 7h resolve? Que DECISÃO muda se for intraday?" |
| RLS / quem NÃO vê | "Vendedor vê o número do colega?" — sem resposta: default restritivo gravado e visível |
| Moeda/unidade | "Tudo em R$? Algo em unidades, kg, m²?" |
| Fuso | "Que fuso fecha o 'dia'?" |
| Motivo/causal | "Esse valor muda por causa de algo que o negócio quer ver separado — promoção, campanha, motivo de ajuste/estorno, canal de origem? Vira DIMENSÃO, não fica embutido no valor." |
| Retenção & expurgo | "Quanto tempo esse dado fica no DW? Existe gatilho de eliminação (LGPD)? Quem é o dono desse prazo?" |

Cada resposta (ou hipótese, ou `a-perguntar` registrado) alimenta: filtros
do card, regras da STM, `load_type`/`dedupe`, premissas do documento.
