M4 implementada e backlog validado

docs/adr/ADR-001-teto-de-privilegio-do-agente.md

@@ -0,0 +1,20 @@
+# ADR-001: Fronteira de MaximumEntitlement no MCP Client
+
+**Status:** Aceito.
+**Fonte:** `docs/RI-PLANNING.md` §8.4 (tabela de ADRs), linha ADR-001 — gerado a partir dela por EP-16-T03. Onde a RI tem um componente/teste concreto implementando a decisão, este documento aponta para ele; a tabela em si continua a referência primária e mais atualizada.
+
+## Contexto
+
+Quem define o teto de privilégio do agente.
+
+## Decisão
+
+MCP Client (identidade autenticada) é a fronteira de `MaximumEntitlement`, nunca o agente/prompt.
+
+## Alternativas consideradas
+
+Autorização por role autodeclarado do agente.
+
+## Consequências
+
+Todo design de EP-01/EP-04 gira em torno da identidade do client, não do agente.

docs/adr/ADR-002-enforcement-no-gateway.md

@@ -0,0 +1,20 @@
+# ADR-002: MCP Gateway como PEP unico
+
+**Status:** Aceito.
+**Fonte:** `docs/RI-PLANNING.md` §8.4 (tabela de ADRs), linha ADR-002 — gerado a partir dela por EP-16-T03. Onde a RI tem um componente/teste concreto implementando a decisão, este documento aponta para ele; a tabela em si continua a referência primária e mais atualizada.
+
+## Contexto
+
+Onde aplicar enforcement.
+
+## Decisão
+
+MCP Gateway é o único PEP; nunca delega decisão ALLOW/DENY ao LLM.
+
+## Alternativas consideradas
+
+Enforcement distribuído em cada MCP Server.
+
+## Consequências
+
+Centraliza EP-05; servidores de domínio (EP-06) não reimplementam authz.

docs/adr/ADR-003-reautorizacao-de-tools-call.md

@@ -0,0 +1,20 @@
+# ADR-003: Reautorizacao independente em tools/call
+
+**Status:** Aceito.
+**Fonte:** `docs/RI-PLANNING.md` §8.4 (tabela de ADRs), linha ADR-003 — gerado a partir dela por EP-16-T03. Onde a RI tem um componente/teste concreto implementando a decisão, este documento aponta para ele; a tabela em si continua a referência primária e mais atualizada.
+
+## Contexto
+
+`tools/list` filtrado é suficiente?
+
+## Decisão
+
+Não — `tools/call` deve ser reautorizado independentemente do discovery.
+
+## Alternativas consideradas
+
+Confiar apenas em filtered discovery.
+
+## Consequências
+
+EP-05 implementa dois pontos de enforcement, não um.

docs/adr/ADR-004-contexto-nunca-eleva-privilegio.md

@@ -0,0 +1,20 @@
+# ADR-004: Contexto agentico nunca eleva privilegio
+
+**Status:** Aceito.
+**Fonte:** `docs/RI-PLANNING.md` §8.4 (tabela de ADRs), linha ADR-004 — gerado a partir dela por EP-16-T03. Onde a RI tem um componente/teste concreto implementando a decisão, este documento aponta para ele; a tabela em si continua a referência primária e mais atualizada.
+
+## Contexto
+
+Contexto agêntico pode elevar privilégio?
+
+## Decisão
+
+Nunca — contexto só pode subtrair (`Context may subtract, must never add`).
+
+## Alternativas consideradas
+
+Permitir elevação mediante "confiança" do modelo.
+
+## Consequências
+
+Testes de EP-15 (Teste 3/4) validam a invariante.

docs/adr/ADR-005-cache-privado-de-tools-list.md

