Operation Log & Sync Documentation
The Operation Log is the single sync system for all providers (SuperSync,
WebDAV, Dropbox, LocalFile). It is an event-sourced persistence + sync layer:
the log is the source of truth, current state is derived by replaying it, and
vector clocks detect concurrent edits.
User Action
│
▼
NgRx Store (runtime source of truth)
│
┌───────────────────┼───────────────────┐
▼ │ ▼
OpLogEffects │ Other Effects
│ │
├──► SUP_OPS ◄───────┘ (local persistence — IndexedDB)
│
└──► Sync Providers
├── SuperSync (operation-based, real-time)
└── WebDAV / Dropbox / LocalFile (file-based, single sync-data.json)
Start here
Reference docs
| Document |
Scope |
| operation-log-architecture.md |
Authoritative architecture: Local Persistence (A), File-Based Sync (B), Server Sync (C), Validation & Repair (D), Smart Archive (E), Atomic State Consistency (F), and Why this architecture: rejected alternatives |
| contributor-sync-model.md |
The single sync invariant for contributors (one intent = one op; replayed/remote ops must not re-trigger effects) |
| operation-rules.md |
Design rules and guidelines for operations |
| package-boundaries.md |
Dependency/ownership boundaries for @sp/sync-core, @sp/sync-providers, app wiring |
| vector-clocks.md |
Vector clock implementation, pruning, history |
| supersync-encryption-architecture.md |
End-to-end encryption (AES-256-GCM + Argon2id) |
| diagrams/ |
Mermaid diagrams split by topic |
Scenario catalogs (expected behavior)
Related
Historical design notes and superseded plans are not kept as docs; they live
in git history (reference the relevant commit if you need the rationale).
