# Escopo do Projeto — Gerador de Recibos

**Versão:** 1.1 — substitui a v1.0
**Data:** 11/09/2026
**Responsável:** Rafael — RAVAPI Soluções
**Status:** aguardando validação final antes das migrations

**O que mudou desde a v1.0:**
1. O documento passa a ter **direção** — recebimento ou pagamento
2. `payers` vira **`counterparties`** — a outra parte é cadastro completo, serve às duas direções
3. Novo módulo de **usuários da empresa**, com segregação de funções
4. **Licenciamento via Klavo** — provisionamento, validação e medição de uso

---

## 1. Natureza jurídica do documento

O recibo é **prova de quitação civil** (Código Civil, arts. 319 e 320). Não é documento fiscal.

**Consequências para o projeto:**

- Não exige certificado digital, SEFAZ, homologação municipal nem obrigação acessória.
- **Não substitui NF-e nem NFS-e.** Aviso fixo na emissão e impresso nas duas vias. Se o cliente precisa de documento fiscal, o caminho é o módulo de NFS-e do Klavo — não este produto.
- Sem autoridade externa validando, a credibilidade vem inteiramente da disciplina interna de numeração, imutabilidade e rastreabilidade.

**Elementos exigidos pelo art. 320:** valor e espécie da dívida, nome do devedor (ou de quem pagou por ele), tempo e lugar do pagamento, assinatura do credor ou de seu representante.

**A regra que organiza tudo:** *quem dá quitação é sempre quem recebeu o dinheiro.* Ela vale nas duas direções e define quem assina o documento.

> **Risco a resolver antes da produção — retenções em pagamento a pessoa física.** Quando a empresa (PJ) paga um prestador PF autônomo, normalmente incidem retenção previdenciária e possivelmente IRRF, sob responsabilidade de quem paga. O recibo simples documenta o pagamento, mas não substitui a obrigação de reter e recolher. Isso atinge diretamente o módulo de freelancers. **Confirmar com o contador de cada cliente** — pode antecipar o módulo de RPA para dentro do escopo do módulo embarcado.

---

## 2. Direção do documento

Campo `direcao`, com dois valores. A empresa é sempre o **emitente** (quem opera o sistema), mas nem sempre o credor.

| | **RECEBIMENTO** | **PAGAMENTO** |
|---|---|---|
| Empresa é | credora | devedora |
| Contraparte é | devedora (pagou) | credora (recebeu) |
| Quem assina | a empresa | a contraparte |
| Corpo do texto | "Recebemos de {contraparte}…" | "Recebi de {empresa}…" |
| Caso típico | evento de buffet, aluguel, serviço prestado | diária de freelancer, fornecedor, reembolso |
| Série sugerida | R | P e F |

**Concordância verbal:** o verbo segue o tipo de pessoa do credor — PJ imprime "Recebemos", PF imprime "Recebi". Regra pequena, mas é o tipo de detalhe que faz o documento parecer feito por quem entende.

**Rótulo das vias:** deixa de ser "Pagador / Emitente" e passa a ser **"Via do pagador" / "Via do recebedor"**. Assim está correto nas duas direções, sem lógica condicional.

**Assinatura em tela nos dois modos:**
- Recebimento — quem assina é o responsável da empresa, já no balcão.
- Pagamento — quem assina é a contraparte. É o caso do freelancer assinando no tablet ao receber a diária, e é o principal motivo de a assinatura em tela existir.

**Séries têm direção fixa.** Uma série R só emite recebimento, uma série P só emite pagamento. Isso mantém a numeração sequencial com significado contábil (entrada × saída) e evita que um clique errado inverta a natureza do documento.

---

## 3. Decisões arquiteturais (fechadas)

