M3 implementada e backlog atualizado

docs/RI-PLANNING.md

@@ -1508,14 +1508,31 @@ backlog:
 
 | Marco | Tarefas | Critério de "pronto" |
 |---|---|---|
-| **M0 — Walking skeleton** | EP-00-T01, EP-00-T02, EP-00-T04, EP-06-T02, EP-05-T01, EP-08-T01 | Cliente MCP → Gateway → (roteamento estático) → MCP Server de exemplo (Sales) → resposta, com `trace_id` correlacionado visível em log/coletor OTel. Sem enforcement real ainda. |
-| **M1 — Segurança núcleo (Fase 1 do README) ✅ concluído (2026-09-11)** | EP-01 completo, EP-03 completo, EP-04 completo, EP-05-T02/T03/T04/T06/T07/T08, EP-02-T01/T02/T03/T05 (via M2), EP-06-T01/T03/T04, EP-08-T02/T03/T04 | `tools/list` filtrado por entitlement real (Keycloak+OPA), `tools/call` reautorizado, cache privado, fail-closed, anti-bypass, auditoria completa. Cobre RF-01 a RF-09 e Fases 0–2 do roadmap do README. **Adendo (2026-09-11, fechamento retroativo pós-M2)**: todos os itens acima que ainda restavam abertos após o M2 (EP-01-T04/T05, EP-05-T03/T07/T08, EP-06-T01/T03/T04, EP-08-T02/T03/T04) foram implementados nesta rodada — Fabric router real (multi-backend, EP-06-T01), segundo domínio Finance com backend real (EP-06-T03), adapter REST genérico standalone (EP-06-T04), taxonomia de auditoria IC/NOC/GRL + correlação decisionId/policyDecisionId/entitlementVersion (EP-08-T02/T03), stack local otel-collector+Jaeger (EP-08-T04), cache hint SEP-2549 (EP-05-T03 — ver limitação de wire-mode abaixo), segmentação de rede + gate de credencial nos domain servers (EP-05-T07), validação header/body Mcp-Method/Mcp-Name (EP-05-T08), lint de shared client (EP-01-T05), spike de mTLS documentado em `docs/adr/ADR-019-identity-extension.md` (EP-01-T04). **Limitação real descoberta e documentada**: SEP-2549 (`ttlMs`) é vocabulário exclusivo do protocolo 2026-07-28, que só existe no modo *stateless per-request* do SDK (`server/discover`, sem handshake `initialize`) — esta RI usa o handshake de sessão clássico em toda parte, então o campo nunca chega ao wire nesta arquitetura (o SDK descarta o campo na serialização para versões de protocolo anteriores); `cache_scope="private"` e o não-caching server-side já garantem a propriedade de segurança do Teste 5 independentemente disso. Ver `src/emcp_bus/gateway/cache.py`. **EP-00-T03 (pipeline de CI)**, apesar de não listado nesta linha, também foi implementado (`.github/workflows/ci.yml`). |
-| **M2 — Governança e downstream ✅ concluído (2026-09-11)** | EP-02 completo (T01-T05, incluindo T02/T03/T05 adiados do M1), EP-04-T04, EP-07 completo, EP-14 completo | Publishing pipeline com lifecycle completo, outbound identity sem passthrough, aprovação humana funcionando fail-closed — todos ligados ao Gateway real (EP-05) e testados com OPA real. Cobre RF-10, RF-11, Fase 3 parcial. Detalhes e limitações em `RI/README.md`. **Adendo (2026-09-11, mesmo dia — Docker e Java passaram a estar disponíveis no ambiente)**: `docker-compose.yml` validado com daemon Docker real (build/up/fail-closed/trace cross-container), e **EP-01-T01 (Keycloak) implementado e validado com Keycloak 26.7.3 real** (`deploy/keycloak/realm-export.json`, perfil `identity` no compose, `tests/e2e/test_real_keycloak.py`) — item que a linha do M1 acima já citava como pré-requisito ("Keycloak+OPA") mas que só foi de fato implementado/testado agora. |
-| **M3 — Personalização e orquestração (Fase 4 do README)** | EP-09, EP-10, EP-11, EP-12, EP-13-T01..T04 | Perfil→entitlement→ofertas filtradas→NBA→dispatch→execução MCP funcionando ponta a ponta com LangGraph no Orchestrator e Langfuse no agente de exemplo. Cobre RF-12 a RF-17. |
+| **M0 — Walking skeleton ✅ concluído (2026-09-11, revalidado 2026-09-14)** | EP-00-T01, EP-00-T02, EP-00-T04, EP-06-T02, EP-05-T01, EP-08-T01 | Cliente MCP → Gateway → (roteamento estático) → MCP Server de exemplo (Sales) → resposta, com `trace_id` correlacionado visível em log/coletor OTel. Sem enforcement real ainda. Critério satisfeito desde a implementação inicial; hoje o roteamento deixou de ser estático (EP-06-T01, ver M1), mas o próprio trace correlacionado do walking skeleton continua coberto por `tests/e2e/test_walking_skeleton.py`. |
+| **M1 — Segurança núcleo (Fase 1 do README) ✅ concluído (2026-09-11, revalidado 2026-09-14)** | EP-01 completo, EP-03 completo, EP-04 completo, EP-05-T02/T03/T04/T06/T07/T08, EP-02-T01/T02/T03/T05 (via M2), EP-06-T01/T03/T04, EP-08-T02/T03/T04 | `tools/list` filtrado por entitlement real (Keycloak+OPA), `tools/call` reautorizado, cache privado, fail-closed, anti-bypass, auditoria completa. Cobre RF-01 a RF-09 e Fases 0–2 do roadmap do README. **Adendo (2026-09-11, fechamento retroativo pós-M2)**: todos os itens acima que ainda restavam abertos após o M2 (EP-01-T04/T05, EP-05-T03/T07/T08, EP-06-T01/T03/T04, EP-08-T02/T03/T04) foram implementados nesta rodada — Fabric router real (multi-backend, EP-06-T01), segundo domínio Finance com backend real (EP-06-T03), adapter REST genérico standalone (EP-06-T04), taxonomia de auditoria IC/NOC/GRL + correlação decisionId/policyDecisionId/entitlementVersion (EP-08-T02/T03), stack local otel-collector+Jaeger (EP-08-T04), cache hint SEP-2549 (EP-05-T03 — ver limitação de wire-mode abaixo), segmentação de rede + gate de credencial nos domain servers (EP-05-T07), validação header/body Mcp-Method/Mcp-Name (EP-05-T08), lint de shared client (EP-01-T05), spike de mTLS documentado em `docs/adr/ADR-019-identity-extension.md` (EP-01-T04). **Limitação real descoberta e documentada**: SEP-2549 (`ttlMs`) é vocabulário exclusivo do protocolo 2026-07-28, que só existe no modo *stateless per-request* do SDK (`server/discover`, sem handshake `initialize`) — esta RI usa o handshake de sessão clássico em toda parte, então o campo nunca chega ao wire nesta arquitetura (o SDK descarta o campo na serialização para versões de protocolo anteriores); `cache_scope="private"` e o não-caching server-side já garantem a propriedade de segurança do Teste 5 independentemente disso. Ver `src/emcp_bus/gateway/cache.py`. **EP-00-T03 (pipeline de CI)**, apesar de não listado nesta linha, também foi implementado (`.github/workflows/ci.yml`). **Adendo (2026-09-14, revalidação de prontidão)**: reinstalação limpa do `.venv` (3 dias depois, mesmo ambiente) + `make lint`/`make typecheck`/`make validate-schemas`/`make export-schemas` (sem diff) + suíte completa `--forked` → **119/119 testes passando** (97 unit + 22 e2e), sem nenhuma falha — confirma que o commit `f3efcc3` ("M0 e M1 revisados e fixes implementados") capturou exatamente o estado validado na sessão anterior, sem drift. |
+| **M2 — Governança e downstream ✅ concluído (2026-09-11, revalidado 2026-09-14)** | EP-02 completo (T01-T05, incluindo T02/T03/T05 adiados do M1), EP-04-T04, EP-07 completo, EP-14 completo | Publishing pipeline com lifecycle completo, outbound identity sem passthrough, aprovação humana funcionando fail-closed — todos ligados ao Gateway real (EP-05) e testados com OPA real. Cobre RF-10, RF-11, Fase 3 parcial. Detalhes e limitações em `RI/README.md`. **Adendo (2026-09-11, mesmo dia — Docker e Java passaram a estar disponíveis no ambiente)**: `docker-compose.yml` validado com daemon Docker real (build/up/fail-closed/trace cross-container), e **EP-01-T01 (Keycloak) implementado e validado com Keycloak 26.7.3 real** (`deploy/keycloak/realm-export.json`, perfil `identity` no compose, `tests/e2e/test_real_keycloak.py`) — item que a linha do M1 acima já citava como pré-requisito ("Keycloak+OPA") mas que só foi de fato implementado/testado agora. Ciclo de aprovação (EP-14) hoje testado e2e tanto contra Sales quanto contra Finance (EP-06-T03, ver M1). |
+| **M3 — Personalização e orquestração (Fase 4 do README) ✅ concluído (2026-09-14)** | EP-09, EP-10, EP-11, EP-12, EP-13-T01..T04 | Perfil→entitlement→ofertas filtradas→NBA→dispatch→execução MCP funcionando ponta a ponta com LangGraph no Orchestrator e Langfuse no agente de exemplo. Cobre RF-12 a RF-17. **EP-09 (Profile Intelligence) ✅** — `src/emcp_bus/profile_intelligence/{models,rule_based_provider,governance}.py`: contrato `ProfileView` (T01), provider determinístico rule-based (T02), guardrails de governança — pseudonimização, lineage log, stub de drift monitor (T03). **EP-10 (Offering Filter) ✅** — `src/emcp_bus/offering_filter/service.py`: `FilteredOfferings = ActiveCatalog ∩ MaximumEntitlement ∩ ConsentContext` (T01); invariante de subconjunto provada com Hypothesis, 2000 casos gerados (T02). **EP-11 (Service Orchestrator) ✅** — `src/emcp_bus/orchestrator/*.py`: `DecisionContext` versionado (T01); `StateGraph` real do LangGraph 0.6 com checkpointer SQLite, nós fixos resolve_profile→resolve_entitlement→filter_offerings→decide_nba→approval_gate (T02); `NBADecisionModel` pluggable + referência determinística (T03); recálculo/degradação após DENY como edge condicional, nunca chamando o Fabric diretamente (T04); interrupção human-in-the-loop via `langgraph.types.interrupt`/`Command(resume=...)`, integrada a EP-14 (T05) — validado contra OPA real + LangGraph real + checkpointer SQLite real, incluindo prova de que retomar de um checkpoint pausado não reprocessa nós já executados. **EP-12 (Agent Runtime) ✅** — `src/emcp_bus/agent_runtime/*.py`: serviço de dispatch que nunca gera/armazena credencial própria, usa exclusivamente o MCP Client já registrado via `client_credentials` real (T01); channel adapter conversacional + registro com falha explícita para canal não suportado (T02); handoff com minimização de contexto e resolução de entitlement sempre independente por agente (T03, `could`); Identity Resolver/BusinessContext declarativo (`config/orchestrator/identity.yaml`), nunca consultado pelo PDP — checado mecanicamente via AST (T04). Validado com **Keycloak real + Gateway real**: `AgentDispatcher` alcançando o backend Sales real e sendo negado no cross-domain, e dois agentes reais (`sales-read-agent`/`finance-payments-agent`) obtendo tokens `client_credentials` independentes. **EP-13-T01..T04 (Agente de exemplo + Langfuse) ✅** — `agents/example_agent/`: agente conversacional com tool-calling **real** (endpoint OpenAI-compatible da OCI Generative AI, `meta.llama-3.3-70b-instruct`, tool-calling confirmado empiricamente 2026-09-14), catálogo restrito ao `tools/list` do próprio client — cenário de prompt injection do §29 reproduzido de verdade contra o Gateway/PDP reais (T01); Langfuse self-hosted real (`deploy/langfuse/docker-compose.override.yml`, adaptado do compose oficial upstream, perfil `llm-observability` opt-in) — **subida de verdade e validada**: 6 containers (web/worker/postgres/clickhouse/redis/minio) saudáveis, spans de MCP e de generation (com `gen_ai.request.model`/tokens reais) confirmados fisicamente na tabela `events_core` do ClickHouse via o endpoint OTLP real do Langfuse (`/api/public/otel/v1/traces`) — validação manual documentada em `RI/README.md`, não um teste e2e automatizado (custo de subir 6 containers a cada run) (T02); redação de PII/segredos antes de qualquer export (`src/emcp_bus/common/pii_redaction.py`, T03); versionamento de prompt local (`agents/example_agent/prompts/store.py`) como núcleo testável do "nunca sobrescreve versão anterior" — sync real para a API de Prompt Management do Langfuse documentado como adapter fino não implementado nesta sessão (T04, `could`). Dependências novas: `langgraph`, `langgraph-checkpoint-sqlite`, `hypothesis`, `openai`, `python-dotenv`. **201 testes automatizados no total** (171 unit + 30 e2e, todos passando com `--forked`, incluindo os novos testes reais de LLM/Keycloak/OPA/LangGraph do M3 — nenhum mock no núcleo de segurança ou orquestração). |
 | **M4 — Hardening e entrega** | EP-13-T05, EP-13-T06 (could), EP-15 completo, EP-16 completo | Suíte de 10 testes de aceite (§45) e cenários adversariais (§46, incluindo o de EP-15-T03/ADR-023) passando contra a stack completa; **os dois modos de integração do ADR-024 demonstrados** — Modo A (EP-13-T05: Global Supervisor externo, dois backends/MCP Clients, handoff sem elevação de privilégio) e, se o tempo permitir, Modo B (EP-13-T06: nosso Service Orchestrator como único cérebro de NBA/NBO, mesma stack de segurança); ADRs documentados; README da RI publicado. |
 
 **Caminho crítico:** EP-00 → EP-01/EP-06 (paralelos) → EP-05 (núcleo do PEP) → EP-02/EP-03/EP-04 (entitlement real) → EP-08 (correlação) → EP-09/EP-10 → EP-11 (Orchestrator) → EP-12/EP-13 → EP-15 (validação) → EP-16 (entrega). EP-07 e EP-14 podem ser paralelizados a partir de M1 sem bloquear o caminho principal até M3.
 
