[Needs discussion] Real-time sync architecture (WebSockets vs. SSE vs. polling)

[Wikid82]

Why

Multiple planned features (kiosk wall dashboard, #38; general responsiveness — a chore added on a phone should appear on the kitchen tablet without a manual refresh) want live updates. The research suggested WebSockets, but that needs a persistent, stateful server process, which conflicts with Hestia's current single-process Next.js/Docker deployment model and its explicit no-background-jobs philosophy (see CLAUDE.md).

This needs a decision, not an implementation, first

• WebSockets: true bidirectional real-time, but requires a long-lived server process/connection manager — a real architecture change (custom server, or a separate process/sidecar), at odds with "one process to deploy"
• Server-Sent Events (SSE): one-way push over plain HTTP, works within a standard Next.js route, much smaller architectural footprint, sufficient for "dashboard should update when something changes" use cases
• Polling: simplest, zero architecture change, but adds latency and periodic load; may be good enough for a household-scale app

Recommendation to evaluate

SSE looks like the best fit for Hestia's constraints (single process, no background workers) if the actual need is "push updates to connected clients," not bidirectional messaging. Needs Jeremy's sign-off before scheduling — this affects the deployment model.

Depends on

None — this is the discussion that unblocks scheduling any "live update" work.

Acceptance criteria

• A decision is recorded (WebSockets / SSE / polling) with rationale
• If it's a genuine architecture change, CLAUDE.md is updated to reflect it before implementation starts