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
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