Storage Model pt

Modelo de armazenamento

English | 中文 | 日本語 | 한국어 | Español | Português | Русский

Todos os dados do usuário vivem em chrome.storage.local, embrulhado por lib/storage.js. Sem conta, sem servidor.

Histórico global e plano

• history é um array plano de mensagens global, de conversa única (não por aba) — o padrão de produto intencional: um novo tópico = o usuário abre explicitamente uma nova sessão pela gaveta. A auto-troca de sessão por aba foi explicitamente rejeitada (ADR-0002); não reapresente a proposta.
• Forma da entrada: {role, content}; content é uma string ou (multimodal) [{type:'text'}, {type:'image_url'}]; entradas de anexo carregam o cabeçalho PAGE_CONTEXT_PREFIX; entradas de vídeo recebem o carimbo videoSrc (a pré-condição para as pílulas de timestamp clicáveis).
• Um envio = exatamente uma bolha de usuário é um invariante (editar&reenviar / regenerar removem a bolha antiga primeiro).

Snapshots de sessão: índice leve + chaves de corpo (批E, 2026-09-30)

• savedSessions em si é um ÍNDICE LEVE [{id,name,createdAt,pinned,textDigest}]; os bytes dos snapshots vivem em chaves session_<id> por sessão. Toda função de sessão passa por readSessionIndex(), que migra snapshots legados de chave única na hora (corpos escritos ANTES da reescrita do índice; idempotente, seguro contra crashes).
• A busca da gaveta cruza nomes + textDigest (digest apenas de texto, limitado a 100K caracteres/sessão — conteúdo além do limite não é pesquisável; trade-off documentado).
• As chaves session_<id> são leituras direcionadas e deliberadamente NÃO estão em GET_ALL_KEYS.

O contrato do GET_ALL_KEYS

getAll() lê uma lista FIXA de chaves leves (DEFAULTS menos history mais três configurações de options), nunca get(null) — este último desserializava imagens de ≤8MB mais todos os snapshots a cada turno/anexo/explicação. Uma chave nova que os consumidores do getAll precisam ver entra na lista; chaves de leitura direcionada ficam de fora.

Ciclo de vida das imagens: pixels nunca são destruídos (ADR-0013, restrição rígida)

A bolha mostra o que foi enviado — pixels de imagens armazenados nunca são apagados ou degradados (snapshots de sessão também incluem os bytes, ADR-0005). Toda a compactação acontece no lado da REQUISIÇÃO:

• Carimbo imagesSeen: após um turno bem-sucedido, entradas com imagem recebem o carimbo; os construtores de requisição chamam prepareHistoryForModel, que substitui imagens JÁ VISTAS por placeholders de rótulo ([图N] / [Figure 3: …]) e deixa as NÃO VISTAS passar com os pixels. Turnos seguintes reenviam texto barato em vez de ~1K tokens/imagem.
• boundUnseenImageBytes: higiene ao abrir o painel — pixels não vistos estacionados são limitados a 8MB REDUZINDO os mais antigos a miniaturas (nunca rótulos: uma entrada que perde pixels perde a figura da sua bolha). A entrada mais recente com imagem é sempre poupada.
• Provedores de agente não precisam de mudança alguma: buildAgentTurn coleta apenas a run de page-context final (nunca respondida, nunca carimbada).

Redução de contexto no lado da requisição

• Envelhecimento de contexto (ageStaleAttachments): no momento do envio, anexos "frios" (não os mais recentes, ≥3 turnos de usuário atrás, ≥8000 caracteres) viram um stub determinístico de uma linha — o armazenamento fica intocado; o determinismo mantém o prefixo de cache do provedor estável após a quebra única.
• Auto-resumo de anexos: anexos acima do limite recebem uma passada de compressão por LLM após o armazenamento; blocos multimodais image_url sobrevivem à reescrita.
• Resgate de overflow: um turno que falha por overflow de contexto reconstrói a requisição com os anexos grandes aparados e tenta uma vez; o armazenamento só é reescrito DEPOIS que o turno repetido tem sucesso — o anexo bruto sobrevive à falha.

Higiene de despertar do SW

Os caches de site vivem em chrome.storage.session; a restauração é preguiçosa (a primeira chamada a siteCacheCtx paga a leitura) e valida se a aba está viva (o que também matou a corrida restauração-vs-fechamento); listeners de purga se registram sob demanda. Nada que faça cold-start do SW deve ser permanente.

---

Versões autoritativas: Storage-Model (inglês) / Storage-Model-zh (chinês) — instantâneo de primeira tradução por IA, sincronizado em 2026-10-01.