Future Features

Long-term ideas and improvements. These are not prioritized for current development but are worth revisiting as the product matures.

Team-level restore (and team-level checkpointing)

Current restore is all-or-nothing across all teams. Rolling back Team A also undoes Team B’s recent work. The event-sourced architecture could support team-scoped restore (BuildDocumentAtSequence selectively restoring one team’s subtree), but it would be a non-trivial extension. Team-level checkpointing could complement this.

Typed event system (reflection-based, open-closed processing)

The current event system uses stringly-typed EventType + Dictionary<string, string> data. A future improvement could introduce typed event classes (e.g., CreateTeamEvent, UpdateNameEvent) with a reflection-based dispatch registry. This would give compile-time safety for event data access, eliminate the TryGetValue/TryParse boilerplate in handlers, and make the EventTypes.All set self-maintaining via assembly scanning. The open-closed principle would allow adding new event types by just adding a class. Main obstacle: the checkpoint serialization format and cold start replay would need migration support.

Data retention policy and cleanup

The checkpoints and events tables will accumulate indefinitely. At scale, a retention policy should address:

Pruning old checkpoints (only the most recent N or those within a time window are needed for cold start)
Archiving or compacting old event log entries beyond a certain age
Defining retention windows appropriate to operational and audit needs

Not relevant for 3-5 years given expected usage, but should be revisited as data volumes grow.

D2 sequence and ER diagrams (docs)

The documentation site currently uses D2/ELK for all structural diagrams (flowcharts, DAGs, state machines) and Mermaid for sequence diagrams and the ER diagram. D2 has two shapes worth evaluating as replacements:

shape: sequence_diagram — D2’s native sequence diagram type. Actors are implicit from edges rather than declared. Simpler sequences translate cleanly; complex ones using Mermaid’s alt/opt/loop blocks would need restructuring using D2 containers. Worth trying on a few diagrams to compare visual quality and maintainability.
sql_table shape — D2’s native table shape for ER-style diagrams, as an alternative to Mermaid’s erDiagram / crow’s foot notation. D2’s sql_table is column-level rather than relationship-level, which may or may not be a better fit depending on the diagram’s purpose.

Adopting both would give the docs a fully unified D2 toolchain.