mirror of
https://github.com/deepseek-ai/deepseek-harness
synced 2026-08-15 21:04:50 +00:00
32aaa8983e
# Conflicts: # docs/development.i18n.yaml # packages/client/ui-conversation/src/client/chat/MessageItem.tsx # packages/client/ui-primitives/src/markdown/CodeBlock.tsx # scripts/snapshots/translation-prompt-v4/request-response.expected.json
storage/ — non-session storage family
English | 中文
The storage family persists everything that is not a session event log: a hub where named backends and typed data forms meet. Design record: domain KV storage Agent Note.
| Package | Role | ctx key |
|---|---|---|
storage/ |
The hub: named backend registry + merge-extensible data-form mounts, backend facet vocabulary, shared conformance suite | ctx.storage |
storage-json/ |
JSON backend: one human-readable file per unit, atomic whole-file rewrite | registers backend json |
storage-sqlite/ |
SQLite backend: one database hosting all routed units, document-per-row | registers backend sqlite |
domain/ |
Domain data form: zod-validated records, per-domain write chain, domain/changed events, backend routing by configuration |
ctx.storageDomain + ctx.storage.domain |
Backends own one medium each and expose data-shape facets (kv today; an append-log facet is reserved for the future session-backend migration). Each backend plugin publishes an internal lifecycle service after registration; the domain plugin injects every configured backend key before exposing its own service, so config-tree row order carries no startup semantics. Consumers never touch backends directly — they inject storageDomain and open declared domains through it.