Recuperação de Contexto

O ChatCLI implementa um sistema de recuperação automatica de contexto que lida com três tipos de falha comuns em sessões longas: overflow da janela de contexto do modelo (“prompt too long”), limites de payload de proxy/gateway corporativo (413/WAF 403/EOF silencioso), e limite de tokens de saída. Quando a API rejeita uma requisição por qualquer um desses motivos, o sistema aplica estratégias progressivamente mais agressivas para recuperar a sessão sem perder a conversa.

Recuperação de Context Overflow

Quando a API retorna um erro de “context too long”, o ChatCLI aplica até 3 niveis de recuperação antes de desistir. Todo loop recupera, não só o agent/coder: o REPL de chat (o prefixo e a mensagem de contexto do turno são reconstruídos sobre o histórico recuperado), o chat RPC atrás de MCP/ACP/gateway, o one-shot (-p, aviso no stderr para o stdout continuar “pipeável”) e cada participante do MoA (a própria thread é compactada; o painel não falha mais por um overflow). O helper compartilhado é limitado (CHATCLI_MAX_RECOVERY_ATTEMPTS, padrão 3) e dá as mesmas garantias de uma compactação planejada: memória descarregada antes, hooks avisados com o gatilho recovery, mensagens descartadas arquivadas no CCR, rebuild de cache contabilizado. O classificador que decide “isto é overflow” é compartilhado por todos os loops e pela cadeia de fallback de provedores, e cobre a frase de cada provedor — OpenAI chat e Responses (“context window”, context_length_exceeded), Anthropic (“prompt is too long”), Gemini (“input token count … exceeds”), xAI (“maximum prompt length”), Mistral, Groq, Bedrock — mais uma checagem por status em 400/413 cujo corpo combina uma palavra de token/tamanho com uma de excesso.

Nivel 1: Orcamento Agressivo
Nivel 2: Truncamento de Emergencia
Nivel 3: Truncamento Nuclear

Primeira tentativa: reduz os limites de orcamento pela metade e limpa desalinhamentos.Acoes:

Repara pareamento de tool results (remove orfaos, injeta sinteticos)
Aplica 50% de DefaultTurnBudgetChars e DefaultPerResultMaxChars só para esta sessão — os defaults do processo nunca são mutados, então outras sessões de um gateway ou rpcserve nunca veem limites pela metade
Aplica enforcement de orcamento com limites reduzidos
Trunca mensagens longas do assistente para 5.000 chars

Os limites originais sao restaurados após a aplicacao. Apenas o histórico atual e afetado pela reducao.

Segunda tentativa: mantem apenas mensagens do sistema e as ultimas N mensagens.Acoes:

Preserva todas as mensagens de sistema (system prompt, bootstrap, contextos)
Mantem as ultimas 10 mensagens não-sistema (configurável)
Garante que o histórico comeca com uma mensagem user (requisito da API)
Valida pareamento de tool results no histórico truncado

Terceira tentativa: mantem apenas o mínimo para continuar.Acoes:

Preserva mensagens de sistema
Mantem apenas as ultimas 4 mensagens (2 trocas user/assistant)
Injeta mensagem de aviso explicando que o contexto foi compactado

[Context was automatically compacted due to size limits.
Previous conversation history has been summarized.
Continue from where you left off.]

Detecção de Erro — overflow do modelo

O sistema reconhece múltiplas formas de erro de overflow:

Mensagem de Erro	Provedor
`context length exceeded`	Anthropic
`prompt is too long`	OpenAI
`request too large`	Varios
`max_tokens exceed`	Varios
`input too long`	Google
`token limit`	Genérico

Recuperação de proxy/gateway corporativo

Ambientes corporativos frequentemente rodam atrás de proxies ou gateways que impõem um teto de body size para POSTs — tipicamente 1-5 MB, totalmente independente da janela de contexto do modelo. Você pode estar dentro do limite do Anthropic (200K tokens / ~800 KB) e mesmo assim tomar uma rejeição misteriosa do proxy. Pior: muitos proxies não retornam um 413 limpo — alguns mandam 403 do WAF (Cloudflare, Akamai, mod_security), 431 (header too large), ou simplesmente dropam a conexão TCP no meio do POST, emergindo como EOF / connection reset no cliente. O ChatCLI detecta esses três padrões e aplica o mesmo fluxo de recuperação do context overflow.

