# O documento de escopo — bundle OKF + documento final

## Conteúdo

- Três vistas do mesmo bundle
  - O que muda de verdade entre proposta comercial e termo — não é só tom
- Layout do bundle
- Campos obrigatórios por conceito
- O documento final (Typst é o padrão sugerido)
- Auto-review antes de apresentar (adaptado do design review Kimball)

O escopo de um projeto NÃO é um arquivo só. São duas camadas com papéis distintos:

1. **Bundle OKF** (`escopo/` no diretório do projeto) — os arquivos .md de controle,
   um conceito por arquivo, com frontmatter YAML. É a fonte de verdade versionada
   em git e o que o agente lumo-cli consome depois da aprovação (progressive
   disclosure: lê `index.md` e navega só para o que precisa).
2. **Documento do cliente** — a visão apresentável, gerada A PARTIR do bundle,
   nunca editada à parte. Por padrão um PDF compilado via Typst
   (`termo-abertura.pdf`), mas o formato final é flexível — ver "Três vistas do
   mesmo bundle" abaixo. Cliente aprova esse documento; o agente executa o
   bundle. Os dois dizem a mesma coisa.

> **Mecânica OKF**: se a skill `okf` estiver instalada, delegue a ela init/add/
> link/index/log/validate. Sem ela, mantenha a regra mínima: todo .md com
> frontmatter YAML e `type` não-vazio, `index.md` na raiz, `log.md` com entradas
> datadas (mais recente primeiro).

## Três vistas do mesmo bundle

O bundle carrega, campo a campo, a camada de confiança (`confianca: confirmado
| hipótese | a-perguntar` — ver `incognitas.md`). Essa etiqueta não é um
detalhe interno esquecido no documento final: ela decide como o mesmo
conteúdo aparece em cada vista — e o bundle tem **três** vistas, não duas.
A proposta comercial e o termo de abertura não são dois documentos escritos
em paralelo: são duas renderizações a mais da mesma fonte, ao lado da vista
crua que o analista já usa para executar.

| Vista | Público | Trabalho | Incerteza aparece como |
|---|---|---|---|
| **crua** | analista, lumo-cli | executar | etiqueta técnica visível (`confianca:`, `hipótese`, `a-perguntar`) |
| **comercial** | comprador | ganhar o deal | **escopo incluído** |
| **termo** | aprovador | blindar o dimensionamento | **risco declarado** |

Continuidade entre proposta comercial e termo é garantida **por
construção** — as duas saem do mesmo bundle, no mesmo comando — e não por
disciplina de manter dois arquivos alinhados à mão.

**Fronteira de responsabilidade.** Montar as três vistas — decidir quais
seções cada uma carrega, em que ordem, e escrever o texto do documento — é
sempre trabalho da `lumo-scope`. Quando uma seção inclui o visual de um
widget (wireframe), esse visual (HTML/SVG/PNG) é gerado pela `lumo-mockup` e
só **embutido** aqui; a `lumo-mockup` nunca monta documento — ela devolve o
render, a `lumo-scope` decide onde ele entra em cada vista (ver
`lumo-mockup:SKILL.md`, "O que esta skill NÃO faz").

- **Vista crua (interna, toggle)** — etiquetas `confirmado` / `hipótese` /
  `a-perguntar` visíveis lado a lado com o valor. É o que o analista lê
  navegando o bundle, e o que a `lumo-cli` consome para decidir o que já pode
  virar spec e o que ainda depende de resposta.
- **Vista comercial (pré-venda, o comprador)** — a proposta que precisa
  ganhar o deal. A incerteza nunca aparece como dúvida crua: reposiciona-se
  como trabalho já embutido no escopo — "o diagnóstico de disponibilidade de
  dado está incluído no projeto", não "isto ainda não foi validado". É
  decisão consciente de posicionamento, não ocultação: um
  marcador de dúvida cru pode custar o deal contra um concorrente que
  promete tudo sem verificar antes.
- **Vista termo (aprovação, o aprovador)** — o documento que o cliente
  assina e que blinda a equipe contra projeto mal dimensionado. Aqui a
  mesma incerteza aparece como o que de fato é: um **risco declarado e
  aceito**, nunca escondido nem inflado — é o material que o aprovador usa
  para saber exatamente o que está comprando.

