# Ingestão — a porta de entrada: coletar e destilar antes de perguntar

## Conteúdo

- O primeiro ato: "me passa tudo que você tem sobre este cliente"
- Pesquisa na internet — empresa + segmento
- A regra de ouro da destilação
- Checagem de tenant existente — antes de modelar qualquer coisa
- Anexo ilegível — peça o texto colado, não brigue com OCR

Este arquivo define o **primeiro ato da skill**: antes de qualquer pergunta de
negócio ao analista, ela esgota o que já existe — documentos entregues,
artefatos da ferramenta atual do cliente, e pesquisa na internet. Só depois
disso é que sobra alguma coisa pra perguntar de verdade (e mesmo aí, a
entrevista prioriza reação a uma hipótese já escrita sobre pergunta em
aberto — ver `entrevista.md`). O resultado da ingestão são campos com
`confianca: hipótese` e registros `confianca: a-perguntar` no vocabulário de
`incognitas.md` — leia aquele arquivo primeiro se ainda não leu; este aqui
assume os 3 níveis de confiança e o schema de incógnita como dados prontos.

## O primeiro ato: "me passa tudo que você tem sobre este cliente"

A skill abre com uma coleta, nunca com uma pergunta de negócio. Frase de
abertura fixa:

> "Antes de qualquer coisa, me passa tudo que você já tem sobre este
> cliente — proposta, prints, planilha, transcrição de call, o que for. Eu
> leio tudo primeiro."

**Coletar antes de perguntar é respeito ao tempo escasso do analista.** Cada campo que a skill consegue hipotetizar sozinha a partir de
um documento é uma pergunta a menos que o analista precisa responder do
zero — o inverso exato do que quebrou nas duas sessões que motivaram este
redesign: interrogatório em série sem antes olhar pro que já existia.

### Insumos aceitos e como cada um destila

