HMS MediaEngine Agent
362e089be0
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).
33 lines
1.3 KiB
Markdown
33 lines
1.3 KiB
Markdown
# ADR-0006: Frontend – React mit Vite
|
||
|
||
- **Status:** Angenommen
|
||
- **Datum:** 2026-09-11
|
||
- **Phase:** 5
|
||
- **Bauplan:** §7 („TypeScript, React oder Svelte, Vite-basierter Build“), §32 ADR-Pflicht
|
||
|
||
## Entscheidung
|
||
|
||
**React 18 mit Vite** im statischen SPA-Modus.
|
||
|
||
## Begründung
|
||
|
||
- Größtes Ökosystem an Komponenten, Tastatur- und Drag-Bibliotheken – wichtig für dichte Layer-Tabellen mit Ziehwerten (§17.3), Drag-Sortierung, undockbare Paneele (§17.2)
|
||
- Breitere Verfügbarkeit erfahrener Frontend-Entwickler
|
||
- Vite-Build für statische Assets passt zu §3.2 (Web-UI ist nie Videoausgang)
|
||
- Svelte wäre kleiner – aber bei einer professionellen Arbeitsoberfläche mit komplexem State (100+ Parameter je Layer) überwiegt Reacts Vorhersagbarkeit
|
||
- Ein Wechsel ist durch die saubere REST/WebSocket-API-Trennung (§23) jederzeit ohne Backend-Änderung möglich
|
||
|
||
## Alternativen
|
||
|
||
- Svelte/SvelteKit: kompakter, aber kleineres Ökosystem; bei tabellenlastiger UI weniger Vorteile
|
||
|
||
## Folgen
|
||
|
||
- pnpm-Lockfile; statische Auslieferung über FastAPI (web/-Ordner, §9)
|
||
- Vitest + Playwright für Tests (§7)
|
||
- Design-Tokens zentral in CSS-Variablen (§17.6), kein UI-Framework wie MUI – eigene dichte Oberfläche
|
||
|
||
## Freigabe
|
||
|
||
- Standardumsetzung gemäß §7; ADR dokumentiert die Auswahl.
|