dashboard events: unified coord channel + /dashboard/{stream,history}; broker forwards

hive-c0re/src/dashboard_events.rs

@@ -0,0 +1,47 @@
+//! Unified dashboard event channel.
+//!
+//! Anything the browser wants to react to in near-real-time flows through
+//! `Coordinator.dashboard_events`. Each event is stamped with a monotonic
+//! per-process `seq` so the client can dedupe its buffered live traffic
+//! against snapshot/history responses (drop frames with
+//! `seq <= snapshot.seq`).
+//!
+//! Why one channel instead of one-per-domain: browsers cap concurrent
+//! SSE connections per origin (~6 in chrome) and dispatch-by-kind on the
+//! client is a one-liner. Splits get reserved for high-volume sub-streams
+//! that most consumers don't care about (none yet).
+//!
+//! Message-broker traffic (`Sent` / `Delivered`) lives on this channel
+//! too. A background forwarder task in `main.rs` subscribes to the broker
+//! and re-emits each `MessageEvent` as a `DashboardEvent::Sent` /
+//! `DashboardEvent::Delivered` with a freshly-stamped seq. Keeping the
+//! broker's intra-process channel separate avoids coupling the broker
+//! (used by `recv_blocking` inside the harness loop) to dashboard
+//! presentation concerns.
+//!
+//! New mutation kinds (approval added/resolved, question added/answered,
+//! transient changed, etc.) land here as additional variants. The client
+//! dispatches by `kind` and updates the relevant section.
+
+use serde::Serialize;
+
+#[derive(Debug, Clone, Serialize)]
+#[serde(rename_all = "snake_case", tag = "kind")]
+pub enum DashboardEvent {
+    /// Broker `Sent` event mirrored onto the dashboard channel.
+    Sent {
+        seq: u64,
+        from: String,
+        to: String,
+        body: String,
+        at: i64,
+    },
+    /// Broker `Delivered` event mirrored onto the dashboard channel.
+    Delivered {
+        seq: u64,
+        from: String,
+        to: String,
+        body: String,
+        at: i64,
+    },
+}