@@ -0,0 +1,20 @@
+# ADR-005: Cache privado de tools/list
+
+**Status:** Aceito.
+**Fonte:** `docs/RI-PLANNING.md` §8.4 (tabela de ADRs), linha ADR-005 — gerado a partir dela por EP-16-T03. Onde a RI tem um componente/teste concreto implementando a decisão, este documento aponta para ele; a tabela em si continua a referência primária e mais atualizada.
+
+## Contexto
+
+Cache de `tools/list` entre clients.
+
+## Decisão
+
+`cacheScope=private`, chave = identidade+contexto+policy_version.
+
+## Alternativas consideradas
+
+Cache compartilhado por performance.
+
+## Consequências
+
+EP-05-T03; teste dedicado de isolamento (EP-15).

docs/adr/ADR-006-sem-token-passthrough.md

@@ -0,0 +1,20 @@
+# ADR-006: Proibicao de token passthrough
+
+**Status:** Aceito.
+**Fonte:** `docs/RI-PLANNING.md` §8.4 (tabela de ADRs), linha ADR-006 — gerado a partir dela por EP-16-T03. Onde a RI tem um componente/teste concreto implementando a decisão, este documento aponta para ele; a tabela em si continua a referência primária e mais atualizada.
+
+## Contexto
+
+Token do agente pode ser repassado ao backend?
+
+## Decisão
+
+Não — proibido blind token passthrough; inbound ≠ outbound identity.
+
+## Alternativas consideradas
+
+Passthrough direto do token do client.
+
+## Consequências
+
+EP-07 implementa exchange/service account por backend.

docs/adr/ADR-007-backend-nao-exposto-diretamente.md

@@ -0,0 +1,20 @@
+# ADR-007: Backend nunca exposto diretamente ao client
+
+**Status:** Aceito.
+**Fonte:** `docs/RI-PLANNING.md` §8.4 (tabela de ADRs), linha ADR-007 — gerado a partir dela por EP-16-T03. Onde a RI tem um componente/teste concreto implementando a decisão, este documento aponta para ele; a tabela em si continua a referência primária e mais atualizada.
+
+## Contexto
+
+Backend acessível diretamente pelo client?
+
+## Decisão
+
+Não — rede/identidade restringem acesso só ao Gateway/Fabric.
+
+## Alternativas consideradas
+
+Expor Fabric publicamente com authz "best effort".
+
+## Consequências
+
+EP-05-T07, EP-15 (teste de bypass).

docs/adr/ADR-008-segmentacao-por-dominio-e-risco.md

@@ -0,0 +1,20 @@
+# ADR-008: Segmentacao de clients por dominio e risk tier
+
+**Status:** Aceito.
+**Fonte:** `docs/RI-PLANNING.md` §8.4 (tabela de ADRs), linha ADR-008 — gerado a partir dela por EP-16-T03. Onde a RI tem um componente/teste concreto implementando a decisão, este documento aponta para ele; a tabela em si continua a referência primária e mais atualizada.
+
+## Contexto
+
+Como segmentar clients.
+
+## Decisão
+
+Por domínio + risk tier (R0–R4), não um client global.
+
+## Alternativas consideradas
+
+Um client "enterprise admin" único.
+
+## Consequências
+
+Define P6 (granularidade) e EP-04.

docs/adr/ADR-009-risk-tiers-de-capabilities.md

@@ -0,0 +1,20 @@
+# ADR-009: Risk tiers R0-R4 para capabilities
+
+**Status:** Aceito.
+**Fonte:** `docs/RI-PLANNING.md` §8.4 (tabela de ADRs), linha ADR-009 — gerado a partir dela por EP-16-T03. Onde a RI tem um componente/teste concreto implementando a decisão, este documento aponta para ele; a tabela em si continua a referência primária e mais atualizada.
+
+## Contexto
+
+Como classificar capabilities.
+
+## Decisão
+
+Risk tiers R0–R4 no Registry, controlando aprovação/observabilidade exigidas.
+
+## Alternativas consideradas
+
+Sem classificação formal.
+
+## Consequências
+
+EP-02-T01 inclui `risk_tier` obrigatório no schema do manifesto.