| # | Decisão | Escolha |
|---|---|---|
| 1 | Formato do produto | SaaS autônomo **e** módulo do sistema de freelancers — base de código única |
| 2 | Escopo fiscal da v1 | Recibo simples de quitação (RPA como módulo posterior — ver risco na seção 1) |
| 3 | Assinatura e validação | Linha manual + QR de verificação pública + assinatura em tela opcional |
| 4 | Multi-tenancy | RLS por `tenant_id`, padrão do RAVAPI Platform Template |
| 5 | Representação monetária | `BIGINT` em centavos, sem exceção |
| 6 | Direção | Recebimento e pagamento, com série de direção fixa |
| 7 | Licenciamento | Klavo é a fonte da verdade comercial; o produto valida licença assinada |

---

## 4. Arquitetura dual-mode

Núcleo como **`DynamicModule` NestJS** (`RecibosModule.forRoot(config)`), publicado como pacote privado `@ravapi/recibos`.

**Modo A — SaaS autônomo.** App NestJS + Next.js + banco próprios. Licença emitida pelo Klavo.
**Modo B — Módulo embarcado.** O sistema de freelancers importa o módulo; tabelas no schema `recibos` do banco do host.

```ts
interface RecibosConfig {
  dataSource: DataSource;
  schema: string;                    // default: 'recibos'
  tenantResolver: () => string;
  userResolver: () => UserRef;       // modo B: usuários vêm do host
  manageUsers: boolean;              // modo A: true — o módulo administra usuários
  storage: StorageAdapter;
  mailer?: MailerAdapter;
  license: LicenseProvider;          // cliente Klavo ou provider offline
  publicVerifyBaseUrl: string;
}
```

**Regras de fronteira:**
- Numeração, encadeamento de hash, valor por extenso, snapshot e selo vivem só no núcleo. Nunca reimplementados no host.
- Nenhuma FK cruza para o schema do host. A ligação com o pagamento de freelancer é por `external_ref` (string opaca) + `external_source`.
- No modo B, o módulo não gerencia usuários nem licença — herda os do host. O sistema de freelancers já é licenciado à parte.

---

## 5. Modelo de dados

Schema `recibos`. Todas as tabelas com `tenant_id` e RLS ativa.

