Release 0.5.1

docs/DECISIONS.md

@@ -1,6 +1,6 @@
 # Entscheidungen
 
-Stand der Quellenprüfung: 21. Oktober 2026. Verwendet wurden offizielle
+Stand der Quellenprüfung: 22. Oktober 2026. Verwendet wurden offizielle
 Dokumentationen und die npm-Registry für konkrete Paket-Metadaten.
 
 ## D-001: SvelteKit 3 und Node-Unterstützung
@@ -225,3 +225,54 @@ Ein zufälliger 256-Bit-Token steht in der URL, während SQLite nur seinen
 SHA-256-Hash speichert. Medienzugriff prüft Token, aktuelle Präsentation und
 Bildzuordnung gemeinsam. Synchronisierung erfolgt über kleines `no-store`-
 Polling statt über eine dauerhaft offene Serververbindung.
+
+## D-018: Verwendung aus bestehenden Sendungsdaten ableiten
+
+„Gesendet“ ist kein Zustand am Fundus-Piece. Die Anzeige wird ausschließlich
+aus der vorhandenen Original-ID, einer erledigten Verwendung außerhalb der
+Reservebank und dem Status `completed` ihrer Sendung abgeleitet. Dadurch können
+Einplanung, Reserve und Überspringen ein Original nicht versehentlich als
+gesendet markieren, und mehrere tatsächliche Verwendungen bleiben als Historie
+sichtbar.
+
+Eine Duplikation im Sendungsablauf kopiert den konkreten Verwendungssnapshot und
+nicht das Original-Piece. Die neue ID, der Status `open` und fehlende
+Live-Intervalle trennen sie von der bisherigen Durchführung. Der allgemeine
+Verwendungseditor darf den Live-Status nicht mehr aus Formulardaten schreiben;
+Statuswechsel bleiben der Live-Geschäftslogik vorbehalten.
+
+Eine bestehende Einplanung wird nicht automatisch mit späteren Änderungen am
+Original synchronisiert. Die ausdrücklich ausgelöste Aktion **Aus Fundus
+aktualisieren** überschreibt nur Titel, Dauer und Redaktionstexte. Eigene
+Notizen, Status und Messintervalle bleiben erhalten. Alle Zuordnungen und Filter
+verwenden ausschließlich `original_piece_id`, niemals veränderliche Titel. Im
+allgemeinen Fundus gilt „eingeplant“ global für jede nicht abgeschlossene
+Sendung; im Sendungsbau gilt es lokal für die aktuelle Sendung samt Reserve.
+
+## D-019: Lokale Linkmetadaten und streng abgeleitete Video-Embeds
+
+Sendewerk verwendet Metascraper ausschließlich serverseitig, um Titel,
+Beschreibung, Bild und Herausgeber einer ausdrücklich gewählten vorhandenen
+Quelle zu ermitteln. Die Ergebnisse werden gespeichert und nicht bei jedem
+Seitenaufruf neu geladen. Manuell korrigierte Felder haben Vorrang. Ein eigener
+HTTP(S)-Client prüft Protokoll, Port, DNS-Ergebnisse und jedes Redirectziel,
+bindet den Request an die geprüfte öffentliche Adresse und begrenzt Redirects,
+Laufzeit und Antwortgröße. Damit ist weder ein externer Vorschaudienst noch die
+Übernahme fremden HTMLs erforderlich.
+
+Player werden nur für streng erkannte YouTube- und TikTok-URLs erzeugt. Aus der
+validierten Anbieter-ID baut Sendewerk die offiziellen Embed-Adressen selbst;
+gespeichertes oder fremd geliefertes Embed-HTML wird nicht verwendet. YouTube
+nutzt die datenschutzreduzierte `youtube-nocookie.com`-Adresse und den
+`start`-Parameter. TikTok erhält eine Startposition nach `onPlayerReady` über
+die dokumentierte Player-`postMessage`-API. Autoplay bleibt ausgeschaltet, und
+ein Inhaltswechsel ersetzt das Iframe vollständig.
+
+Quellen:
+
+- <https://github.com/microlinkhq/metascraper>
+- <https://developers.google.com/youtube/player_parameters>
+- <https://developers.google.com/youtube/terms/required-minimum-functionality>
+- <https://developers.tiktok.com/doc/embed-player>
+- <https://developers.tiktok.com/doc/embed-videos>
+- <https://owasp.org/www-community/attacks/Server_Side_Request_Forgery>