Release 0.4.0

2026-10-21 23:52:05 +02:00
1 parent 7590be66a5
commit 4042fe6a64
@@ -91,3 +91,32 @@
  ungewollten horizontalen Überlauf
 - Mobile Darkmode-Aufnahme des Piece-Editors visuell kontrolliert
 - `bash -n start.sh` und `git diff --check`: erfolgreich
+
+## Etappe 4
+
+| Kriterium                                 | Nachweis                                                                                    | Stand                 |
+| ----------------------------------------- | ------------------------------------------------------------------------------------------- | --------------------- |
+| Spieleabend und mehrere JC-/Spieleblöcke  | persistierte Spieleabend-Vorlage, Seed-Sendung und Browserrundlauf mit Standardablauf       | erfüllt am 21.10.2026 |
+| Reihenfolge und Texte bleiben nach Reload | Verhaltenstests sowie Browsertest für Tastatur- und Drag-and-drop-Sortierung                | erfüllt am 21.10.2026 |
+| Original bleibt unverändert               | Service- und Browsertest planen dasselbe Piece mehrfach mit eigenen Titeln, Notizen, Dauern | erfüllt am 21.10.2026 |
+| Keine doppelte Dauer; Reserve zählt nicht | explizite und summierte Abschnitte sowie Reserve in Verhaltenstest und Browser geprüft      | erfüllt am 21.10.2026 |
+| Entfernen betrifft nur Einplanung         | Verhaltenstest löscht Verwendung und Abschnittskopie, nicht das Original                    | erfüllt am 21.10.2026 |
+| Sendungsänderung verändert keine Vorlage  | tiefe Vorlagenkopie vor und nach Abschnittsänderung verglichen                              | erfüllt am 21.10.2026 |
+| Smartphone-Planungsablauf                 | Abschnittsanlage, Pane-Umschaltung und Überlauf bei 390 Pixeln geprüft                      | erfüllt am 21.10.2026 |
+| Gleichwertige Bedienwege                  | Drag-and-drop, Enter auf Verschiebeschaltfläche sowie klick-/touchbare Zielauswahl geprüft  | erfüllt am 21.10.2026 |
+| Lokale Planungsaktualisierung             | Quelle und Reserve per Drag-and-drop ohne Dokumentreload; lokaler Speicherzustand geprüft   | erfüllt am 21.10.2026 |
+| Sichtbare Einfügeposition                 | Abschnitt, Fundusquelle und Reserve zeigen vor dem Drop Vorschau und transparentes Original | erfüllt am 21.10.2026 |
+| Piece-Dauer in Minuten                    | Fundus- und Verwendungseditor rechnen Minuten serverseitig in ganze Sekunden um             | erfüllt am 21.10.2026 |
+| Gleichzeitige Änderungen                  | veraltete showweite Revision rollt die gesamte Mutation zurück                              | erfüllt am 21.10.2026 |
+
+## Ausgeführte Prüfungen Etappe 4
+
+- `npm run lint`: erfolgreich
+- `npm run check`: 0 Fehler und 0 Warnungen
+- `npm test`: 18 Tests in 4 Dateien erfolgreich
+- `npm run build`: erfolgreich mit `@sveltejs/adapter-node`
+- `npm run test:e2e`: 11 von 11 Browsertests erfolgreich
+- Browserprüfung bei 390, 768, 960, 1280 und 1440 Pixeln in beiden Themes ohne
+  ungewollten horizontalen Überlauf
+- Mobile Aufnahme des vollständigen Sendungsbaukastens visuell kontrolliert
+- `bash -n start.sh` und `git diff --check`: erfolgreich
@@ -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

@@ -172,3 +172,33 @@ mit sicherheitsrelevanten Headern aus. Das Adapter-Requestlimit liegt mit 6 MB
 knapp oberhalb des fachlichen Dateilimits.

 Quelle: <https://owasp.org/www-community/vulnerabilities/Unrestricted_File_Upload>
+
+## D-014: Sendung als transaktionales Aggregat
+
+Eine ganzzahlige Revision auf `shows` schützt in Etappe 4 sämtliche Metadaten,
+Abschnitte, Verwendungen und Reihenfolgen gemeinsam. Jede Mutation erhöht die
+Revision in derselben SQLite-Transaktion. Damit können voneinander abhängige
+Listenänderungen nicht teilweise gespeichert oder durch einen veralteten
+Browserstand unbemerkt überschrieben werden.
+
+Verwendungen speichern vollständige redaktionelle Text- und Dauerkopien. Die
+Original-ID bleibt Referenz, ist aber keine Live-Datenquelle. Eine interne,
+eindeutige Reservesection pro Sendung erlaubt dieselben geprüften Verschiebe-
+und Löschoperationen für Plan und Reserve; Dauerabfragen schließen sie aus.
+
+## D-015: Drag-and-drop nur als zusätzliche Bedienung
+
+Abschnitte, Verwendungen und gefilterte Quellen können über eindeutige Griffe
+gezogen werden. Dieselben Ergebnisse sind mit sichtbaren
+Hoch-/Runter-Schaltflächen und Zielauswahl erreichbar. Diese Bedienelemente
+funktionieren mit einfachem Klick, Touch und Tastatur auch ohne Drag-and-drop
+oder clientseitige Spezialgesten. Das folgt WCAG 2.2 SC 2.5.7;
+Tastaturzugang allein wäre keine ausreichende Zeigeralternative. Die
+zugehörigen Form-Actions werden progressiv verbessert: Ohne JavaScript bleiben
+normale POSTs möglich, mit JavaScript erfolgt die Aktualisierung ohne
+Dokumentreload und mit lokalem Speicherzustand.
+
+Quellen:
+
+- <https://www.w3.org/WAI/WCAG22/Understanding/dragging-movements>
+- <https://svelte.dev/docs/kit/form-actions>
@@ -2,9 +2,9 @@

 ## Aktueller Umfang