```sql
-- ---------- cadastros ----------
companies (
  id, tenant_id, razao_social, nome_fantasia, tipo_pessoa,
  cnpj_cpf, inscricao_estadual, inscricao_municipal,
  logradouro, numero, complemento, bairro, cidade, uf, cep,
  telefone, email, logo_asset_id, cidade_padrao_emissao,
  aviso_rodape TEXT, criado_em, atualizado_em, ativo
)

counterparties (                       -- a outra parte, nas duas direções
  id, tenant_id, tipo_pessoa,
  nome_razao_social, nome_fantasia, cpf_cnpj,
  inscricao_estadual, inscricao_municipal,
  pis_nit,                             -- PF prestadora; pré-requisito do RPA
  logradouro, numero, complemento, bairro, cidade, uf, cep,
  telefone, email,
  chave_pix, banco, agencia, conta,    -- usado quando a empresa paga
  observacoes, criado_em, atualizado_em, ativo
)

series (
  id, tenant_id, company_id, codigo, descricao,
  direcao ENUM('RECEBIMENTO','PAGAMENTO'),   -- fixa, imutável após o 1º uso
  proximo_numero BIGINT, ativo, criado_em
  -- UNIQUE (company_id, codigo)
)

users (                                -- modo A apenas
  id, tenant_id, nome, email, papel,
  status ENUM('CONVIDADO','ATIVO','INATIVO'),
  senha_hash, mfa_secret, ultimo_acesso,
  convidado_por, convidado_em, criado_em
  -- UNIQUE (tenant_id, email)
  -- nunca deletado: referenciado por recibos selados
)

user_series_permissions (user_id, series_id)   -- restringe onde cada um emite

assets (id, tenant_id, tipo, mime, bytes_sha256, tamanho, storage_key, criado_em)

-- ---------- rascunho (mutável) ----------
receipt_drafts (
  id, tenant_id, company_id, series_id, counterparty_id,
  direcao, valor_centavos, descricao, natureza, forma_pagamento,
  data_pagamento, local_pagamento, referencia,
  assinatura_asset_id, signatario_nome, signatario_documento,
  criado_por, criado_em, atualizado_em
)

-- ---------- documento selado (append-only) ----------
receipts (
  id, tenant_id, company_id, series_id,
  direcao, numero BIGINT, serie_codigo, numero_formatado,
  codigo_verificacao,
  valor_centavos BIGINT, valor_extenso TEXT,
  descricao, natureza, forma_pagamento,
  data_pagamento DATE, local_pagamento, referencia,

  credor_snapshot JSONB,               -- quem recebeu e dá quitação
  devedor_snapshot JSONB,              -- quem pagou
  emitente_papel ENUM('CREDOR','DEVEDOR'),
  counterparty_id,                     -- referência ao cadastro de origem

  logo_asset_id, logo_sha256,
  assinatura_asset_id, assinatura_sha256,
  signatario_nome, signatario_documento,

  external_source, external_ref,       -- ex.: 'freelancers' / pagamento #8842

  -- reservado ao módulo RPA; sempre NULL na v1
  retencao_inss_centavos BIGINT,
  retencao_irrf_centavos BIGINT,
  retencao_iss_centavos BIGINT,
  valor_liquido_centavos BIGINT,
  tabela_retencao_versao TEXT,

  hash_documento CHAR(64), hash_anterior CHAR(64),
  sequencia_cadeia BIGINT, versao_payload SMALLINT,
  emitido_por, emitido_em TIMESTAMPTZ
  -- UNIQUE (company_id, series_id, numero)
  -- UNIQUE (tenant_id, codigo_verificacao)
)

receipt_cancellations (receipt_id PK, tenant_id, motivo NOT NULL, cancelado_por, cancelado_em)

receipt_events (id, tenant_id, receipt_id, tipo, usuario_id, ip INET, user_agent, metadata JSONB, ocorrido_em)

-- ---------- licenciamento ----------
license_state (
  tenant_id PK, klavo_contract_id, plano,
  status ENUM('ATIVA','SUSPENSA','CANCELADA'),
  limites JSONB,                       -- empresas, usuários, recibos/mês
  modulos TEXT[],                      -- ex.: ['rpa','relatorios']
  token_atual TEXT, valido_ate TIMESTAMPTZ,
  ultima_sincronizacao, atualizado_em
)

usage_counters (tenant_id, competencia DATE, recibos_selados, PRIMARY KEY(tenant_id, competencia))
```

**Por que gravar credor e devedor como snapshots separados, em vez de derivar da direção na leitura:** o documento selado precisa ser legível sem executar regra de negócio. Daqui a cinco anos, um auditor abre a linha e vê quem recebeu e quem pagou, sem depender de o código de 2026 ainda existir.

**Por que reservar as colunas de retenção agora, mesmo sem o RPA:** `receipts` é tabela imutável, com permissão de `INSERT` apenas e trigger bloqueando alteração. Acrescentar colunas depois exige mexer na estrutura de uma tabela protegida, em cima de documentos já selados — a pior migration possível. Cinco colunas nulas custam espaço desprezível hoje e evitam esse problema quando o módulo entrar. As colunas ficam fora do payload do hash enquanto forem nulas; ao ativar o RPA, entram com `versao_payload` incrementada, e os documentos antigos continuam validando pela versão com que foram selados.

---

## 6. Imutabilidade

Seis camadas. Nenhuma sozinha é suficiente.

**6.1 Permissões de banco** — o papel da aplicação tem `SELECT, INSERT` em `receipts` e `receipt_events`. Sem `UPDATE`, sem `DELETE`.

