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

- [x] **No way to actually run a brew.** ~~There's no Start/Pause/Stop/
  Confirm anywhere in `web/index.html`~~ Start/Stop/Confirm are now wired
  up (`btn-sud-start`/`btn-sud-stop` in `app.js`, gated by
  `updateSudActions()` mirroring `update_sud_actions()`'s
  enabled/disabled logic; Confirm via the `#sud-message-dialog` below).
  Still missing: Pause - trivial to add the same way as Start/Stop
  whenever it's actually needed.

- [x] **`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`).

- [x] **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.