Roadmap

Expose the command log as a user-facing feature: a timeline of changes made to their data, by whom, and when. This is the journal — a queryable history of what happened.

The activity monitor takes this further into real-time: a live view combining command executions, domain events, and frontend actions into a unified stream. Could be powered by WebSocket push from the command tracing lifecycle hooks.

The journal queries historical entries; the monitor streams them as they are recorded.

A dual-schema pattern where the global command_log stores lean metadata for cross-tenant insights, while a tenant-scoped table stores the full payload including sensitive fields. The ExcludeCmdBody option already provides the mechanism — this would formalize the pattern with library support.

Re-execute a command from its stored payload to reproduce behavior or recover from failures. The command log already stores everything needed — this would add the infrastructure to pick up a stored command and resubmit it.

A command can serve as a draft for immutable data: instead of writing to the database immediately, persist the command body, apply it in-memory to project the result, and let the user iterate before committing. On approval, execute the command — it flows through normal tracing and produces the canonical record.

The library does not ship this, but the design is straightforward. A typical implementation has these pieces:

A built-in or reference cleanup job that purges old command log entries based on their retention value. ShortLived entries are deleted first, LongLived after a configurable period, Permanent entries are kept indefinitely.