Storage Model ko

스토리지 모델

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

모든 사용자 데이터는 lib/storage.js가 감싸는 chrome.storage.local에 산다. 계정 없음, 서버 없음.

전역 플랫 히스토리

• history는 전역 단일 대화 플랫 메시지 배열이다(탭별이 아님) — 의도된 제품 기본값: 새 주제 = 사용자가 드로어에서 명시적으로 새 세션을 연다. 탭별 자동 전환은 명시적으로 기각되었다(ADR-0002); 다시 제안하지 마라.
• 엔트리 형태: {role, content}; content는 문자열 또는 (멀티모달) [{type:'text'}, {type:'image_url'}]; 첨부 엔트리는 PAGE_CONTEXT_PREFIX 헤더를 단다; 비디오 엔트리는 videoSrc 스탬프를 찍는다(클릭 가능한 타임스탬프 필의 전제조건).
• 한 전송 = 정확히 한 사용자 버블이 불변식이다(편집&재전송 / 재생성은 먼저 오래된 버블을 제거한다).

세션 스냅숏: 경량 인덱스 + 본문 키 (批E, 2026-09-30)

• savedSessions 자체는 경량 인덱스 [{id,name,createdAt,pinned,textDigest}]다; 스냅숏 바이트는 세션별 session_<id> 키에 산다. 모든 세션 함수는 readSessionIndex()를 통과하는데, 이것이 구식 단일 키 스냅숏을 그 자리에서 마이그레이션한다(인덱스 재작성 전에 쓰인 본문; 멱등, 크래시 안전).
• 드로어 검색은 이름 + textDigest(텍스트 전용 다이제스트, 세션당 100K 자 상한 — 상한을 넘는 내용은 검색 불가; 문서화된 트레이드오프)에 맞춘다.
• session_<id> 키는 타깃 읽기이며 의도적으로 GET_ALL_KEYS에 없다.

GET_ALL_KEYS 계약

getAll()은 고정된 경량 키 목록(DEFAULTS에서 history를 빼고 옵션 설정 세 개를 더한 것)을 읽고, 절대 get(null)이 아니다 — 후자는 매 턴/첨부/설명마다 ≤8MB 이미지와 모든 스냅숏을 역직렬화했었다. getAll 소비자가 봐야 하는 새 키는 목록에 들어가고; 타깃 읽기 키는 밖에 머문다.

이미지 수명 주기: 픽셀은 결코 파괴되지 않는다 (ADR-0013, 강제 제약)

버블은 전송된 것을 보여준다 — 저장된 이미지 픽셀은 결코 삭제되거나 열화되지 않는다(세션 스냅숏도 바이트를 포함한다, ADR-0005). 모든 압축은 요청 측에서 일어난다:

• imagesSeen 스탬핑: 성공한 턴 후 이미지를 포함한 엔트리에 스탬프가 찍힌다; 요청 빌더는 prepareHistoryForModel을 호출하는데, 이것은 본(SEEN) 이미지를 라벨 플레이스홀더([图N] / [Figure 3: …])로 바꾸고 보이지 않은 것은 픽셀째 통과시킨다. 이후 턴은 이미지당 ~1K 토큰 대신 값싼 텍스트를 재전송한다.
• boundUnseenImageBytes: 패널 오픈 위생 — 주차된 보이지 않는 픽셀은 가장 오래된 것부터 썸네일로 다운스케일해 8MB로 상한이 매겨진다(절대 라벨화가 아니다: 픽셀을 잃은 엔트리는 버블 그림을 잃는다). 가장 최신의 이미지 엔트리는 항상 면제된다.
• 에이전트 프로바이더는 변경이 0이다: buildAgentTurn은 (답변된 적 없고, 스탬프된 적 없는) 후행 페이지-컨텍스트 실행만 수집한다.

요청 측 컨텍스트 슬리밍

• 컨텍스트 에이징(ageStaleAttachments): 전송 시점에 "차가운" 첨부(최신이 아니고, ≥3 사용자 턴 뒤이고, ≥8000 자)는 한 줄짜리 결정론적 스텁이 된다 — 저장소는 그대로; 결정론성이 1회성 단절 이후에도 프로바이더 캐시 프리픽스를 안정적으로 유지한다.
• 첨부 자동 요약: 임계값을 넘는 첨부는 저장 후 LLM 압축 패스를 한 번 거친다; 멀티모달 image_url 블록은 재작성을 살아남는다.
• 오버플로 구제: 컨텍스트 오버플로로 실패한 턴은 큰 첨부를 잘라낸 채 요청을 재건하고 한 번 재시도한다; 저장소 재작성은 재시도한 턴이 성공한 후에만 — 원본 첨부는 실패에서 살아남는다.

SW 웨이크 위생

사이트 캐시는 chrome.storage.session에 산다; 복원은 지연이다(첫 siteCacheCtx 호출이 읽기 비용을 지불한다)하고 탭 생존을 검증한다(이것이 복원-vs-닫기 경합도 함께 죽였다); 퍼지 리스너는 필요할 때 등록된다. SW를 콜드 스타트하는 것은 영구적이어서는 안 된다.

---

원본 출처: AGENTS.md storage.js / 批E / "History image lifecycle" / "Large-context latency" 절; ADR-0005 / 0012 / 0013. 권위판: Storage-Model(영어) / Storage-Model-zh(중국어) — AI 초벌 번역 스냅숏, 동기화 2026-10-01.