@oondemand/create-central-oon 0.6.13 → 0.7.1

package/docs/AGENTS.md

@@ -28,15 +28,13 @@ O `AGENTS.md` da raiz pertence ao projeto e nunca pode ser sobrescrito pelo scaf
 | Domínio, models, validações e fórmulas | [BACKEND_API.md](BACKEND_API.md), [BACKEND_DOMAIN_MANIFEST.md](BACKEND_DOMAIN_MANIFEST.md), [BACKEND_PATTERNS.md](BACKEND_PATTERNS.md), [REACTIVE_DOMAIN_FORMULAS.md](REACTIVE_DOMAIN_FORMULAS.md) |
 | CRUD, metadata e UI | [METADATA_CRUD_UI.md](METADATA_CRUD_UI.md), [FRONTEND_API.md](FRONTEND_API.md), [FRONTEND_CODE_FIRST.md](FRONTEND_CODE_FIRST.md) |
 | Auth, ativação, tenant ou permissões | [AUTH_ACTIVATION_RBAC.md](AUTH_ACTIVATION_RBAC.md), [RBAC_SECURITY.md](RBAC_SECURITY.md), [DO_AND_DONT.md](DO_AND_DONT.md) |
-| Renderizar, visualizar ou baixar PDF | [APP_LICENSING.md](APP_LICENSING.md), [PDF_RENDERING.md](PDF_RENDERING.md), [BACKEND_API.md](BACKEND_API.md), [FRONTEND_API.md](FRONTEND_API.md) |
-| Configurar templates ou enviar e-mail | [APP_LICENSING.md](APP_LICENSING.md), [TRANSACTIONAL_EMAIL.md](TRANSACTIONAL_EMAIL.md), [RBAC_SECURITY.md](RBAC_SECURITY.md) |
+| Renderizar, visualizar ou baixar PDF | [PDF_RENDERING.md](PDF_RENDERING.md), [BACKEND_API.md](BACKEND_API.md), [FRONTEND_API.md](FRONTEND_API.md) |
+| Configurar templates ou enviar e-mail | [TRANSACTIONAL_EMAIL.md](TRANSACTIONAL_EMAIL.md), [RBAC_SECURITY.md](RBAC_SECURITY.md) |
 | Execução local | [RUNTIME_MODES.md](RUNTIME_MODES.md), [LOCAL_DEVELOPMENT.md](LOCAL_DEVELOPMENT.md), [LOCAL_SECURITY_BOUNDARY.md](LOCAL_SECURITY_BOUNDARY.md) |
-| Rotas, hooks, jobs e filas | [APP_LICENSING.md](APP_LICENSING.md), [ROUTES_HOOKS_WORKERS.md](ROUTES_HOOKS_WORKERS.md), [BACKEND_PATTERNS.md](BACKEND_PATTERNS.md) |
-| Upgrade do Core | [CORE_UPGRADE.md](CORE_UPGRADE.md), [TESTING_CONFORMANCE.md](TESTING_CONFORMANCE.md), [releases/0.6.0.md](releases/0.6.0.md) |
+| Rotas, hooks, jobs e filas | [ROUTES_HOOKS_WORKERS.md](ROUTES_HOOKS_WORKERS.md), [BACKEND_PATTERNS.md](BACKEND_PATTERNS.md) |
+| Upgrade do Core | [CORE_UPGRADE.md](CORE_UPGRADE.md), [TESTING_CONFORMANCE.md](TESTING_CONFORMANCE.md), [releases/0.7.0.md](releases/0.7.0.md) |
 | UX avançada | [ADVANCED_UX_PATTERNS.md](ADVANCED_UX_PATTERNS.md), [DETAIL_MODAL_AND_RELATED_GRIDS.md](DETAIL_MODAL_AND_RELATED_GRIDS.md), [PORTAL_COCKPIT_PATTERNS.md](PORTAL_COCKPIT_PATTERNS.md) |
 
