# Hermes WebUI Service Autostart Design

## Goal

`hermes-webui start` already starts the Python WebUI server as a detached daemon. Add a separate service-management surface so users can install, start, stop, restart, inspect, and uninstall WebUI as a login/boot service.

## CLI Surface

Add:

```text
hermes-webui service install [--port <port>] [--host <host>]
hermes-webui service start
hermes-webui service stop
hermes-webui service restart
hermes-webui service status
hermes-webui service uninstall
```

Service-managed starts run:

```text
hermes-webui start --foreground --port <port> --host <host>
```

The foreground mode is intentional: systemd, launchd, and Windows Task Scheduler own the long-lived process and restart policy. Manual `hermes-webui start` remains the direct detached-daemon path.

## Platform Backends

- Linux: user systemd unit at `~/.config/systemd/user/bitseek-hermes-webui.service`; enable and manage with `systemctl --user`.
- macOS: launchd plist at `~/Library/LaunchAgents/com.bitseek.hermes-webui.plist`; manage with `launchctl bootstrap/bootout/kickstart`.
- Windows: scheduled task named `BitSeekHermesWebUI`; trigger `ONLOGON`; action runs a generated hidden `wscript.exe` wrapper, which in turn runs the `.cmd` wrapper stored under `%LOCALAPPDATA%\hermes\webui-service\`.

## State And Logs

WebUI state stays under `HERMES_WEBUI_STATE_DIR` or `$HERMES_HOME/webui`. Runtime logs still use `server.log`; service managers may also expose their own logs/status.

## Docker Compose Test Boundary

Most Docker containers do not run systemd or launchd. Compose tests should verify:

- CLI syntax and generated service files using a fake HOME and fake service-manager binaries.
- The manual detached daemon path still starts and survives after the CLI exits.
- Unsupported platform/service-manager errors are explicit when no service manager is present.