Detecção de Erro — proxy/gateway

Padrão detectado	Exemplo	Função
HTTP 413 + variantes	`413 Payload Too Large`, `request entity too large`, `body too large`, `maximum request size`, `431 Request Header Fields Too Large`	`IsPayloadTooLargeError`
403 com sinais de WAF/firewall	403 com `firewall`, `waf`, `security policy`, `blocked by`, `cloudflare`, `cf-ray`, `mod_security`, `akamai`, `proxy denied`, `policy violation`	`IsProxyWAFRejection`
403 com corpo HTML (Bedrock/AWS SDK)	`StatusCode: 403 ... deserialization failed ... invalid character '<' looking for beginning of value` (SDK tentando decodar uma página de bloqueio HTML do proxy como JSON)	`IsProxyWAFRejection`
EOF / reset com histórico grande	`unexpected eof`, `connection reset`, `broken pipe`, `stream error` e histórico > 500 KB	`IsLikelyPayloadProblem` (heurístico)

A detecção de WAF é conservadora — um 403 sem sinais de firewall continua sendo tratado como erro de autenticação (refresh OAuth + retry). Só quando o 403 carrega sinais específicos do proxy/WAF é que ele é reclassificado como falha recuperável de payload. Isso evita invalidar credenciais OAuth válidas quando o problema real está na rede.

O caso Bedrock corporativo: quando o proxy/WAF intercepta a requisição POST ao Bedrock Runtime e devolve uma página HTML de bloqueio com status 403, o AWS SDK tenta fazer parse do body como JSON e falha com "invalid character '<' looking for beginning of value" e RequestID vazio. Esse padrão é um fingerprint inequívoco de middlebox (um 403 real da AWS retorna JSON bem-formado) — o ChatCLI reclassifica para falha recuperável de payload e dispara a mesma ladder de recovery.

A detecção de EOF/connection-reset aplica um limiar de tamanho do histórico (500 KB) antes de suspeitar de payload. Requisições pequenas que sofrem EOF continuam sendo tratadas como falhas transitórias de rede (retry normal). Só quando o histórico já está suspeitosamente grande é que o EOF é reclassificado como possível body cap.

Pre-flight check

A cada turno do agente, o histórico é medido antes do request sair. Dois caminhos: Com CHATCLI_MAX_PAYLOAD configurado: Se o histórico passa de 85% do cap, o BudgetRatio é forçado para 0.40 antes de qualquer coisa — compactação agressiva preventiva. O usuário vê:

ℹ pre-flight: history 4.2 MB ≈ 86% do cap configurado (5.0 MB) — compactando

Sem cap configurado: Se o histórico passa de 2.5 MB, um aviso one-shot por sessão é emitido sugerindo configurar a env var. Não dispara de novo no mesmo run para evitar barulho.

ℹ history 2.8 MB — se seu ambiente tem proxy/gateway, export CHATCLI_MAX_PAYLOAD=5MB (ajuste p/ limite do proxy)

Cap adaptativo aprendido

Os providers Bedrock anotam cada erro de transporte com o tamanho exato da requisição que o middlebox rejeitou. Quando uma rejeição de payload acontece, o ChatCLI deriva o limite da sessão diretamente dessa observação — ¾ do tamanho rejeitado — em vez de chutar:

⚠ Falha recuperável (rejeição do proxy/WAF (403 + sinais de segurança)) — compactando e tentando novamente
ℹ Gateway rejeitou uma requisição de 126.4 KB — limite de payload ajustado para 94.8 KB nesta sessão (exporte CHATCLI_MAX_PAYLOAD para sobrepor)

Na prática isso muda tudo: gateways corporativos reais frequentemente limitam o corpo em torno de 128 KB, onde um chute de vários megabytes não mudaria nada. O cap aprendido só aperta — se CHATCLI_MAX_PAYLOAD já estiver abaixo dele, seu valor vence; uma rejeição menor posterior aperta ainda mais. Quando o tamanho rejeitado é desconhecido (providers sem anotação de tamanho), vale o comportamento anterior como fallback: assumir 4 MB para o resto da sessão.

ℹ Assumindo limite de 4 MB/payload — exporte CHATCLI_MAX_PAYLOAD (ex.: 5MB, 512KB) para ajustar

