Matriz de Visibilidade dos Contextos

A Matriz de Visibilidade dos Contextos governa, em uma única tabela, em quais funcionalidades os dados de cada contexto podem ser usados. Quando a plataforma acumula muitos contextos, toda tela acaba listando todos: o usuário de triagem esbarra em contextos de piloto, o time de BI vê bases que não deveria usar e ninguém sabe onde cada contexto "vale". Na matriz, cada linha é um contexto cadastrado, cada coluna é uma funcionalidade, e o checkbox na interseção diz se aquele contexto aparece naquela funcionalidade — a exposição de todos os contextos governada de um lugar só, com efeito imediato.

A matriz fica no topo da tela Sistema›Contextos›Gerenciar (screens/settings-contextos.html), entre o cabeçalho e a seção "Configurações por Contexto".

Colunas (funcionalidades cobertas)

As colunas aparecem em ordem alfabética pelo nome da funcionalidade — a mesma ordem da tela:

Painel de Regras, Upload PDF e Upload URL já existiam antes da matriz, cada uma com endpoint próprio e guardada nas configurações globais da plataforma. Em 2026-09-06 elas foram migradas: hoje as sete colunas usam o mesmo endpoint e o mesmo arquivo das demais, e a palavra "legado" saiu — o que sobrou daquela época é só a nota histórica no fim desta página.

Semântica: lista vazia = todos visíveis

A regra vale para todas as colunas:

• Nenhum contexto marcado numa coluna → todos os contextos ficam visíveis naquela funcionalidade. Este é o estado inicial.
• Um ou mais marcados → somente os marcados aparecem; os demais são filtrados.

Essa semântica evita que você "se tranque": desmarcar todos os contextos de uma coluna volta ao comportamento de todos-visíveis, nunca a uma tela vazia.

Como usar

1. Acesse Sistema›Contextos›Gerenciar.
2. Na Matriz de Visibilidade dos Contextos (topo da página), localize a linha do contexto e a coluna da funcionalidade. A linha traz o rótulo de exibição do contexto, não o nome interno — o contexto de nome interno Emprestimos aparece como "Análise de Crédito — Empréstimos". Os avisos que apontam para esta matriz nomeiam o contexto nas duas formas, Rótulo (nome-interno), justamente para você achar a linha. A tabela mostra cinco contextos por vez e rola verticalmente a partir do sexto; o cabeçalho das funcionalidades e a coluna do contexto ficam fixos durante a rolagem. A lista Configurações por Contexto, logo abaixo, segue a mesma regra de cinco linhas visíveis.
3. Marque ou desmarque o checkbox. A alteração persiste imediatamente — não existe botão "Salvar" separado — e sobrevive a um reload da página.
4. Na coluna Painel de Regras, a matriz avisa a tela de regras de triagem na hora, e ela se atualiza em tempo real. Nas demais, recarregue a tela correspondente para conferir o efeito.

Permissão necessária. Ver a matriz exige CONFIG_VIEW; alterar um checkbox exige CONFIG_EDIT. Sem CONFIG_EDIT, a gravação é negada com mensagem em português. Veja o guia de roles e permissões.

Exemplo prático — restringir um contexto em piloto

Você acabou de criar o contexto "Consumidor" e quer que, por enquanto, ele apareça apenas na triagem — fora do envio de documentos:

1. Abra Sistema›Contextos›Gerenciar e localize a matriz no topo.
2. Na coluna Painel de Regras, marque todos os contextos que devem seguir visíveis — incluindo "Consumidor". (Lembre: enquanto a coluna estava vazia, todos apareciam; ao marcar, só os marcados aparecem.)
3. Nas colunas Upload PDF e Upload URL, marque todos os contextos exceto "Consumidor".
4. Cada clique persiste na hora. Recarregue a tela de regras ou de envio para conferir o efeito.

O que cada funcionalidade faz com a matriz

Painel de Regras, Upload PDF e Upload URL — aplicação ativa

A tela de regras da triagem recebe a lista de contextos já filtrada. As telas de envio (PDF e URL) filtram a lista ao carregar; se a consulta de visibilidade falhar por indisponibilidade transitória, elas degradam mostrando todos os contextos — você nunca fica sem opção por causa de uma oscilação.

Ontologia — sem tela desde 28/09/2026

A coluna Ontologia filtrava o seletor de contexto da antiga tela de Ontologia (parte da Investigação). Desde 28/09/2026 essa tela é o DATTA Investigation, o Chat no modo da pesquisa profunda: os contextos saem da barra do Chat — a sua escolha de contextos, o workspace e os contextos que você pode ler —, e a coluna Ontologia deixou de filtrar qualquer tela. A marcação continua gravada, como as colunas de governança.

