# Governança e retenção

Leia a postura atual de governança para retenção, exclusão, exportação, limites de dados e evidências de auditoria.

- Canonical: https://docs.xmemo.dev/pt-br/docs/concepts/governance-retention
- Locale: pt-BR
- Content-Locale: pt-BR
- Canonical-Content-Digest: 64872f32f2fa2549e9b806845665721e6289a5b6fe5d9e8dc96165599625c17b
- Edition-Digest: 3e8b80ff086239178d0227b3b423604646e63e43e936a67aedfced0ca6916b31
- Source-Revision: sha256:47f2eb881bc452bf2c7284e56f7b3ce65901de5335e31c6b20f6047355dc4f40

## A retenção é gerenciada pelo serviço hoje

O MeGovernanceResponse atual informa retention.status=operator_managed e retention.available=false. As regras de retenção automática não são configuráveis por conta; as ações de arquivar, esquecer e limpar exigem uma ação explícita da conta. Esta página descreve a postura implementada, não uma promessa de cronograma automático de retenção.

```json
{
  "retention": {
    "status": "operator_managed",
    "available": false
  },
  "delete": {
    "status": "self_service",
    "available": true
  }
}
```

## Exclusão e exportação têm posturas separadas

A exclusão individual de memória é self-service. O encerramento da conta revoga o acesso e coloca em fila um fluxo de limpeza Personal; o contrato de resposta informa que os dados compartilhados com a equipe permanecem com a equipe. A exportação é um download self-service ou uma solicitação, dependendo da configuração do runtime, e os artefatos preparados expiram automaticamente.

- delete — a exclusão individual de memória em self-service está disponível.
- export — o status é self_service_download somente quando o runtime o habilita; caso contrário, request_only.
- data_boundary — limitado à conta; não é permitido acesso entre contas.

## As ações de governança deixam evidências de auditoria

A resposta de governança informa audit.status=enabled e descreve as ações da conta como emissoras de eventos de auditoria; o acesso ao log de auditoria e a exportação de auditoria em self-service continuam sendo gerenciados pela equipe do serviço. A exclusão de memória também registra o modo, a presença do motivo e as referências do alvo na fila de auditoria da memória, sem reter o conteúdo esquecido no resultado público.

```json
{
  "data_boundary": {
    "status": "account_scoped",
    "available": true
  },
  "audit": {
    "status": "enabled",
    "available": true
  }
}
```

## Verifique a postura efetiva antes de escolher um modo

O modo de segurança e a postura de governança são controles separados. O modo Cloud permite processamento no servidor; o Keyguard usa encapsulamento de chave do cliente com descriptografia temporária auditada; o Vault mantém os corpos das memórias criptografados no cliente e normalmente exige recuperação local. Escolha o tratamento de retenção, exclusão e segurança com base nos contratos de resposta atuais, sem presumir que uma única configuração controla os três.

```text
retention  = operator_managed
delete     = self_service
audit      = enabled
security   = resolve the effective Cloud, Keyguard, or Vault mode
```

## Usuário do ChatGPT

Dê ao ChatGPT acesso duradouro às suas preferências do XMemo, fatos do projeto, decisões e TODOs sem colar tokens bearer no chat.

Conecte o servidor MCP hospedado do XMemo pelo fluxo OAuth do app ChatGPT/OpenAI e aprove a concessão memory:read e memory:write para sua conta do XMemo.

Salve uma preferência de teste ou anotação de projeto, inicie um novo chat e peça ao ChatGPT para recuperá-la via XMemo antes de prosseguir.

Se o OAuth falhar ou as ferramentas não aparecerem, saia do servidor MCP no app host, reconecte a URL do servidor XMemo e tente novamente antes de criar tokens diretos.

## Desenvolvedor Copilot / Codex

Transfira decisões do repositório, convenções de código, notas de correção de bugs e histórico de tarefas entre agentes de IDE e CLI.

Use OAuth para VS Code / GitHub Copilot e Gemini CLI quando disponível. Para Copilot CLI, Codex, Cursor ou outros clientes MCP diretos, mantenha XMEMO_KEY no ambiente local ou cofre de segredos e defina um XMEMO_AGENT_INSTANCE_ID estável.

Registre uma decisão da base de código ou correção de bug e peça ao próximo agente de IDE ou CLI para recuperar o contexto relevante do XMemo antes de editar.

Se as recuperações estiverem vazias, verifique o caminho da configuração MCP selecionada, a variável de ambiente XMEMO_KEY para clientes diretos e eventuais credenciais OAuth desatualizadas no app host.

## Líder de piloto de equipe / corporativo

Avalie a memória compartilhada com controles de conta, atribuição de origem, fluxos de exportação/exclusão e evidências de configuração seguras para revisores.

Crie ou acesse o espaço de trabalho protegido do XMemo, convide usuários aprovados e conecte cada cliente via OAuth ou credencial direta com escopo de acordo com os selos de disponibilidade.

Peça para um membro do piloto salvar uma memória de equipe de teste, confirme a atribuição de origem no XMemo e revise os caminhos de exclusão/exportação e suporte.

Se um membro não conseguir se conectar, verifique as permissões de função, aprovação OAuth, status de prontidão do cliente e orientações de suporte antes de emitir um novo token.

## Operador de agentes autônomos

Permita que agentes headless ou agendados registrem progresso, recuperem decisões anteriores e mantenham uma identidade estável e não secreta de instância.

Obtenha /api/v1/mcp/config/autonomous-agent. Prefira auth_modes.oauth quando o executor suportar OAuth + cabeçalhos personalizados; use auth_modes.xmemo_key com XMEMO_KEY de um cofre de segredos apenas para executores totalmente headless.

Execute uma tarefa de teste que grave progresso no XMemo, reinicie o executor e confirme se ele recupera esse progresso usando o mesmo XMEMO_AGENT_INSTANCE_ID.

Se a atribuição mudar ou as recuperações se dividirem entre instâncias, persista XMEMO_AGENT_INSTANCE_ID fora do git e verifique se o executor não o está gerando a cada início.