# Tipos de App e tenancy

> appKind, disponibilidade, modo de acesso e tenancy — a matriz canônica de arquiteturas do Ecossistema Oon.

## Tipos de App (`appKind`)

| `appKind` | Papel no ecossistema | Exemplo |
|---|---|---|
| `member-central` | Central publicada para um tenant, licença e ambiente. O caso mais comum. | Central de Compras, Central Financeira |
| `root-central` | Central de Ativações — a raiz de confiança do Ecossistema. | Central de Ativações |
| `portal-cockpit` | Portal ou cockpit transversal. | Meus Apps |

O `appKind` **não** limita a customização: páginas, componentes, layouts e temas locais funcionam em todos os tipos.

## Três dimensões independentes

- **Disponibilidade** — finalidade: `system`, `common`, `self`, `licensed`.
- **Tenancy** — isolamento: `none`, `single_tenant`, `multi_tenant`.
- **Implantação** — derivada: `none → singleton`, `single_tenant → dedicated`, `multi_tenant → shared`.

`self/single_tenant` é o uso da própria organização proprietária, sem licença comercial artificial. `licensed` admite exclusivo e compartilhado; clientes multi-tenant usam somente Produção. **Licenciamento, capacidade e autorização comercial pertencem à Central, nunca ao código do App.**

## Matriz canônica

| Categoria | tenancyModel | availability | accessMode | authorizationMode | deployment |
|---|---|---|---|---|---|
| App próprio da organização | `single_tenant` | `self` | `explicit_users` | `rbac` | `dedicated` |
| App licenciado single-tenant | `single_tenant` | `licensed` | `explicit_users` | `rbac` | `dedicated` |
| App licenciado multi-tenant | `multi_tenant` | `licensed` | `explicit_users` | `rbac` | `shared` ou `dedicated` |
| App comum tenant-aware | `multi_tenant` | `common` | `tenant_members` | `rbac` | `shared` |
| App global da Plataforma | `none` | `common` | `authenticated_users` | `rbac` | `singleton` |
| Central root | `none` | `system` | `explicit_users` | `rbac` | `singleton` |

## Regras de validação

- `root-central` exige `none/system/explicit_users/rbac/singleton`.
- Apps `member` não podem usar `availability=system`.
- `tenant_members` exige um App tenant-aware (não `none`).
- `authenticated_users` exige `tenancyModel=none`, `availability=common`, `authorizationMode=rbac` e `singleton`. Não é acesso público: exige identidade Oon ativa.
- `single_tenant` não pode usar `shared`.
- `deploymentMode` legado só é aceito quando concorda com o derivado; `hybrid` é rejeitado.

## Escopo de dados por model

Independente do tenancy do App, cada model declara seu `scope`:

| `scope` | Isolamento |
|---|---|
| `legacy` (padrão) | Sem filtro de linha. |
| `system` | Dados do sistema, sem filtro de linha. |
| `tenant` | Campo `tenantId` interno, obrigatório, imutável e indexado; filtrado pelo contexto autenticado. |
| `user` | `tenantId` (quando o App tem tenant) + `usuarioId`; cada usuário vê só os seus. |

```javascript
defineModel({ name: "Pessoa", scope: "tenant", schema: { /* ... */ } });
```

> [!WARNING]
> O `central.domain.json` desta linha não propaga `scope` para as models. Models declarativas são adequadas a Apps **single_tenant dedicados**. Para isolamento de linhas em multi-tenant, use `defineModel({ scope: "tenant" })`.

## Apps globais e tenant-alvo

Apps com `tenancyModel=none` não montam `TenantProvider`, não restauram tenant do storage e não consomem o parâmetro `tenant`. Uma sessão global não contém `tenantId`, e o header `x-oon-tenant-id` não a transforma em sessão de tenant.

Operações administrativas sobre uma organização usam um identificador próprio, como `targetTenantId`, convertido pelo backend no header `x-oon-target-tenant-id` do contrato administrativo. Esse alvo é apenas um seletor — o backend revalida usuário, tenant, membership, RBAC, entitlement e quota.

## Ambientes de Apps licenciados single-tenant

O proprietário (A) mantém os deployments de Dev, HML e Produção. Produção usa o tenant de dados do cliente (B); Dev/HML usam o tenant de dados de A, tanto para membros de A quanto para usuários autorizados de B — sem criar membership de B em A.

- `req.accessContext.tenantId` é o **contexto de dados**; `authorizationTenantId` identifica a organização da concessão.
- A Central revalida licença, grant, política e revisão do ambiente em cada requisição protegida; o Core não mantém cache positivo de autorização.
- Dev/HML são fechados para B por padrão e exigem liberação independente.
- Publicação, promoção, rollback e aceite técnico de HML são exclusivos de A.

Fonte: https://sdk.oonapps.com/docs/fundamentos/tipos-de-app-e-tenancy