Release 0.4.0

docs/ARCHITECTURE.md

@@ -31,23 +31,23 @@ spätere API dieselben Regeln verwenden.
 - Zeitpunkte werden als ISO-8601-UTC-Text gespeichert. Dauern sind nichtnegative
   ganze Sekunden. Zeitzonendarstellung ist `Europe/Berlin`.
 
-## Geplantes Gesamtdatenmodell
+## Gesamtdatenmodell
 
-Etappe 1 materialisiert nur den für echte Vorschau- und Seed-Daten benötigten
-Kern. Folgende Grenzen sind für spätere Migrationen bereits festgelegt.
+Die ersten vier Etappen materialisieren Identität, Inhaltsverwaltung und
+Sendungsplanung. Folgende Grenzen gelten für umgesetzte und spätere Bereiche.
 
-| Bereich     | Geplante Entitäten und Beziehungen                                                                                               |
-| ----------- | -------------------------------------------------------------------------------------------------------------------------------- |
-| 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 |
-| Sendungsbau | `shows`, geordnete `show_sections`, kopierte `piece_usages`, Reservebank und Sendungsvorlagen; 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                             |
-| Freigaben   | widerrufbare, gehashte Lesetokens mit Sendung, Umfang, Passwortoption und Ablaufzeit                                             |
-| RSS         | Feedquellen, Abrufläufe und externe Einträge mit stabiler Herkunfts-ID sowie Status neu/übernommen/verworfen                     |
-| API/Audit   | technische Berechtigungen, Idempotenzschlüssel und Audit-Ereignisse mit Akteur, Aktion und Ziel                                  |
-| Betrieb     | Anwendungseinstellungen und spätere Job-Zustände, keine Geheimnisse im Klartext ohne begründete Schutzstrategie                  |
+| Bereich     | Geplante Entitäten und Beziehungen                                                                                                        |
+| ----------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
+| 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          |
+| 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                                      |
+| Freigaben   | widerrufbare, gehashte Lesetokens mit Sendung, Umfang, Passwortoption und Ablaufzeit                                                      |
+| RSS         | Feedquellen, Abrufläufe und externe Einträge mit stabiler Herkunfts-ID sowie Status neu/übernommen/verworfen                              |
+| API/Audit   | technische Berechtigungen, Idempotenzschlüssel und Audit-Ereignisse mit Akteur, Aktion und Ziel                                           |
+| Betrieb     | Anwendungseinstellungen und spätere Job-Zustände, keine Geheimnisse im Klartext ohne begründete Schutzstrategie                           |
 
 ### Historien- und Kopierregel
 
@@ -102,6 +102,9 @@ Medienänderungen verwenden ein bedingtes Update auf die erwartete Revision.
 Eine veraltete Bearbeitung liefert einen Konflikt und verändert weder Piece noch
 Zuordnungen. Archivieren merkt sich den vorherigen Arbeitsstatus für die
 Wiederherstellung. Duplikate erhalten neue IDs und unabhängige Bilddateien.
+Piece-Dauern werden in den Fundus- und Verwendungseditoren als Minuten erfasst,
+an der Servergrenze auf volle Sekunden gerundet und ausschließlich als ganze
+Sekunden persistiert.
 
 Markdown wird roh gespeichert, mit Marked serverseitig gerendert und danach mit
 sanitize-html auf eine kleine Allowlist reduziert. Bilder werden nicht über
@@ -111,6 +114,41 @@ sind zufällige IDs; Originalnamen werden nie als Pfad verwendet. `/media/[id]`
 prüft die Anmeldung und liefert private Antworten mit `no-store`, `nosniff`,
 Same-Origin-Ressourcenrichtlinie und restriktiver CSP aus.
 
+## Sendungsbau
+
+Etappe 4 bündelt alle Planungsmutationen in `src/lib/server/shows.ts`. Eine
+Sendung ist die Konflikt- und Transaktionsgrenze: Jede Änderung an Metadaten,
+Abschnitten, Verwendungen oder Reihenfolge vergleicht die erwartete Revision und
+erhöht sie atomar. Abgeschlossene Sendungen sind bereits an dieser Grenze gegen
+weitere Bearbeitung geschützt.
+
+Beim Einplanen werden Titel, Dauer, Einleitung, Recherche, Moderation,
+Überleitung und Präsentation aus dem sendefertigen Piece kopiert. Eigene Notizen
+liegen ausschließlich an der Verwendung. Die Referenz zum Original bleibt für
+Historie und Nachvollziehbarkeit erhalten, wird aber nicht live gespiegelt.
+
+Jede Sendung besitzt intern genau einen ausgeblendeten Reserveabschnitt. Dadurch
+verwenden Plan und Reserve dieselbe geprüfte Verwendungslogik, während die
+Reserve in der öffentlichen Struktur und allen Dauerberechnungen getrennt
+bleibt. Positionen werden nach jeder Transaktion kollisionsfrei normalisiert.
+Eine explizite Abschnittsdauer ersetzt die Summe der Verwendungen vollständig.
+
+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 Editorformulare bleiben progressive SvelteKit-Form-Actions, werden im
+Browser aber mit `use:enhance` gesendet. Dadurch bleibt das Dokument bei
+Planungsmutationen bestehen; nur die serverseitigen Seitendaten werden
+aktualisiert. Ladeanzeige und FLIP-Animation liegen am betroffenen Abschnitt
+oder an der betroffenen Verwendung. Eindeutige Drag-Griffe übertragen entweder
+eine Quellenkopie, einen Abschnitt oder eine Verwendung auf dieselben
+serverseitig geprüften Actions wie die alternativen Schaltflächen. Während des
+Ziehens bleibt das Original transparent an seinem Ausgangsort; eine flüchtige
+Vorschau in der Liste belegt bereits die anhand der Zeigerposition berechnete
+Zielhöhe und verdrängt dadurch die benachbarten Elemente. Persistiert wird erst
+beim Loslassen.
+
 ## Oberflächenstruktur
 
 Die Hauptnavigation umfasst Eingang, Fundus, Sendungen, Archiv und Verwaltung.
@@ -123,9 +161,9 @@ Desktopfenster ohne horizontalen Überlauf bedienbar bleiben.
 Der Live-Modus ist eine eigene, fokussierte Ansicht; die spätere
 Präsentationsausgabe erhält eine separate, strikt reduzierte Datenansicht.
 
-Etappe 1 zeigt Fundus, Sendungsbau und Live-Modus als sichtbare
-`Gestaltungsvorschau`. Die Daten kommen bereits aus SQLite, mutierende
-Fachabläufe werden jedoch nicht vorgetäuscht.
+Fundus und Sendungsbau sind produktive Arbeitsansichten. Der Live-Modus bleibt
+bis Etappe 5 eine sichtbare Gestaltungsvorschau, kann aber bereits gezielt die
+gewählte Sendung und deren kopierte Texte lesen.
 
 ## Sicherheitsgrenzen ab den Folgeetappen