Storage & sessions

Primitives

The storage API is intentionally small and capability-based:

• KeyValueStore — scoped settings, cursors, and lightweight runtime state;
• DocumentStore — structured records by collection and id;
• AppendLogStore — ordered streams for sessions, memory evolution, and audit history.

It is not an ORM and does not leak SQL concepts to the crates above it.

Scope

Every primitive is keyed by a StorageScope, which can represent global state, a workspace, a user, or an organization and project pair. That is why every CLI command takes --organization-id and --project-id: they select the scope your data is stored under. Backends map a scope to tables, key prefixes, or tenant ids, but callers see one stable model.

Backends

Two backends implement the same traits today:

• In-memory for tests and harness development;
• SQLite for durable local project state, which is what the CLI uses through --memory-db.

Redis and cloud backends are planned behind the same traits, so domain crates never change when the backend does.

Durable sessions

codel00p-session builds on those primitives: it stores session metadata as documents and the transcript as an append log. Because the harness emits a typed event for every step, a stored session can be replayed exactly, which is what agent resume and the session commands rely on. Approved memory is stored the same way, with its review and audit history kept as append logs.