Start the design document with the high-level architecture

DESIGN.md: one process with several threads (D16), three layers (D17),
HA-centric object classes (D18), injected configuration (D19). Design
decisions move from REQUIREMENTS.md to DESIGN.md.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/PROGRESS.md

@@ -10,21 +10,20 @@ CLAUDE.md ("Working rules").
 
 ## Next steps
 
-Phase 2 for the MVP scope (D8: MQTT connection + discovery + availability, the MVP sensors, a
-basic notification). Design topics, proposed order:
+Phase 2: first the high-level architecture, then the details for the MVP (D8). High-level
+questions, in this 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.
+1. ~~Process model~~: one process, several threads (D16).
+2. ~~Layers~~: presentation, business logic, I/O (D17).
+3. How features plug in: object classes (D18) and configuration injection (D19) settled;
+   open: how the classes are wired.
+4. HA channels: MQTT only, or prepare for a second one for the dashboard (Q2/Q3)?
+5. Overlay kinds: dashboard tabs and world overlays (platform extension).
+6. Runtime model: which work runs in which thread (D16: several threads).
+7. Test strategy at a high level.
 
-Later, not needed for the MVP: Q1 (several notifications), Q2/Q3 (dashboard); check only
-whether they constrain the MVP architecture.
+Details afterwards (MQTT library done: D14, D15): topics and payloads, basic notification,
+configuration, packaging of libmosquitto.
 
 ## Log
 
@@ -41,6 +40,11 @@ whether they constrain the MVP architecture.
   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.
+- 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.