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/Stop are now wired up (btn-sud-start/btn-sud-stop in app.js, gated by updateSudActions() mirroring update_sud_actions()'s enabled/disabled logic). Still missing: Pause, and {"Sud": {"Confirm": true}} - that one needs sudUserMessage/sudState (next item) to know when it's actually waiting on one.

• WAIT_USER never surfaces to the user. sudUserMessage is tracked in app.js but nothing ever shows it - show_user_message() (client/brewpi_gui.py:877-882) pops a modal the instant WAIT_USER is newly entered (prev_state != WAIT_USER) and sends Confirm itself when the user dismisses it. Needs the same "newly entered" edge detection in onSudChanged()'s State branch (the wasRunning tracking there is close, but checks running-vs-not, not specifically the WAIT_USER transition) plus a modal (a plain <dialog> works, no library needed) that sends Confirm on close.

• 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.

• 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.