docs/adr/ADR-010-governanca-do-registry.md

@@ -0,0 +1,20 @@
+# ADR-010: Governanca do Global Capability Registry
+
+**Status:** Aceito.
+**Fonte:** `docs/RI-PLANNING.md` §8.4 (tabela de ADRs), linha ADR-010 — gerado a partir dela por EP-16-T03. Onde a RI tem um componente/teste concreto implementando a decisão, este documento aponta para ele; a tabela em si continua a referência primária e mais atualizada.
+
+## Contexto
+
+Governança do Global Capability Registry (título e número herdados de §49 do README — "Global Capability Registry Governance").
+
+## Decisão
+
+O Registry é um control-plane asset (§6.6) com autoridade e ciclo de vida próprios, separados da visão de catálogo entregue a cada client. Na RI: armazenamento e API de leitura dedicados (EP-02-T03), consumidos por Gateway/Fabric/Offering Filter mas nunca editados por eles; lifecycle formal nominate→review→register→publish→observe→(change|deprecate→retire) (§23) implementado como máquina de estados (EP-02-T04); toda alteração passa pelo publishing pipeline (EP-02-T02) — nenhum cadastro manual direto em produção (RF-11). Owner organizacional do Registry (quem aprova mudanças de schema/política do próprio control plane) permanece uma decisão de governança corporativa fora do escopo técnico da RI (§48, pergunta 4, segue aberta).
+
+## Alternativas consideradas
+
+Deixar o Registry como uma tabela editável ad hoc por qualquer serviço; fundir a visão de controle (Registry) com a visão de execução (catálogo filtrado por client), o que violaria a separação control plane/data plane do §24.
+
+## Consequências
+
+EP-02 inteiro; reforça que EP-05 (Gateway) e EP-10 (Offering Filter) só leem o Registry, nunca escrevem nele.

docs/adr/ADR-011-pipeline-de-publicacao.md

@@ -0,0 +1,20 @@
+# ADR-011: Pipeline obrigatorio de publicacao de capabilities
+
+**Status:** Aceito.
+**Fonte:** `docs/RI-PLANNING.md` §8.4 (tabela de ADRs), linha ADR-011 — gerado a partir dela por EP-16-T03. Onde a RI tem um componente/teste concreto implementando a decisão, este documento aponta para ele; a tabela em si continua a referência primária e mais atualizada.
+
+## Contexto
+
+Ciclo de publicação de capabilities.
+
+## Decisão
+
+Pipeline obrigatório com gates de schema/risco/policy/health antes de entrar no Registry — sem cadastro manual em produção.
+
+## Alternativas consideradas
+
+Registro direto via API administrativa sem pipeline.
+
+## Consequências
+
+EP-02-T02 implementa o gate; nenhuma capability "nasce" já publicada.

docs/adr/ADR-012-entitlement-manager-como-autoridade.md

@@ -0,0 +1,20 @@
+# ADR-012: Entitlement Manager como autoridade unica de MaximumEntitlement
+
+**Status:** Aceito.
+**Fonte:** `docs/RI-PLANNING.md` §8.4 (tabela de ADRs), linha ADR-012 — gerado a partir dela por EP-16-T03. Onde a RI tem um componente/teste concreto implementando a decisão, este documento aponta para ele; a tabela em si continua a referência primária e mais atualizada.
+
+## Contexto
+
+Autoridade do cardápio máximo.
+
+## Decisão
+
+Entitlement Manager é a única autoridade de `MaximumEntitlement`; não faz ranking nem confia em atributos autodeclarados do LLM.
+
+## Alternativas consideradas
+
+Fundir Entitlement Manager e Offering Filter num único componente.
+
+## Consequências
+
+Mantém EP-04 e EP-10 como serviços/módulos distintos com contratos próprios.

docs/adr/ADR-013-contrato-de-profile-intelligence.md

