# Multi-sessão — reabrir o bundle, ingerir o diff, fechar o loop de valor

## Conteúdo

- Reabrir um bundle — nunca re-executa a coleta
- Ingerir call/e-mail como diff — não é coleta a frio
- Log por sessão — uma entrada por rodada
- 2026-08-04 — rascunho (sessão 6)
- O ciclo de valor central: mockup → cliente ajusta → devolve → refina

Um projeto de escopo real não acontece numa sentada só. Ele roda em dias ou
semanas, várias sessões: levantamento inicial → mockup → mostra pro cliente
→ cliente ajusta (às vezes traz uma call nova) → o documento amadurece.
Este arquivo cobre tudo que acontece **da segunda sessão em diante** — a
primeira é `ingestao.md` (coleta a frio) seguida, se sobrar pergunta, de
`entrevista.md`. Consome o vocabulário de `incognitas.md`
(`confirmado`/`hipótese`/`a-perguntar` + o schema de registro de incógnita) —
leia aquele arquivo primeiro se ainda não leu. Reaproveita a mecânica de
destilação de `ingestao.md`, mas com uma diferença estrutural: ali a skill
destila para um bundle vazio; aqui ela destila **contra um bundle que já
existe**, e o produto é um diff sobre o que já está gravado,
em vez de hipótese nova solta.

## Reabrir um bundle — nunca re-executa a coleta

**Reabrir nunca é recomeçar.** Ao voltar a um projeto num dia diferente, a
skill lê `escopo/index.md`, navega para os arquivos que ele referencia e
agrega a etiqueta de confiança de cada campo em três baldes —
`confirmado`, `hipótese`, `a-perguntar` — mais os registros de
`escopo/incognitas.md` com `dono: cliente` ainda sem resposta. O resultado
vira um resumo de abertura, nunca um questionário do zero:

> "Retomando o escopo da Distribuidora Vale Sul. Confirmado: grain de
> Faturamento (um item de cada pedido de venda), owner da Receita Líquida
> (Marcos Aurélio). Em hipótese: SCD2 na dimensão Cliente, tipo de carga
> Incremental no fato. Perguntamos ao cliente se pedido cancelado entra na
> receita e ainda não voltou. O que mudou desde a última vez?"

A pergunta de fechamento é sempre "o que mudou", nunca "vamos começar
definindo o processo de negócio" — reabrir um processo de negócio já
descrito, uma dimensão já hipotetizada ou uma pergunta já registrada é
exatamente o que `entrevista.md` já proíbe dentro de uma sessão só
("registro não se cobra de novo, se atualiza"); entre sessões a regra é a
mesma, só que a lacuna de tempo é maior. **Nunca re-executa a coleta/quiz ao
reabrir — só o delta.**

**De onde vem "perguntamos e não voltou".** Não basta olhar `a-perguntar`
sozinho — isso mistura pergunta nunca enviada com pergunta enviada sem
resposta, e as duas pedem ação diferente (despachar vs. cobrar). A distinção
sai do cruzamento com `log.md` (seção abaixo): toda rodada que despacha
perguntas ao cliente registra os `id`s enviados; ao reabrir, qualquer `id`
despachado numa rodada anterior que continue `a-perguntar` — não promovido,
sem registro de resposta — entra no balde "perguntamos e não voltou" do
resumo. `id` que nunca apareceu num despacho é só um `a-perguntar` comum,
ainda não enviado.

## Ingerir call/e-mail como diff — não é coleta a frio

A frase de abertura da coleta a frio ("me passa tudo que você já tem") não
serve aqui — o bundle já tem estado. A frase de reabertura é dirigida ao
delta:

> "Me manda o que rolou desde a última vez — call nova, e-mail do cliente,
> print, o que for. Eu cruzo com o que já está gravado."

Todo material novo passa pela mesma varredura de `ingestao.md` (decisão,
número, nome de pessoa, frase literal sobre a dor de negócio), mas em vez de
semear hipótese solta, cada achado é comparado campo a campo contra o que já
está no bundle. Três desfechos possíveis, nunca um quarto silencioso:

