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).
54 lines
2.2 KiB
Markdown
54 lines
2.2 KiB
Markdown
# ADR-0008: Build-first-Strategie – verzögerte Hardware-Validierung
|
||
|
||
- **Status:** Angenommen (Auftraggeber-Freigabe)
|
||
- **Datum:** 2026-09-11
|
||
- **Phase:** 0/1 (übergreifend)
|
||
- **Bauplan:** §1, §1.1 Nr. 1/9/10, §29.7, §36 Nr. 16
|
||
|
||
## Kontext
|
||
|
||
Die Entwicklungsumgebung ist ein CPU-only-Linux-Container ohne Windows-GPU.
|
||
Der Auftraggeber wünscht am 2026-09-11 ausdrücklich: „erst fertig bauen und dann
|
||
auf Windows testen". PLAN.md §1 erlaubt Abweichungen vom normativen Ablauf,
|
||
wenn sie per ADR dokumentiert, technisch begründet und vom Auftraggeber
|
||
freigegeben werden. Diese Freigabe liegt mit der Anfrage vor.
|
||
|
||
## Entscheidung
|
||
|
||
1. Die Phasen 1–5 werden **plattformneutral vollständig gebaut** (Code, Tests
|
||
auf CPU-Ebene, Schemas, Dokumentation), bevor Hardwaremessungen stattfinden.
|
||
2. Gate 0 und alle renderer-nahen Abnahmen werden **gesammelt in einem
|
||
Windows-Durchlauf** nachgeholt (reverse validation). Reihenfolge dort:
|
||
Portabilität → Decode/Residenz → Framezeit/DMX-Latenz → Adaptive Quality →
|
||
Golden Images → Onefolder-Build.
|
||
3. Kein Gate wird vorher als grün gemeldet; STATUS.md führt die ausstehende
|
||
Hardware-Validierung offen als Checkliste.
|
||
|
||
## Alternativen
|
||
|
||
- Streng planmäßig (Gate 0 zuerst): sicherer, aber ohne Windows-Zugang blockiert;
|
||
vom Auftraggeber verworfen.
|
||
- Windows-Cloud-VM in der Entwicklungsumgebung: hier nicht verfügbar.
|
||
|
||
## Folgen und Risiken
|
||
|
||
- ADR-0004/0005 müssen ohne Messdaten vorläufig entschieden werden →
|
||
ausdrücklicher Bestätigungsvorbehalt für den Windows-Durchlauf.
|
||
- Der D3D11-Elementpfad bleibt bis dahin unvalidiert. Absicherung: der
|
||
Backend-Vertrag (§12.6) hält Korrekturen im Adapter lokal; Projekt-,
|
||
Parameter-, DMX- und Web-API ändern sich nicht.
|
||
- Shader werden nur statisch bereitgestellt; Compile- und Golden-Image-Tests
|
||
entstehen im Windows-Durchlauf.
|
||
- Fällt Gate 0 rot aus: gezielte Sanierung nach §1.1 Nr. 9 mit ERRORS.md-Eintrag;
|
||
kein Architektur-Neubau erforderlich (Vertragsabsicherung).
|
||
|
||
## Messwerte / Nachweise
|
||
|
||
- CPU-Ebene: pytest/Ruff grün je Etappe (TEST_REPORT.md, fortlaufend).
|
||
- Hardware: ausstehend; Checkliste in STATUS.md.
|
||
|
||
## Freigabe
|
||
|
||
Auftraggeber: per Chat-Anfrage 2026-09-11 („erst fertig bauen und dann auf
|
||
Windows testen") – hiermit dokumentiert.
|