@@ -0,0 +1,20 @@
+# ADR-013: Contrato plugavel de Profile Intelligence
+
+**Status:** Aceito.
+**Fonte:** `docs/RI-PLANNING.md` §8.4 (tabela de ADRs), linha ADR-013 — gerado a partir dela por EP-16-T03. Onde a RI tem um componente/teste concreto implementando a decisão, este documento aponta para ele; a tabela em si continua a referência primária e mais atualizada.
+
+## Contexto
+
+Contrato de Profile Intelligence.
+
+## Decisão
+
+Interface genérica e substituível (`ProfileView` versionado, com `reasonCodes`), implementação plugável.
+
+## Alternativas consideradas
+
+Acoplar a um vendor/taxonomia específica de segmentação.
+
+## Consequências
+
+EP-09 define apenas o contrato + stub de referência (ver P7).

docs/adr/ADR-014-perfil-nunca-amplia-entitlement.md

@@ -0,0 +1,20 @@
+# ADR-014: Perfil nunca amplia entitlement
+
+**Status:** Aceito.
+**Fonte:** `docs/RI-PLANNING.md` §8.4 (tabela de ADRs), linha ADR-014 — gerado a partir dela por EP-16-T03. Onde a RI tem um componente/teste concreto implementando a decisão, este documento aponta para ele; a tabela em si continua a referência primária e mais atualizada.
+
+## Contexto
+
+Perfil pode ampliar entitlement?
+
+## Decisão
+
+Nunca — `FilteredOfferings ⊆ MaximumEntitlement`, perfil só ordena/reduz.
+
+## Alternativas consideradas
+
+Perfil de alto engajamento desbloqueando novas tools.
+
+## Consequências
+
+EP-10-T02 traz teste de propriedade validando a invariante para entradas aleatórias.

docs/adr/ADR-015-nba-nao-e-autorizacao.md

@@ -0,0 +1,20 @@
+# ADR-015: NBA como decisao de orquestracao, nao de autorizacao
+
+**Status:** Aceito.
+**Fonte:** `docs/RI-PLANNING.md` §8.4 (tabela de ADRs), linha ADR-015 — gerado a partir dela por EP-16-T03. Onde a RI tem um componente/teste concreto implementando a decisão, este documento aponta para ele; a tabela em si continua a referência primária e mais atualizada.
+
+## Contexto
+
+NBA é decisão de autorização?
+
+## Decisão
+
+Não — é intenção de orquestração; Gateway/PDP reautorizam toda execução.
+
+## Alternativas consideradas
+
+Orchestrator despachar direto para o backend sem passar pelo Gateway.
+
+## Consequências
+
+EP-11-T04 implementa o branch de DENY/recálculo do §10.1.

docs/adr/ADR-016-contrato-de-dispatch-handoff.md

@@ -0,0 +1,20 @@
+# ADR-016: Contrato de dispatch/handoff do Agent Runtime
+
+**Status:** Aceito.
+**Fonte:** `docs/RI-PLANNING.md` §8.4 (tabela de ADRs), linha ADR-016 — gerado a partir dela por EP-16-T03. Onde a RI tem um componente/teste concreto implementando a decisão, este documento aponta para ele; a tabela em si continua a referência primária e mais atualizada.
+
+## Contexto
+
+Contrato de dispatch/handoff do Agent Runtime.
+
+## Decisão
+
+Objeto de dispatch versionado (`decisionId`, `expiresAt`, `reasonCodes`) que não substitui o token do MCP Client.
+
+## Alternativas consideradas
+
+Runtime injetar credenciais próprias no agente.
+
+## Consequências
+
+EP-12-T01 consome exclusivamente o dispatch object + MCP Client já existente.

docs/adr/ADR-017-correlacao-ponta-a-ponta.md

