InternalADRs
ADR-0018: Package Names and Intended Responsibilities
Canonical package set and naming: store-* (client truth), db-* (server persistence), bind-* (UI bindings).
Status
Accepted
Context
We need stable package naming conventions that convey responsibility and make the client/store vs server/db distinction obvious.
Decision
Recommended initial package set:
Foundation
@rippledb/core— HLC, tags, Change types, merge/compare, utilities (pure)
Client side
@rippledb/client— sync orchestration (outbox, pull/apply/push), policies, stream handling (no DB deps)
Server side
@rippledb/server— server interfaces and helpers for append + cursor pull (no DB deps)
Client truth stores
@rippledb/store-sqlite— client truth store implementation (+ batch loader hooks)@rippledb/store-indexeddb— later (browser-only)@rippledb/store-memory— tests
Server persistence
@rippledb/db-postgres— cursorable change history + append + optional materialization helpers@rippledb/db-sqlite— dev / tests@rippledb/db-dynamodb— later
UI bindings
@rippledb/bind-tanstack-query— invalidation wiring + list registry + coalescing@rippledb/client-controllers— Abstract CRUD controllers with batch loading@rippledb/client-query— Final application-level DX, combining controllers and UI bindings
Future (not v0)
@rippledb/transport-ws— optional realtime helpers- CRDT/doc controller modules (separate scope)
Alternatives Considered
- Single package
- Different naming scheme (
adapter-*,driver-*,ui-*)
Consequences
- Clear imports and mental model
- Easy to extend with more stores/dbs/bindings
- Some packages start very small (acceptable)