matzmanandClaude Opus 5.5
06de5cf184
D25: dashboard tabs and world overlays; premultiplied-alpha flag. D26: one world overlay for all notifications. D27: MVP placement "spawn in front, then stay". D28: DSH-1 (web UI out-of-the-box test) joins the MVP, full dashboard becomes DSH-2. Add the research on notification UI in VR (DESIGN.md, Appendix A). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
92 lines
4.6 KiB
Markdown
92 lines
4.6 KiB
Markdown
# 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: first the high-level architecture, then the details for the MVP (D8, plus DSH-1 by
|
||
D28). High-level
|
||
questions, in this order:
|
||
|
||
1. ~~Process model~~: one process, several threads (D16).
|
||
2. ~~Layers~~: presentation, business logic, I/O (D17).
|
||
3. ~~How features plug in~~: object classes (D18), configuration injection (D19), one class
|
||
per HA entity type with native types preferred (D23).
|
||
4. ~~HA channels~~: MQTT for the device, own channel for the dashboard later (D24).
|
||
5. Overlay kinds: dashboard tabs and world overlays (D25), one notification overlay (D26),
|
||
MVP placement (D27); DSH-1 web UI test in the MVP (D28).
|
||
6. Runtime model: which work runs in which thread (D16: several threads).
|
||
7. Test strategy at a high level.
|
||
|
||
Details afterwards (MQTT library done: D14, D15): topics and payloads, basic notification,
|
||
configuration, packaging of libmosquitto.
|
||
|
||
## 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.
|
||
- DSH-1 split: web UI out-of-the-box test in the MVP, full dashboard as DSH-2 (D28).
|
||
- Overlays: two kinds (D25), one overlay for all notifications (D26), MVP placement "spawn in
|
||
front, then stay" (D27). Researched notification UI in VR (DESIGN.md, Appendix A). Found:
|
||
premultiplied-alpha flag missing in the platform.
|
||
- HA channels: MQTT for everything device-related; dashboard channel decided with Q2/Q3 (D24).
|
||
- Entities: one class per HA entity type, native types preferred, own service only as fallback
|
||
(D23). Found: MQTT `notify` drops the title.
|
||
- Start-up hook `prepare()` in the platform (D21); modes, `--desktop-novr` and `--config`
|
||
(D22).
|
||
- New requirement UI-1: status display in the main tab (D20).
|
||
- The user installed `mosquitto` on the dev host, so native builds can use libmosquitto.
|
||
- Started docs/DESIGN.md: one process (D16), three layers (D17), HA-centric object classes
|
||
(D18). HA side: FrameAssistant needs only stock HA; how the user wraps commands (scripts,
|
||
pyscript) is up to them (NFR-6 unchanged).
|
||
- Agreed to settle the high-level architecture first (list under "Next steps"), before
|
||
component details.
|
||
- 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.
|