@@ -0,0 +1,20 @@
+# ADR-017: Correlacao ponta a ponta via IDs versionados
+
+**Status:** Aceito.
+**Fonte:** `docs/RI-PLANNING.md` §8.4 (tabela de ADRs), linha ADR-017 — gerado a partir dela por EP-16-T03. Onde a RI tem um componente/teste concreto implementando a decisão, este documento aponta para ele; a tabela em si continua a referência primária e mais atualizada.
+
+## Contexto
+
+Correlação ponta a ponta.
+
+## Decisão
+
+`profileVersion`+`entitlementVersion`+`decisionId`+`policyDecisionId`+`mcpRequestId` propagados via OTel/trace context em todos os componentes.
+
+## Alternativas consideradas
+
+Correlação apenas por log textual sem padrão.
+
+## Consequências
+
+EP-08-T03 formaliza os campos; base para EP-15 (auditabilidade).

docs/adr/ADR-018-stack-de-implementacao.md

@@ -0,0 +1,59 @@
+# ADR-018: Stack de implementacao da RI
+
+**Status:** Aceito.
+**Fonte:** `docs/RI-PLANNING.md` §8.4 (tabela de ADRs), linha ADR-018 — gerado a partir dela por EP-16-T03. Onde a RI tem um componente/teste concreto implementando a decisão, este documento aponta para ele; a tabela em si continua a referência primária e mais atualizada.
+
+## Contexto
+
+Stack de implementação da RI (fecha G2).
+
+## Decisão
+
+Python 3.12+, `uv`, Pydantic v2, YAML declarativo com JSON Schema, SDK oficial `mcp`.
+
+## Alternativas consideradas
+
+Node/TypeScript (SDK MCP também oficial); Go.
+
+## Consequências
+
+Define toda a estrutura de repositório (8.5).
+
+## Versões confirmadas (EP-16-T04)
+
+Spike sem dependências, executável a qualquer momento (`docs/RI-PLANNING.md`
+EP-16-T04): confirmar, imediatamente antes de fixar em `pyproject.toml`/
+`docker-compose.yml`, os números exatos de versão estável de cada peça da
+stack — nenhuma versão citada em código/config sem confirmação real
+(`pip index versions`/download direto/instalação real), nunca de memória.
+Registro consolidado, com a data em que cada grupo foi verificado (ver
+`RI/README.md`, "Versões fixadas", para a mesma lista mantida junto ao
+`pyproject.toml`):
+
+Confirmadas em 2026-09-11:
+
+- `mcp` 2.2.0 (SDK Python v2 — API mudou significativamente da v1; ver
+  comentários em `src/emcp_bus/gateway/server.py`)
+- `pydantic` 2.13.x, `opentelemetry-sdk` 1.44.x, `uvicorn` 0.52.x,
+  `pyjwt[crypto]` 2.14.x, `ruff` 0.16.x, `mypy` 2.3.x, `pytest` 9.1.x
+- `OPA` 1.20.2 (binário estático, sintaxe Rego v1 como padrão)
+- `pytest-forked` 1.7.x
+
+Confirmadas em 2026-09-14 (M3/M4, via instalação/`docker pull` reais):
+
+- `langgraph` 0.6.x + `langgraph-checkpoint-sqlite` 2.x (EP-11)
+- `hypothesis` 6.1xx.x (dev, EP-10-T02)
+- `openai` 1.109.x (EP-13-T01)
+- `python-dotenv` 1.2.x (dev)
+- `types-jsonschema` 4.26.x (dev, stubs para `mypy --strict`; `jsonschema`
+  em si já era dependência transitiva de `mcp[cli]`, EP-15-T01)
+- Langfuse self-hosted 4.35.0 (`docker.langfuse.com/langfuse/langfuse:4`,
+  imagem oficial, EP-13-T02)
+- Keycloak 26.7.3 (`quay.io/keycloak/keycloak:26.7.3`, Quarkus; Standard
+  Token Exchange GA desde 26.2 — EP-01-T01/EP-07)
+- `opentelemetry-collector-contrib` 0.114.0 e `jaeger` (all-in-one) 1.62.0
+  (perfil `observability` do `docker-compose.yml`, EP-08-T04)
+
+Nenhuma versão acima foi alterada desde a confirmação original — este
+registro é o ponto único de verdade que `RI/README.md` linka de volta para
+cá.