Diagnóstico de piso — quando compactar não resolve

O system prompt (charter do agente, personas, skills, docs de ferramentas MCP) nunca é compactado. Quando ele sozinho atinge o tamanho que o gateway acabou de rejeitar, nenhuma compactação de histórico produz uma requisição aceitável — repetir payloads idênticos só queimaria tentativas de recovery. O ChatCLI detecta isso e falha rápido com uma mensagem acionável:

✖ A base não-compactável da requisição (system prompt: 131.2 KB — personas, skills,
  docs de ferramentas MCP) atinge ou excede o tamanho rejeitado pelo gateway (126.4 KB).
  Compactar histórico não resolve — reduza servidores MCP, skills ou personas,
  ou aumente o limite de corpo do proxy/WAF

A ¾ do tamanho rejeitado dispara um aviso — a sessão continua, mas você está perto da borda:

⚠ O system prompt sozinho tem 96.1 KB — próximo do limite de rejeição do gateway;
  considere reduzir servidores MCP, skills ou personas

Três features estruturais encolhem esse piso: as descrições de ferramentas MCP são limitadas a uma linha no índice do system prompt (schema completo via @tools describe), os corpos de skills injetadas respeitam CHATCLI_SKILL_INJECT_BUDGET mais seu cap de 2× por execução, e blocos de skill mid-loop envelhecem para stubs após CHATCLI_SKILL_AGE_TURNS turnos (recuperáveis via @recall). Veja Integração MCP e Skill Registry.

Encolhimento de conteúdo — o Nível 3 que funciona de verdade

Dropar mensagens inteiras é no-op quando o histórico é curto — sessões de agente frequentemente têm só o system prompt e um punhado de tool results gigantes, e o MinKeepRecent mantém exatamente as mensagens que carregam o volume. A truncagem de emergência ganhou por isso um passe final: encolhe o conteúdo das mensagens não-system, da maior para a menor, até caber no budget de payload. Mensagens system nunca são tocadas. Com a camada de compressão ativa, cada mensagem é arquivada verbatim no store CCR antes do primeiro corte e o conteúdo encolhido carrega um marcador <<ccr:KEY>> — o modelo recupera o original a qualquer momento com @recall. A truncagem nuclear (nível 3 da escada de recovery) adicionalmente limita cada mensagem não-system mantida a 4.000 chars.

O que cada nível garante

As mesmas garantias valem em qualquer loop que compacte (chat, agent/coder, one-shot, /compact) e no recovery de overflow:

Nada que o modelo pediu para manter é tocado. Mensagens marcadas PreserveVerbatim (um resultado de @recall que o modelo pediu explicitamente por inteiro) ficam fora do segmento sumarizado e são reanexadas logo após o resumo no Nível 2, mantidas inteiras no Nível 3 e ignoradas pelo encolhimento de conteúdo. Um tool result nativo verbatim reanexado sem a tool call dona vira mensagem de usuário, então o reparo de pareamento nunca o apaga. Mensagens verbatim ocupam no máximo um quarto do budget: além disso, as mais antigas são arquivadas de novo no CCR, viram stub com marcador @recall e perdem a flag, então a compactação sempre converge.
Compactação que não muda nada não é compactação. Um no-op, um resumo rejeitado ou uma falha descarta o snapshot de undo (então /rewind compact nunca “restaura” um histórico idêntico) e dispara o PostCompact par com outcome=skipped; restaurar um checkpoint do /rewind usa a mesma contabilidade do /rewind compact (reescrita no journal, rebuild de cache esperado, pilha de undo limpa).
O Nível 3 deixou de ser lossy. As mensagens que ele descarta são arquivadas no store CCR antes, e o aviso de truncagem carrega um marcador @recall para o segmento inteiro — a mesma recuperabilidade que os Níveis 1 e 2 já tinham. O recovery de overflow descarrega a memória pendente, arquiva as mensagens que remove e anexa o marcador ao histórico recuperado.
Um resumo ruim nunca substitui o segmento. Um gate de qualidade rejeita recusas e respostas curtas demais para o segmento (piso proporcional ao tamanho, teto de 80 caracteres); o sumarizador é tentado mais uma vez e, se falhar, o pipeline cai para o Nível 3 com seu arquivo.
O sumarizador não é pago à toa. Quando um resumo não traz o histórico para dentro do budget, as duas compactações seguintes pulam o Nível 2 e vão direto ao Nível 3 em vez de pagar uma chamada de sumarização por turno.
Hooks veem toda compactação. PreCompact/PostCompact disparam com trigger auto, manual ou recovery (hooks).
É contabilizado. /cost mostra o número de compactações, quantas caíram no Nível 3 e quanto o sumarizador custou; os contadores persistem com a sessão (cost tracking).