**6.2 Triggers de bloqueio**
```sql
CREATE TRIGGER trg_receipts_immutable
BEFORE UPDATE OR DELETE ON recibos.receipts
FOR EACH ROW EXECUTE FUNCTION recibos.raise_immutable();
```

**6.3 Snapshot de dados** — `credor_snapshot`, `devedor_snapshot` e `logo_sha256` congelam tudo no selo. Alteração posterior de cadastro não toca em documento emitido.

**6.4 Encadeamento de hash** — cadeia por `company_id`.

```
payload_canonico = JSON com chaves ordenadas, UTF-8 NFC, sem espaços, contendo:
  direcao, numero_formatado, valor_centavos, descricao, natureza,
  forma_pagamento, data_pagamento, local_pagamento, referencia,
  credor_snapshot, devedor_snapshot, emitente_papel,
  logo_sha256, assinatura_sha256, signatario_nome,
  external_source, external_ref, emitido_por, emitido_em (ISO-8601 UTC)

hash_documento = SHA256( payload_canonico || hash_anterior )
```

Primeiro recibo da empresa usa `hash_anterior = '0' × 64`. A canonicalização é função isolada, versionada em `versao_payload`, com teste de regressão.

**6.5 Cancelamento por contra-registro** — nunca apaga nem altera. Insere linha com motivo obrigatório. O número fica permanentemente consumido, o documento imprime tarja **CANCELADO**, a página pública mostra o status, o hash original permanece válido.

**6.6 Comando de verificação** — `recibos verify-chain --company <id>` recalcula toda a cadeia e reporta a primeira divergência.

---

## 7. Numeração

- Formato `{SERIE}-{NUMERO:06d}` — ex.: `R-000124`, `P-000031`, `F-000087`
- Escopo do sequencial: **empresa + série**
- **Nunca `SEQUENCE` ou `SERIAL`** — não fazem rollback e produzem buracos, inaceitável em documento de quitação
- Mecanismo: `SELECT proximo_numero FROM series WHERE id = ? FOR UPDATE` dentro da transação de emissão
- A `direcao` da série é imutável depois do primeiro documento emitido nela

---

## 8. Usuários da empresa

Módulo ativo apenas no **modo A**. No modo embarcado, os usuários são os do sistema hospedeiro.

**Papéis:**

| Papel | Pode |
|---|---|
| **Proprietário** | tudo, incluindo convidar usuários e ver a licença |
| **Supervisor** | emitir, cancelar (com motivo), ver auditoria |
| **Emissor** | emitir apenas nas séries permitidas; não cancela |
| **Auditor** | ler tudo, exportar; não emite nem cancela |

**Segregação de funções.** A permissão é por série, não global. Na prática isso separa quem pode registrar entrada de dinheiro de quem pode registrar saída — um emissor pode ter acesso à série R e nenhum acesso à série P. É controle interno básico, e é o tipo de coisa que o contador do cliente vai pedir.

**Ciclo de vida:**
- Convite por e-mail com token de uso único e validade de 7 dias
- Usuário **nunca é excluído**, só passa a `INATIVO` — `receipts.emitido_por` e a trilha de auditoria apontam para ele permanentemente
- Desativar revoga sessões imediatamente
- MFA por TOTP, opcional na v1, obrigatório para proprietário e supervisor a partir da v2
- O limite de usuários vem do plano da licença Klavo — atingido o teto, o convite é bloqueado com mensagem que diz qual plano resolve

---

## 9. Licenciamento via Klavo

**Divisão de responsabilidade:** Klavo administra contrato, plano, cobrança e emissão de licença. O gerador de recibos apenas valida e reporta uso. Nada de cadastro comercial duplicado.

**9.1 Provisionamento**
Contrato ativado no Klavo → webhook `contract.activated` → o produto cria tenant, empresa inicial, série padrão e usuário proprietário, e dispara o e-mail de primeiro acesso. Onboarding sem intervenção manual.

**9.2 Formato da licença**
Token assinado (JWT, RS256 ou EdDSA), verificado contra o JWKS público do Klavo. Claims:

