Storage Model ru

Модель хранения

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

Все пользовательские данные живут в chrome.storage.local, обёрнутом в lib/storage.js. Без аккаунта, без сервера.

Глобальная плоская история

• history — глобальный единый разговор, плоский массив сообщений (не по вкладкам) — задуманный продуктовый дефолт: новая тема = пользователь явно открывает новую сессию из панели сессий. Автопереключение по вкладкам было явно отвергнуто (ADR-0002); не предлагать заново.
• Форма записи: {role, content}; content — строка или (мультимодально) [{type:'text'}, {type:'image_url'}]; записи прикреплений несут заголовок PAGE_CONTEXT_PREFIX; видео-записи штампуются videoSrc (предусловие кликабельных капсул таймкодов).
• Одна отправка = ровно один пользовательский пузырь — инвариант (edit&resend / regenerate сначала удаляют старый пузырь).

Снимки сессий: лёгкий индекс + ключи тел (批E, 2026-09-30)

• savedSessions сам по себе — ЛЁГКИЙ ИНДЕКС [{id,name,createdAt,pinned,textDigest}]; байты снимков живут в ключах session_<id> по сессии. Каждая сессионная функция проходит через readSessionIndex(), которая мигрирует legacy-снимки с одним ключом на месте (тела, записанные ДО переписывания индекса; идемпотентно, устойчиво к сбоям).
• Поиск в панели сессий матчит имена + textDigest (дайджест только по тексту, потолок 100K символов на сессию — контент за потолком не ищется; задокументированный компромисс).
• Ключи session_<id> читаются адресно и намеренно НЕ входят в GET_ALL_KEYS.

Контракт GET_ALL_KEYS

getAll() читает ФИКСИРОВАННЫЙ список лёгких ключей (DEFAULTS минус history плюс три настройки options), никогда get(null) — последний десериализовал ≤8MB изображений плюс каждый снимок при каждом ходе/прикреплении/explain. Новый ключ, который должны видеть потребители getAll, идёт в список; адресно-читаемые ключи остаются вне.

Жизненный цикл изображений: пиксели никогда не уничтожаются (ADR-0013, жёсткое ограничение)

Пузырь показывает то, что было отправлено — сохранённые пиксели изображений никогда не удаляются и не деградируют (снимки сессий тоже включают байты, ADR-0005). Всё сжатие происходит на стороне ЗАПРОСА:

• Штамповка imagesSeen: после успешного хода записи с изображениями штампуются; билдеры запросов вызывают prepareHistoryForModel, которая заменяет ВИДЕННЫЕ изображения на текстовые плейсхолдеры ([图N] / [Figure 3: …]), а НЕВИДЕННЫЕ пропускает с пикселями. Последующие ходы пересылают дешёвый текст вместо ~1K токенов за изображение.
• boundUnseenImageBytes: гигиена при открытии панели — припаркованные невиденные пиксели ограничены 8MB путём УМЕНЬШЕНИЯ старейших до миниатюр (никогда не лейблы: запись, потерявшая пиксели, теряет картинку в пузыре). Новейшая запись с изображениями всегда оберегается.
• Агентским провайдерам не нужно никаких изменений: buildAgentTurn собирает только (никогда не отвечённый, никогда не штампованный) хвостовой page-context прогон.

Похудение контекста на стороне запроса

• Старение контекста (ageStaleAttachments): в момент отправки «холодные» прикрепления (не новейшее, ≥3 ходов пользователя назад, ≥8000 символов) превращаются в однострочный детерминированный стаб — хранилище не трогается; детерминизм держит префикс кэша провайдера стабильным после одноразового разрыва.
• Автосуммаризация прикреплений: прикрепления выше порога получают один LLM-проход сжатия после сохранения; мультимодальные блоки image_url переживают перезапись.
• Спасение при переполнении: ход, упавший из-за переполнения контекста, пересобирает запрос с урезанными крупными прикреплениями и ретраит один раз; хранилище перезаписывается ТОЛЬКО после успеха ретрая — сырое прикрепление переживает неудачу.

Гигиена пробуждений SW

Сайтовые кэши живут в chrome.storage.session; восстановление ленивое (первый вызов siteCacheCtx платит за чтение) и проверяет живость вкладки (что заодно убило гонку restore-vs-close); purge-слушатели регистрируются по требованию. Ничто, что холодно стартует SW, не должно быть постоянным.

---

Авторитетные версии: Storage-Model (англ.) / Storage-Model-zh (кит.) — снимок первичного перевода ИИ, синхронизирован 2026-10-01.