O /compact <instrução> guiado segue as mesmas regras: usa a rota de sumarizador configurada (CHATCLI_COMPACT_MODEL) quando existe, dá ao resumo sua própria janela de 10 minutos em vez do antigo prazo de 60 segundos do comando, mantém mensagens PreserveVerbatim, arquiva o segmento e roda o gate de qualidade.

System notice injetado na história

Após um recovery disparado por payload limit, o ChatCLI injeta uma mensagem user antes do retry instruindo o modelo a fazer leituras menores no futuro. Isso quebra o loop do modelo de tentar re-ler o mesmo arquivo gigante que causou o 413 originalmente. O notice é injetado no máximo uma vez por sessão — o recovery detecta uma cópia existente em qualquer lugar do histórico (mesmo dobrada num summary de compactação) e nunca empilha uma segunda, já que cada byte extra trabalha contra o próprio limite sendo recuperado:

[SYSTEM NOTICE — PAYLOAD LIMIT HIT] A proxy/gateway rejected the previous
request due to body size. History was compacted to recover. Going forward:
(1) When reading files, prefer targeted reads with line ranges
    (e.g. sed -n '100,200p' file, or read_file with offset+limit) instead
    of reading entire files.
(2) Prefer grep/ripgrep with specific patterns over full-file reads.
(3) If you previously read a large file, its full content is persisted at
    the path shown in the tool-result preview — re-read specific ranges
    from that file rather than repeating the original read.
(4) Summarize findings incrementally rather than accumulating raw tool output.

Este hint é injetado em inglês intencionalmente. A IA segue instruções em inglês com muito mais fidelidade mesmo quando o usuário está em pt-BR, e esta mensagem não é visível ao usuário — ela só entra no histórico enviado ao modelo.

Escalação de Max Output Tokens

Quando o modelo para de gerar por atingir o limite de max_tokens, o ChatCLI pode escalar automaticamente:

Tentativa	Acao
1a	Dobra o `max_tokens` atual (até o cap do provedor)
2a	Dobra novamente (até o cap do provedor)
3a+	Para de escalar, retorna conteúdo parcial

Mensagem de Continuacao

Quando o modelo e interrompido por limite de tokens, o ChatCLI injeta uma mensagem de continuacao:

Your response was cut off at the token limit.
Resume DIRECTLY from where you stopped — do not repeat any content.
Continue the implementation or explanation from the exact point of interruption.

A mensagem instrui o modelo a continuar de onde parou, evitando repeticao de conteúdo já gerado.

Configuração

Variável de Ambiente	Descrição	Default
`CHATCLI_CONTEXT_WINDOW`	Override global da janela de contexto (em tokens), para qualquer provider/modelo. Tem precedência sobre o catálogo. Use quando a janela real do seu gateway/agente difere da assumida pelo ChatCLI — o orçamento de compactação deriva desse valor.	(auto via catálogo)
`CHATCLI_MAX_RECOVERY_ATTEMPTS`	Tentativas máximas de recuperação de contexto	`3`
`CHATCLI_MAX_TOKEN_ESCALATIONS`	Escalações máximas de max_tokens	`2`
`CHATCLI_EMERGENCY_KEEP_MESSAGES`	Mensagens mantidas no truncamento de emergência	`10`
`CHATCLI_MAX_PAYLOAD`	Teto human-friendly para o body size do POST (ex.: `5MB`, `512KB`, `2.5MB`, `5`=5MB). Quando setado, o compactor respeita esse teto como limite adicional à janela de contexto do modelo, e o pre-flight força compactação ao cruzar 85% do cap.	(não setado — sem teto)

Feedback visual durante a compactação

Desde esta versão, o histórico nunca mais “congela” o terminal durante uma compactação longa. O HistoryCompactor emite status em cada fase do pipeline via SetStatusCallback:

