AUFGERAUMT: Root auf 10 sichtbare Elemente reduziert

Der Nutzer hat recht: Der Ordner war voller Entwicklungs-Muell.
Jetzt ist sauber getrennt:

ROOT (was der Nutzer sieht und braucht):
- run.py                     = das Programm
- hms_app/                   = der Anwendungscode
- HMS MediaEngine.app        = macOS Doppelklick-Starter
- HMS-Start.vbs              = Windows Doppelklick-Starter
- HMS-Install.vbs             = Windows Erst-Installation
- HMS-Mac-Install.command     = macOS Homebrew-Installation
- HMS-Portable-Install.command = macOS Portable-Installation (16GB-Fix)
- installer_gui.py           = grafischer Installer
- launcher.pyw + launcher_core.py = interne Start-Logik
- LIESMICH.txt               = 10-Zeilen-Kurzanleitung
- .gitignore

_entwicklung/ (alles andere, NICHT benoetigt):
- packages/ apps/ native/ plugins/ tools/ schemas/ tests/ docs/
  build/ fixture_profiles/
- PLAN.md STATUS.md ERRORS.md TEST_REPORT.md CHANGELOG.md README.md
- pyproject.toml uv.lock setup_*.sh/ps1 make_mac_app.py

Diese Trennung gilt ab sofort fuer alle Commits. Der Nutzer kann
_entwicklung/ loeschen wenn er Platz braucht - die App laeuft ohne.

Verifiziert: App startet nach Aufraeumen unveraendert (Health 200).
This commit is contained in:
HMS MediaEngine Agent
2026-09-11 23:44:06 +02:00
parent 696e8eb1b3
commit 362e089be0
338 changed files with 24 additions and 387 deletions
@@ -0,0 +1,45 @@
# ADR-0010: Node-Paarung PIN/Fingerprint, Token-Scopes, Widerruf
- **Status:** Angenommen
- **Datum:** 2026-09-11
- **Phase:** 1
- **Bauplan:** §6.3, §27.1, §32 (ADR-Pflicht: Node-Paarung, TLS, Berechtigungsscopes)
## Entscheidung
1. Paarung: kurzlebige PIN + sichtbarer Identitäts-Fingerprint. Ein Node wird
erst nach erfolgreicher PIN-Prüfung steuerbar (§6.3).
2. Nach Paarung erhält der Partner ein wiederrufbares Token mit getrennten
Scopes: `read`, `control`, `content_sync`, `admin` (§27.1).
3. Tokens werden als Hash gespeichert, nie im Klartext; Widerruf = Deletion,
sofort wirksam.
4. Ungepaarte Nodes geben ausschließlich minimale Discovery-/Pairing-
Informationen heraus (§27.1).
## Umsetzung Phase 1
- `hms_cluster.pairing`: PIN-Erzeugung (6-stellig, kryptographisch),
Fingerprint (SHA-256 über Identitäts-Public-Daten, hex-gruppiert sichtbar),
Paarungs-State, Token-Hash mit Scopes + Ablauf, Versuchslimit.
- TLS-Transport und Zertifikatsaustausch folgen mit dem Cluster-WebSocket
(Phase 2); dieses ADR legt die Datenmodell-Basis.
## Alternativen
- Nur Zertifikate ohne PIN: anfällig für falsche Geräte in Setup-Situationen;
sichtbare PIN ist bewusst einfach (§6.3).
- Statische API-Keys: keine Scopes, kein gezielter Widerruf.
## Folgen
- Gate-1-Test „sicher gepaart“: PIN-Prüfung + Token-Ausstellung + Widerruf
getestet; TLS-Handshake folgt in Phase 2 und bleibt in STATUS.md offen.
## Messwerte / Nachweise
- Unit-Tests: PIN-Format/-TTL, Fingerprint-Stabilität, Scope-Zuordnung,
Ablauf, Widerruf, Hash-only-Speicherung, Versuchslimit.
## Freigabe
- Standardumsetzung gemäß §6.3/§27.1.