Add change feed API for streaming graph mutations to consumers

Start with docs/docs/roadmap.md and trace how Meteor’s incremental delivery represents graph deltas before choosing an API transport. Define the event types, filtering, replay, ordering, back-pressure, and update-state guarantees, then verify that the design covers all listed consumer and reconnection requirements.

Context

Compass is currently a pull-only store — you query it to get data. AI agents and downstream systems that need to stay current should be able to subscribe to graph changes rather than polling.

Scope

• Streaming API endpoint that emits graph mutations as they happen
• Event types: entity.created, entity.updated, entity.deleted, relationship.created, relationship.deleted
• Support filtering by entity type, namespace, or relationship type
• Include before/after state for updates (or at minimum, changed fields)
• Transport options: SSE (Server-Sent Events), WebSocket, or gRPC streaming

Design Considerations

• Back-pressure handling for slow consumers
• Cursor-based replay for consumers that disconnect and reconnect
• Event ordering guarantees within a namespace
• Integration with Meteor's incremental delivery — Meteor pushes deltas, Compass propagates them

Why

AI agents maintaining cached context can subscribe and keep their view fresh without polling. Downstream systems (monitoring, alerting, compliance) can react to graph changes in real time.

References

• Compass Roadmap — Active Knowledge