brewpi/web/TODO.md

web/ (browser client) vs. client/brewpi_gui.py parity backlog

web/app.js ported the Manual tab's direct controls and the Progress tab wholesale from client/brewpi_gui.py (see README.md's "Browser client"). Everything below is what that v1 pass deliberately left out - either flagged as deferred in the plan, or only noticed once the port was done and checked against the Qt source side by side.

• No way to actually run a brew. There's no Start/Pause/Stop/ Confirm anywhere in web/index.html Start/Pause/Stop/Confirm are all wired up (btn-sud-start/btn-sud-pause/btn-sud-stop in app.js, gated by updateSudActions() mirroring update_sud_actions()'s enabled/disabled logic - Pause only enabled while actually running, same as the desktop client's actionPause; Confirm via the #sud-message-dialog below).

• WAIT_USER never surfaces to the user. showUserMessage() pops #sud-message-dialog (a plain <dialog>, no library) the instant WAIT_USER is newly entered (onSudChanged()'s State branch tracks prevState for this), and sends {"Sud": {"Confirm": true}} on the dialog's close event - covers both the OK button and Escape, mirrors show_user_message() (client/brewpi_gui.py:877-882).

• No schedule management. New/Load/Save are now wired up in app.js: Load is <input type="file"> + FileReader + {"Sud": {"Load": ...}}; Save sends {"Sud": {"Save": true}} and downloads (Blob+<a download>) whichever Json push answers it (tracked via sudSavePending, mirroring brewpi_gui.py's sud_save_path); New sends the same hardcoded empty-doc Load Qt does.

• No temperature-controller state/cooldown indicator. Qt shows the raw FSM state (label_state.setText(msg['State']) - e.g. "States.HOLD") and a separate blinking "Cool down" label specifically for States.COOL (set_tc_cooling(), client/brewpi_gui.py:820-829, driven by on_tempctrl_changed()'s 'State' branch). app.js's onTempCtrlChanged() never reads msg.State at all right now - worth a small label in the Controller panel, reusing the same 500ms blink-timer pattern the Progress tab's LEDs already have.

• No transient status notifications. Qt's status bar shows short-lived messages on certain events - e.g. "Sud schedule updated: {name}" for 5s on every Name push (client/brewpi_gui.py:1043-1045). web/'s status line only ever shows the persistent Sud/env summaries; there's nowhere for one-shot events to surface at all.

• Nothing persists across reloads. client/user_config.py keeps the last ambient temperature and Sud file-dialog directory in ~/.config/brewpi/gui.json across restarts. web/'s ambient-temp field always starts blank until the first System.AmbientTemp push; localStorage would be the natural equivalent (and the host field could remember the last-used server too, which the desktop GUI doesn't even need since it's one app per machine).

• No reconnect handling. A dropped WebSocket (ws.onclose) just flips the UI to "Disconnected" and stops - the user has to click Connect again by hand. WsClient (ws/client/ws_client.py, used by the desktop GUI) - check whether it already retries and mirror that, or add a simple backoff retry loop in connect().

• Automatic tab (forecast-vs-actual plot) and Plot tab (live strip charts) don't exist. Flagged in the original plan and in README.md's "Browser client" section as deferred pending a charting decision, not an oversight - listed here too so this file alone is a complete picture of the gap. SudForecastPlot/RealtimePlot (client/brewpi_gui.py:121-258) are the reference for what each needs to show. See the uPlot mention below - that's the leading candidate for both.

• UI migration to Vue.js, charts via uPlot. app.js is vanilla JS with hand-rolled document.getElementById/textContent wiring for every piece of state (see its own intro comment) - workable for v1's scope, but every new feature (Pause, the Confirm <dialog>, ...) is more manual DOM plumbing, and there's no charting at all yet (previous item). Mainsail (the Klipper web UI - a comparable "control a piece of hardware over a persistent WebSocket" app) is the reference point for both: Vue 3 + TypeScript + Vuetify for reactive state-to-DOM binding instead of this file's manual updates, and uPlot for live charts specifically - it's canvas-based and fast enough for high-frequency ticks (this server pushes Elapsed/Ist on every tick), unlike heavier libraries like Chart.js. A bigger lift than anything else in this file - revisit once the rest of this backlog (or at least the charting item) makes it worth the rewrite, not before.

• No authentication. Also already called out in README.md - matches the WebSocket server's own complete lack of it, not a new gap, but worth a line here too since "browser, reachable from anywhere on the network" is a wider exposure than the desktop app ever was.