docs/adr/ADR-020-downstream-identity.md

@@ -0,0 +1,20 @@
+# ADR-020: Downstream identity: token exchange ou service account isolado
+
+**Status:** Aceito.
+**Fonte:** `docs/RI-PLANNING.md` §8.4 (tabela de ADRs), linha ADR-020 — gerado a partir dela por EP-16-T03. Onde a RI tem um componente/teste concreto implementando a decisão, este documento aponta para ele; a tabela em si continua a referência primária e mais atualizada.
+
+## Contexto
+
+Downstream identity na RI (fecha G5/P5).
+
+## Decisão
+
+Token exchange (RFC 8693) quando backend suporta OIDC; senão service account isolado por adapter.
+
+## Alternativas consideradas
+
+Reutilizar sempre o token do client (proibido por ADR-006).
+
+## Consequências
+
+EP-07; documentado por backend em manifesto.

docs/adr/ADR-021-escopo-langgraph-langfuse.md

@@ -0,0 +1,20 @@
+# ADR-021: Escopo de LangGraph e Langfuse na RI
+
+**Status:** Aceito.
+**Fonte:** `docs/RI-PLANNING.md` §8.4 (tabela de ADRs), linha ADR-021 — gerado a partir dela por EP-16-T03. Onde a RI tem um componente/teste concreto implementando a decisão, este documento aponta para ele; a tabela em si continua a referência primária e mais atualizada.
+
+## Contexto
+
+Escopo de LangGraph/Langfuse (fecha G8/P8).
+
+## Decisão
+
+LangGraph somente no Service Orchestrator (EP-11) e handoff do Agent Runtime (EP-12); Langfuse somente onde há chamada real a LLM (EP-13). Checkpointer: SQLite em dev.
+
+## Alternativas consideradas
+
+Usar LangGraph também no Gateway/Fabric para "consistência de stack".
+
+## Consequências
+
+Evita over-engineering vetado pela seção 6 do superprompt; Gateway/Fabric continuam Python puro.

docs/adr/ADR-022-referencia-hoshikawa-agent-platform-oci.md

@@ -0,0 +1,20 @@
+# ADR-022: Referencia operacional: Agent Platform OCI (Hoshikawa)
+
+**Status:** Aceito.
+**Fonte:** `docs/RI-PLANNING.md` §8.4 (tabela de ADRs), linha ADR-022 — gerado a partir dela por EP-16-T03. Onde a RI tem um componente/teste concreto implementando a decisão, este documento aponta para ele; a tabela em si continua a referência primária e mais atualizada.
+
+## Contexto
+
+Referência concreta de implementação Python/LangGraph/Langfuse (fecha G2 — **decisão confirmada pelo autor em 2026-09-11**).
+
+## Decisão
+
+Adotar como referência operacional o "Agent Platform OCI" de Christiano Hoshikawa (`github.com/hoshikawa2/agent_platform_oci`): StateGraph com router/supervisor por backend + camada superior de roteamento entre backends (nosso EP-11/EP-12); checkpointing plugável (memory/sqlite/mongodb/produção — nós adotamos SQLite em dev, ver ADR-021); taxonomia de observabilidade **IC/NOC/GRL** via Langfuse (evento de negócio/operacional/guardrail), com instrumentação híbrida (span automático por nó + emissão manual fail-open); `identity.yaml`/`BusinessContext` para normalizar identidade de negócio entre canais; FastMCP como padrão de servidor MCP. Análise completa registrada em `docs/research/hoshikawa-agent-platform-oci.md`.
+
+## Alternativas consideradas
+
+Continuar com o padrão genérico da seção 6 do superprompt sem referência concreta de terceiros (mais lento, mais decisões ad hoc); adotar um framework de agentes de mercado (CrewAI, AutoGen) em vez de LangGraph puro.
+
+## Consequências
+
+Muda a forma (não a segurança) de EP-08, EP-11, EP-12, EP-13 — ver ADR-023 para o limite explícito do que NÃO é adotado.

