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
@@ -0,0 +1,27 @@
|
||||
# ADR-0001: Python-Version pinnen
|
||||
|
||||
- **Status:** Angenommen
|
||||
- **Datum:** 2026-09-10
|
||||
- **Phase:** 0
|
||||
- **Bauplan:** §7 („Python, unterstützte Version exakt pinnen“)
|
||||
|
||||
## Entscheidung
|
||||
|
||||
Der Control Core und alle Python-Pakete pinnen **Python 3.13** (`requires-python = "==3.13.*"` in `pyproject.toml`).
|
||||
|
||||
## Kontext
|
||||
|
||||
Der Bauplan verlangt eine exakt gepinnte Python-Version. 3.13 ist die aktuelle stabile Version mit ausgereiftem `asyncio`, breitem Wheel-Support für FastAPI/Pydantic und PyGObject-Kompatibilität für die GStreamer-Bindings.
|
||||
|
||||
## Alternativen
|
||||
|
||||
- 3.12: kein messbarer Vorteil, kürzeres Supportfenster als 3.13.
|
||||
- 3.14: bei Projektstart zu neu für stabile Binärwheels aller Abhängigkeiten.
|
||||
|
||||
## Folgen
|
||||
|
||||
- uv-Lockfile und CI pinnen 3.13; Versionssprünge erfolgen bewusst per ADR-Änderung.
|
||||
|
||||
## Freigabe
|
||||
|
||||
- Auftragsvorgabe „exakt pinnen“ aus PLAN.md §7; Umsetzung ohne Abweichung.
|
||||
@@ -0,0 +1,28 @@
|
||||
# ADR-0002: GStreamer-Pin für Windows
|
||||
|
||||
- **Status:** Angenommen (Bündelungsumfang folgt nach Phase-0-Build)
|
||||
- **Datum:** 2026-09-10
|
||||
- **Phase:** 0
|
||||
- **Bauplan:** §7.1, §30.2
|
||||
|
||||
## Entscheidung
|
||||
|
||||
Für die portable Windows-Ausgabe wird **GStreamer 1.28.6 (MSVC, x86_64)** gebündelt (Runtime-Paket, exakt manifestierte Plugin-Untermenge). Details: `build/windows/GSTREAMER.md`.
|
||||
|
||||
## Kontext
|
||||
|
||||
Die 1.28-Serie ist die aktuelle stabile Release-Serie mit gepflegtem D3D11-Stack (`d3d11h264dec`, `d3d11convert`, `d3d11compositor`, `d3d11videosink`). Version ermittelt von https://gstreamer.freedesktop.org/download/ (Stand 2026-09-10).
|
||||
|
||||
## Alternativen
|
||||
|
||||
- Ältere LTS-Releases: keine Vorteile, ältere D3D11-Elemente.
|
||||
- Eigener GStreamer-Build: höherer Wartungsaufwand, für Phase 0 nicht nötig.
|
||||
|
||||
## Folgen
|
||||
|
||||
- Phase 0 prüft die Bündelung in einer sauberen Windows-VM ohne installiertes GStreamer (§29.6); Pluginliste und SHA-256 werden nach dem ersten Onefolder-Build manifestiert.
|
||||
- Muss mit der Packaging-Entscheidung (ADR-0005 offen) zusammenarbeiten.
|
||||
|
||||
## Freigabe
|
||||
|
||||
- Entspricht PLAN.md §7.1 (Version pinnen); Bündelungsumfang wird nach dem ersten Portabilitätstest ergänzt.
|
||||
@@ -0,0 +1,23 @@
|
||||
# ADR-0003: IPC – lokales TCP mit length-prefixed MessagePack
|
||||
|
||||
- **Status:** Angenommen (Bauplan-Vorgabe §6.2; umgesetzt in `packages/protocol`)
|
||||
- **Datum:** 2026-09-10
|
||||
- **Phase:** 0
|
||||
|
||||
## Entscheidung
|
||||
|
||||
Control Core ↔ Renderer kommunizieren über lokales TCP auf `127.0.0.1` mit length-prefixed MessagePack (4-Byte-Big-Endian-Länge, Protokollversion 1, Idempotency-Keys; Heartbeat ab Phase 1). JSON ausschließlich im Debugmodus.
|
||||
|
||||
## Alternativen
|
||||
|
||||
- Named Pipes/Unix Sockets: plattformspezifische API-Unterschiede, kein Nutzen im Spike.
|
||||
- JSON-Lines: langsamer und größer; nur für Debug erlaubt (§6.2).
|
||||
|
||||
## Folgen
|
||||
|
||||
- `hms_protocol` definiert Envelope, Framing und Idempotency-Registry mit Unit-Tests.
|
||||
- IPC bindet niemals an eine externe Netzwerkschnittstelle (§6.2).
|
||||
|
||||
## Freigabe
|
||||
|
||||
- Direkte Umsetzung der normativen Vorgabe PLAN.md §6.2.
|
||||
@@ -0,0 +1,47 @@
|
||||
# ADR-0004: Nativer Renderkern – Rust auf dem GStreamer-D3D11-Elementpfad
|
||||
|
||||
- **Status:** Vorläufig angenommen (Bestätigung oder Revision im Windows-Durchlauf)
|
||||
- **Datum:** 2026-09-11
|
||||
- **Phase:** ursprünglich Phase 0; wegen ADR-0008 vorgezogen
|
||||
- **Bauplan:** §6.1C, §7.1, §12.6
|
||||
|
||||
## Entscheidung
|
||||
|
||||
1. Sprache des nativen Moduls: **Rust**.
|
||||
2. Einbindung: **GStreamer-Plugin-Ansatz** – der Rendergraph nutzt die
|
||||
erprobten D3D11-Elemente (d3d11h264dec → d3d11convert → d3d11compositor →
|
||||
d3d11videosink) und eigene Rust-GStreamer-Elemente für Effekt-/Shader-Pässe,
|
||||
statt sofort eine komplett eigenständige Render-Bridge mit eigener
|
||||
Swapchain zu bauen.
|
||||
|
||||
## Begründung (ohne Messdaten, deshalb vorläufig)
|
||||
|
||||
- D3D11Memory-Residenz ist Eigenschaft der GStreamer-Elemente; das Risiko
|
||||
eigengebauten Swapchain-Compositings entfällt.
|
||||
- gstreamer-rs bietet stabile Bindings; Rust liefert Gedächtnissicherheit im
|
||||
nativen Pfad.
|
||||
- Die Effektkette skaliert als Elementkette; der Plugin-Vertrag (§14) bleibt
|
||||
vollständig gewahrt.
|
||||
- Eine spätere wgpu-/eigenständige Bridge bleibt über dasselbe IPC- und
|
||||
Capability-Protokoll anschließbar (§6.1C).
|
||||
|
||||
## Alternativen
|
||||
|
||||
- C++: kein Vorteil, höheres Fehlerrisiko im Speichermanagement.
|
||||
- Sofortige eigenständige Bridge: mehr Kontrolle, aber hohes Risiko ohne
|
||||
Hardware-Feedback (ADR-0008).
|
||||
|
||||
## Folgen
|
||||
|
||||
- Der Renderer-Prozess orchestriert Pipelines; Rust-Elemente übernehmen die
|
||||
Shader-Pässe (HLSL aus dem Plugin-Vertrag).
|
||||
- Rust-Kompilierung erfolgt im Windows-Durchlauf (Container ohne cargo).
|
||||
|
||||
## Messwerte / Nachweise
|
||||
|
||||
- Ausstehend. Gate-0-Messungen bestätigen das Elementpfad-Budget oder lösen
|
||||
eine Revision (eigenständige D3D11-Bridge) aus – ohne API-Änderung (§12.6).
|
||||
|
||||
## Freigabe
|
||||
|
||||
Vorläufig gemäß ADR-0008; endgültig nach Windows-Messung.
|
||||
@@ -0,0 +1,33 @@
|
||||
# ADR-0005: Packaging – Nuitka Onefolder (vorläufig)
|
||||
|
||||
- **Status:** Vorläufig angenommen (Vergleich im Windows-Durchlauf)
|
||||
- **Datum:** 2026-09-11
|
||||
- **Phase:** ursprünglich Phase 0; wegen ADR-0008 vorgezogen
|
||||
- **Bauplan:** §7.1, §30.2
|
||||
|
||||
## Entscheidung
|
||||
|
||||
**Nuitka Standalone/Onefolder** als Packaging-Basis; **PyInstaller Onefolder**
|
||||
als dokumentierter Fallback, falls Nuitka die GStreamer-DLL-Bündelung nicht
|
||||
sauber abbildet. Onefile bleibt wie geplant ausgeschlossen (§7.1).
|
||||
|
||||
## Begründung
|
||||
|
||||
- Nuitka kompiliert zu C: weniger Interpreter-Rest, bessere Reproduzierbarkeit
|
||||
per Buildskript (§30.1).
|
||||
- Die GStreamer-Bündelung ist von der Packaging-Wahl unabhängig
|
||||
(runtime/-Ordner + GST_PLUGIN_PATH, siehe build/windows/GSTREAMER.md).
|
||||
- PLAN.md verlangt den finalen Vergleich auf Windows; hier nur vorläufige Wahl.
|
||||
|
||||
## Folgen
|
||||
|
||||
- Buildskripte targetieren Nuitka; der Fallback-Pfad bleibt gepflegt.
|
||||
|
||||
## Messwerte / Nachweise
|
||||
|
||||
- Ausstehend; der erste Onefolder-Build auf sauberem Windows-Rechner
|
||||
entscheidet final (§29.6).
|
||||
|
||||
## Freigabe
|
||||
|
||||
Vorläufig gemäß ADR-0008; endgültig nach Windows-Build.
|
||||
@@ -0,0 +1,32 @@
|
||||
# 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.
|
||||
@@ -0,0 +1,53 @@
|
||||
# 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.
|
||||
@@ -0,0 +1,50 @@
|
||||
# ADR-0009: Node-Discovery – mDNS/DNS-SD mit manueller Fallback-Liste
|
||||
|
||||
- **Status:** Angenommen
|
||||
- **Datum:** 2026-09-11
|
||||
- **Phase:** 1
|
||||
- **Bauplan:** §6.3, §27.1, §32 (ADR-Pflicht: Node-Discovery und manueller Subnetz-Fallback)
|
||||
|
||||
## Entscheidung
|
||||
|
||||
1. Discovery-Protokoll: mDNS/DNS-SD, Service-Typ `_hmsmedia._tcp.local.`
|
||||
(§6.3).
|
||||
2. TXT-Record enthält ausschließlich kleine, nicht vertrauliche Daten:
|
||||
`proto` (Protokollversion), `node` (Node-ID), `roles` (Rollen, kommasepariert),
|
||||
`port` (API-Port), `caps` (Capability-Digest, kurzer Hash).
|
||||
Keine Tokens, keine Secrets (§27.1).
|
||||
3. mDNS ist **keine Vertrauensentscheidung**: gefundene Nodes sind zunächst
|
||||
`discovered`, steuerbar erst nach Paarung (ADR-0010).
|
||||
4. Für Umgebungen ohne Multicast (VLAN, geroutete Netze, blockiertes mDNS)
|
||||
existiert eine **persistente manuelle Node-Liste** (Host/IP + Port) als
|
||||
gleichwertiger Fallback (§6.3).
|
||||
5. Bibliothek: `zeroconf` (Standard-Python-mDNS) für den Betrieb auf
|
||||
Zielsystemen. Kein Eigenbau des Multicast-Stacks; Alternativen (python-avahi,
|
||||
Eigenbau) verworfen: plattformneutral unzureichend bzw. unnötiges Risiko
|
||||
(§33). Im Entwicklungscontainer werden nur Modell und Registry getestet
|
||||
(kein Multicast nötig); der Echtnetz-Test gehört zu Gate 1 (§29.2).
|
||||
|
||||
## Alternativen
|
||||
|
||||
- Avahi via D-Bus: Linux-only, ungeeignet für Windows-first.
|
||||
- Eigener Multicast-Code: hoher Aufwand, kein messbarer Nutzen.
|
||||
- Nur manuelle Liste: widerspricht §6.3 (Discovery ist Fundament).
|
||||
|
||||
## Folgen
|
||||
|
||||
- `hms_cluster.discovery` definiert ServiceInfo (Instanzname, TXT-Kodierung)
|
||||
und Registry-Kategorien: `discovered`, `paired`, `unknown`, `incompatible`,
|
||||
`offline` (§6.3: UI führt Gruppen getrennt auf).
|
||||
- Doppelte Node-IDs werden als Fehler blockiert, nicht still gemischt (§6.3).
|
||||
- Inkompatible Protokollversionen erscheinen als `incompatible`.
|
||||
|
||||
## Messwerte / Nachweise
|
||||
|
||||
- Unit-Tests: TXT-Roundtrip, Registry-Kategorien, Doppel-Node-ID-Blockade,
|
||||
manuelle Liste, Protokoll-Inkompatibilität.
|
||||
- Multicast-Echtnetz-Test mit zwei Nodes: Teil von Gate 1 (§29.2), auf
|
||||
echter Hardware bzw. im LAN-Test nachzuholen.
|
||||
|
||||
## Freigabe
|
||||
|
||||
- Standardumsetzung gemäß §6.3; zeroconf-Addition als ADR dokumentiert (§33).
|
||||
@@ -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.
|
||||
@@ -0,0 +1,28 @@
|
||||
# Architecture Decision Records
|
||||
|
||||
Vorlage: `_template.md`. Nummerierung fortlaufend. Abweichungen vom Bauplan nur
|
||||
mit ADR und Freigabe (PLAN.md §1).
|
||||
|
||||
## Angenommen
|
||||
|
||||
- ADR-0001: Python-Version-Pin 3.13
|
||||
- ADR-0002: GStreamer-Pin 1.28.6 (Windows)
|
||||
- ADR-0003: IPC – lokales TCP + length-prefixed MessagePack v1
|
||||
- ADR-0008: Build-first-Strategie – verzögerte Hardware-Validierung
|
||||
(Auftraggeber-Freigabe 2026-09-11)
|
||||
- ADR-0009: Node-Discovery – mDNS/DNS-SD mit manueller Fallback-Liste
|
||||
- ADR-0010: Node-Paarung – PIN/Fingerprint, Token-Scopes, Widerruf
|
||||
|
||||
## Vorläufig angenommen (Bestätigung im Windows-Durchlauf, ADR-0008)
|
||||
|
||||
- ADR-0004: Nativer Renderkern – Rust auf dem GStreamer-D3D11-Elementpfad
|
||||
- ADR-0005: Packaging – Nuitka Onefolder (Fallback PyInstaller)
|
||||
|
||||
## Offen
|
||||
|
||||
- ADR-0006: Frontend – React vs. Svelte (Entscheidung zu Beginn Phase 5)
|
||||
- ADR-0007: Typprüfung – mypy vs. pyright
|
||||
- weitere gemäß Bauplan §32 (Persistenz → erledigt in Phase 1 ohne eigene
|
||||
ADR-Nummer, da §24-Vorgaben 1:1 umgesetzt; Preview, Show-Codec, Ownership,
|
||||
Display-Abstraktion, Adaptive-Quality-Policy, Clusterprotokoll-Transport,
|
||||
TLS-Details, Clock-Sync, UI-Design-Tokens)
|
||||
@@ -0,0 +1,30 @@
|
||||
# ADR-NNNN: <Titel>
|
||||
|
||||
- **Status:** Vorgeschlagen | Angenommen | Ersetzt (durch ADR-xxxx) | Verworfen
|
||||
- **Datum:** YYYY-MM-DD
|
||||
- **Phase:** (z. B. Phase 0)
|
||||
- **Betroffene Bauplan-Abschnitte:** (z. B. §7.1, §31 Phase 0)
|
||||
|
||||
## Kontext
|
||||
|
||||
Welches Problem, welche Optionen, welche Messungen/Zahlen liegen vor?
|
||||
|
||||
## Entscheidung
|
||||
|
||||
Die gewählte Option, klar und eindeutig formuliert.
|
||||
|
||||
## Alternativen
|
||||
|
||||
Die geprüften Alternativen und warum sie verworfen wurden.
|
||||
|
||||
## Folgen
|
||||
|
||||
Positiv, negativ, Risiken, Migrationspfad, Testfolgen.
|
||||
|
||||
## Messwerte / Nachweise
|
||||
|
||||
Verweis auf TEST_REPORT.md oder Rohdaten, die die Entscheidung stützen.
|
||||
|
||||
## Freigabe
|
||||
|
||||
Auftraggeber: (Freigabe erforderlich gemäß PLAN.md §1)
|
||||
Reference in New Issue
Block a user