Files
hemx/docs/recipes/local-command-log.md
T
slhx agent 64a736ffcb feat(local): model local command log boundary
Define local/offline truth as commands, domain events, and projections rather than stored DOM patches or EffectBatch payloads, and wire the techdemo through a local command-to-projection-to-effect flow.

req: local/001

req: local/002

req: local/003

req: local/004

req: examples/001
2026-06-11 19:49:34 +02:00

1.4 KiB

Recipe: local command log

A hemx app may feel local-first without making hemx core a client database or sync framework. The local artifact is an app-owned command/event log plus a projection; hemx effects are rendered output, not stored truth. req: local/001 req: local/002

Shape

user intent
→ LocalCommand
→ domain validation
→ LocalEvent
→ Projection
→ hemx EffectBatch

The log may live in memory, IndexedDB, SQLite, a native host store, or another app-chosen persistence layer. That storage choice is not hemx core. req: local/002

Replay and sync

Replaying local work to a server, remote AI/STT gateway, backup target, or peer sync engine is explicit product policy. The app decides what can be queued, exported, deleted, reconciled, retried, rejected, or redacted. A local projection can render immediate feedback while those decisions remain pending. req: local/003

Boundary

Do not persist DOM patches as truth. Do not persist EffectBatch payloads as the local application log. Those are render instructions produced after app/domain code accepts commands and projects events. req: local/001 req: local/004

Use hemx-host only when the local log needs device or shell capabilities such as secure storage, files, haptics, microphone, or notifications. The host still returns facts; app code still owns the command/event/projection policy. req: host/002 req: local/003