docs/adr/ADR-023-autorizacao-nunca-vem-do-payload.md

@@ -0,0 +1,20 @@
+# ADR-023: Autorizacao de tools nunca vem de campo declarado no payload
+
+**Status:** Aceito.
+**Fonte:** `docs/RI-PLANNING.md` §8.4 (tabela de ADRs), linha ADR-023 — gerado a partir dela por EP-16-T03. Onde a RI tem um componente/teste concreto implementando a decisão, este documento aponta para ele; a tabela em si continua a referência primária e mais atualizada.
+
+## Contexto
+
+Autorização de tools NUNCA vem de um campo declarado no payload/conversa (achado crítico da análise do Hoshikawa, reforça ADR-001/002/003).
+
+## Decisão
+
+O MCP Gateway do Agent Platform OCI autoriza tools por um allowlist estático (`tools.yaml`/`authorization.agents.<agent_id>.allowed_tools`) avaliado sobre `agent_id`, campo que chega como **dado do payload de entrada da conversa**, não como claim de uma identidade autenticada verificada independentemente — a própria SPEC-004 deles admite que isso não substitui autenticação/autorização real. Nossa RI reaproveita a *forma* de proxy desse MCP Gateway (contratos `ToolInvocation`/`ToolResult`, cache por tool idempotente, catálogo `/v1/tools`) **exclusivamente na camada de Fabric (EP-06)/UX conversacional**, mas a decisão ALLOW/DENY continua 100% no nosso PEP (EP-05) consultando o PDP (EP-03) com a identidade autenticada do MCP Client (EP-01) — nunca com `agent_id`/`tenant_id` autodeclarado no payload.
+
+## Alternativas consideradas
+
+Reaproveitar também o bloco `authorization` deles como atalho de implementação.
+
+## Consequências
+
+EP-15-T03 ganha um cenário adversarial explícito de "payload-declared agent_id spoofing" (variação do Teste 4, §45) para provar que esse vetor específico está fechado na nossa RI.

docs/adr/ADR-024-posicionamento-multiagente.md

