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

39 lines
1.4 KiB
Markdown

# 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
```text
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