DATTA BPM — aplicação ativa

O seletor de contexto do BPM respeita a matriz nos dois lugares em que ele aparece: na criação de um fluxo, no Process Modeler, e no diálogo de troca de contexto de um fluxo existente. Ao montar a lista, cada um consulta em paralelo os contextos cadastrados e os contextos visíveis para o BPM e, se a segunda lista for não-vazia, filtra os que não estão nela. Desmarcar um contexto na coluna DATTA BPM o tira das duas listas, com efeito imediato após recarregar a tela.

Como nas demais, a falha na consulta da matriz degrada aberta: o seletor volta a mostrar todos os contextos em vez de ficar vazio.

DATTABI e DATTA Extract — governança registrada

As colunas DATTABI e DATTA Extract persistem a intenção de visibilidade e expõem os flags para consumo, mas ainda não filtram as telas correspondentes. O motivo é concreto: hoje essas telas operam por conexões, datasets e referências livres, e não enumeram contextos — a extração rápida lista conexões, e o destino Neo4j do DATTABI Prep é um campo de texto livre. Assim que esses seletores passarem a enumerar contextos, poderão consumir os flags para aplicar o filtro.

Na prática: marcar ou desmarcar DATTABI e DATTA Extract registra a governança e fica disponível para consumo futuro, mas não altera o que aparece nessas telas nesta entrega. A matriz é visibilidade de interface e governança, não uma ACL de dados no servidor.

Onde a configuração fica guardada

As sete funcionalidades ficam num arquivo só, context-visibility.json, no mesmo diretório da configuração de runtime, dentro do volume de configuração da plataforma. O armazenamento usa trava de leitura/escrita mais cache em memória e aplica a semântica "lista vazia = todos visíveis".

O formato do arquivo é um mapa funcionalidade -> lista de contextos:

{
  "rules": ["CPC", "CDC"],
  "pdf": [],
  "url": ["CPC"],
  "ontology": ["processos", "cnpj"],
  "dattabi": [],
  "extract": ["processos"],
  "bpm": ["processos"]
}

Nota histórica — a migração de 2026-09-06

Até essa data, Painel de Regras, Upload PDF e Upload URL viviam em campos nomeados do runtime-config.json e tinham um par de endpoints dedicado cada uma. Os seis endpoints foram removidos, as três entraram na allowlist do endpoint genérico e os valores foram copiados para o context-visibility.json na subida do serviço, uma vez e de forma idempotente: a cópia só acontece quando a funcionalidade ainda não tem chave no arquivo novo, então uma alteração feita pela tela depois da migração nunca é sobrescrita. Depois de copiados, os campos antigos foram limpos do runtime-config.json.

Duas consequências que valem saber:

• Voltar a plataforma para uma imagem anterior à migração não devolve a configuração. O código antigo leria as três listas vazias — e vazia significa "todos visíveis" —, então a restrição sumiria sem erro. Quem precisar reconstruí-la usa o backup do runtime-config.json ou reconfigura pela tela.
• O filtro que descartava contexto excluído na leitura continua existindo, agora só do lado do servidor que decide gravação. A resposta HTTP entrega a lista como está gravada, para as sete: filtrar ali converteria uma lista cujos nomes morreram todos em lista vazia — ou seja, em "todos visíveis" —, transformando restrição em permissão justamente quando a configuração está mais quebrada. A limpeza de verdade acontece na exclusão do contexto, que tira o nome de todas as funcionalidades.

Consultar e gravar por integração

A plataforma expõe endpoints para ler o mapa completo de funcionalidade → contextos visíveis, ler os contextos visíveis de uma funcionalidade e gravar a lista de uma funcionalidade. A leitura exige CONFIG_VIEW; a gravação exige CONFIG_EDIT. Método e caminho de cada um estão na referência de API.

Duas regras valem para essas chamadas:

• A funcionalidade é restrita por allowlist: rules, pdf, url, dattabi, extract, ontology e bpm. Qualquer outro valor é recusado com uma mensagem em português no formato {"error": "Funcionalidade desconhecida: <feature>"}.
• Na gravação, a lista de contextos ausente ou nula é tratada como lista vazia — ou seja, volta ao estado de todos-visíveis.

Limitações conhecidas

• DATTABI, DATTA Extract e Ontologia sem filtro de tela. Os flags são persistidos e expostos, mas as telas ainda não filtram contextos (a Ontologia, desde que a tela virou o DATTA Investigation, em 28/09/2026). O passo seguinte é consumir os flags quando os seletores dessas telas passarem a enumerar contextos.
• Governança de interface, não ACL de dados. A matriz não restringe acesso a dados no servidor por contexto — ela controla o que aparece nas telas. Restrição de dados por contexto é escopo de outra spec.

Diagnóstico