```json
{
  "iss": "https://api.useklavo.com.br",
  "sub": "tenant_019f…",
  "aud": "ravapi-recibos",
  "contrato": "KLV-2026-0184",
  "plano": "profissional",
  "limites": { "empresas": 3, "usuarios": 10, "recibos_mes": 500 },
  "modulos": ["relatorios"],
  "status": "ativa",
  "exp": 1757635200
}
```

Validade curta (24 h a 7 dias), renovação em background. O produto guarda a chave pública em cache e acompanha rotação via JWKS.

**9.3 Indisponibilidade do Klavo**
Período de tolerância de **7 dias** operando com a última licença válida. O licenciador cair nunca pode derrubar o cliente.

**9.4 Suspensão por inadimplência — o ponto mais importante desta seção**

Quando o Klavo marca a licença como suspensa:

| Continua funcionando | Fica bloqueado |
|---|---|
| Ler e buscar recibos emitidos | Selar novo recibo |
| Imprimir e gerar PDF | Criar empresa, série ou usuário |
| Verificação pública pelo QR | |
| Exportar a base completa | |
| Cancelar recibo (com motivo) | |

Documento de quitação já emitido pertence ao cliente e tem efeito legal. Bloquear o acesso a ele por questão comercial seria indefensável — e provavelmente inválido. **Isso precisa estar escrito no contrato de licença do Klavo**, não só no código.

**9.5 Medição de uso**
Recibos selados por competência contados em `usage_counters` e reportados ao Klavo por evento assíncrono na fila, idempotente por `(tenant, competência)`. Serve a planos por volume.

**9.6 Encerramento de contrato**
Janela de exportação de 90 dias com download completo (JSON + PDFs de todos os documentos). Depois, retenção conforme prazo legal antes de qualquer descarte.

**9.7 Endpoints**
- `POST /webhooks/klavo` — assinatura HMAC, tolerância de janela temporal, idempotência por `event_id`
- `GET /license/status` — autenticado, alimenta a tela de licença
- `GET /.well-known/jwks.json` — no lado do Klavo

**9.8 Reaproveitamento futuro**
O Klavo já integra Autentique para assinatura eletrônica. Quando a assinatura avançada entrar no roteiro, o caminho é consumir essa integração em vez de construir outra.

---

## 10. Fluxo de emissão

```
[Escolher direção e série]
        │
        ▼
    [Rascunho]  ──editar livremente──┐
        │                            │
        ├─ selecionar contraparte     │
        ├─ valor, descrição, data     │
        ├─ coletar assinatura de quem recebeu (opc.)
        └─ pré-visualizar A4 ─────────┘
        │
        │  SELAR  (transação única)
        ▼
    [Selado]  → checa licença e limite do plano
              → número atribuído (FOR UPDATE)
              → credor e devedor congelados conforme a direção
              → valor por extenso gerado
              → código de verificação gerado
              → hash encadeado calculado
              → evento EMITIDO + contador de uso
              → rascunho descartado
        │
        ├──► PDF / impressão / e-mail
        └──► CANCELAMENTO (contra-registro, nunca exclusão)
```

O rascunho é a única superfície editável do sistema.

---

## 11. Valor por extenso

Gerador próprio, sem dependência externa, coberto por testes de tabela.

| Valor | Extenso esperado |
|---|---|
| 0,50 | cinquenta centavos |
| 1,00 | um real |
| 2,00 | dois reais |
| 100,00 | cem reais |
| 101,00 | cento e um reais |
| 180,00 | cento e oitenta reais |
| 1.000,00 | mil reais |
| 1.000.000,00 | um milhão de reais |
| 1.234,56 | mil, duzentos e trinta e quatro reais e cinquenta e seis centavos |
| 2.000.000,00 | dois milhões de reais |

---

## 12. Assinatura em tela