-Etappe 1 bis Etappe 3 sind abgeschlossen. Architektur, Gesamtdatenmodell,
-Anmeldung, Rollen, persistente Inhaltsbearbeitung und lokaler Betriebsweg sind
-dokumentiert. Etappe 4 wurde nicht begonnen.
+Etappe 1 bis Etappe 4 sind abgeschlossen. Architektur, Gesamtdatenmodell,
+Anmeldung, Rollen, persistente Inhaltsbearbeitung, Sendungsplanung und lokaler
+Betriebsweg sind dokumentiert. Etappe 5 wurde nicht begonnen.

 ## Umgesetzter Stand Etappe 1

@@ -37,8 +37,8 @@ umgebrochen.

 ## Noch nicht umgesetzt

-Sendungsplanung, echte Live-Steuerung, Präsentationsfenster, Archivabschluss,
-Freigaben, RSS und API. Die bestehenden Vorschauen dürfen nicht als
+Echte Live-Steuerung, Präsentationsfenster, Archivabschluss, Freigaben, RSS und
+API. Die verbleibenden Vorschauen dürfen nicht als
 Implementierung dieser späteren Funktionen verstanden werden.

 ## Umgesetzter Stand Etappe 2
@@ -56,8 +56,8 @@ Implementierung dieser späteren Funktionen verstanden werden.

 - persistente Piece-Neuanlage aus leerem Entwurf oder drei redaktionellen Vorlagen
 - Schnellaufnahme von Gedanken und HTTP-/HTTPS-Links im Eingang
- vollständiger Editor für Quellen, Dauer, Status und getrennte Einleitung,
-  Recherche, Moderation, Überleitung und Präsentation
+- vollständiger Editor für Quellen, Dauer in Minuten, Status und getrennte
+  Einleitung, Recherche, Moderation, Überleitung und Präsentation
 - serverseitig bereinigte Markdown-Vorschau
 - unabhängige Themen, Formate und Abschnittskategorien mit Barkeeper-Verwaltung
 - serverseitige Suche und Filter nach Status, Format, Thema und Abschnitt
@@ -68,6 +68,28 @@ Implementierung dieser späteren Funktionen verstanden werden.
 - private Rasterbilder mit Größen-/Signaturprüfung und geschützter Auslieferung
 - erweiterter Seed mit Eingangs-, Archiv-, Markdown- und Recherchebeispielen

+## Umgesetzter Stand Etappe 4
+
+- Sendungsübersicht mit leerem Start, Standardablauf und Spieleabend-Vorlage
+- frei benennbare, kategorisierte und sortierbare Abschnitte einschließlich
+  eigenständiger Spieleblöcke
+- Einplanung ausschließlich sendefertiger Pieces als unabhängige Text- und
+  Dauerkopien; Mehrfachverwendung desselben Originals ist möglich
+- showweite Reservebank, die nicht in Abschnitts- oder Gesamtdauer einfließt
+- explizite Abschnittsdauer ersetzt die Piece-Summe statt sie zu addieren
+- Bearbeiten, Entfernen sowie Verschieben innerhalb und zwischen Abschnitten
+- Piece-Dauern werden im Editor in Minuten eingegeben und intern weiterhin als
+  ganze Sekunden gespeichert
+- Drag-and-drop über eindeutige Griffe, auch direkt aus gefilterten Quellen,
+  mit positionsgenauer Einfügevorschau, transparentem Original und
+  gleichwertigen Klick-, Touch- und Tastaturaktionen
+- Planungsmutationen ohne Dokumentreload mit lokalem Speicherzustand und
+  animierter Neusortierung der betroffenen Elemente
+- kopierbare Twitch-Titel und Ankündigungstexte
+- showweite optimistische Revision schützt Metadaten, Reihenfolge und Inhalte
+  vor unbemerktem parallelem Überschreiben
+- realistischer Seed mit Standardablauf und eigenständigem Spieleabend
+
 ## Bekannte offene Betriebsprüfung

 Eine echte Cloudron-Installation samt Backup/Restore, Reverse-Proxy-Verhalten