@@ -0,0 +1,20 @@
+# ADR-024: Posicionamento do E-MCP-BUS frente a plataformas multiagente externas
+
+**Status:** Aceito.
+**Fonte:** `docs/RI-PLANNING.md` §8.4 (tabela de ADRs), linha ADR-024 — gerado a partir dela por EP-16-T03. Onde a RI tem um componente/teste concreto implementando a decisão, este documento aponta para ele; a tabela em si continua a referência primária e mais atualizada.
+
+## Contexto
+
+Posicionamento do E-MCP-BUS em relação a plataformas de orquestração multiagente externas, como o Agent Platform OCI (**decisão confirmada e ampliada pelo autor em 2026-09-11** — resolve G11).
+
+## Decisão
+
+O E-MCP-BUS **não compete** com plataformas de orquestração como o Agent Platform OCI — mas também **não se limita a coexistir sob elas**. Princípio de design explícito: **modularidade + compatibilidade = escolha**. Nosso Service Orchestrator (EP-11) não é um passa-through fino: ele calcula NBA **e NBO** (Next Best Action/Next Best Offer) com um modelo de decisão próprio (regras + guardrails +, opcionalmente, um modelo de IA de ranking/recomendação — ver EP-11-T03) sobre o universo de `FilteredOfferings` que o MCP Fabric expõe (serviços, ofertas, ações, campanhas — não só "tools" técnicas). Isso habilita **dois modos de integração igualmente válidos, escolhidos pelo adotante conforme a topologia desejada**: **(A) Governança-somente** — uma plataforma de orquestração externa (ex.: Agent Platform OCI, com seu próprio Global Supervisor e StateGraph decidindo NBA) conecta-se ao E-MCP-BUS apenas para acesso governado ao Fabric; nosso Service Orchestrator não participa, ou participa apenas como fonte de `FilteredOfferings` (como já descrito no restante deste ADR e em EP-13-T05). **(B) Substituição completa** — nosso próprio Service Orchestrator (EP-11) assume integralmente o papel de "cérebro" de decisão (NBA/NBO), dispensando o Global Supervisor/StateGraph de decisão da plataforma externa; o Agent Runtime (EP-12) e os channel adapters da plataforma externa (ex.: os backends de agente do Hoshikawa) tornam-se meros executores do dispatch que nosso Orchestrator produz. Em qualquer um dos dois modos, o núcleo de segurança (PEP/PDP, EP-05/EP-03) nunca muda de lugar — apenas quem calcula a NBA/NBO muda. Em ambos os modos, cada backend/agente de domínio continua registrado como um **MCP Client distinto** (EP-01), vinculado a um client profile/entitlement próprio por domínio+risk tier (EP-04, P6), e o "MCP Gateway" interno de qualquer plataforma consumidora (ADR-023) é sempre substituído pelo nosso Gateway/PEP como único ponto de autorização. Isso é a "elevação a Enterprise": catálogo/entitlement/auditoria governados centralmente, com a decisão de NBA/NBO podendo vir de dentro (modo B) ou de fora (modo A) do bus, por escolha modular do adotante.
+
+## Alternativas consideradas
+
+Forçar um único modo de integração (ex.: só "governança-somente"), o que subutilizaria o Service Orchestrator e obrigaria sempre uma plataforma externa de decisão; tratar o Agent Platform OCI como um substituto do E-MCP-BUS (incorreto — ele não resolve entitlement); reimplementar do zero a engenharia de orquestração já validada em ADR-022 mesmo quando o modo B é escolhido (a forma StateGraph/checkpointing/handoff continua reaproveitável dentro do nosso EP-11/EP-12).
+
+## Consequências
+
+Reformula o objetivo de EP-11 (Service Orchestrator explicitamente descrito como calculador de NBA **e NBO** sobre serviços/ofertas/ações do Fabric, com modelo de decisão pluggable) e de EP-13 (demonstra os dois modos — ver EP-13-T05 para o modo A e EP-13-T06, novo, para o modo B). Reforça que EP-06/EP-05 tratam qualquer "MCP Gateway" de uma plataforma consumidora como não-confiável para autorização, nos dois modos.

docs/adr/ADR-025-engine-do-pdp.md

@@ -0,0 +1,20 @@
+# ADR-025: OPA/Rego como engine do PDP
+
+**Status:** Aceito.
+**Fonte:** `docs/RI-PLANNING.md` §8.4 (tabela de ADRs), linha ADR-025 — gerado a partir dela por EP-16-T03. Onde a RI tem um componente/teste concreto implementando a decisão, este documento aponta para ele; a tabela em si continua a referência primária e mais atualizada.
+
+## Contexto
+
+Engine do PDP (fecha G3 — **decisão confirmada pelo autor em 2026-09-11**; renumerado de ADR-010 para ADR-025 em 2026-09-11 para não colidir com o ADR-010 do README, "Global Capability Registry Governance").
+
+## Decisão
+
+OPA/Rego, self-hosted, OSS (Apache-2.0). Decisão definitiva, não sujeita a revisão. **Verificado em 2026-09-11 via busca web**: OPA está em v1.0+, com sintaxe Rego v1 como padrão (breaking change vs. v0) — EP-03 deve escrever policies em sintaxe Rego v1 desde o início.
+
+## Alternativas consideradas
+
+Cedar (AWS, cita-se em §43.2); engine própria em Python.
+
+## Consequências
+
+EP-03 inteiro fica acoplado à API REST do OPA; policies versionadas como código em Rego v1.