| Desfecho | Quando acontece | O que a skill faz |
|---|---|---|
| **Promove** | material novo confirma um campo hoje em `hipótese` (ou responde um `a-perguntar`) | `hipótese`→`confirmado` (ou nasce `confirmado` direto), com o rastro completo de `incognitas.md`: `validado_por`, `validado_em`, `canal`, `evidencia` |
| **Contradiz** | material novo diz o oposto de um campo já gravado — em `confirmado` ou em `hipótese` | **nunca sobrescreve em silêncio**: sinaliza a contradição lado a lado (valor antigo vs. novo, com as duas fontes) e leva ao analista para decidir qual vale |
| **Abre incógnita nova** | material novo menciona algo que o bundle ainda não rastreava | nasce registro `a-perguntar` (ou `hipótese`, se defensável), schema completo de `incognitas.md` |

**Promover** reaproveita literalmente o exemplo canônico de `incognitas.md`.
O grain que nasceu hipótese na coleta a frio —

```yaml
grain:
  frase: "um item de cada pedido de venda"
  confianca: hipótese
  origem: "destilado da proposta comercial (insumos/proposta.pdf)"
```

— chega confirmado numa call de acompanhamento, e o rastro entra completo,
não só a etiqueta:

```yaml
grain:
  frase: "um item de cada pedido de venda"
  confianca: confirmado
  validado_por: "Marcos Aurélio — Diretor Comercial"
  validado_em: "2026-07-20"
  canal: "call de acompanhamento (sessão 3)"
  evidencia: "transcrição min 12:40 — confirma grain de item, não de pedido"
```

