Storage Model es

Modelo de almacenamiento

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

Todos los datos del usuario viven en chrome.storage.local, envuelto por lib/storage.js. Sin cuentas, sin servidor.

Historial global plano

• history es un array plano de mensajes global y de conversación única (no por pestaña) — el comportamiento por defecto previsto del producto: un tema nuevo = el usuario abre explícitamente una nueva sesión desde el cajón. El auto-cambio de sesión por pestaña fue rechazado explícitamente (ADR-0002); no volver a proponerlo.
• Forma de la entrada: {role, content}; content es una cadena o (multimodal) [{type:'text'}, {type:'image_url'}]; las entradas de adjunto llevan la cabecera PAGE_CONTEXT_PREFIX; las entradas de vídeo llevan el sello videoSrc (la precondición para las píldoras de timestamp clicables).
• Un envío = exactamente una burbuja de usuario es un invariante (editar y reenviar / regenerar eliminan primero la burbuja antigua).

Instantáneas de sesión: índice ligero + claves de cuerpo (批E, 2026-09-30)

• savedSessions en sí es un ÍNDICE LIGERO [{id,name,createdAt,pinned,textDigest}]; los bytes de las instantáneas viven en claves session_<id> por sesión. Toda función de sesión pasa por readSessionIndex(), que migra en el acto las instantáneas legacy de clave única (los cuerpos se escribieron ANTES de reescribir el índice; idempotente, seguro ante caídas).
• La búsqueda del cajón coincide con nombres + textDigest (digest solo de texto, limitado a 100K caracteres/sesión — el contenido que supera el límite no es buscable; compromiso documentado).
• Las claves session_<id> son lecturas dirigidas y deliberadamente NO están en GET_ALL_KEYS.

El contrato de GET_ALL_KEYS

getAll() lee una lista FIJA de claves ligeras (DEFAULTS menos history más tres ajustes de options), nunca get(null) — esta última deserializaba imágenes de ≤8MB más cada instantánea en cada turno/adjunto/explicación. Una clave nueva que los consumidores de getAll deban ver entra en la lista; las claves de lectura dirigida se quedan fuera.

Ciclo de vida de las imágenes: los píxeles nunca se destruyen (ADR-0013, restricción estricta)

Una burbuja muestra lo que se envió — los píxeles de imagen almacenados nunca se eliminan ni se degradan (las instantáneas de sesión también incluyen los bytes, ADR-0005). Toda la compactación ocurre en el lado de la PETICIÓN:

• Sellado imagesSeen: tras un turno exitoso, las entradas con imágenes quedan selladas; los constructores de peticiones llaman a prepareHistoryForModel, que reemplaza las imágenes VISTAS por placeholders de etiqueta ([图N] / [Figure 3: …]) y deja pasar las NO VISTAS con píxeles. Los turnos posteriores reenvían texto barato en lugar de ~1K tokens/imagen.
• boundUnseenImageBytes: higiene al abrir el panel — los píxeles no vistos en espera se limitan a 8MB REDUCIENDO los más antiguos a miniaturas (nunca etiquetas: una entrada que pierde píxeles pierde la imagen de su burbuja). La entrada más reciente con imágenes siempre se salva.
• Los proveedores de agente no necesitan ningún cambio: buildAgentTurn solo recoge el run final de contexto de página (nunca respondido, nunca sellado).

Adelgazamiento de contexto en el lado de la petición

• Envejecimiento de contexto (ageStaleAttachments): en el momento del envío, los adjuntos «fríos» (no el más reciente, ≥3 turnos de usuario por detrás, ≥8000 caracteres) se convierten en un stub determinista de una línea — el almacenamiento queda intacto; el determinismo mantiene el prefijo de caché del proveedor estable tras el quiebre único.
• Auto-resumen de adjuntos: los adjuntos por encima del umbral reciben una pasada de compresión LLM tras almacenarse; los bloques multimodales image_url sobreviven a la reescritura.
• Rescate por desbordamiento: un turno que falla por desbordamiento de contexto reconstruye la petición con los adjuntos grandes recortados y reintenta una vez; el almacenamiento se reescribe SOLO después de que el turno reintentado tenga éxito — el adjunto original sobrevive al fallo.

Higiene de los despertares del SW

Las cachés de sitio viven en chrome.storage.session; la restauración es perezosa (la primera llamada a siteCacheCtx paga la lectura) y valida la vitalidad de la pestaña (lo que también eliminó la carrera restauración-vs-cierre); los listeners de purga se registran bajo demanda. Nada que arranque en frío el SW debe ser permanente.

---

Versiones autoritativas: Storage-Model (inglés) / Storage-Model-zh (chino) — instantánea de primera traducción por IA, sincronizada el 2026-10-01.