Agentur: Eintraege gehoeren allen -- und Events bekommen ein eigenes Formular

Gemessen am 07.09.2026, bevor irgendetwas geaendert wurde: Von drei
Agentur-Eintraegen sah eine Creatorin genau EINEN -- den, der ihr
zugeordnet war. Ein Event fuer alle traf weder `creator_id = ich` noch
`erstellt_von = ich`; die Agentur-Seite war fuer jeden Creator leer.
Nicht kaputt, nicht fehlerhaft: leer, so wie eine Seite aussieht, auf
der noch nichts steht.

Die Pruefung dazu war gruen. Sie legte ihre Testeintraege mit
`creator_id: idLuna` an und pruefte damit einen Fall, den es im Alltag
nicht gibt.

- Bereichseinstellung `fuerAlle` + `ohneCreatorBezug`, daraus abgeleitet
  sichtbarEintrag(). BEWUSST neben sichtbar() statt darin: an derselben
  Funktion haengen Aufgaben, Dateien, Termine und Calls -- wer dort
  "1=1" einschleust, gibt nebenbei fremde Akten frei. Eine Gegenprobe
  mit einer zweiten Creatorin haelt das fest.
- Die Zuordnung bietet nur noch "Agentur" an. Der Server verwirft eine
  Zuordnung ausserdem selbst -- inklusive des frei getippten Namens, und
  zwar NACH externPruefen: davor haette der Name den Riegel wieder
  aufgemacht.
- "Event & Kampagne" heisst jetzt "Agentur-Events" und hat ein eigenes
  Formular: Von/Bis, Titel, Beschreibung, Aufgaben (Punkte und Preise),
  Regeln. Die Karte zeigt den Zustand als WORT (laeuft bis / startet /
  vorbei seit), nicht nur als Farbe.
- Drei neue Spalten -- und sie stehen auch im Tabellenneubau vom 06.09.
  Der laeuft NACH dem Spaltennachtrag und haette sie samt Inhalt
  weggeworfen, ohne Fehler und mit stimmender Zeilenzahl.
- Creator sehen weiterhin alles und tragen weiterhin nichts ein (403).
  Die Unterzeile sagt jetzt "alles, was hier steht" statt "alles, was zu
  dir gehoert" -- eine vollstaendige Liste soll sich nicht wie ein
  Ausschnitt lesen.

pruef-agentur: 61 Pruefungen (vorher 40), alle gruen. Zwei eigene
Fehler nebenbei gefunden und behoben: eine Beschriftung mit 11,2 px
(Grenze 11,5) und ein Testdatum aus UTC statt Ortszeit.
Zusaetzlich gruen: css-klassen, struktur, formulare,
barrierefrei-workspace, handy.

Co-Authored-By: Claude Opus 5 <[email protected]>

server/workspace.js

@@ -246,6 +246,28 @@ function umstellungen(d) {
     ["aufgaben", "abgebrochen_am", "TEXT"],
     ["aufgaben", "abbruch_von", "INTEGER REFERENCES personen(id) ON DELETE SET NULL"],
     ["aufgaben", "status_vorher", "TEXT"],
+
+    /* AGENTUR-EVENTS (07.09.2026).
+
+       Ein Event ist kein Notizzettel mit Ueberschrift und Text. Wer
+       mitmachen soll, muss vier Dinge finden, ohne zu fragen: bis wann
+       es laeuft, was zu tun ist, was es zu gewinnen gibt und was
+       verboten ist. Genau daran scheitern Aktionen -- nicht am Aufruf,
+       sondern an den Rueckfragen danach.
+
+       Der BEGINN ist `datum` (gibt es schon, ist NOT NULL). Neu ist
+       das Ende und die beiden Textfelder. `event_`-Vorsatz, weil es im
+       Workspace bereits eine Tabelle `aufgaben` gibt -- eine Spalte
+       `aufgaben` auf `eintraege` waere beim Lesen von Code jedes Mal
+       eine Verwechslung.
+
+       ADD COLUMN und kein Tabellenneubau: Es aendert sich kein CHECK,
+       also darf die Tabelle stehen bleiben. Der Neubau vom 06.09. war
+       noetig, weil dort der erlaubte Wertebereich von `bereich` wuchs
+       -- und er ist der Weg, bei dem man Inhalte verlieren kann. */
+    ["eintraege", "event_ende", "TEXT"],
+    ["eintraege", "event_aufgaben", "TEXT"],
+    ["eintraege", "event_regeln", "TEXT"],
   ]) {
     try {
       const vorhanden = d.prepare(`PRAGMA table_info(${tabelle})`).all().map((s) => s.name);
@@ -501,15 +523,31 @@ function umstellungen(d) {
           format        TEXT,
           saeule_id     INTEGER,
           geplant       TEXT,
-          creator_extern TEXT
+          creator_extern TEXT,
+          /* Die drei Event-Spalten MUESSEN hier mit stehen (07.09.2026).
+
+             Der Spalten-Nachtrag weiter oben laeuft frueher als dieser
+             Neubau. Auf einer Datenbank, die noch den alten CHECK hat
+             -- eine Sicherung von vor dem 06.09., in einen heutigen
+             Stand eingespielt --, waeren die drei Spalten also erst
+             angelegt und hier sofort wieder weggeworfen worden: mit
+             allem, was drinsteht, ohne Fehlermeldung, und die
+             Zeilenzahl haette weiterhin gestimmt. Genau die
+             Verlustart, vor der der Kommentar zu dieser Umstellung
+             warnt. */
+          event_ende     TEXT,
+          event_aufgaben TEXT,
+          event_regeln   TEXT
         );
         INSERT INTO eintraege_neu
           (id, bereich, art, titel, text, datum, bewertung, dringlichkeit, status,
            creator_id, erstellt, erstellt_von, geaendert,
-           hook, format, saeule_id, geplant, creator_extern)
+           hook, format, saeule_id, geplant, creator_extern,
+           event_ende, event_aufgaben, event_regeln)
           SELECT id, bereich, art, titel, text, datum, bewertung, dringlichkeit, status,
                  creator_id, erstellt, erstellt_von, geaendert,
-                 hook, format, saeule_id, geplant, creator_extern
+                 hook, format, saeule_id, geplant, creator_extern,
+                 event_ende, event_aufgaben, event_regeln
           FROM eintraege;
         DROP TABLE eintraege;
         ALTER TABLE eintraege_neu RENAME TO eintraege;