Release 0.5.8

docs/ARCHITECTURE.md

@@ -41,7 +41,7 @@ und spätere Bereiche.
 | ----------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
 | Identität   | `users`, Rollen, Sessions, Einladungen, Reset-Tokens und Sperren sind umgesetzt; technische Zugänge folgen später                         |
 | Taxonomie   | getrennte `section_categories`, `formats`, `topics`; Pieces und Vorschläge über Zuordnungstabellen mehrfach verknüpft                     |
-| Inhalt      | `pieces` mit Status, Dauer, Revision, getrennten Textbereichen, Quellen und privaten Medien; Vorlagen sind definierte Startwerte          |
+| Inhalt      | `pieces` mit Status, Dauer, Revision, getrennten Textbereichen, Quellen und privaten Medien; revisionierte Vorlagen speichern Snapshots   |
 | Sendungsbau | `shows`, geordnete `show_sections`, kopierte `piece_usages`, Reservebank und Sendungsvorlagen sind umgesetzt; Original-ID bleibt Referenz |
 | Live        | expliziter Live-Stand, aktuelles Element, Status je Verwendung, tatsächliche Zeiten und getrennte Präsentationsausgabe                    |
 | Historie    | unveränderliche Abschluss-Snapshots und Verwendungshistorie; Übersprungenes zählt nicht als gesendet                                      |
@@ -102,6 +102,13 @@ Linkkarte beziehungsweise Video auswählen. Abgerufene Metadaten und Kennzeichen
 für manuell korrigierte Felder liegen am Piece; ein erneuter Abruf überschreibt
 diese Felder nicht.
 
+Piece-Vorlagen liegen als validierte JSON-Snapshots in `piece_templates`. Jeder
+Speichervorgang kopiert den vollständigen Vorlageninhalt tief und erhöht bei
+einer Aktualisierung die Revision; spätere Änderungen am Ausgangs-Piece wirken
+nicht auf die Vorlage zurück. Die leere Vorlage bleibt virtuell. Interner Titel
+und optionaler Präsentationstitel sind getrennte Felder; ohne öffentlichen Titel
+verwendet die Präsentationsprojektion den internen Titel als Fallback.
+
 Jedes Piece besitzt eine ganzzahlige Revision. Speichern, Archivieren und
 Medienänderungen verwenden ein bedingtes Update auf die erwartete Revision.
 Eine veraltete Bearbeitung liefert einen Konflikt und verändert weder Piece noch
@@ -161,6 +168,11 @@ Sendungsvorlagen und ihre Abschnitte sind eigene Tabellen. Beim Anlegen werden
 die Abschnitte mit neuen IDs kopiert; spätere Änderungen an der Sendung können
 die Vorlage deshalb nicht verändern.
 
+Die Direktanlage aus einer Sendung erzeugt Piece und Verwendung innerhalb einer
+verschachtelbaren SQLite-Transaktion. `planning_commands` speichert die
+Befehls-ID und das Ergebnis, sodass ein wiederholter Request dieselben IDs
+zurückgibt und weder ein zweites Piece noch eine zweite Einplanung erzeugt.
+
 Die Editorformulare bleiben progressive SvelteKit-Form-Actions, werden im
 Browser aber mit `use:enhance` gesendet. Der Verwendungseditor liegt in einem
 nativen Dialog, den ein beschrifteter Icon-Button öffnet. Dadurch bleibt das
@@ -191,12 +203,19 @@ Zurückgehen, Wiederaufnahme und bereits abgeschlossene Laufzeit getrennt von de
 geplanten Dauer nachvollziehbar.
 
 Die interne Route `/live` benötigt weiterhin eine aktive Sitzung und darf
-Recherche, Moderation und eigene Arbeitsdaten lesen. Die separate Ausgabe
-`/heinzlive/[token]` liegt dagegen in einem reduzierten Layout ohne Navigation
-oder Nutzerdaten. In SQLite liegt nur der SHA-256-Hash des 256-Bit-Tokens; ein
-neu erzeugter Ausgabezugang widerruft den vorherigen. Page, Polling-JSON und
-Medienroute leiten ihre Daten aus einer eigenen Positivliste ab. Bilder werden
-nur ausgeliefert, wenn sie zum aktuell ausdrücklich präsentierten Piece gehören.
+Recherche, Moderation und eigene Arbeitsdaten lesen. Die separate Ausgabe nutzt
+den stabilen Kanal `/heinzlive/default` in einem reduzierten Layout ohne
+Navigation oder Nutzerdaten. Der geheime 256-Bit-Schlüssel steht nur im
+URL-Fragment und wird per POST gegen ein `HttpOnly`-, `SameSite=Strict`-Cookie
+getauscht. SQLite speichert seinen SHA-256-Hash für die Zugangsprüfung sowie den
+rohen Schlüssel, weil die angemeldete Steuerung dieselbe stabile OBS-Adresse
+erneut ausgeben können muss. Datenbank und Sicherungen sind deshalb Teil der
+Geheimnisgrenze. Eine Rotation widerruft den bisherigen Schlüssel, normales
+erneutes Öffnen behält ihn bei.
+Page, Polling-JSON und Proxyrouten leiten ihre Daten aus einer eigenen
+Positivliste ab. Implizite Piece-Quellen und private Uploads werden nicht
+veröffentlicht; nur die ausdrücklich gewählte Link- oder Videoquelle und deren
+erlaubte Vorschau-URL können die Grenze passieren.
 Normale Auswahl, Fortschaltung oder Wiederaufnahme verändern den
 Präsentationsstand nicht. Die öffentliche Projektion liest ausschließlich den
 gespeicherten Verwendungssnapshot; spätere Änderungen am Original erscheinen