Keep HTTP as the foundation

The board loads a complete incident snapshot over HTTP, submits operator commands over HTTP, and streams subsequent changes. This is a small part of a live service-status board that streams incidents without losing its ordinary HTTP foundation, but the boundary it creates affects everything that follows.

A live connection should complement HTTP rather than replace every request in the application. The useful target is not encyclopedic coverage. Make one deliberate choice, observe its consequences, and know which requirement would make you revise it.

Watch for one shortcut in particular: trying to send the entire application protocol through one long-lived socket because it feels more real-time. It makes later failures harder to locate. Instead, separate snapshots, commands, and event notifications so each has an inspectable contract and retry policy. Prefer an implementation you can explain from the outside before optimizing it.

Keep the wider goal in view: Choose the least complicated channel that meets the product requirement, and keep a non-live path for recovery. A short observation with concrete evidence is more useful than a confident sentence with no reproduction path.

Define one snapshot route, one command route, and one event envelope; explain which one repairs a missed update. Hand the result to someone else and see whether the behavior is clear without an oral explanation.