|
|
||
|---|---|---|
| .. | ||
| storage | ||
| storage-domain | ||
| storage-json | ||
| storage-sqlite | ||
| README.i18n.yaml | ||
| README.md | ||
| README.zh.md | ||
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.