Files

T

HMS MediaEngine Agent 362e089be0 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).

2026-09-11 23:44:06 +02:00

2.2 KiB

Raw Blame History

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

Die Phasen 1–5 werden plattformneutral vollständig gebaut (Code, Tests auf CPU-Ebene, Schemas, Dokumentation), bevor Hardwaremessungen stattfinden.
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.
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.

2.2 KiB Raw Blame History Unescape Escape