Queue Cure : Real-time queue management for clinics.

A live digital token queue for a neighbourhood clinic: a receptionist screen to add patients and call the next token, and a patient-facing waiting room screen that updates instantly — no refresh — with a wait estimate computed from that clinic's actual consultation times, not a guess. Multi-clinic: any number of clinics can use this from one deployment. Each clinic creates its own queue and gets its own private link — nothing is shared, including live updates (verified — see "Multi-clinic isolation" below). Process Why a single shared snapshot instead of separate diffs per screen Early designs for things like this often try to send minimal "patches" to each screen (e.g. "token 12 status changed to done"). That's more bandwidth-efficient, but it means each screen has to reconstruct queue state from a stream of patches — and if a screen misses one message (reconnect, tab backgrounded on a phone, flaky clinic wifi), it silently drifts out of sync forever. Sending one full, authoritative snapshot on every change is slightly more data, but it makes "out of sync" structurally impossible: a screen that reconnects gets the truth, not a delta. Results Empty queue: "Call Next" disables with a plain explanation instead of letting the receptionist click into a no-op or an error. Last patient of the day: calling next when no one is waiting still correctly closes out the current patient — it just doesn't open a new one. The button label changes to "Finish current patient" so this isn't ambiguous. No-shows: a dedicated skipped status, separate from done, so a no-show doesn't get counted as a completed consultation in the duration average (which would quietly corrupt the wait-time math). Daily reset with no cron job: every query is resets everyday Reflection Auth changed shape, too. A single-clinic PIN can live as a frontend constant and it's a minor sin (anyone with devtools can find it, but it's one clinic's one secret). That doesn't scale to N clinics — there's no single constant to bake in. So the PIN moved server-side: hashed with bcrypt at clinic-creation time, checked via a clinic:auth socket event, and the authorization lives on the socket connection, not in the browser. That's a meaningfully different trust model, not just a refactor — worth flagging because it's easy to read "added multi-clinic" as a pure UI change when it actually moved