│ 📦 Compactando histórico (23 msgs, 4.2 MB → alvo 2.9 MB)
│ 🧹 Trim: removendo reasoning/dedup (sem LLM)…
│ 🧠 Resumindo mensagens antigas via LLM (pode levar 30-90s — ESC cancela)…
│ ✓ Resumo aplicado (23 → 9 msgs, 4.2 MB → 1.8 MB)

Cancelamento: a chamada LLM de summarização agora deriva do context do turno — Ctrl+C / ESC propaga corretamente e aborta a compactação sem corromper o histórico (retorna ctx.Err() em vez de cair para truncamento de emergência cego).

Flush de memória antes da compactação

O worker de memória destila fatos do histórico vivo alguns turnos atrás da conversa; a compactação substitui o meio desse histórico por um resumo, então o que o worker ainda não tinha alcançado era destilado, no melhor caso, a partir do resumo. Todo ponto de compactação (auto-compact no chat, agent e coder, /compact explícito e guiado, one-shot) agora entrega o segmento ainda não extraído à fila durável do worker antes da reescrita, para que as mensagens originais cheguem à memória de longo prazo intactas, independentemente do que o resumo mantém.

Leituras repetidas (pré-budget)

No mesmo limite de turno, DedupRepeatedReads remove as cópias que uma sessão de coder acumula ao ler o mesmo arquivo repetidas vezes: quando um @coder read posterior do mesmo caminho cobre a mesma faixa de linhas ou uma mais ampla, toda leitura anterior daquele caminho vira um stub de uma linha (arquivado antes no CCR, então @recall restaura) e a leitura mais nova fica intacta. Leituras posteriores mais estreitas nunca substituem uma anterior mais ampla, a saída de @recall nunca é tocada, e cada passagem é reportada na linha do turno. O modelo mantém exatamente uma visão atual por arquivo em vez de cinco.

Microcompact (pré-budget)

A checagem de budget em si é honesta com o payload: pesa o texto das mensagens mais argumentos de tool calls nativas, payloads de imagem e excesso de system-parts, então históricos pesados em tools ou visão cruzam o limiar quando a requisição real cruza — não depois de um proxy já ter rejeitado. Antes do NeedsCompaction checar se o histórico excede o budget, o agent loop aplica ApplyMicrocompact — uma passada pure-Go, sem LLM, sem rede que progressivamente trunca/resume tool results antigos (2+ turnos atrás → head+tail preview; 4+ turnos atrás → one-line summary). Na maioria dos casos isso mantém o histórico dentro do budget sem disparar o Level 2 (caro). A entrada do sumarizador é orçada contra a janela do próprio modelo sumarizador (metade dela, piso de 20K chars) em vez de um corte fixo cabeça/cauda por mensagem: cada mensagem do segmento recebe uma cota justa, uma mensagem já dobrada num stub <<ccr:KEY>> é restaurada do arquivo CCR quando o original cabe, mensagens longas mantêm cabeça e cauda na proporção 3:1, e tool calls nativas são nomeadas para o resumo listar os comandos executados. A mesma renderização serve o /compact <instrução>. Com a camada de compressão ativa, o microcompact é sem perda: o tool result original é arquivado no store CCR antes do corte e o stub de preview/summary embute um marcador <<ccr:KEY>>. Os marcadores sobrevivem entre níveis — quando um preview truncado depois vira um summary de uma linha, o marcador permanece no summary — então o modelo sempre pode expandir o original com @recall.

🗜 microcompact: 3 truncados, 2 resumidos, 1.7 MB liberados

Configurável via env:

Variável de Ambiente	Descrição	Default
`CHATCLI_MICROCOMPACT_TRUNCATE_TURNS`	Turnos de idade para começar a truncar tool results	`2`
`CHATCLI_MICROCOMPACT_SUMMARIZE_TURNS`	Turnos de idade para substituir por summary de uma linha	`4`
`CHATCLI_COMPACT_MODEL`	`PROVIDER:modelo` dedicado ao resumo estruturado de Nível 2 (mais barato/rápido que o modelo da sessão)	(cliente da sessão)

Ratio de Orcamento Agressivo

No nivel 1, os limites de orcamento de tool results sao multiplicados por 0.5 (50%). Isso significa:

Parâmetro	Normal	Nivel 1 Recuperação
Budget por turno	200.000 chars	100.000 chars
Max por resultado	20.000 chars	10.000 chars