- Captura por `<canvas>`, mouse e toque, PNG transparente
- Coletada na fase de rascunho — o `assinatura_sha256` entra no payload do hash
- **Quem assina depende da direção:** recebimento → responsável da empresa; pagamento → a contraparte
- Campos `signatario_nome` e `signatario_documento` permitem representante, previsto no art. 320
- Sem assinatura capturada, imprime a linha para assinar à mão
- É assinatura eletrônica **simples** (Lei 14.063/2020). Suficiente entre particulares; a interface não deve sugerir equivalência a ICP-Brasil

---

## 13. Verificação pública e LGPD

**URL:** `https://ravapi.com/v/{codigo}`
**Código:** ULID em Crockford Base32, exibido como `XXXX-XXXX-XXXX`. Aleatório e desacoplado do número sequencial — impede varredura.

**Exibe:** nome fantasia e logo do emitente, número e série, direção, valor, data, status (válido/cancelado com data e motivo), nome da contraparte parcialmente mascarado, documento mascarado.

**Nunca exibe:** descrição do pagamento, endereços, telefones, e-mails, documento completo, dados bancários, assinatura.

**Proteções:** rate limit por IP, sem endpoint de listagem, `noindex`.

**Retenção:** mínimo de 5 anos. Exclusão de contraparte do cadastro não afeta recibos — os snapshots já estão congelados no documento.

---

## 14. Layout de impressão A4

**Página:** 210 × 297 mm, retrato, margens 10 mm. Duas vias idênticas empilhadas, corte tracejado em 148,5 mm.

**Cada via (≈ 133 mm úteis):**

| Região | Conteúdo |
|---|---|
| Topo direito | `VIA DO PAGADOR` / `VIA DO RECEBEDOR` |
| Cabeçalho | Logo (máx. 18 mm) + dados do emitente |
| Faixa de destaque | `RECIBO Nº R-000124` + valor |
| Corpo | Texto de quitação, redigido conforme a direção e o tipo de pessoa do credor |
| Detalhes | Forma de pagamento, referência, data e local |
| Rodapé | Assinatura de quem recebeu + nome e documento do signatário |
| Canto inferior direito | QR (20 × 20 mm) + código de verificação |
| Rodapé fino | Aviso configurável: não substitui nota fiscal |

**Cancelado:** tarja diagonal vermelha nas duas vias, com data.
**Renderização:** HTML + CSS via Puppeteer. Mesmo template para tela e PDF.

---

## 15. Stack

| Camada | Tecnologia |
|---|---|
| Backend | NestJS + TypeORM |
| Banco | PostgreSQL (Neon, pooler 6432, `sslmode=require`) |
| Frontend | Next.js 14 + Tailwind CSS |
| Auth | JWT com claim de tenant |
| Filas | BullMQ + Redis (e-mail, PDF em lote, medição para o Klavo) |
| PDF | Puppeteer headless |
| E-mail | PHPMailer/SMTP SSL 465 |
| Storage | Adapter — filesystem ou S3-compatible |
| Licenciamento | Klavo (api.useklavo.com.br) — JWT assinado + webhooks |

Identidade: `#2d8fff`, logo RAVAPI em SVG branco, cabeçalho de copyright nos fontes.

---

## 16. Requisitos não funcionais

- **Concorrência:** emissões simultâneas na mesma série sem duplicidade nem buraco. Teste de carga obrigatório.
- **Isolamento de tenant:** teste automatizado de tentativa de leitura cruzada.
- **Determinismo do hash:** mesma entrada serializada 1.000 vezes produz hash idêntico.
- **Resiliência de licença:** suíte que simula Klavo fora do ar, licença expirada e licença suspensa, verificando que leitura e impressão continuam.
- **PDF:** menos de 3 s por documento.
- **Backup:** exportação completa por empresa (JSON + PDFs), sob demanda do cliente.
- **Offline:** fora de escopo na v1. Reavaliar se o módulo for para o PDV.

