# Progress

Where the project stands, and what happened in each session. Newest first. The process is in
CLAUDE.md ("Working rules").

## Current state

- **Iteration 1, phase 2 (planning and design) started.** Phase 1 is approved (D13);
  [REQUIREMENTS.md](REQUIREMENTS.md) is the baseline.

## Next steps

Phase 2 for the MVP scope (D8: MQTT connection + discovery + availability, the MVP sensors, a
basic notification). Design topics, proposed order:

1. ~~Q4: MQTT client library~~: done, libmosquitto (D14). Remaining for the design: Qt
   event-loop integration, shipping the library in the package (build + `install.sh`).
2. Component structure: configuration, MQTT/discovery layer, sensor sources, notification
   service; how they fit into `Dashboard` (the app class).
3. HA entity model: topics, discovery payloads, availability, device grouping (CON-2/3/5,
   SEN-15).
4. Basic notification (NOT-1): needs an overlay outside the dashboard, i.e. the planned
   `WorldOverlay` (CLAUDE.md, "Planned extension"); MVP placement to be decided.
5. Test strategy for the MVP and the measurement method for NFR-3.

Later, not needed for the MVP: Q1 (several notifications), Q2/Q3 (dashboard); check only
whether they constrain the MVP architecture.

## Log

### 2026-10-05: requirements approved

- User approved REQUIREMENTS.md including the priorities (D13). Phase 2 started.
- Q4 decided: libmosquitto, shipped in the package (D14). Qt MQTT ruled out: private Qt API
  requires the exact Qt version. Checked on the Frame: no MQTT library installed; libssl/
  libcrypto 3 and libcjson 1 present.
- HA discovery: own small layer on QJson, device-based discovery (D15); hacpp and the
  embedded libraries rejected.
- Checked on the Frame which Qt modules, plugins and audio/network tools exist; library list
  per requirement in REQUIREMENTS.md Appendix C. Notable: Qt WebEngine and Qt WebSockets are
  present (relevant for Q2/Q3).
- libmosquitto ABI check: Debian's 2.0.21 needs at most `OPENSSL_3.0.0`/`GLIBC_2.34`; the
  Frame has OpenSSL 3.2.1 and glibc 2.39. No libcjson dependency. D14 holds.
- Stay with the Debian build container: an Arch container wouldn't match SteamOS's own package
  versions (private repos, rolling Arch) and has no arm64 multiarch for cross builds.

### 2026-10-04/05: project set-up and requirements

- Copied the vrdashboard template. Removed what the app doesn't need:
  - `examples/` (diagnostics app) and the `VRDASH_BUILD_EXAMPLES` option
  - the Frame test package (`scripts/package-frame-test.sh`, `docs/FRAME-TESTING.md`,
    screenshots)
  - the demo UI (`src/qml/DemoPage.qml`)

  `Main.qml` shows a placeholder card.
- Named the app **FrameAssistant**, "Steam Frame companion for Home Assistant":
  - CMake project `frameassistant`, executable `frame-assistant`
  - app key `net.matzman.frameassistant`, tab "Frame Assistant", QML module `FrameAssistant`

  Names rejected:
  - "Steam…" and "…Home Assistant": trademarks
  - "HASS…": the user dislikes it, because "Hass" is German for hate.
- Agreed working rules (in CLAUDE.md):
  - explicit permission for everything; ask instead of assuming
  - iterative five-phase cycle; an informal "ok" approves a phase
  - document everything in Markdown in `docs/`
- `git init`. Baseline commit `4a5b090`.
- Requirements engineering (several question rounds with the user). The results are in
  REQUIREMENTS.md:
  - decisions D1–D12
  - 51 requirements
  - research on OpenVR data sources (Appendix A)
- Checks: `native-debug` builds, `ctest` passes 6/6 (Vulkan surface test skipped, no Vulkan on
  this host), `--snapshot` renders.