| Insumo | Como a skill destila | Produz |
|---|---|---|
| Proposta comercial / escopo estimado aprovado (PDF/DOCX) | Extrai o que o comercial já prometeu: dashboards citados, métricas mencionadas, público-alvo, prazo | Hipóteses de `dashboards/`, `metricas/`, público de cada um — rascunho inicial do bus matrix |
| Transcrição de call (comercial ou já com o cliente) | Varre por decisão, número, nome de pessoa e frase literal sobre a dor de negócio | Promove ou semeia campos com `origem: "destilado da transcrição (insumos/<arquivo>)"`; frase literal do cliente vira citação em `projeto.md` |
| Relatórios, planilhas, exportações do cliente | Colunas e agrupamentos do relatório existente ≈ dimensões/métricas que o cliente já enxerga hoje | Hipóteses de grain e de quais cortes (dimensões) importam de fato |
| Artefatos da ferramenta atual: Power BI/**PBIX**, prints de dashboard, PDF de relatório | Título dos visuais, eixos, filtros e cards visíveis — na v1 tratado como insumo textual/visual; parsing estruturado do modelo de dados do PBIX é melhoria futura, fora deste escopo | Hipóteses de quais métricas o cliente **já acompanha hoje** — evita perguntar o óbvio ("vocês olham receita por loja?" quando o print já mostra o card) |
| Select de exemplo / relatório de validação (raro) | Já é dado real, extraído do banco do cliente | **Única exceção da regra de ouro abaixo**: pode nascer `confirmado` direto, com `evidencia` apontando pro select/relatório |

Guarde os documentos originais recebidos em `escopo/insumos/` no bundle — é
pra lá que toda `origem:` de campo destilado aponta (ver o exemplo de
`grain` em `incognitas.md`, que já usa `insumos/proposta.pdf`).

## Pesquisa na internet — empresa + segmento

Em paralelo à leitura dos documentos, e **antes** de perguntar qualquer coisa
de negócio ao analista, pesquise a empresa e o segmento do cliente na
internet: site institucional, o que a empresa faz, porte (nº de unidades,
funcionários, faturamento se público), vertical de atuação. Isso alimenta
duas coisas:

1. **Carrega o pacote certo de `verticais/index.md`** antes da Fase 2 da
   entrevista (varejo, distribuição, indústria, financeiro, serviços/
   recorrência — ou nenhum, se o segmento não tiver pacote próprio) — soma
   armadilhas específicas, nunca substitui a taxonomia genérica.
2. **Semeia hipóteses de negócio genéricas do vertical** — ex.: "atacadista"
   puxa hipótese de dimensão de rota/CD; "assinatura/SaaS" puxa hipótese de
   métrica de churn — antes mesmo de o analista descrever o processo.

Toda hipótese que vier da web carrega `origem: "pesquisa web — <página
consultada>"`. Site institucional é boa fonte pra "o que a empresa faz" e
"porte"; é péssima fonte pra regra de negócio operacional ("líder do
segmento há 20 anos" é marketing, não grain nem métrica) — não promova esse
tipo de frase a hipótese de dado.

## A regra de ouro da destilação

**O que sai de documento ou de pesquisa web nasce `hipótese` — nunca
`confirmado` sem validação humana**, mesmo que o documento pareça
definitivo (um PDF de proposta assinado pelo cliente ainda é hipótese de
dado até alguém nomeado confirmar o campo específico, com os 4 subcampos de
`confirmado` de `incognitas.md`). A única exceção é o select de exemplo/
relatório de validação da tabela acima — é dado real do banco, não
inferência sobre um documento.

**O que não está em lugar nenhum — nem documento, nem web, nem resposta já
dada — vira registro `a-perguntar` (schema completo em `incognitas.md`:
`id`/`campo`/`hipotese`/`confianca`/`dono`/`gatilho`/`pergunta_cliente`/
`risco_se_errar`). Não vira pergunta solta ao analista, e muito menos nota
de rodapé.** Detalhe de implementação (semântica de status, regra de corte
de data) é sempre candidato a `a-perguntar` com `dono: cliente` ou
`dono: precisa-acesso-banco` — nunca pergunta de abertura ao analista, que
só sabe responder sobre o processo de negócio dele, não sobre a
implementação de dados do cliente dele.

Exemplo de destilação de um print de Power BI:

```yaml
metrica_receita:
  nome: "Receita Líquida"
  confianca: hipótese
  origem: "print do dashboard atual (insumos/powerbi-receita.png) — card
    'Receita Líquida R$ 1,2M' no topo da página; título do visual sugere
    corte por loja no eixo"
```

O que essa mesma destilação NÃO responde (a semântica de status por trás do
número) vira incógnita — mesmo formato do exemplo `cancelamento-pedido` em
`incognitas.md`, não repetido aqui.

## Checagem de tenant existente — antes de modelar qualquer coisa

Rodada barata, obrigatória, ANTES de escrever a primeira hipótese de grain
ou tabela nova — mesmo quando o cliente "parece" novo:

```bash
lumo tenants list                                   # já existe workspace Horus pra este cliente?
lumo init <tenant-id>                               # se existir, vincula o workspace de trabalho
lumo list flow && lumo list table && lumo list app  # o que já está construído — pode já cobrir
                                                     # boa parte do que o cliente está pedindo agora
```

**Sem rede, sem credencial, ou o comando falha?** A checagem não vira opcional,
vira **incógnita bloqueante**. Registre em `incognitas.md` com
`dono: analista` e `gatilho: antes de publicar qualquer tabela`, escreva no
`log.md` que a etapa foi pulada e por quê, e siga com o levantamento. O que não
pode acontecer é a etapa sumir em silêncio: o custo dela é retrabalho de
modelagem inteira quando o tenant já tinha metade do que você desenhou do zero.

Se o tenant já existe: **reconcilie antes de hipotetizar.** Herde o que já
está publicado (fatos, dimensões, apps) em vez de desenhar por cima do zero;
o escopo do projeto novo é o GAP real entre o que já existe e o que foi
pedido, não um redesenho inteiro do que já funciona. (Caso real que motivou
esta regra: a skill modelou "do zero" por 41 minutos antes de descobrir que
o tenant do cliente já existia havia 1 ano em produção, com 15 tabelas e 4
apps — os 41 minutos inteiros foram jogados fora.)

Se não existe: segue modelando normalmente — mas a checagem em si não é
opcional, é o primeiro comando antes de qualquer hipótese de dado, mesmo
quando o caso parece óbvio demais pra precisar checar.

## Anexo ilegível — peça o texto colado, não brigue com OCR

Um PDF que não extrai texto direto (escaneado, imagem, protegido) é um
insumo que falhou na 1ª tentativa — não um problema de engenharia a resolver
na hora. Regra:

**1 tentativa de extração direta. Falhou? Pare e peça o texto colado ao
analista** — nunca empilhe OCR, conversor, ferramenta de sistema alternativa
ou comando exótico tentando arrancar texto de um arquivo que não coopera.
"Não consegui extrair texto deste anexo — pode colar o conteúdo relevante
aqui (texto corrido, ou até print de um trecho)?" resolve em uma mensagem o
que uma cadeia de tentativas de tooling não resolve em várias. (Caso real
que motivou esta regra: ~9 comandos de shell gastos brigando com OCR de um
PDF ilegível antes de simplesmente pedir o texto colado — o mesmo resultado
que a 1ª mensagem já teria dado, sem custar nada de tempo do analista.)

Texto colado pelo analista entra na mesma esteira de destilação de qualquer
outro insumo — mesma regra de ouro acima: nasce `hipótese`, não
`confirmado`, mesmo vindo direto do analista (ele está repassando o dado do
cliente, não validando um campo específico do bundle).