-Antes de copiar exemplos de efeitos de negócio, determine a categoria do App pelo contrato governado. Em App comercial licenciado, aplique [APP_LICENSING.md](APP_LICENSING.md) antes de cada novo efeito. Root/globais tenantless não recebem tenant ou licença comercial artificiais; ausência de tenant em um App comercial não é isenção. Runtime local permanece sem efeitos operacionais.
-
 ## Fronteira obrigatória
 
 - O App declara domínio e experiência em código; o Core fornece bootstrap, autenticação, ativação, RBAC, tenant, CRUD, metadata, shell, componentes genéricos e deployment.
@@ -56,4 +54,3 @@ npm test
 ```
 
 Uma entrega que depende da leitura de fonte privada ou de outro App não está concluída: registre a lacuna na documentação distribuída.
-

package/docs/AGENT_WORKFLOW.md

@@ -11,7 +11,7 @@
 
 ## Regra closed-book
 
-Mantenha os três pacotes OonCore na linha 0.6.x declarada pelo App e sincronize `.ooncore` após qualquer atualização.
+Mantenha os três pacotes OonCore na linha 0.7.x declarada pelo App e sincronize `.ooncore` após qualquer atualização.
 
 Trabalhe somente com o App e sua `.ooncore/`. Não leia fonte privada, `node_modules` ou outros Apps para descobrir como usar o Core. Se faltar assinatura, declaração, exemplo, erro ou limite necessário, interrompa essa parte e registre a lacuna documental.
 

package/docs/AUTH_ACTIVATION_RBAC.md

@@ -8,7 +8,9 @@ Ativação de plataforma cria a identidade operacional usada por integrações a
 
 ## Catálogo público de perfis
 
-Todo App com RBAC declarado expõe `GET /core/role-catalog`. O contrato `schemaVersion: 1` contém apenas `appCode`, `enabled` e `roles[]` com `code`, `name`, `description` e `admin`. Permissões internas não são expostas.
+Todo App com RBAC declarado expõe `GET /core/role-catalog`. O contrato `schemaVersion: 1` contém `appCode`, `enabled` e `roles[]` com `code`, `name`, `description` e `admin`. Desde o SDK 0.7.1, a extensão aditiva opcional `roles[].commercialPermissions` publica nomes explícitos de permissões funcionais permitidas pelo papel. Wildcards são expandidos somente pelas permissões declaradas em `rbac.permissions`; wildcard literal e namespaces `tenant`, `publications`, `homologation`, `production`, `apps`, `users` e `roles` são excluídos. Políticas internas e permissões técnicas não são publicadas.
+
+O campo permanece opcional no schemaVersion 1: catálogos anteriores são conformes para descoberta e fluxos existentes. O novo aceite comercial inicial requer essa capacidade e deve falhar fechado com `APP_ROLE_CATALOG_UNAVAILABLE` quando ausente; não se infere autoridade do nome admin. Consumidores antigos devem tolerar campos adicionais. O runtime continua intersectando cada grant explícito com a política local atual.
 
 O catálogo serve para descoberta e seleção de perfis pelo Control Plane. Ele não concede acesso: o backend consumidor deve validar `schemaVersion` e `appCode`, consultar somente o Deployment resolvido pela plataforma, revalidar o perfil antes de persistir o grant e falhar fechado quando o catálogo estiver ausente ou inválido.
 

package/docs/BACKEND_API.md

@@ -38,12 +38,7 @@ O namespace público `capabilities` contém:
 
 O App nunca configura URL, credencial interna ou implementação de uma capability. A única exceção é a injeção de dublês documentada para testes automatizados.
 
-`operationalRequestHeaders({ tenantId, correlationId })` produz headers de identidade do Deployment. O tenant vem do contexto validado e correlationId é opcional. Retorna `LOCAL_OPERATION_NOT_SUPPORTED` no runtime local; nunca improvise identidade local.
-
-## Licença por App
-
-`licensing.assertBusinessOperation` e `licensing.verifyConsumerRequest` (0.6.7):
-consulte [APP_LICENSING.md](APP_LICENSING.md) para escopo, erros, local, jobs e reconciliação.
+`operationalRequestHeaders(options)` produz headers de identidade do Deployment. Retorna `LOCAL_OPERATION_NOT_SUPPORTED` no runtime local; nunca improvise identidade local.
 
 ## Runtime local
 

package/docs/CORE_UPGRADE.md

@@ -10,8 +10,8 @@ Os três pacotes devem permanecer na mesma linha:
 
 1. Leia o `AGENTS.md` da raiz e preserve regras/domínio do projeto.
 2. Registre versões atuais, lockfiles e `central.app.json`.
-3. Atualize os três pacotes para a mesma versão `0.6.x`.
-4. Ajuste compatibilidade para `>=0.6.0 <0.7.0` somente quando a migração estiver pronta.
+3. Atualize os três pacotes para a mesma versão `0.7.x`.
+4. Ajuste compatibilidade para `>=0.7.0 <0.8.0` somente quando a migração estiver pronta.
 5. Rode `npm run ooncore:docs` e revise o diff de `.ooncore/`.
 6. Remova `DEV_TOKEN`, `VITE_DEV_TOKEN`, tokens fixos e URLs da plataforma do caminho local.
 7. Preserve `AGENTS.md` raiz, models, regras, provas e documentação do domínio.

package/docs/FRONTEND_API.md

@@ -23,18 +23,9 @@ O contrato principal do frontend é code-first.
 - `useOonApi`, `useOonResource`, `useCoreMetadata`, `useModelSchema`: acesso padronizado;
 - rotas reservadas e guards obrigatórios pertencem ao Core.
 
-## Contexto e descarte de estado por tenant
-
-`useOonTenant()` devolve `{activeTenantId: string | null, switchTenant(id), clearTenant()}`
-em Apps com tenancy. Não chame esse hook em Apps `tenancyModel=none`.
-O Core atualiza o header e limpa o cache de queries na troca. Estado React local,
-formulários, tokens de uso único e respostas assíncronas também devem ser descartados:
-uma página filha com `key={activeTenantId ?? "no-tenant"}` é uma composição possível.
-`useOonAuth().hasPermission(code)` permite ocultar ações, com autorização obrigatória
-e independente no backend. `useOonApi()` fornece `{http}` para o cliente autenticado.
-
 ## Domínio e UI
 
 Views declarativas continuam disponíveis como composição opcional dentro do
 objeto App. Componentes, páginas e layouts locais podem ser usados em qualquer
 `appKind`. Consulte `FRONTEND_CODE_FIRST.md`.
+

package/docs/PDF_RENDERING.md

@@ -21,12 +21,9 @@ Não adicione URL, usuário, senha ou implementation reference. O runtime resolv
 
 ## API pública do backend
 
-O exemplo é para **App comercial licenciado**; leia [APP_LICENSING.md](APP_LICENSING.md) antes de usá-lo. Root/globais tenantless não recebem tenant ou licença artificiais, e ausência de tenant em App comercial não dispensa o guard. A categoria não é escolhida pelo request. Runtime local não autoriza geração operacional.
-
 ```js
 const {
   capabilities,
-  licensing,
   defineRoutes,
   GenericError,
   requirePermission,
@@ -50,10 +47,6 @@ defineRoutes("/pdf", (router) => {
       res.once("close", abort);
 
       try {
-        await licensing.assertBusinessOperation({
-          tenantId: req.accessContext?.tenantId,
-          correlationId: req.id,
-        });
         const pdf = await capabilities.pdf.render(
           {
             html: req.body.html,
@@ -137,8 +130,6 @@ Nunca envie a geração diretamente a um endpoint de infraestrutura pelo navegad
 
 ## Erros
 
-O guard propaga `423` com o código comercial (por exemplo, `APP_LICENSE_SUSPENDED`) ou `503`/`LICENSE_AUTHORITY_UNAVAILABLE`. Preserve o erro no tratamento padrão do Core, mostre o motivo e mantenha a operação pendente; não capture para continuar a geração nem devolva sucesso. O frontend deve tratar esses status também quando a resposta foi solicitada como blob. Contexto comercial ausente também impede a geração.
-
 `PdfRenderingError` expõe `code`, `statusCode`, `retryable` e detalhes sanitizados.
 
 | Código | Retry | Significado |
@@ -153,7 +144,7 @@ O guard propaga `423` com o código comercial (por exemplo, `APP_LICENSE_SUSPEND
 | `PDF_RENDERING_TRANSPORT_ERROR` | sim | falha transitória de transporte |
 | `PDF_RENDERING_INVALID_OUTPUT` | sim | saída inválida ou acima do limite |
 
-Use retentativas da capability apenas quando `error.retryable === true`, com backoff e idempotência na operação chamadora. Cada nova tentativa de geração deve passar novamente pelo guard; uma decisão anterior ou um job já aceito não autoriza a próxima chamada. A consulta é pontual, não atômica com o start: não cancela nem desfaz geração já iniciada. Downloads de documentos já produzidos não iniciam nova geração e seguem as regras de acesso existentes.
+Use retentativas apenas quando `error.retryable === true`, com backoff e idempotência na operação chamadora.
 
 ## Segurança e runtime local
 
@@ -164,4 +155,3 @@ Use retentativas da capability apenas quando `error.retryable === true`, com bac
 - propague cancelamento do request por `AbortSignal`;
 - no runtime local, a capability falha fechado com `PDF_RENDERING_UNAVAILABLE` quando não resolvida;
 - em testes automatizados, um transport fake pode ser injetado por `capabilities.configurePdfRendering` e deve devolver bytes iniciados por `%PDF-`; não gere um “PDF” textual falso no código do App.
-

package/docs/TRANSACTIONAL_EMAIL.md

@@ -54,16 +54,10 @@ Templates usam somente interpolação Handlebars escapada. Blocos, helpers, sube
 
 ## Envio no backend
 
-Leia [APP_LICENSING.md](APP_LICENSING.md). O exemplo de **App comercial licenciado** demonstra somente a revalidação antes de enfileirar, verificável com mocks isolados. **Não habilita envio comercial assíncrono operacional**: a pendência do executor abaixo precisa ser resolvida antes disso. Root/globais tenantless seguem autoridade/RBAC próprios, sem tenant ou licença artificiais. A categoria não vem do request; tenant ausente em App comercial não é isenção. Runtime local não autoriza envio operacional.
-
 ```js
-const { capabilities, licensing } = require("@oondemand/oon-core-back");
+const { capabilities } = require("@oondemand/oon-core-back");
 
 async function enviarConfirmacao({ email, nome, idempotencyKey }, req) {
-  await licensing.assertBusinessOperation({
-    tenantId: req.accessContext?.tenantId,
-    correlationId: req.id,
-  });
   return capabilities.transactionalEmail.send(
     {
       templateCode: "confirmacao",
@@ -83,14 +77,6 @@ async function enviarConfirmacao({ email, nome, idempotencyKey }, req) {
 
 `idempotencyKey` é obrigatória. O retorno é `{ dispatchId, status, correlationId }`; `status` é `accepted` ou `duplicate`. Não trate `accepted` como entrega confirmada.
 
-### Licenciamento, fila e retentativas
-
-O guard propaga `423` com o código comercial (por exemplo, `APP_LICENSE_SUSPENDED`) ou `503`/`LICENSE_AUTHORITY_UNAVAILABLE`. Preserve status/código no tratamento padrão do Core, mostre o motivo e mantenha a operação pendente, sem enfileirar ou devolver sucesso. Contexto comercial ausente também impede o enqueue. Não use pagamento, cache positivo ou captura do erro como autorização.
-
-A autorização no enqueue não autoriza um envio futuro. O executor precisa revalidar a autoridade e o contexto antes de **cada tentativa** no provedor, inclusive retry automático e retry de dead letter. Em OonCore 0.6.10, este exemplo não comprova essa integração no worker; não há neste contrato uma opção pública para adicioná-la. Não habilite esse caminho comercial até existir contrato/implementação e prova isolada de suspensão ou revogação entre enqueue e envio, indisponibilidade, contexto divergente e retentativa. Não contorne essa lacuna acessando internals do SDK ou criando executor paralelo no App.
-
-Mesmo uma revalidação correta é pontual e não atômica com o envio: não cancela chamada já iniciada nem desfaz e-mail aceito pelo provedor. Recibos, callbacks, reconciliação e histórico de efeitos anteriores devem continuar acessíveis conforme suas regras; não confunda essas operações com um novo envio. `accepted` e `duplicate` não são comprovantes de autorização duradoura nem de entrega.
-
 Outras operações públicas do namespace `capabilities.transactionalEmail` incluem preview e versionamento de templates, consulta de dispatches e retry de dead letter. Para administração interativa, prefira o componente do Core.
 
 ## Painel administrativo
@@ -123,4 +109,3 @@ O componente usa as rotas autenticadas em `/core/transactional-email/*`. Credenc
 - erros usam `TransactionalEmailError` e códigos `EMAIL_*` sanitizados;
 - no runtime local, falhe fechado até a capability e seu secret store/configuração estarem disponíveis;
 - testes devem substituir a fronteira externa; não envie e-mail real e não grave credenciais de teste.
-

package/docs/releases/0.7.0.md

@@ -0,0 +1,9 @@
+# OonCore 0.7.0 — Novo Ecossistema Oon
+
+Esta linha é o marco de compatibilidade com a identidade operacional por deployment e a autorização comercial single-tenant do novo ecossistema.
+
+Atualize Core Back, Core Front e create-central-oon juntos. Declare compatibilidade `>=0.7.0 <0.8.0` após validar a migração e sincronize `.ooncore`.
+
+A abertura por `oon_launch` valida a nova sessão antes de persistir token e tenant. Seleção anterior não acompanha o handshake; logout ou login posterior cancelam a troca pendente. A Central continua sendo a autoridade para tenant, licença, grant, ambiente e deployment.
+
+Nenhuma regra de licenciamento deve ser implementada no domínio do App. Após atualizar as dependências, execute docs check, conformance, typecheck e testes; publique e homologue o runtime consumidor com a Central compatível. A atualização do pacote não publica nem migra automaticamente Apps.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@oondemand/create-central-oon",
-  "version": "0.6.13",
+  "version": "0.7.1",
   "repository": {
     "type": "git",
     "url": "git+https://github.com/oondemand/oon-platform.git",

package/templates/_base/backend/package.json

@@ -12,6 +12,6 @@
     "deploy": "oonCore-back deploy"
   },
   "dependencies": {
-    "@oondemand/oon-core-back": "^0.6.13"
+    "@oondemand/oon-core-back": "^0.7.1"
   }
 }

package/templates/_base/frontend/package.json

@@ -11,7 +11,7 @@
     "sync:metadata": "oonCore-front sync:metadata"
   },
   "dependencies": {
-    "@oondemand/oon-core-front": "^0.6.13",
+    "@oondemand/oon-core-front": "^0.7.1",
     "@chakra-ui/react": "^3.13.0",
     "@emotion/react": "^11.14.0",
     "@tanstack/react-query": "^5.65.0",

package/templates/_base/package.json

@@ -13,6 +13,6 @@
     "dev:frontend": "npm run dev --prefix frontend"
   },
   "devDependencies": {
-    "@oondemand/create-central-oon": "0.6.13"
+    "@oondemand/create-central-oon": "0.7.1"
   }
 }

package/docs/APP_LICENSING.md

@@ -1,75 +0,0 @@
-# Licença comercial por aplicativo — contrato 1 (Core 0.6.7)
-
-Disponível no namespace público `licensing` de `@oondemand/oon-core-back`.
-Requer a Central de Ativações com `/licensing/decision` e `/licensing/identity`.
-O SDK não substitui autenticação, RBAC, vínculo de Deployment ou licença organizacional.
-
-```js
-const { licensing } = require("@oondemand/oon-core-back");
-await licensing.assertBusinessOperation({ tenantId: accessContext.tenantId, correlationId });
-// Inicie agora o efeito autorizado: PDF, e-mail, emissão ou mutação externa.
-```
-
-Chame imediatamente antes de **cada novo efeito**, inclusive em jobs aceitos anteriormente.
-Não guarde autorização no JWT, snapshot ou cache positivo. A decisão é uma leitura pontual;
-uma suspensão posterior não cancela uma chamada já iniciada nem desfaz um efeito confirmado.
-Preserve recibos, callbacks, reconciliação, downloads já gerados e histórico sem reiniciar efeitos.
-
-O Core usa identidade operacional do próprio Deployment e a autoridade configurada pelo
-runtime. O App não configura URL da Central, credencial interna ou transporte paralelo.
-Timeout de 3 segundos, sem redirects, sem retry e sem cache positivo. Resposta ausente,
-incompatível ou de outro escopo retorna `LICENSE_AUTHORITY_UNAVAILABLE` (503).
-Runtime local não pode obter identidade operacional: `LOCAL_OPERATION_NOT_SUPPORTED`.
-Em testes unitários, injete o guard na camada de domínio; isso nunca habilita operação local real.
-
-Um contrato bloqueado retorna HTTP 423 com código `APP_LICENSE_REQUIRED`,
-`APP_LICENSE_NOT_STARTED`, `APP_LICENSE_EXPIRED`, `APP_LICENSE_SUSPENDED`,
-`APP_LICENSE_CANCELLED`, `APP_LICENSE_OVERDUE` ou `APP_LICENSE_INVALID`.
-Bloqueios organizacionais e de entitlement também são preservados.
-Exiba a razão comercial; deixe a operação pendente. Pagamento não renova nem reativa sozinho.
-
-## Aplicabilidade: comercial, root/global e local
-
-O guard abaixo se aplica a novos efeitos de negócio de um **App comercial licenciado**, com tenant obtido do contexto autenticado do backend. A licença de uso do App e a assinatura própria do cliente são independentes; o consumidor consulta a decisão da Central, sem recalcular essas regras.
-
-Root e globais tenantless seguem sua autoridade operacional e RBAC próprios: não crie tenant, proprietário comercial ou licença fictícios para fazê-los passar pelo guard. A categoria vem do contrato governado do App, nunca de um booleano enviado pelo cliente, da ausência de tenant ou de um override de ambiente. Contexto de tenant ausente em App comercial deve falhar, sem executar o efeito.
-
-No runtime local não existe autorização operacional. Use mocks da fronteira de licenciamento e da capability somente em testes isolados; não transforme indisponibilidade em sucesso nem injete credenciais operacionais.
-
-## Gateway que recebe chamadas de outros Apps
-
-```js
-const identity = await licensing.verifyConsumerRequest({
-  headers: req.headers,
-  requireLicense: false,
-});
-// Vincule identity.{tenantId,appCode,environment} ao consumidor cadastrado no gateway.
-// Autorize base e operação no domínio do gateway, depois:
-await licensing.verifyConsumerRequest({ headers: req.headers, requireLicense: true });
-```
-
-`requireLicense` é `true` por padrão. `false` consulta apenas a identidade e vínculo
-ativo Deployment–tenant, permitindo receber/consultar evidências durante suspensão.
-**Não autoriza um efeito novo.** A autenticação específica do consumidor e sua política
-continuam obrigatórias. O bearer do gateway nunca é encaminhado à Central.
-
-Headers obrigatórios: `x-oon-deployment-id`, `x-oon-deployment-token`, `x-app-code`,
-`x-oon-tenant-id`. Eles só são confiáveis depois da validação remota. Não aceite App,
-ambiente ou tenant do body. Todas as respostas são comparadas com o escopo solicitado.
-Nenhum segredo ou diagnóstico bruto do provedor é incluído nos erros normalizados.
-
-## Resposta da autoridade
-
-`POST /licensing/decision` (body vazio): `schemaVersion: 1`, `appCode`, `tenantId`,
-`environment`, `allowed`, `code`, `version`, `checkedAt`, `maxAgeSeconds: 0`.
-Permissão exige versão positiva e código nulo; negação tem código reconhecido.
-`POST /licensing/identity`: `schemaVersion: 1`, `appCode`, `tenantId`, `environment`,
-`maxAgeSeconds: 0`. Respostas autenticadas têm `Cache-Control: no-store`.
-
-## Limite atual de jobs
-
-Este contrato oferece o guard de efeitos, não um executor durável de integrações.
-A documentação de process jobs existente não especifica registro público de handlers
-externos, inbox/outbox e retomada autônoma necessários ao gateway da issue #170.
-Essa extensão precisa de contrato e testes próprios antes de declarar I4 concluída.
-