---

## 17. Roadmap

| Fase | Entrega | Critério de aceite |
|---|---|---|
| **0** | Migrations, schema, RLS, triggers, esqueleto do `DynamicModule` | `UPDATE` em `receipts` falha; tenant A não lê tenant B |
| **1** | Empresas, contrapartes, séries com direção, upload de logo | Cadastro completo com validação de CPF/CNPJ |
| **2** | Usuários, convite, papéis, permissão por série | Emissor sem acesso à série P não consegue emitir pagamento |
| **3** | Rascunho → selo, numeração com lock, hash chain, extenso | Tabela do extenso 100% verde; 50 emissões concorrentes sem falha |
| **4** | Template A4 duas vias nas duas direções, PDF, pré-visualização | Impressão física conferida; texto correto em recebimento e pagamento |
| **5** | Assinatura em tela, QR, página pública | Documento impresso verificável por terceiro sem login |
| **6** | Cancelamento, auditoria, busca, `verify-chain` | Cancelamento não altera hash; cadeia validada por comando |
| **7** | Integração Klavo — webhooks, validação, limites, medição | Contrato ativado provisiona tenant; suspensão bloqueia só emissão |
| **8** | E-mail, duplicação, relatório CSV/XLSX | Contador recebe extrato separado por direção |
| **9** | Empacotamento `@ravapi/recibos` e integração no sistema de freelancers | Mesma base rodando nos dois modos; série F emitindo pagamento |
| **10** | Módulo RPA com retenções | *Pode ser antecipado — ver risco na seção 1* |

---

## 18. Fora de escopo (v1)

- Emissão de NF-e ou NFS-e — quem faz isso no portfólio é o Klavo
- Integração com SEFAZ ou prefeituras
- RPA com retenções de INSS, IRRF e ISS — módulo pago posterior, salvo antecipação
- Recibo de aluguel e templates especializados
- Assinatura ICP-Brasil ou Autentique
- Contas a pagar/receber, conciliação bancária, fluxo de caixa
- App mobile nativo

---

## 19. Riscos e pontos de atenção

| Risco | Mitigação |
|---|---|
| **Pagamento a PF sem retenção devida** | Alinhar com o contador de cada cliente; avaliar antecipação do RPA; aviso na interface ao emitir pagamento para contraparte PF |
| Cliente achar que recibo dispensa nota fiscal | Aviso fixo na emissão e impresso; oferecer o módulo de NFS-e do Klavo |
| Direção invertida por engano | Série com direção fixa; cor e rótulo distintos na interface; confirmação no selo |
| Canonicalização divergir entre versões | Função isolada, `versao_payload` gravada, teste de regressão |
| Klavo indisponível travar o cliente | Tolerância de 7 dias com a última licença válida |
| Suspensão bloquear documento legal do cliente | Bloqueio restrito à emissão; cláusula explícita no contrato de licença |
| Numeração travar sob carga | Lock por série, não global; monitorar espera |
| Divergência entre modo SaaS e embarcado | Suíte roda contra os dois modos no CI |

---

## 20. Pendências para fechar antes da Fase 0

1. **Retenções em pagamento a PF** — consulta ao contador. É a pendência que pode mudar o roadmap.
2. **Planos e limites do Klavo** — quais faixas, e o que cada uma libera (empresas, usuários, recibos/mês, módulos).
3. **Séries no modo embarcado** — confirmar série F dedicada ao módulo de freelancers, sempre direção pagamento.
4. **MFA** — opcional na v1 ou obrigatório desde o início para proprietário e supervisor?
5. **Storage de assets** — filesystem no Oracle Cloud ou S3-compatible desde já.
6. **Prazo de tolerância da licença** — 7 dias é proposta; alinhar com a política comercial do Klavo.

---

*Copyright (c) 2026 RAVAPI Soluções. Todos os direitos reservados. www.ravapi.com*