O mesmo vale para um `a-perguntar` que finalmente voltou: o registro
`cancelamento-pedido` de `incognitas.md` (dono: cliente, "pedido cancelado
entra na receita?") some da lista de perguntas em aberto e vira campo
`confirmado` em `metricas/receita-liquida.md#inclusoes`, com o `canal` e a
`evidencia` apontando pra mesma call.

**Contradizer** é o caso que a coleta a frio não precisa tratar (bundle
vazio não contradiz nada) e que reabertura precisa tratar sempre. Exemplo:
o grain acima já está `confirmado` como "um item de cada pedido de venda" —
e uma call nova, meses depois, traz o analista dizendo "na verdade a gente
fatura por pedido inteiro, não por item". Isso não é uma correção
silenciosa nem uma hipótese nova concorrente; é uma contradição de um campo
que já tinha rastro, e o rastro antigo não perde validade sozinho:

```yaml
grain:
  # ATENÇÃO — contradição não resolvida, ver log.md 2026-08-04
  confirmado_anterior:
    frase: "um item de cada pedido de venda"
    validado_por: "Marcos Aurélio — Diretor Comercial"
    validado_em: "2026-07-20"
    canal: "call de acompanhamento (sessão 3)"
    evidencia: "transcrição min 12:40"
  dito_agora:
    frase: "um pedido de venda inteiro"
    canal: "call de acompanhamento (sessão 6)"
    evidencia: "transcrição min 04:15 — contradiz o grain confirmado em 20/07"
  confianca: a-perguntar   # volta a incerto até alguém nomeado resolver qual vale
```

Um `confirmado` contradito nunca vira `hipótese` por conta própria — cai
para `a-perguntar` com as duas versões lado a lado, porque a pergunta certa
("qual dos dois está certo, e por que mudou") é decisão humana, não
inferência da skill. Se o campo contradito era só `hipótese` (nunca tinha
rastro), o material novo pode substituir direto — mas ainda entra no log
como "mudado", nunca como se a hipótese anterior nunca tivesse existido.

**Abrir incógnita nova** segue exatamente o schema de `incognitas.md` — id,
campo, hipótese, confiança, dono, gatilho, `pergunta_cliente` se for o caso,
risco — só que a `origem`/`canal` agora aponta pro material da rodada atual
em vez do insumo da coleta inicial.

## Log por sessão — uma entrada por rodada

`escopo/log.md` já existe como changelog do bundle (`documento-template.md`,
versionamento MAJOR.MINOR em `sizing-change-control.md` para depois da
aprovação). Antes da aprovação, cada rodada de reabertura — reler o estado,
ingerir o diff, fechar com o analista o que mudou — fecha com **uma entrada
própria em `log.md`**, datada, no mesmo padrão `rascunho` que o bundle-gabarito
já usa (ver `exemplo-canonico/escopo/log.md`, entrada de 2026-04-08), só que
agora estruturada em três blocos fixos — o delta da rodada, nunca um resumo
livre:

```markdown
## 2026-08-04 — rascunho (sessão 6)
* **Promovido**: grain de Faturamento tinha voltado `hipótese` após
  contradição da sessão 5 — call de hoje reconfirma "um item de cada pedido
  de venda"; rastro atualizado (`validado_em: 2026-08-04`).
* **Mudado**: nenhuma contradição nova nesta rodada.
* **Aberto**: nova incógnita `cancelamento-parcial` (a-perguntar, dono:
  cliente) — call mencionou cancelamento de item avulso dentro de um
  pedido maior, caso não coberto pelo grain atual.
* Despachado ao cliente nesta rodada: nenhuma pergunta nova (ver
  `escopo/incognitas.md` para o backlog de `pergunta_cliente` já pendente).
```

O campo **Despachado** é o que alimenta a seção "Reabrir um bundle" acima —
é ele que diferencia pergunta nunca enviada de pergunta enviada sem volta.
Toda rodada que gera e efetivamente manda a lista de `pergunta_cliente` para
o cliente registra aqui os `id`s enviados, mesmo quando a lista fica vazia
(registrar "nenhuma" evita ambiguidade na próxima reabertura). Quando uma
rodada não mexe em nenhum dos três blocos (sessão só de leitura, sem novo
material), a entrada ainda é gravada — vazia nos três, só para marcar que a
sessão aconteceu e nada mudou.

## O ciclo de valor central: mockup → cliente ajusta → devolve → refina

Este é o caso de uso que a multi-sessão existe para servir — não um caso de
borda. O documento não amadurece numa entrevista longa e definitiva; ele
amadurece em voltas: a skill escreve a ficha e aciona o mockup (Fase 3,
`wireframe-kit.md`/`ficha-para-vega.md`/`wireframe-companion.md`, todos na
skill `lumo-mockup`), o analista mostra pro cliente, o cliente leva
dias pensando, e volta com ajuste — call, e-mail, print anotado, ou os
próprios comentários de `escopo/eventos-wireframe.jsonl` quando a rodada
usou o companion ao vivo. Cada retorno do cliente é uma reabertura, e o
ajuste que ele traz é processado exatamente pela mesma mecânica de diff da
seção acima — só que o alvo agora é a ficha de widget, não o processo de
negócio inteiro:

1. **Mockup** — wireframe entregue com KPI cards e fichas já preenchidos,
   parte `confirmado`, parte `hipótese` visível (nunca escondida).
2. **Cliente ajusta** — feedback chega por qualquer canal aceito em
   `ingestao.md`/`eventos-wireframe.jsonl`. "O KPI de topo devia ser por
   loja, não por região" contradiz um campo de `dashboards/*.md` que talvez
   já estivesse `confirmado` da rodada anterior — mesma regra: sinaliza, não
   sobrescreve, se o campo tinha rastro; promove direto se era só hipótese.
   "Também queremos ver ticket médio ali do lado" abre uma incógnita nova
   (ou, se já decidido ali mesmo com pessoa nomeada, nasce `confirmado`
   direto, com o próprio retorno do cliente como `canal`/`evidencia`).
3. **Devolve pra skill** — o analista cola a resposta do cliente (texto,
   e-mail encaminhado, ou aciona a leitura de `eventos-wireframe.jsonl`); a
   skill reabre o bundle correspondente a esse dashboard, roda o diff, e
   fecha a rodada com a entrada de `log.md` (Promovido/Mudado/Aberto).
4. **Refina** — o wireframe é redesenhado só nos pontos que o diff tocou
   (nunca do zero) e volta pro cliente; o ciclo repete quantas vezes forem
   necessárias até aprovação — cada volta é uma sessão a mais, cada sessão
   uma entrada a mais em `log.md`, nunca uma nova rodada de perguntas de
   Fase 0/2 revisitando o que já foi decidido.

O sinal de que o ciclo está sendo respeitado: a skill nunca pede pro cliente
"começar a descrever o dashboard de novo" numa volta — ela mostra o que
mudou desde a última aprovação e pergunta só sobre o delta, exatamente como
na reabertura de qualquer outro bundle.