Nas duas vistas vestidas (comercial e termo), a mecânica de tradução da
etiqueta é a mesma — só o enquadramento muda por vista:
  - `hipótese` vira texto natural, nunca a palavra "hipótese" crua;
  - `a-perguntar` some do corpo do documento e reaparece como item da seção
    **Perguntas para o Cliente**, gerada a partir dos registros de
    `incognitas.md` com `dono: cliente` (o `pergunta_cliente` de cada um,
    pronto para enviar — ver `incognitas.md`);
  - `confirmado` aparece como afirmação direta, sem qualificador;
  - Caso especial: estrutura `confirmado` com conteúdo ainda dependente de
    carga (fato sem profiling real — regra "Estrutura ≠ conteúdo na
    promoção" em `incognitas.md`) — em ambas as vistas vestidas, "conteúdo
    ainda não carregado" vira "diagnóstico de disponibilidade de dado
    incluído no projeto", nunca a etiqueta crua nem uma afirmação
    de que o número já existe.
  - A etiqueta técnica (`confianca:`, `hipótese`, `a-perguntar`) NUNCA aparece
    crua em nenhuma das duas vistas vestidas.

**Registro de escrita das vistas vestidas.** Quem assina a proposta ou o termo
reconhece texto gerado por máquina, e isso custa credibilidade num documento
comercial. Três construções estão proibidas no corpo de qualquer vista
vestida, incluindo títulos de seção, legendas e overlays:

1. **Antítese corretiva**, no formato "X não é Y, é Z" ou "não porque A, mas
   porque B". Afirme direto o que vale, sem montar o contraste antes.
   Reprovado: *"o projeto não é uma migração, é uma reconstrução"*.
   Aprovado: *"o projeto reconstrói o modelo em vez de migrá-lo"*.
2. **Enumeração tripla por ritmo**, do tipo "rápido, barato e confiável".
   Lista de verdade com 3 itens em bullets continua valendo; o que sai é o
   triplete usado por cadência dentro da frase.
3. **Travessão (`—`)**. Use vírgula, ponto, dois-pontos ou parênteses. Trocar
   por hífen ou meia-risca não resolve, porque o problema está na cadência da
   frase, e não no caractere.

A vista crua (analista e lumo-cli) fica de fora desta regra, porque ninguém
de fora a lê.

A **redação exata** de cada combinação nível de confiança × vista — a frase
pronta para usar no widget — não mora aqui: é
`lumo-mockup:references/marcadores-confianca.md` §4, o dono desse
vocabulário. Este arquivo define QUANDO cada vista existe e QUE seções ela
carrega no documento; a `lumo-mockup` define COMO a frase é escrita, campo a
campo, dentro do widget. Um dono por regra — não redefina o vocabulário
aqui.

### O que muda de verdade entre proposta comercial e termo — não é só tom

Se as duas vistas vestidas tivessem as mesmas seções, "vista comercial"
seria só um adjetivo aplicado ao termo — a prova de que são documentos
diferentes, com trabalhos diferentes, é o corte real de conteúdo. A tabela
usa a numeração de "O documento final" abaixo:

| # | Seção | Proposta comercial | Termo de abertura |
|---|---|---|---|
| 1 | Capa | Sim — "Proposta Comercial"; sem `vMAJOR.MINOR` do bundle (controle interno, não fala com o comprador) | Sim — cliente, projeto, `vMAJOR.MINOR`, data, status |
| 2 | Contexto e objetivo | Sim, reenquadrado como valor/ROI para quem decide comprar | Sim, mesma dor, sem o enquadramento de venda |
| 3 | Dashboards e público | Sim, sem corte | Sim, sem corte |
| 4 | Matriz de escopo | Sim — só a leitura "o que está incluído"; a célula vazia não é destacada como limite formal | Sim — ✓ e vazio lado a lado; o vazio É o limite formal do que foi vendido |
| 5 | De onde vêm os dados | Resumido — nomeia as fontes em prosa, sem o diagrama table-level | Diagrama table-level completo. O STM coluna-a-coluna **nunca** sai do bundle, em nenhuma vista — não interessa ao comprador nem ao aprovador, só a quem executa |
| 6 | Métricas e fórmulas | Sim — nome e definição em linguagem simples; fórmula técnica só entra se ajudar a vender | Sim, completo — nome, definição, fórmula, exclusões |
| 7 | Wireframes | Sim — é o WOW da venda | Sim — as mesmas imagens, mesmo banner de dados ilustrativos |
| 8 | Fora de escopo | Resumido — item e motivo, sem o custo aproximado em tier (negociação ainda não fechada) | Integral — item, motivo E custo em tier |
| 9 | Critérios de aceite | **Não entra** — comando de verificação técnica não fala com quem decide a compra | Sim, obrigatório — é a seção que blinda o dimensionamento |
| 10 | Dimensionamento | Sim — tiers e faixas por fase, sem preço; vende o modelo de entrega fatiada | Sim, o mesmo inventário |
| 11 | Premissas e riscos + RACI | Resumido — menciona papéis definidos e riscos mapeados, sem RACI nomeado | Sim, completo e nomeado — fala com quem vai responder por cada papel |
| 12 | Mudanças após aprovação | Resumido — cita que existe régua de mudança (argumento comercial: "sem susto de aditivo") | Sim, completo — a régua real (extensão-grátis vs. novo ciclo) |
| 13 | Aprovação | Assinatura comercial — aceite segue para a produção do termo | Assinatura formal e vinculante — gate do `git tag scope-vX.Y` |

O corte de verdade está em 9 (ausente na comercial), no RACI nomeado de 11,
e no detalhe processual de 8/12 — é isso que prova que o termo faz um
trabalho que a proposta não faz (blindar dimensionamento), e vice-versa
(ganhar o deal não pede blindagem, blindagem não pede sedução). Fora essas
diferenças, as seções compartilhadas (3, 6, 7, 10) usam o mesmo conteúdo
destilado do bundle — só a vista muda como a incerteza dentro delas aparece.

**É uma fonte, três renderizações — não três documentos mantidos à mão.**
Editar o bundle atualiza as três vistas; nunca ajuste uma vista vestida
direto (o mesmo "nunca editada à parte" da camada 2 acima). Se o cliente
pede uma mudança no texto apresentável, a mudança entra no bundle — no
campo, na etiqueta de confiança ou no `pergunta_cliente` — e a vista vestida
correspondente é regerada; não é um find-and-replace no documento final.

**Formato de saída flexível.** O PDF via Typst é a sugestão padrão de
renderização final, não uma obrigação. A mesma fonte (o bundle) pode virar
DOCX, markdown puro, HTML ou outro formato a pedido do analista — "gerar o
PDF Typst" não é um passo obrigatório nem a linha de chegada do processo; a
linha de chegada é o bundle completo e aprovado. Ver "O documento final"
abaixo para o esqueleto Typst, útil como referência de conteúdo e ordem de
seções mesmo quando o formato de saída escolhido for outro.

## Layout do bundle

```
escopo/
  index.md                      # navegação + okf_version + status/versão do escopo
  log.md                        # changelog MAJOR.MINOR (ver sizing-change-control.md)
  insumos/                      # materiais originais do cliente (proposta, prints,
                                # exports, PBIX) — cada campo destilado do bundle tem a
                                # `origem` apontada pra cá (ver ingestao.md)
  projeto.md                    # type: project-charter — objetivo, aprovador, público,
                                #   bus matrix, RACI, premissas/riscos globais
  processos/<processo>.md       # type: business-process — 1 por linha do bus matrix:
                                #   grain-sentence, tipo de fato, dimensões, métricas (links)
  tabelas/<fact|dim>_<nome>.md  # type: table — destino DW proposto
  metricas/<metrica>.md         # type: metric — 1 KPI card por arquivo
  lineage.md                    # type: lineage — mermaid table-level + STM column-level
  apps/<app>.md                 # type: bi-app — o CUBO: quais tabelas (fatos+dims),
                                #   relationships (herdados do lineage), expressions de
                                #   tabela vs de app, dashboards filhos, razão rel/tabela
  dashboards/<dash>.md          # type: dashboard — a UMA pergunta, público, fichas de widget
  wireframes/<dash>.html        # mockup Vega-Lite (renderizado pela skill lumo-mockup,
                                #   ver lumo-mockup:references/wireframe-kit.md)
  fora-de-escopo.md             # type: scope-exclusions
  aceite.md                     # type: acceptance-criteria
  revisoes.md                   # type: review-log — gates A/B/C (validacao-adversarial.md), append-only
  eventos-wireframe.jsonl       # aprovações/ajustes do live view (wireframe-companion.md,
                                #   skill lumo-mockup), se usado
  aprovacao.<pdf|eml|png>       # ARTEFATO da aprovação do cliente — obrigatório antes do git tag
  proposta-comercial.typ        # fonte Typst da vista COMERCIAL — gerada do MESMO
                                # bundle do termo-abertura abaixo (ver "Três vistas
                                # do mesmo bundle" acima); nunca editada à parte —
                                # muda o bundle, regera o arquivo. Documento de
                                # pré-venda, o que ganha o deal
  proposta-comercial.pdf        # o que vai para o comprador, antes da assinatura
  termo-abertura.typ            # fonte Typst da vista TERMO — gerada do MESMO bundle
                                # da proposta-comercial acima (mesma regra: nunca
                                # editada à parte). Rota Typst continua válida só
                                # para esta parte; o desenho nativo de wireframe em
                                # Typst foi aposentado
                                # wireframes entram no PDF como SVG gerado por
                                # vl-convert e embutido direto (#image(...), ver
                                # lumo-mockup:references/pipeline.md); o HTML com
                                # o mesmo SVG fica para iteração/live view (modo: rascunho)
  termo-abertura.pdf            # o que o cliente assina
```

Linke os conceitos entre si (métrica → tabela → lineage → dashboard) — é o que
permite ao lumo-cli rastrear "este widget consome esta métrica que vem desta coluna".

## Campos obrigatórios por conceito

Campo ausente = documento não está pronto. Não existe "preencho depois".

**`tabelas/*.md`** (frontmatter + corpo):
```yaml
type: table
papel: fato | dimensao | bridge   # enum FECHADO: só estes três. "fato-mestre"
                                  # NÃO entra aqui — é `estrategia`, abaixo, e
                                  # um fato-mestre continua `papel: fato`
grain: "uma linha = <frase de negócio, nunca lista de dimensões>"
tipo_fato: transacional | snapshot-periodico | snapshot-acumulativo | snapshot-atual
                         # só fatos; snapshot-atual = Total sobrescreve, histórico
                         # descartado DE PROPÓSITO — exige justificativa (por que não
                         # snapshot-periodico?)
load_type: Total | Temporal | Incremental
coluna_particao_tracking: <col ou null>   # imutabilidade validada? ver evidência
chave_negocio: [<colunas da origem que DEVEM sobreviver ao ETL>]
dedupe: <regra ou null>
dimensao_conformada: nova | reusa <dw-desk/tabela existente>
scd: type1 | type2   # dimensões: histórico versionado ou overwrite
dw_desk_destino: "<nome — decisão do analista, nunca inferida>"
retencao_dw: <prazo ou a-perguntar>   # LGPD: prazo de retenção + gatilho de expurgo (14ª armadilha)
estrategia: star | fato-mestre   # fato-mestre = consolidação no tratamento, ver limites-horus.md
                                 # ortogonal a `papel`: quem é fato-mestre tem
                                 # `papel: fato` + `estrategia: fato-mestre`
confianca: confirmado | hipótese | a-perguntar   # camada de confiança do registro (ver incognitas.md)
```
Realidade da materialização (ver `limites-horus.md`): `papel` é rótulo do
bundle, não campo real da plataforma; `chave_negocio` só se reforça na prática
via `key_type: unique`, dedupe em expression ou o delete-window do load
Temporal — declare qual; SCD2 é build manual precificado, não recurso nativo.

Corpo: colunas propostas (nome de negócio ↔ nome físico ↔ origem; linhas de FK
ganham coluna de cardinalidade 1:N/N:N), e o bloco de **evidência** por decisão
estrutural (formato em `fonte-profiling.md`):
`Decisão → Teste executado → Resultado → Status (Validado | Premissa não validada — risco)`.

**`lineage.md`** — origem "seed manual / sem flow" (upload avulso, sem ETL
repetível) é caso de primeira classe, não exceção à parte. Este lineage é a
**fonte autoritativa dos joins**: na execução, cada relationship é copiado
para TODO app que use as duas tabelas (`limites-horus.md`) — join declarado
num app que não está aqui é scope creep, não implementação.

**`projeto.md`** — soma duas decisões condicionais quando aplicável: **fonte
em migração** (2 sistemas coexistindo para o mesmo processo — substitui e
descontinua / paralelo por período / consolida já) e **escopo de
consolidação** (unidade única ou grupo/multi-tenant — muda RACI e quem aprova
acesso). Ver `limites-horus.md`.

**`metricas/*.md`** — o KPI card (campos em `entrevista.md`, todos obrigatórios).

**`apps/*.md`** (frontmatter + corpo):
```yaml
type: bi-app
tabelas: [<fato/dim do cubo — links para tabelas/*.md>]   # o conjunto que o app expõe
relationships:                       # herdados de lineage.md; join declarado aqui que não
  - de: "<dim>.<col>"                # está no lineage = scope creep
    para: "<fato>.<col>"
    cardinalidade: 1:N
razao_rel_tabela: <n>                # ≈1,0 saudável; >1,5 = constellation (limites-horus.md)
expressions_tabela: [<métrica reusável por qualquer app — mora na tabela>]
expressions_app: ["<métrica local, único lugar de {FILTER|COLUMN=...}>"]
dashboards: [<links para dashboards/*.md filhos deste app>]
bi_desk_destino: "<nome — decisão do analista, nunca inferida>"
confianca: confirmado | hipótese | a-perguntar
```
O app é onde a decisão "vários fatos com dimensões compartilhadas vs fato-mestre"
mora (`limites-horus.md`, `calibracao-qualidade.md#defaults-opinativos` — linha
"Modelagem por app"). Métrica que é razão entre processos de grãos diferentes é
`expressions_app` OU coluna no fato-mestre — **nunca** `camada: tabela` num join
fato-fato (armadilha PADO `atingimento_meta`).

Corpo: o desenho do cubo em prosa — quais processos do bus matrix este app
cobre, por que estes fatos convivem no mesmo app, e a justificativa da
estratégia escolhida (star com dimensões compartilhadas vs fato-mestre) com o
sinal concreto que a motivou.

**`dashboards/*.md`**:
```yaml
type: dashboard
app: "<link para apps/<app>.md — obrigatório; o cubo de onde este dashboard sai>"
publico: executivo | operacional | analista
pergunta: "<a UMA pergunta que o dashboard responde>"
decisoes_que_suporta: [<top-3 decisões do usuário>]
                         # a primeira é a mais relevante — é dela que sai o
                         # overlay narrativo do mockup (contrato com a skill
                         # lumo-mockup, ver overlay-narrativo.md §2 e §7)
prioridade: alta | media | baixa   # obrigatório com >1 dashboard — ordena as fatias de entrega
bi_desk_destino: "<nome — decisão do analista, nunca inferida>"
```
Corpo: as fichas de widget numeradas (formato em `lumo-mockup:references/wireframe-kit.md`,
skill `lumo-mockup`) + link para o wireframe HTML gerado por ela. Isso pré-preenche
o design brief da lumo-design (público, dataset, pergunta) — inclua `mood_accent:`
só se o analista informou marca/cor do cliente.

Quando o mesmo dashboard for pedido para 2+ bi-desks, registre a provenance
("B é clone de A na vX.Y; mudanças não propagam — cliente ciente") — sem isso
o cliente descobre a divergência sozinho depois do go-live.

**`aceite.md`** — critérios binários por entregável, cada um terminando num comando
de verificação real:
```
- [ ] Receita Líquida do dashboard = query direta na origem, em 2 NÍVEIS: total
      geral (tolerância ≤ 0,5%) E 1 quebra por dimensão/período com a mesma
      tolerância — o total pode bater por coincidência de dois erros que se
      cancelam, a quebra não
      → verificar: lumo app query app:<id> --fields <col:SUM> vs lumo credential query
- [ ] Volumetria da carga = COUNT(*) da query de origem (query 1 do profiling)
      menos os filtros declarados no card → verificar: lumo credential query
      vs linha de carga do flow
- [ ] Dado disponível até 07:00 (D-1)         → verificar: lumo flow logs flow:<id>
      (pré-requisito: linha de evidência de defasagem_atual da fonte — query 4)
- [ ] Grain permanece 1:1 no destino: COUNT(*) = COUNT(DISTINCT <chave>) na
      tabela DW carregada → verificar: lumo credential query (uniqueness não é
      só decisão de Fase 1 — um bug de dedupe reintroduz duplicidade)
- [ ] Layout confere com wireframe aprovado    → verificar: lumo app export app:<id> --image-format png
- [ ] Papéis com acesso: <nomeados>; SEM acesso: <nomeados>
- [ ] Sessão de 30min com o usuário diário nomeado, ANTES do go-live (rodada de
      onboarding — não é o mesmo que treinamento genérico em bloco)
- [ ] ≥X% dos papéis nomeados acessaram o dashboard entre D+14 e D+30 pós-go-live
      → verificar: log de acesso da plataforma
- [ ] Owner confirma, por escrito, que a `decisao_associada` da métrica está
      sendo tomada com o número — não só que "o número está certo"
- [ ] Modelo do app sem fanout: razão relationships/tabela ≤ 1,5 E toda dimensão
      comum a 2+ fatos é conformada (mesma tabela) → verificar: lumo info app:<id> --full
- [ ] Cobertura: toda tabela do bus matrix do app aparece no cubo; nenhum join
      declarado num app fora do lineage.md → verificar: lumo info app:<id> --full vs
      lineage.md
- [ ] Métrica que cruza 2 fatos reconcilia no NÍVEL DO APP, não só do widget
      → verificar: lumo app query app:<id> --fields <m> vs query direta na origem
      (a mesma métrica pode bater num dashboard e furar noutro se o app tiver fanout)
```
Linguagem vaga ("dados devem bater", "conforme necessário", "etc.") é proibida.

O `app:<id>` do comando de verificação sai do `apps/<app>.md` do bundle — se o
`<id>` ficou literal, não resolvido, a decisão de cubo não foi tomada (defeito
PADO); resolva antes de fechar o aceite.

**`fora-de-escopo.md`** — mesma dignidade do que está dentro: item, motivo, e o
custo aproximado da inclusão em tiers ("ficaria +1 tier por exigir carga
Incremental"). Célula vazia do bus matrix = linha aqui. Dois itens recorrentes
que também moram aqui, nunca em fase nova: **schema drift** — "mudança na
fonte pós-entrega: sustentação tier X ou change request" — e **sustentação
pós-go-live** como decisão de escopo, não operação implícita: dono de
sustentação NOMEADO, janela de estabilização com critérios de saída
explícitos, e fronteira de monitoramento Horus×TI-cliente (quem olha o quê).
Isso aparece no documento final junto do resto do fora-de-escopo — não cria Fase 5.

## O documento final (Typst é o padrão sugerido)

Por padrão, gere `termo-abertura.typ` a partir do bundle e compile para PDF —
essa é a rota sugerida, não a única (ver "Três vistas do mesmo bundle" acima).
Se o analista pedir DOCX, markdown ou outro formato, use a mesma lista de
seções abaixo como estrutura de conteúdo; o que muda é o formato de saída,
não o conteúdo nem a ordem.

```bash
typst compile escopo/termo-abertura.typ escopo/termo-abertura.pdf
```

Esqueleto em [`termo-abertura.typ`](termo-abertura.typ) — adapte conteúdo, não a
ordem das seções:

1. Capa: cliente, projeto, versão vMAJOR.MINOR, data, status.
2. Contexto e objetivo (a dor; decisões que o projeto habilita).
3. Dashboards e público (tabela: dashboard · público · a pergunta que responde).
4. Matriz de escopo (bus matrix: linhas = processos/cubos, colunas = dimensões;
   ✓ = incluído; vazio = fora de escopo). As linhas do bus matrix são
   processos/fatos de um mesmo **app**; um bundle com N apps tem N bus
   matrices, não uma só — cada cubo é fechado em si.
5. De onde vêm os dados (lineage table-level como diagrama; STM completo fica no
   bundle — no documento final só as fontes e regras de negócio relevantes ao
   cliente).
6. Métricas e fórmulas (nome, definição em linguagem simples, fórmula, exclusões).
7. Wireframes (imagem/print de cada HTML aprovado, com o banner de dados ilustrativos
   visível) + fichas resumidas.
8. **Fora de escopo** (integral).
9. Critérios de aceite (a versão de negócio; comandos ficam no bundle).
10. Dimensionamento (inventário com tiers S/M/L/XL e faixas por fase — sem horas,
    sem preço; ver sizing-change-control.md).
11. Premissas e riscos + RACI.
12. Mudanças após aprovação (resumo da régua extensão-grátis vs novo ciclo).
13. Aprovação: nome/cargo/data + "qualquer mudança fora deste documento requer
    novo ciclo de aprovação".

O documento final é neutro e sóbrio (preto/cinza, uma família tipográfica, sem
cor de marca) — pela mesma razão do wireframe: o cliente está aprovando
conteúdo. Vale independente do formato de saída escolhido.

## Auto-review antes de apresentar (adaptado do design review Kimball)

Percorra e corrija inline; refaça até passar. Este auto-review é o **piso** de
qualidade que a skill aplica no documento final — não um gate na sessão: se o
analista quer avançar rápido, a skill roda a passada mesmo assim e aponta o
que encontrou, e o analista decide se embarca com as ressalvas anotadas. Não
pule por reflexo ("já revisei" não substitui a checagem de verdade, pela
mesma razão que "já validei com o cliente" não substitui o registro) — uma
hipótese rotulada é conteúdo válido aqui, não é reprovação. Depois dele, o
checkpoint opcional (Gate C de `validacao-adversarial.md`, se acionado) é o
teto — o auto-review é só o piso.

- [ ] Todo fato tem grain-sentence de negócio (frase, não lista de FKs)?
- [ ] Toda métrica tem KPI card completo, com aditividade, `decisao_associada`
      respondida e owner-PESSOA?
- [ ] **Campos de pessoa** (owner, aprovador, RACI, dono de pendência) em TODO o
      bundle: nenhum contém termo genérico (cliente, comercial, TI, diretoria,
      o time)?
- [ ] Toda dimensão declara: conformada-reusada ou nova (com `motivo` quando há
      equivalente)? SCD decidido (SCD1 só com `justificativa_scd1`)?
- [ ] Todo widget tem ficha com encoding preenchido?
- [ ] Lineage cobre TODA coluna citada em métrica (origem → regra → destino)?
- [ ] Toda decisão estrutural tem evidência de profiling OU registro
      `a-perguntar` completo em `incognitas.md` (`dono`, `gatilho`,
      `risco_se_errar`)? **Consistência**: nenhum `Status: Validado` com
      `Resultado` que o contradiz (grain check linhas ≠ distintos)?
- [ ] **Taxonomia (checklist de qualidade, opcional)**: para cada processo,
      as 14 armadilhas genéricas + as do pacote vertical têm referência
      explícita no corpo? Não é condição de fechamento — é sinal de
      cobertura; lacuna que valer a pena perguntar vira registro
      `a-perguntar`, o resto fica marcado como não aplicável.
- [ ] `fora-de-escopo.md` não está vazio, e cada item tem motivo + custo em tier?
- [ ] Zero: linguagem vaga (`calibracao-qualidade.md` tem a régua bom/ruim),
      "TBD" sem etiqueta, horas/dias/preço, contradições bundle × documento
      final? **Hipótese ou `a-perguntar` rotulada com `confianca:` não é
      placeholder — é conteúdo válido**; o que reprova aqui é campo sem
      etiqueta de confiança nenhuma, texto vago tipo "conforme necessário", ou
      algo que uma vista vestida diz e o bundle contradiz.
- [ ] Perguntas para o Cliente (seção gerada a partir de `dono: cliente` em
      `incognitas.md`) consolidadas numa lista única no documento final, com
      `pergunta_cliente` pronto para enviar? Rodadas encurtadas por pressa
      contadas na capa?
- [ ] Gates A e B, se acionados, registrados em `revisoes.md`
      (`validacao-adversarial.md`)? Achado `Bloqueado` não impede seguir
      sozinho — mas exige decisão do analista/dono documentada (aceitar o
      risco registrado, ou corrigir); nenhum `Bloqueado` solto sem essa
      decisão escrita.
- [ ] index.md, log.md e cross-links atualizados (okf validate, se disponível)?

**Sign-off é artefato, não anotação:** o `git tag scope-vX.Y` só pode ser
orientado com `escopo/aprovacao.<ext>` presente no bundle (PDF assinado, e-mail
encaminhado ou export de assinatura) cujo assinante bate com o `aprovador` de
`projeto.md`. Sem o arquivo, a skill se recusa a orientar o tag — gate técnico,
não lembrete.