Fluxo de Recuperação

API retorna erro recuperável (context overflow | 413 | WAF 403 | EOF c/ histórico grande)
  │
  ├─ Payload-related: cap aprendido do tamanho rejeitado (¾) ────────────┐
  │   ├─ System prompt ≥ tamanho rejeitado → FALHA RÁPIDA c/ diagnóstico │
  │   └─ System notice injetado no histórico (uma vez por sessão)        │
  │                                                                      │
  ├─ Tentativa 1: Orçamento agressivo (50%) + pairing cleanup            │
  │   └─ Reenvia para API                                                │
  │       ├─ Sucesso → continua normalmente                              │
  │       └─ Falha → próxima tentativa                                   │
  │                                                                      │
  ├─ Tentativa 2: Emergency truncate (system + últimas 10 msgs)         │
  │   └─ Reenvia para API                                                │
  │       ├─ Sucesso → continua com histórico reduzido                   │
  │       └─ Falha → próxima tentativa                                   │
  │                                                                      │
  └─ Tentativa 3: Nuclear truncate (system + últimas 4 msgs,            │
      cada uma limitada a 4.000 chars, arquivada no CCR antes)           │
      └─ Reenvia para API                                                │
          ├─ Sucesso → continua com histórico mínimo                     │
          └─ Falha → erro reportado ao usuário                           │
                                                                         │
  Tamanho rejeitado desconhecido: CHATCLI_MAX_PAYLOAD auto-setado ◄──────┘
                                  para 4MB se não configurado

Após o truncamento nuclear (nível 3), o contexto de trabalho do modelo cai para as últimas 2 trocas. Com a camada de compressão ativa o conteúdo dropado permanece recuperável — os stubs carregam marcadores <<ccr:KEY>> que o modelo expande com @recall — mas o /compact proativo continua sendo a melhor experiência: um summary estruturado vale mais que uma pilha de marcadores de recall.

Interação com Outros Sistemas

A recuperação de contexto trabalha em conjunto com:

Tool Result Budget

O orcamento de resultados e a primeira linha de defesa. A recuperação ativa quando o orcamento não foi suficiente.

Microcompactacao

A compactação progressiva reduz o crescimento do contexto ao longo do tempo.

Controle de Conversa

O comando /compact e a forma proativa de prevenir overflow.

Cost Tracking

Monitore o uso de contexto para antecipar quando /compact sera necessário.

Motor de contexto externo (MCP)

CHATCLI_CONTEXT_ENGINE=mcp:<server> entrega o resumo de Nível 2 a um servidor MCP configurado que expõe context_compact(segment, budget_chars, instruction): o segmento renderizado da conversa (a mesma renderização orçada que o sumarizador embutido recebe), o orçamento em chars e, no /compact <instrução> guiado, a instrução do usuário. A resposta substitui o segmento; o arquivo CCR, os checkpoints e o @recall seguem funcionando exatamente como antes. Erro, timeout (3 min) ou resposta vazia caem no sumarizador embutido naquela compactação. Aparece em /config compression. CHATCLI_CONTEXT_ENGINE=provider soma a edição de contexto server-side do próprio modelo ao pipeline local. Na Anthropic (API key ou OAuth) toda requisição do loop de tools carrega o beta context-management-2025-06-27 e um bloco context_management com uma edição clear_tool_uses_20250919: quando o prompt passa de 100 K tokens de entrada, a própria API limpa os tool results mais antigos, mantendo os cinco tool uses mais recentes e liberando pelo menos 20 K tokens por edição, antes de esses tokens serem cobrados. As edições aplicadas voltam na resposta e são espelhadas localmente: os tool results mais antigos que o servidor limpou viram stubs no histórico local (os originais arquivados no CCR, recuperáveis com @recall), a calibração chars/token pula aquele turno, a próxima escrita de cache é contabilizada como rebuild esperado e o /context status mostra quantas edições, tool results e tokens o provedor limpou. A compactação local, o arquivo CCR e o /rewind compact seguem iguais, então nada se perde que já não fosse recuperável. Provedores sem equivalente server-side documentado ignoram a opção.

Início

Primeiros Passos

Conceitos Fundamentais

Funcionalidades

Segurança

Suporte

Recuperação de Contexto