+### Nível de prontidão para M4 (avaliado em 2026-09-14, atualizado após conclusão do M3)
+
+**M0, M1, M2 e M3 estão concluídos** (ver linha do M3 na tabela acima para o detalhamento tarefa-a-tarefa — EP-09 a EP-12 completos, EP-13-T01..T04 completos). Caminho crítico até M4 (`... → EP-11 → EP-12/EP-13 → EP-15 (validação) → EP-16 (entrega)`): EP-11 (Orchestrator, LangGraph real) e EP-12/EP-13 (Agent Runtime + agente de exemplo) — os itens que o caminho crítico original citava como pré-requisito do M4 — estão implementados e testados contra dependências reais (OPA, Keycloak, LangGraph, LLM, Langfuse). **Não há bloqueio técnico para iniciar o M4** (EP-13-T05/T06, EP-15, EP-16).
+
+Ressalvas não-bloqueantes específicas do M3 (ver `RI/README.md`, seção "M3 — Personalização e orquestração" e "Limitações conhecidas", para o detalhamento completo): EP-12-T03 (handoff) tem o primitivo cross-process pronto mas nenhum subgrafo LangGraph intra-processo ainda (não há dois agentes ativos simultâneos até o EP-13-T05); EP-13-T02 (Langfuse) foi validado manualmente de verdade, não por teste e2e automatizado; EP-13-T04 (prompt versioning) tem o núcleo local pronto mas não sincroniza com a API real do Langfuse.
+
+### Nível de prontidão para M3/M4 — avaliação histórica, antes do início do M3 (2026-09-14)
+
+**M0, M1 e M2 estão 100% concluídos e revalidados** — nenhuma tarefa aberta nos três marcos (auditoria tarefa-a-tarefa contra os entregáveis reais em disco, feita nesta revisão: todo `entregavel` de EP-00 a EP-08 e EP-14 existe e está funcional). Especificamente para o caminho crítico até M3 (`EP-06 → EP-05 → EP-02/03/04 → EP-08 → EP-09/10`, ver acima): EP-06-T01 (Fabric router multi-backend) e EP-06-T03 (segundo domínio real, Finance) — os dois itens que este mesmo documento identificou como bloqueio técnico real do M3 — estão implementados e testados, assim como EP-08-T02/T03 (auditoria/correlação), também pré-requisito citado. **Não há bloqueio técnico remanescente para iniciar o M3.**
+
+Únicas ressalvas, nenhuma bloqueante:
+- **EP-06-T04** (adapter REST) implementado e testado apenas de forma standalone — nenhum backend de exemplo desta RI é REST, então não há um caminho ao vivo através do Gateway exercitando-o. Só passa a importar se um EP-09+ precisar de um backend não-MCP-nativo.
+- **EP-08-T04** (stack de observabilidade) tem a config validada (`docker compose config`) mas não foi exercitada com tráfego OTLP real end-to-end.
+- A flakiness de teste e2e que sessões anteriores documentaram como um risco de credibilidade da suíte está **resolvida** (`pytest-forked`, 119/119 testes reprodutíveis) — deixa de ser um risco a carregar para M3/M4.
+
+**Adendo (2026-09-14, resolvido durante o início do M3, a pedido do autor)**: **Token exchange RFC 8693** (modo `token_exchange` de `BackendConfig`, dentro de EP-07) deixou de ser um `NotImplementedError` — implementado em `src/emcp_bus/downstream/identity.py` (`TokenExchangeClient`) contra o Standard Token Exchange do Keycloak (GA desde 26.2, sem feature flag de preview). Validado empiricamente contra um Keycloak 26.7.3 real (não apenas suposto pela doc): (a) o parâmetro `audience` do exchange exige um **client id realmente registrado** no realm — uma string livre ("custom audience") falha com "Audience not found"; (b) pedir `audience` sem também pedir, via `scope`, um client scope que efetivamente adiciona essa audience falha com "Requested audience not available" (o parâmetro `audience` só restringe, nunca adiciona). `deploy/keycloak/realm-export.json` ganhou o client `gateway-token-exchange` (`standard.token.exchange.enabled: true`), dois clients placeholder somente-audiência (`sales-domain-service`/`finance-domain-service`, nunca usados para login) e dois client scopes (`aud-sales-domain-service`/`aud-finance-domain-service`) com `oidc-audience-mapper`. `BackendConfig` ganhou `token_exchange_scope` (novo campo obrigatório no modo `token_exchange`). `credential_for`/`CapabilityRouter.route` tornaram-se `async def` (a troca de token é uma chamada de rede) — refletido em todo o Gateway. 7 novos testes (4 unit com `httpx.MockTransport` simulando o fluxo de dois passos do Keycloak + cache; 3 e2e contra Keycloak real, incluindo um `tools/call` de ponta a ponta pelo Gateway usando uma credencial obtida por token exchange, não `SALES_DOMAIN_SERVICE_TOKEN`) — todos passando. `service_account` continua o modo padrão dos backends seed (`config/backends/*.yaml`); `token_exchange` é uma alternativa disponível e verificada, não o padrão.
+
 ---
 
 ## 8.8 Riscos principais