DogFatherGit/dogfather-universe
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
dogfather-universe/server/workspace-bereiche.js
T
DogFatherGitandClaude Opus 5 3e1e0810ba Agentur-Events: die Karte als Aushang, Aufgaben zum Abhaken 
Filipe, mit einem Bildschirmfoto des Oktober-Events: "ich will das viel
geiler viel perfekter. und auch wenn man die eintraegt und so soll viel
mehr perfektioniert und uebersichtlicher sein."

VORHER GEMESSEN (1280 px, eine einzige Eventkarte):

  Kartenhoehe            1196 px   -- das Fenster ist 900 px
  davon Banner            638 px   -- 53 %, ohne einen Buchstaben
  Titel steht bei        1482 px   -- zweimal scrollen bis zum Namen
  Titelgroesse          15,36 px   -- 1,4 px mehr als der Fliesstext
  Etikett               10,88 px   -- unter der eigenen Grenze (11,5)
  Datum                     3 x    -- in drei Zeilen untereinander
  Knoepfe              4 x gleich  -- "loeschen" wie "zur Aufgabe"

NACHHER, dieselbe Messung: Karte 618 px, Buehne 203 px, Titel 75 px
unter der Kartenkante und 24,8 px gross, Etikett 12 px, das Datum
einmal, "loeschen" abgesetzt.

DIE KARTE
Das Banner ist nicht mehr ein Anhang ueber dem Titel, sondern die
Buehne dahinter -- Hoehe gedeckelt, Titel darauf. Dazu die Frage, die
bei einem Wettbewerb wirklich zaehlt und bisher nirgends beantwortet
wurde: "noch 12 Tage", mit Zeitbalken. Ein Knopf "Banner ganz" holt das
vollstaendige Bild zurueck, das beim Umbau sonst verloren gegangen
waere -- bei Filipes Banner steht die Ansage IM Bild.

DIE AUFGABEN
Aus Fliesstext wird eine Liste, und jeder hakt fuer sich ab (neue
Tabelle event_punkte, Schluessel aus dem Zeilentext). Umsortieren
laesst den Haken, wo er ist; wird die Bedingung selbst umgeschrieben,
faellt er -- beides nachgemessen. Die Leitung sieht, wer wie weit ist,
eine Creatorin sieht diese Liste gar nicht erst.

DAS FORMULAR
Ein Feld je Zeile statt eines leeren Textfeldes. Im echten Event stand
".Jeden Tag Live gehen" neben ". 33k Diamanten erreichen" -- einmal mit
Leerzeichen, einmal ohne. Das ist die zwangslaeufige Folge davon, dass
die Aufzaehlungszeichen von Hand getippt werden; jetzt setzt sie das
Formular. Dazu "Laeuft 14 Tage.", eine Warnung bei verdrehtem Zeitraum
und eine Vorschau, die dieselbe Funktion benutzt wie die echte Karte.

NEBENBEI GEFUNDEN UND BEHOBEN
* Das Banner kam bei Creatorn mit 404 zurueck -- also an genau der
  Karte, die fuer sie gemacht ist. Die Regel "wer das Brett sieht,
  sieht das Bild" galt nur fuer die sieben Community-Bretter. Jetzt
  fragt der Bildweg dieselbe Regel wie das Brett (darfEintragSehen);
  die Gegenprobe zeigt, dass ein fremder Eintrag weiterhin 404 gibt.
* Zwei Stellen setzten das Formular zurueck, die kuerzere liess
  Vorschau und Zeilen-Editor stehen -- beim naechsten "Neuer Eintrag"
  standen die Aufgaben des vorigen Events noch da.
* Der Schriftgrund ragte auf dem Handy 6 px ueber die Karte (feste
  -20 px gegen 14 px Polsterung); jetzt an die Polsterung gekoppelt.

GEPRUEFT
pruef-eventkarte.mjs (neu): 77 Pruefungen, 0 Fehler -- mit Gegenproben
zu jeder Zusage und einer Kontrastmessung am Bildpunkt auf einem
weissen Banner (14,7:1; ohne den Schriftgrund 1,05:1).
pruef-agentur.mjs auf die neuen Bausteine nachgezogen, Zahl unveraendert
bei 62. pruef-eintrag-bild.mjs 24/0.

OFFEN, NICHT AUS DIESEM UMBAU: Das Brett `agentur` ist auf der
Crew-Adresse erreichbar. Zweimal gemessen, mit und ohne diese
Aenderung -- gleiches Ergebnis. Gehoert zur Trennungsregel vom
24.09.2026 und wird getrennt entschieden.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-10-03 19:02:05 +02:00

3135 lines
144 KiB
JavaScript
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
/* =====================================================================
workspace-bereiche.js — LIVE, Content, Technik, Community und Schutz.
Diese fuenf Bereiche aus Phase 2 haben im Konzept dieselbe Grundform:
Eintraege zu einem Creator, mit Art, Datum, Titel, Text und Status.
Sie unterscheiden sich nur darin, WELCHE Arten es gibt und ob eine
Bewertung oder eine Dringlichkeit dazugehoert.
Deshalb ein gemeinsamer Unterbau statt fuenf fast gleicher Module:
eine Tabelle, eine Sichtbarkeitsregel, eine Pruefung. Ein Fehler laesst
sich damit an einer Stelle beheben statt an fuenf, und ein neuer
Bereich ist ein Eintrag in BEREICHE -- kein neues Modul.
Die Feldnamen und Arten stammen woertlich aus dem Deck (Seiten 7-12).
===================================================================== */
import express from "express";
/* Fuer das Anhaengen von Bildern an einen Beitrag (24.09.2026).
`dateiErkennen` kommt aus dem Chat -- dort steht die einzige
Fassung, und an ihr haengt die Sicherheit aller Uploads im Haus. */
import { writeFileSync, mkdirSync, unlinkSync } from "node:fs";
import { join } from "node:path";
import { randomBytes, createHash } from "node:crypto";
import { dateiErkennen } from "./workspace-chat.js";
import { TREFF_START, VORSCHLAG_HINWEIS } from "./workspace-treff-start.js";
import { vorlagenFuer } from "./workspace-treff-vorlagen.js";
import { ARBEIT_START } from "./workspace-arbeit-start.js";
/* Wann ein Zettel einen Termin hat -- DIESELBE Regel, aus der auch der
Kalender seine Auswahl baut. Sie steht in einer eigenen Datei, weil
sie jetzt zwei Verwender hat: Der Kalender fragt "welche gehoeren
hinein?", die Brettkarte fragt "stehe ICH drin?". Zwei Fassungen
derselben Regel laufen auseinander, und dann behauptet die Karte
etwas, das der Kalender nicht zeigt. */
import { terminVon } from "./workspace-termin-regel.js";
/* OB EIN WEG UEBERHAUPT OFFEN STEHT -- gefragt werden die BEIDEN
Schranken, die es gibt, und zwar hier am Server statt im Browser.
Anlass (19.09.2026): Auf jeder Brettkarte mit Termin stand "Im
Kalender am 24.09." als Link. Fuer die Community fuehrt er ins
Leere -- `kalender.html` steht in der Rechtetafel auf ALLE, und
ALLE ist ausdruecklich OHNE "gast". Ein Klick landete wortlos auf
der Startseite.
Die Regel im Browser nachzubauen waere die vierte Stelle, an der
dieselbe Frage beantwortet wird (Kachel, Rechtetafel, Adressregel
-- und dann der Link). Die vierte ist immer die, die etwas
durchlaesst. */
import { darfSeite } from "./rechte.js";
/* EIN KATALOG AUS ZWEI QUELLEN (17.09.2026)
Die sieben Bretter des Treffs stehen in workspace-treff-start.js,
die elf Arbeitsbereiche in workspace-arbeit-start.js. Getrennte
Dateien, weil die Texte fuer voellig verschiedene Leser geschrieben
sind -- die einen fuer die Community, die anderen fuer das Team.
HIER WERDEN SIE EINMAL ZUSAMMENGEFUEHRT und nicht an jeder der
beiden Abfragestellen einzeln. Zwei Stellen mit "das eine ODER das
andere" waeren zwei Stellen, an denen man beim naechsten Katalog
eine vergisst -- und die vergessene faellt nicht auf, weil sie
einfach nichts anzeigt.
Ueberschneiden duerfen sich die Schluessel nicht; sollte es je
passieren, gewinnt der Treff (er ist oeffentlich, dort waere ein
falscher Text teurer). */
const STARTKATALOG = { ...ARBEIT_START, ...TREFF_START };
/* WOHIN DIE BILDER EINES BEITRAGS GEHEN (24.09.2026).
DERSELBE ORDNER WIE DIE DATEIABLAGE -- und das ist Absicht, keine
Bequemlichkeit: Die Auslieferung (/api/dateien/:id/bild) sucht dort
und kennt nur einen Pfad. Ein eigener Ordner haette eine zweite
Stelle gebraucht, die ihn kennt, und Coverbilder aus dem
Video-Einlesen liegen ohnehin schon hier.
Beide Namen stehen ueber join(DATEN_ORDNER, ...) -- genau dieses
Muster liest tools/wiederherstellung-proben.mjs aus, um zu pruefen,
ob die Sicherung sie mitnimmt. */
const BILD_ORDNER_EINTRAG = join(DATEN_ORDNER, "dateien");
const ABLAGE_ORDNER_EINTRAG = join(DATEN_ORDNER, "dateien");
import {
db, protokolliere, echteIp, sitzungLesen, DATEN_ORDNER, betreutWo, darfCreator, betreuteIds, istLeitung, istDogFather, siehtAlles, istSpicy, ohneDogFather,
externPruefen, externSql,
ohneTeamDogi, ohneAgentur, siehtModis, fuehrtTeamDogi, MODI_BEREICHE_ERLAUBT, brettHinterSeiteOffen, TEAM_DOGI_ROLLEN,
TREFF_BRETTER, TREFF_ROLLEN, AUSSEN_ROLLEN,
heuteLokal,
gehoertAufDieseAdresse,
bereicheFuer, kanaeleFuer, KANAELE,
} from "./workspace.js";
import { nachrichtSchicken } from "./workspace-chat.js";
import {
darfSchreiben, freigabeBedingung, entfernenVorbereiten, TREFF_TEAM_ROLLEN,
sofortFreigeben,
TREFF_FREIGABE_BRETTER, mitRollenname,
} from "./workspace-treff.js";
/* Wer eine Anfrage stellen darf -- dieselbe Menge, die der
Bewerbungsweg selbst prueft. Eine zweite hier waere die, die beim
naechsten Nachschaerfen auseinanderlaeuft. */
import { BEWERBUNG_ROLLEN } from "./workspace-bewerbung-rollen.js";
export const bereicheRouter = express.Router();
/* Die Bereiche und ihre Arten. Bewusst hier und nicht in der Datenbank:
Es sind Festlegungen aus dem Konzept, keine Nutzdaten. */
/** Wie lange eine Ansage am Anschlagbrett haengt -- in Stunden.
*
* Filipe am 22.09.2026: „die sachen sollen in der seite vom
* anschlagbrett immer automatisch nach 24h von da verschwinden."
*
* ALS ZAHL AN EINER STELLE, damit die Anzeige („seit gestern") und
* die Regel (was noch haengt) nicht auseinanderlaufen koennen. Sie
* geht mit der Antwort an den Browser -- eine 24 im Skript waere die
* zweite Fassung, und beim naechsten Mal stuende dort eine andere
* Zahl als hier. */
export const ANSCHLAG_STUNDEN = 24;
export const BEREICHE = {
/* =====================================================================
DIE SIEBEN BRETTER DES TREFFS (11.09.2026)
Der Raum fuer die Zuschauer. Sie laufen ueber dieselbe Maschinerie
wie Ideen-Board und Angebote -- ein Bereich, seine Arten, dieselbe
Seite. Eine eigene Bauart daneben waere eine zweite
Sichtbarkeitsregel, und genau deren Vervielfaeltigung hat am
10.09. ein Leck verursacht.
ALLE SIEBEN HABEN `fuerAlle`: Im Treff sieht jeder jeden Beitrag.
Ein Raum, in dem man nur sieht, was man selbst geschrieben hat,
waere kein Raum. Die Grenze nach aussen zieht nicht `fuerAlle`,
sondern der Riegel in sichtbarEintrag() -- die Agentur sieht kein
einziges dieser Bretter.
ALLE SIEBEN HABEN `ohneCreatorBezug`: Hier geht es um niemanden aus
der Agentur. Das Feld waere nicht nur ueberfluessig, es waere die
Einladung, versehentlich einen Creator mit einem Zuschauer zu
verknuepfen.
===================================================================== */
anschlag: {
name: "Anschlagbrett",
/* Was dasteht, wenn nichts dasteht. Ein Bereich, der
schweigt, sieht kaputt aus statt leer. */
leer: "Gerade gilt nichts Besonderes. Das ist eine gute Nachricht.",
ober: "Vom Team",
arten: {
ansage: "Ansage",
regel: "Neue Regel",
hinweis: "Hinweis",
danke: "Danke an euch",
},
bewertung: false,
dringlichkeit: false,
ohneCreatorBezug: true,
fuerAlle: true,
},
ansteht: {
name: "Was ansteht",
/* Was dasteht, wenn nichts dasteht. Ein Bereich, der
schweigt, sieht kaputt aus statt leer. */
leer: "Noch kein Termin eingetragen. Der nächste Stream steht hier, sobald er feststeht.",
ober: "Termine",
/* AUSDRUECKLICH NICHT AN DEN ECHTEN KALENDER GEKOPPELT.
Ein Termin traegt Titel, Ort und Gegenueber -- und die Regel im
Haus lautet seit dem 07.09., dass ein Kalender als Ganzes privat
ist. Eine Filterung waere eine Einstellung, die man falsch setzen
kann; ein Eintrag hier ist eine Entscheidung, die jemand trifft.
Der Preis ist, dass das Team es zweimal schreibt. Das ist der
guenstigere von beiden. */
arten: {
stream: "Stream",
event: "Event",
turnier: "Turnier",
pause: "Keine Sendung",
},
bewertung: false,
dringlichkeit: false,
ohneCreatorBezug: true,
fuerAlle: true,
},
treff: {
name: "Das Rudel",
/* Was dasteht, wenn nichts dasteht. Ein Bereich, der
schweigt, sieht kaputt aus statt leer. */
leer: "Noch hat niemand Hallo gesagt. Sei der Erste — ein Satz reicht.",
ober: "Euer Raum",
/* DIE REIHENFOLGE IST ABSICHT. Das erste Feld bestimmt, was
geschrieben wird -- wer ein Formular oeffnet, dessen erste
Auswahl "Problem" heisst, schreibt Probleme auf.
"Hallo, ich bin neu" steht vorn, weil die ersten sieben Tage
darueber entscheiden, ob jemand bleibt: Wer in dieser Zeit
erlebt, dass er hier einen Platz hat, kommt deutlich haeufiger
wieder. Jede Vorstellung bekommt eine Antwort -- das ist der
ganze Trick, und er steht in keinem Code. */
arten: {
hallo: "Hallo, ich bin neu",
frage: "Frage",
lob: "Das war gut",
problem: "Etwas stimmt nicht",
},
bewertung: false,
dringlichkeit: false,
ohneCreatorBezug: true,
fuerAlle: true,
},
wunsch: {
name: "Wunschliste",
/* Was dasteht, wenn nichts dasteht. Ein Bereich, der
schweigt, sieht kaputt aus statt leer. */
leer: "Noch kein Wunsch. Was würdest du im nächsten Stream gern sehen?",
ober: "Was ihr euch wünscht",
/* DER WEG EINES WUNSCHES (17.09.2026).
Bis heute kannte ein Eintrag zwei Zustaende: offen und erledigt.
Fuer eine Wunschliste ist das zu wenig -- und der Mangel ist
kein Schoenheitsfehler, sondern der Grund, warum solche Listen
sterben:
Eine Wunschliste ohne sichtbare Erfuellung ist ein Briefkasten
ohne Postbote. Nach dem dritten unbeantworteten Wunsch
schreibt niemand mehr.
"Diesmal nicht" gehoert ausdruecklich dazu. Ein Nein ist eine
Antwort; Schweigen ist keine. Wer sieht, dass entschieden wurde,
schreibt beim naechsten Mal wieder -- auch wenn die Entscheidung
gegen ihn ausfiel.
DIE DATENBANK KONNTE DAS SCHON. Ihre CHECK-Regel erlaubt seit
laengerem 'angenommen' und 'abgelehnt'; nur die Pruefung im
Server liess sie nicht durch. Die Tabelle war der Logik voraus. */
zustaende: {
offen: "Offen",
angenommen: "Wird gemacht",
erledigt: "Gemacht",
abgelehnt: "Diesmal nicht",
},
/* Dazu ein Datum: "Wird gemacht" allein ist ein Versprechen,
"Wird gemacht -- am 24.09." ist ein Termin. */
mitGeplant: true,
arten: {
stream: "Für den Stream",
technik: "Technik",
gemeinsam: "Für die Community",
sonstiges: "Sonstiges",
},
bewertung: false,
/* KEINE DRINGLICHKEIT VON EINEM EINZELNEN. Was wichtig ist,
entscheidet hier nicht der Schreiber, sondern wie viele
mitwollen -- "Will ich auch" kommt als naechster Schritt. Eine
Dringlichkeit daneben waere eine zweite Rangordnung, und die
beiden wuerden einander widersprechen. */
dringlichkeit: false,
ohneCreatorBezug: true,
fuerAlle: true,
},
highlight: {
name: "Highlights",
/* Was dasteht, wenn nichts dasteht. Ein Bereich, der
schweigt, sieht kaputt aus statt leer. */
leer: "Hier kommen eure Clips und Bilder hin. Der erste darf ruhig wackelig sein.",
ober: "Von euch",
arten: {
clip: "Clip",
bild: "Bild",
fanart: "Fanart",
moment: "Moment",
},
bewertung: false,
dringlichkeit: false,
ohneCreatorBezug: true,
fuerAlle: true,
},
regeln: {
name: "Regeln & Hilfe",
/* Was dasteht, wenn nichts dasteht. Ein Bereich, der
schweigt, sieht kaputt aus statt leer. */
leer: "Hier stehen die Regeln des Rudels — sobald sie eingetragen sind.",
ober: "Wie es hier läuft",
/* REGELN IN EINFACHER SPRACHE UND AN ECHTEN FAELLEN. Vage Regeln
erzeugen Grenzfaelle, und die muss dann jeder Modi einzeln
entscheiden -- das ist der Weg, auf dem ein Team uneinheitlich
wird und die Community es merkt. */
arten: {
regel: "Regel",
frage: "Häufige Frage",
hilfe: "Hilfe",
folge: "Was passiert, wenn",
},
bewertung: false,
dringlichkeit: false,
ohneCreatorBezug: true,
fuerAlle: true,
},
mitmachen: {
name: "Mitmachen",
/* Was dasteht, wenn nichts dasteht. Ein Bereich, der
schweigt, sieht kaputt aus statt leer. */
leer: "Hier steht, wie man dazugehören kann — sobald es eingetragen ist.",
ober: "Nachwuchs",
/* DIE BRUECKE ZU DEN TALENTEN. Wer sich hier meldet, ist ein
Kandidat -- und Kandidaten gehoeren in die Kategorie, die es
dafuer schon gibt, nicht in eine zweite Liste daneben.
Daneben gehoert der ehrliche Satz, dass eine Bewerbung nicht der
Hauptweg ist: Der treffsicherste Weg ist, dass jemandem aus dem
Team auffaellt, wie du dich verhaeltst. Das steht so im Brett,
weil es stimmt -- und weil es die richtige Erwartung setzt. */
arten: {
gesucht: "Wir suchen",
lust: "Ich hätte Lust",
frage: "Frage dazu",
},
bewertung: false,
dringlichkeit: false,
ohneCreatorBezug: true,
fuerAlle: true,
},
live: {
/* HEISST WIE DIE KACHEL (20.09.2026). Die Kachel sagt
„Live-Ablauf", die Seite sagte „LIVE-Analyse" -- und der
Untertext der Kachel verspricht eine Checkliste. Wer darauf
tippt, landet unter einem anderen Namen. Der Weg faengt auf
der Startseite an, also gewinnt der Name von dort. */
name: "Live-Ablauf",
/* Was dasteht, wenn nichts dasteht. Ein Bereich, der
schweigt, sieht kaputt aus statt leer -- und der Satz
sagt NICHT nur "leer", sondern was hier hingehoert. */
leer: "Noch keine Notiz zu einem Stream. Hier landet, was vorher vorbereitet, während der Sendung mitgeschrieben und danach ausgewertet wird.",
arten: { vorbereitung: "Vorbereitung", mitschrift: "Während LIVE", auswertung: "Auswertung" },
bewertung: true, // Review-Score aus dem Konzept, Seite 7
dringlichkeit: false,
},
/* Content ist der einzige Bereich mit einer STRECKE statt einer Liste:
Die Arten sind hier Stufen, die ein Video der Reihe nach durchlaeuft.
Grundlage ist der Satz aus dem Konzept ("Hook bis Upload") und die
Recherche vom 31.08.2026: Eine Redaktionsplanung ist eine Strecke,
kein Kalender -- ein Kalender voller Termine verbirgt genau die drei
Stellen, an denen es klemmt.
Fuenf Stufen, nicht drei: Zwischen "Idee" und "Veroeffentlicht" lag
vorher alles, was den Unterschied macht. Und nicht mehr als fuenf --
jede weitere Spalte ist eine, die auf dem Handy nicht mehr passt. */
content: {
/* Umbenannt am 01.09.2026: "Planung" klang nach Terminen und
Tabellen. Was hier wirklich passiert, ist das Sammeln und
Weiterentwickeln von IDEEN -- der Kalender daneben plant. */
name: "Content-Ideen",
/* Was dasteht, wenn nichts dasteht. Ein Bereich, der
schweigt, sieht kaputt aus statt leer -- und der Satz
sagt NICHT nur "leer", sondern was hier hingehoert. */
leer: "Noch keine Idee gesammelt. Fang klein an — ein Stichwort reicht, der Rest kommt beim Drehen.",
arten: {
idee: "Idee",
skript: "Hook & Skript",
gedreht: "Gedreht",
fertig: "Fertig & geplant",
veroeffentlicht: "Veröffentlicht",
},
bewertung: false,
dringlichkeit: false,
strecke: true, // hat eine Reihenfolge, nicht nur Kategorien
},
technik: {
name: "Technik",
/* Was dasteht, wenn nichts dasteht. Ein Bereich, der
schweigt, sieht kaputt aus statt leer -- und der Satz
sagt NICHT nur "leer", sondern was hier hingehoert. */
leer: "Noch kein Eintrag. Hierhin gehört, wie das Setup aufgebaut ist, was gerade klemmt und wie es beim letzten Mal gelöst wurde.",
arten: { setup: "Setup", problem: "Problem", loesung: "Lösung", anleitung: "Anleitung" },
bewertung: false,
dringlichkeit: true,
},
community: {
name: "Community",
/* Was dasteht, wenn nichts dasteht. Ein Bereich, der
schweigt, sieht kaputt aus statt leer -- und der Satz
sagt NICHT nur "leer", sondern was hier hingehoert. */
leer: "Noch nichts eingetragen. Hier steht, was in der Community läuft — Aktionen, Moderation und was beim letzten Konflikt geholfen hat.",
arten: { moderation: "Moderation", aktion: "Aktion", konflikt: "Konflikt" },
bewertung: false,
dringlichkeit: true,
},
schutz: {
name: "Schutz & Regeln",
/* Was dasteht, wenn nichts dasteht. Ein Bereich, der
schweigt, sieht kaputt aus statt leer -- und der Satz
sagt NICHT nur "leer", sondern was hier hingehoert. */
leer: "Noch kein Eintrag. Hierhin gehören die Regeln, Vorfälle und was daraus gelernt wurde — damit beim nächsten Mal niemand raten muss.",
arten: { richtlinie: "Richtlinie", vorfall: "Vorfall", eskalation: "Eskalation", gelernt: "Gelernt" },
bewertung: false,
dringlichkeit: true,
},
/* DER SECHSTE BEREICH (06.09.2026).
Kernprinzip 04 des Konzepts: "Die Agentur bleibt angebunden." Fuenf
Bereiche standen, dieser fehlte -- und damit fehlte der einzige
Ort, an dem steht, welche Kampagne laeuft, welche Schulung ansteht
und wie ein Anliegen an die Agentur ausgegangen ist. Das lief
ueber private Nachrichten: nicht auffindbar, nicht nachvollziehbar,
und beim naechsten Mal fing man wieder von vorn an.
VIER ARTEN, und die vierte ist der Punkt:
kampagne was laeuft, bis wann, unter welcher Bedingung
schulung Termine und Inhalte, verweist auf die Bibliothek
anliegen der OFFIZIELLE Weg hin -- mit Stand
zustaendig wer wofuer zustaendig ist: wir oder die Agentur
Die letzte Art ist keine Verlegenheit, sondern das, was das Konzept
ausdruecklich fordert ("Betreuung & Umsetzung ist unsere Seite,
offizielle Wege und Plattformthemen sind Agenturseite"). Solange
das nur im Kopf steht, wird bei jedem Streitfall neu verhandelt,
wer eigentlich haette handeln muessen.
Dringlichkeit: ja. Ein Anliegen an die Agentur, das drei Wochen
liegt, ist etwas anderes als eines von gestern -- und ohne Stufe
sieht man den Unterschied in einer Liste nicht.
Bewertung: nein. Hier wird nichts benotet; es ist ein
Zusammenarbeits-Bereich, kein Analysebereich. */
/* FUER ALLE, NICHT FUER EINEN (07.09.2026).
Die anderen fuenf Bereiche sind Betreuungsakten: Dort steht etwas
UEBER einen Creator, und nur er und seine Betreuung sehen es. Die
Agentur ist das Gegenteil -- ein Event, eine Schulung, eine
Zustaendigkeit gilt fuer alle gleichzeitig.
Bis heute lief sie trotzdem unter der Akten-Regel, und das hatte
eine Folge, die niemandem auffiel: Ein Event ohne Creator-Zuordnung
traf weder `creator_id = ich` noch `erstellt_von = ich` -- fuer
jeden Creator war die Agentur-Seite schlicht LEER. Nicht "kaputt",
nicht "Fehler": leer, so wie eine Seite aussieht, auf der noch
nichts steht. Gemessen am 07.09.2026: Von drei Eintraegen sah die
Creatorin genau den einen, der ihr zugeordnet war.
Zwei Schalter, weil es zwei verschiedene Fragen sind:
fuerAlle -- jeder sieht jeden Eintrag dieses Bereichs
ohneCreatorBezug -- ein Eintrag gehoert hier NIEMANDEM einzeln */
/* =====================================================================
DAS IDEEN-BOARD (10.09.2026, Kapitel 5.6 des Anforderungsdokuments)
"Sammelstelle fuer Content-, Live- und Community-Ideen mit
Priorisierung." Genau das steht hier -- und fast nichts davon
musste neu gebaut werden: `eintraege` hat Titel, Text, Status und
`dringlichkeit` (hoch/mittel/niedrig), und das IST die
Priorisierung. Eine eigene Tabelle daneben waere eine VIERTE
Sichtbarkeitsregel gewesen; genau deren Vervielfaeltigung hat heute
schon ein Leck verursacht.
`ohneCreatorBezug`: Eine Idee gehoert der Runde, nicht einer
Person. Stuende ein Name daneben, laese sich der Eintrag wie ein
Auftrag an diese Person -- und niemand faende ihn spaeter wieder,
wenn sie nicht mehr da ist.
KEIN `fuerAlle`. Das waere der naheliegende Griff gewesen (die
Agentur-Ablage darueber macht es so) und der falsche: `fuerAlle`
heisst woertlich JEDER, auch Manager, Scouts und Creator. Wer die
Sammlung sehen darf, entscheidet stattdessen dieselbe Regel wie
ueberall -- sichtbar() haengt die Modi-Bedingung an, und der Zugang
zur Seite haengt an siehtModis(). Zwei Wege, eine Antwort.
DIE ARTEN SIND DIE DREI AUS DEM DOKUMENT, dazu "Sonstiges": Eine
Idee, die in keine der drei passt, soll nicht ungeschrieben
bleiben, weil das Formular sie nicht kennt. */
/* =====================================================================
DIE RUECKMELDUNG (10.09.2026, Kapitel 5 und 6 des Pflichtenhefts)
Filipe: "Nicht nur ich soll meine Modis bewerten oder ihnen Feedback
geben koennen. Auch die Modis sollen mir Feedback geben koennen."
Und: "Es soll nicht nur dazu dienen, Leistungen zu kontrollieren. Es
soll vor allem dabei helfen, als Team besser zu werden."
EIN BEREICH FUER BEIDE KAPITEL, NICHT ZWEI. Kapitel 5 (gegenseitiges
Feedback) und Kapitel 6 (gemeinsame Reflexion) stellen dieselben
Fragen -- "Was laeuft gut? Was laeuft schlecht? Was fehlt?" --, nur
einmal an eine Person und einmal an das Team. Zwei Bretter dafuer
haetten bedeutet, dass man beim Schreiben zuerst entscheiden muss,
an WEN es geht, bevor man weiss, WAS man sagen will. Hier ist es
umgekehrt: erst die Sache, dann die Richtung (siehe nur_leitung).
DIE NEUN FRAGEN SIND SEINE, wortwoertlich aus dem Pflichtenheft
zusammengezogen. Sie stehen als "Arten" da und nicht als freies
Textfeld, weil genau das der Unterschied zwischen einer Sammlung
und einem Haufen ist: Neun Faecher kann man auswerten, tausend
Formulierungen nicht.
KEINE ANONYMITAET, und das ist eine Entscheidung, keine Luecke. In
einem Team dieser Groesse waere sie ohnehin keine -- an drei
Saetzen erkennt jeder jeden. Ein Versprechen, das nicht haelt, ist
schlimmer als keines. Was es stattdessen gibt, ist die Wahl
zwischen "fuers Team" und "nur an DogFather". */
/* =====================================================================
ENTWICKLUNG (11.09.2026)
Filipe: "wo wir aufgaben oder bewertungen ueber modis eingeben
koennen."
ES IST KEINE NOTE, UND DAS IST KEINE ZIMPERLICHKEIT, SONDERN DAS
ERGEBNIS DER RECHERCHE. Die groesste Untersuchung dazu (Schoepke-
Gonzalez u. a., New Media & Society 2024, ueber 500 befragte
Freiwillige) nennt zwei Hauptgruende, warum Moderatoren aufhoeren:
zu wenig Zeit -- und Konflikte im Team beziehungsweise schaedliches
Verhalten der Leitung. Eine Bewertungsfunktion ist damit genau das
Werkzeug, mit dem man ein Team verliert, wenn sie als Ueberwachung
gebaut ist.
Was HAELT, ist ebenso gut belegt: Anerkennung. Dank und
Rueckmeldung erhoehen die Verweildauer messbar; Rollenklarheit
senkt Burnout.
DARAUS FOLGEN DIE FUENF ARTEN, und ihre Reihenfolge ist Absicht:
Das Erste, was man sieht, ist "Das laeuft gut". Wer ein Formular
oeffnet, dessen erstes Feld "Problem" heisst, schreibt Probleme
auf.
"ZU VIEL GERADE" IST DIE WICHTIGSTE ART und die, die es sonst
nirgends gibt. Der haeufigste Grund zu gehen ist Zeitmangel, und
der zeigt sich frueh -- nur schreibt ihn niemand auf, weil es
kein Feld dafuer gibt. Jetzt gibt es eins.
DIE PERSON SIEHT DEN BEREICH NICHT. Eine halb sichtbare Akte ist
schlimmer als eine geschlossene: Niemand weiss mehr, was der
andere gerade liest. Damit Anerkennung trotzdem ankommt, laesst
sich jeder Eintrag als Nachricht an die Person schicken -- ein
ausdruecklicher Schritt, und im Eintrag steht danach, wann er
getan wurde.
===================================================================== */
entwicklung: {
name: "Entwicklung",
/* Was dasteht, wenn nichts dasteht. Ein Bereich, der
schweigt, sieht kaputt aus statt leer -- und der Satz
sagt NICHT nur "leer", sondern was hier hingehoert. */
leer: "Noch keine Beobachtung eingetragen. Hier wird festgehalten, was jemand gut kann, woran er arbeitet und was verabredet ist.",
ober: "Über die Zeit",
arten: {
staerke: "Das läuft gut",
dank: "Danke dafür",
wachsen: "Daran arbeiten wir",
last: "Zu viel gerade",
absprache: "So haben wir es vereinbart",
},
bewertung: false,
dringlichkeit: true,
dringlichkeitName: "Wie dringend",
/* Der Personenbezug ist hier der SINN des Eintrags und nicht eine
Nebenangabe -- deshalb ausdruecklich KEIN `ohneCreatorBezug`. */
einsatzFeld: true,
einsatzName: "Was daraus folgen soll",
},
/* =====================================================================
TALENTE (11.09.2026)
Filipe: "auch fuer zuschauer die vielleicht modis werden koennten
waere auch geil."
DIE VIER MERKMALE SIND NICHT AUSGEDACHT. Sie sind das, was sich in
der Literatur zu Moderatorenauswahl immer wieder findet (ModSquad,
Kitfox Games, Discord-Leitfaeden): ruhig bleiben, wenn es hitzig
wird; von selbst helfen; die Regeln UND die Leute kennen; und
regelmaessig da sein. Ausdruecklich NICHT dabei: "schreibt viel"
-- angenehm im Chat zu sein ist nachweislich etwas anderes, als
ein guter Moderator zu sein.
Und der treffsicherste Weg ueberhaupt ist der fuenfte: die
EMPFEHLUNG aus dem Team. Wer schon dabei ist, hat den Menschen im
Alltag erlebt, nicht in einem Bewerbungsformular.
DER STATUS IST DIE PROBEZEIT. `offen` heisst beobachtet,
`angenommen` heisst angesprochen -- und was daraus wird,
entscheidet sich in "Personen & Zugaenge" mit einem Zugang auf
Stufe "Probe". Eine eigene Kandidatentabelle waere ein zweiter Ort
fuer dieselbe Frage.
===================================================================== */
talente: {
name: "Talente",
/* Was dasteht, wenn nichts dasteht. Ein Bereich, der
schweigt, sieht kaputt aus statt leer -- und der Satz
sagt NICHT nur "leer", sondern was hier hingehoert. */
leer: "Noch kein Name notiert. Wem im Chat etwas auffällt — jemand, der ruhig bleibt, wenn es hitzig wird, oder der anderen hilft — trägt ihn hier ein.",
ober: "Nachwuchs",
arten: {
ruhig: "Bleibt ruhig, wenn es hitzig wird",
hilft: "Hilft anderen von selbst",
kennt: "Kennt die Regeln und die Leute",
da: "Ist regelmäßig da",
empfohlen: "Aus dem Team empfohlen",
},
bewertung: true,
bewertungName: "Wie sicher bin ich",
dringlichkeit: true,
dringlichkeitName: "Wie eilig",
ohneCreatorBezug: true,
einsatzFeld: true,
einsatzName: "Wo ich ihn oder sie gesehen habe",
},
rueckmeldung: {
name: "Rückmeldung",
/* Was dasteht, wenn nichts dasteht. Ein Bereich, der
schweigt, sieht kaputt aus statt leer -- und der Satz
sagt NICHT nur "leer", sondern was hier hingehoert. */
leer: "Noch keine Rückmeldung. Hier kann jeder sagen, was gut läuft und wo es hakt — auch über DogFather und über die Regeln.",
/* Wie beim Ideen-Board: Das hier ist keine Akte ueber jemanden,
sondern etwas, das allen gehoert. */
ober: "Gemeinsam besser werden",
arten: {
gut: "Läuft gut",
haken: "Läuft nicht gut",
behalten: "Unbedingt behalten",
dogfather: "An DogFather",
team: "Was dem Team fehlt",
regeln: "Regel ändern",
ablauf: "Besser organisieren",
idee: "Idee",
zukunft: "Wunsch für später",
},
bewertung: false,
/* Dringlichkeit ja: "Der Ton war gestern kaputt" ist etwas anderes
als "waere schoen, irgendwann". Eine Sammlung ohne Rangfolge
wird nach vier Wochen nicht mehr gelesen. */
dringlichkeit: true,
ohneCreatorBezug: true,
/* Schaltet das Feld "nur an DogFather" frei -- siehe pruefe() und
sichtbarEintrag(). Ohne dieses Merkmal wird es in jedem anderen
Bereich stillschweigend verworfen, wie Bewertung und
Dringlichkeit auch. */
vertraulich: true,
},
ideen: {
name: "Ideen-Board",
/* Was dasteht, wenn nichts dasteht. Ein Bereich, der
schweigt, sieht kaputt aus statt leer -- und der Satz
sagt NICHT nur "leer", sondern was hier hingehoert. */
leer: "Noch keine Idee gesammelt. Alles darf hier rein, auch halb gedacht — sortiert wird später.",
/* DAS WORT UEBER DEM TITEL. Ueberall sonst steht dort "Betreuung",
weil die Bereichsseiten Betreuungsakten sind -- ueber jemanden
gefuehrt, von seinen Betreuern. Eine Ideensammlung ist das
Gegenteil: Sie gehoert niemandem und wird von allen gefuellt.
Es stand fest in bereich.html und wurde nie gesetzt; aufgefallen
ist es auf dem Bildschirmfoto. Das Feld ist ab jetzt Teil der
Bereichsangaben, damit der naechste Bereich es einfach mitbringen
kann statt es zu erben. */
ober: "Sammelstelle",
arten: {
content: "Content-Idee",
live: "Live-Idee",
community: "Community-Idee",
sonstiges: "Sonstiges",
},
bewertung: false,
dringlichkeit: true,
ohneCreatorBezug: true,
},
/* =====================================================================
DIE ANGEBOTE (10.09.2026, Wunsch Filipe)
*"ich brauch auch noch kategorien wie, angebote, wo die modis
sachen planen und auch entscheiden was ich machen muss wenn das und
das erledigt wird."*
Ein Modi schlaegt etwas vor -- eine Aktion, ein Format, eine Regel
-- und schreibt dazu, was DogFather dafuer tun muesste. DogFather
oder VanVan nimmt an oder lehnt ab; bei Annahme entstehen die
Aufgaben. Entschieden wird im Eingang, an derselben Stelle
wie die uebrigen Rueckmeldungen: EIN Eingang, nicht zwei.
DIE ZWEI ZAHLEN SIND UMBENANNT, nicht neu erfunden: `bewertung`
(1-5) heisst hier NUTZEN, `dringlichkeit` heisst AUFWAND. Beide
Felder gibt es laengst; sie mit neuen Namen zu belegen ist besser,
als zwei weitere Spalten anzulegen, die dasselbe koennen. Damit
die Oberflaeche nicht "Dringlichkeit" ueber den Aufwand schreibt,
stehen die Namen hier.
KEIN `fuerAlle`, wie beim Ideen-Board: Wer die Angebote sieht,
entscheidet dieselbe Regel wie ueberall. */
angebote: {
name: "Angebote",
/* Was dasteht, wenn nichts dasteht. Ein Bereich, der
schweigt, sieht kaputt aus statt leer -- und der Satz
sagt NICHT nur "leer", sondern was hier hingehoert. */
leer: "Noch kein Vorschlag. Wer eine Aktion, ein Format oder eine Regel vorschlagen will, schreibt es hier auf.",
arten: {
aktion: "Aktion",
format: "Format",
regel: "Regel",
technik: "Technik",
sonstiges: "Sonstiges",
},
ober: "Vorschläge",
bewertung: true,
bewertungName: "Nutzen",
dringlichkeit: true,
dringlichkeitName: "Aufwand",
einsatzFeld: true,
einsatzName: "Was DogFather dafür tun müsste",
ohneCreatorBezug: true,
},
agentur: {
name: "Agentur",
/* Was dasteht, wenn nichts dasteht. Ein Bereich, der
schweigt, sieht kaputt aus statt leer -- und der Satz
sagt NICHT nur "leer", sondern was hier hingehoert. */
leer: "Noch kein Eintrag. Hier laufen Kampagnen, Schulungen und Anliegen zusammen, die zwischen Team und Agentur besprochen werden.",
arten: {
kampagne: "Agentur-Events",
schulung: "Schulung",
anliegen: "Anliegen an die Agentur",
zustaendig: "Zuständigkeit",
},
bewertung: false,
dringlichkeit: true,
fuerAlle: true,
ohneCreatorBezug: true,
},
};
/* Aus den Bereichseinstellungen abgeleitet, nicht danebengeschrieben.
Eine zweite Liste waere beim naechsten Bereich auseinandergelaufen --
und zwar still. */
const BEREICHE_FUER_ALLE = Object.entries(BEREICHE)
.filter(([, e]) => e.fuerAlle).map(([k]) => k);
const DRINGLICHKEITEN = ["hoch", "mittel", "niedrig"];
const STATUS = ["offen", "erledigt"];
/* Wie viele Beitraege in einer Stunde? Zehn ist reichlich fuer einen
Menschen und wenig fuer ein Skript. Die Zahl steht hier und nicht in
der Route, damit sie an genau einer Stelle steht -- die Pruefung
liest sie mit. */
export const BEITRAEGE_JE_STUNDE = 10;
/* Gilt die Bremse hier? Nur in den Community-Bereichen. Eine
Content-Planung ist Arbeit am eigenen Kanal; dort waere eine Bremse
eine Behinderung ohne Gegenwert. */
const treffBereich = (b) => TREFF_BRETTER.includes(b);
/* WO EIN GESPRAECH GEMEINT IST (17.09.2026), Stufe 6.
Nicht ueberall. Aus dem Plan, §9: "Keine Kommentarfunktion ueberall.
Nur dort, wo ein Gespraech gemeint ist." Ein Antwortfeld unter jedem
Aushang hiesse: Jeder Aushang muss betreut werden -- und ein
unbeantwortetes Antwortfeld ist schlimmer als keins. */
const MIT_ANTWORTEN = new Set(["treff", "wunsch"]);
const TITEL_MAX = 160;
const TEXT_MAX = 6000;
/* =====================================================================
DIE PUNKTE EINES AGENTUR-EVENTS (03.10.2026)
`event_aufgaben` und `event_regeln` sind Fliesstext, den DogFather
tippt -- eine Zeile je Punkt, meistens mit einem Aufzaehlungszeichen
davor. Dass er von Hand gesetzt wird, sieht man dem Ergebnis an: Im
echten Oktober-Event stand „·Jeden Tag Live gehen" neben
„· 33k Diamanten erreichen", einmal mit Leerzeichen, einmal ohne.
HIER WIRD DARAUS EINE LISTE. Die Oberflaeche bekommt Punkte, keinen
Absatz -- damit sie Haken daran haengen kann und die Einrueckung
nicht mehr davon abhaengt, wie jemand getippt hat.
DER SPEICHERTEXT BLEIBT UNVERAENDERT. Zerlegt wird beim LESEN, nicht
beim Schreiben: Wer das Event spaeter bearbeitet, soll genau das
wiederfinden, was er geschrieben hat. Und ein Textfeld, das beim
Speichern umformatiert wird, ist ein Textfeld, dem man nicht traut.
===================================================================== */
/* Die Zeichen, mit denen Menschen Aufzaehlungen anfangen. Sie gehoeren
nicht zum Inhalt des Punktes -- und wer heute „·" tippt und morgen
„-", meint denselben Punkt. */
const PUNKT_ZEICHEN = /^[\s]*[-–—•·*▪◦‣>+]+[\s]*/u;
/** Der Kern einer Aufgabenzeile, ohne Zierde.
* Nur fuer den Vergleich gedacht -- angezeigt wird der Originaltext. */
function punktKern(zeile) {
return String(zeile || "")
.replace(PUNKT_ZEICHEN, "")
/* Eine fuehrende Nummerierung („1.", „2)") ebenfalls weg: Wer
einen Punkt davorsetzt, verschiebt sonst alle Nummern und damit
alle Schluessel -- genau der stille Haken-Umzug, den die Tabelle
verhindern soll. */
.replace(/^\s*\d+[.)]\s*/, "")
.replace(/\s+/gu, " ")
.trim()
.toLowerCase();
}
/** Der Schluessel, unter dem ein Haken gespeichert wird.
*
* AUS DEM TEXT, NICHT AUS DER ZEILENNUMMER -- die Begruendung steht
* bei der Tabelle `event_punkte` in workspace.js. Hier nur das Wie:
* Kern bilden, davon die ersten 16 Zeichen des SHA-256. 16 Zeichen
* sind 64 Bit; bei hoechstens ein paar Dutzend Punkten je Event ist
* eine Verwechslung ausgeschlossen, und der Schluessel bleibt kurz
* genug, um in einer Adresse zu stehen. */
export function punktSchluessel(zeile) {
return createHash("sha256").update(punktKern(zeile), "utf8")
.digest("hex").slice(0, 16);
}
/** Zerlegt ein Textfeld in Punkte.
*
* LEERE ZEILEN FALLEN WEG, aber nicht die Absicht dahinter: Wer eine
* Leerzeile zwischen zwei Bloecke setzt, trennt -- und das ergibt in
* einer Liste ohnehin keinen eigenen Punkt.
*
* GLEICHE PUNKTE NUR EINMAL: Stuende „22 Live-Stunden" zweimal da,
* haetten beide denselben Schluessel. Ein Haken wuerde dann an zwei
* Stellen gleichzeitig erscheinen und die Zaehlung „2 von 3" waere
* falsch. Der zweite faellt deshalb weg -- zusammen mit der Zeile,
* denn eine doppelte Bedingung ist ohnehin ein Tippfehler. */
export function punkteAusText(text) {
const raus = [];
const gesehen = new Set();
for (const zeile of String(text || "").split(/\r?\n/)) {
const kern = punktKern(zeile);
if (!kern) continue;
const schluessel = punktSchluessel(zeile);
if (gesehen.has(schluessel)) continue;
gesehen.add(schluessel);
raus.push({
schluessel,
/* Angezeigt wird der Text OHNE das getippte Aufzaehlungszeichen:
Die Liste setzt ihr eigenes, und zwei davon nebeneinander
sehen nach einem Fehler aus. */
text: String(zeile).replace(PUNKT_ZEICHEN, "").trim(),
});
}
return raus;
}
const jetzt = () => new Date().toISOString();
function angemeldet(req, res, next) {
const person = sitzungLesen(req);
if (!person) return res.status(401).json({ fehler: "nicht_angemeldet" });
req.person = person;
next();
}
function gleicheHerkunft(req, res, next) {
const herkunft = req.get("origin");
if (!herkunft) return next();
let erlaubt;
try { erlaubt = new URL(herkunft).host === req.get("host"); } catch { erlaubt = false; }
if (!erlaubt) return res.status(403).json({ fehler: "fremde_herkunft" });
next();
}
bereicheRouter.use("/workspace/api/bereich", angemeldet);
/* =====================================================================
DAS IDEEN-BOARD GIBT ES NUR FUER DIE, DIE ES SEHEN DUERFEN
(10.09.2026)
404 und nicht 403: "Kein Zugriff" waere die Auskunft, dass es den
Bereich gibt -- und wer nach "warum darf ich das nicht" fragt, fragt
als naechstes "wer denn dann". Ein Bereich, den es fuer mich nicht
gibt, wirft keine Fragen auf. Wortgleich mit der Antwort auf einen
erfundenen Bereichsnamen (siehe `if (!BEREICHE[bereich])` weiter
unten).
ALS EIGENE HUERDE UND NICHT ALS ABFRAGE IN DEN VIER HANDLERN: Es gibt
Lesen, Anlegen, Aendern und Loeschen. Vier Abfragen sind vier
Gelegenheiten, eine zu vergessen -- und die vergessene faellt nicht
auf, weil an ihrer Stelle nichts steht. Der Pfad-Praefix greift auch
fuer die Wege mit einer Nummer dahinter.
ZWEI SCHLOESSER, ABSICHTLICH: Hier haengt der ZUGANG zur Seite,
sichtbar() haengt die Bedingung an die ZEILEN. Faellt eines weg,
haelt das andere. */
for (const geschuetzt of ["ideen", "angebote", "rueckmeldung"]) {
bereicheRouter.use(`/workspace/api/bereich/${geschuetzt}`, (req, res, next) => {
if (siehtModis(req.person)) return next();
return res.status(404).json({ fehler: "nicht_gefunden" });
});
}
/* ---------------------------------------------------------------------
ZWEI BEREICHE GEHEN NUR DOGFATHER UND DIE RECHTE HAND AN (11.09.2026)
Filipe: "wo WIR aufgaben oder bewertungen ueber modis eingeben
koennen." Wir heisst hier: die beiden.
`siehtModis` waere zu weit -- darin sind die Modis selbst enthalten,
und in "Entwicklung" steht, was ueber sie aufgeschrieben wird.
`fuehrtTeamDogi` ist die engere Menge und dieselbe, die schon den
Eingang und die Kanaele traegt.
404 UND NICHT 403: Ein Modi soll nicht erfahren, dass es diese
Bereiche gibt. Ein "das darfst du nicht" waere die Auskunft, die
genau die Frage aufwirft, die niemand stellen soll.
ZWEI SCHLOESSER WIE OBEN: Hier haengt der ZUGANG, die Sichtbarkeit
der Zeilen haengt an sichtbarEintrag(). Faellt eines weg, haelt das
andere. */
for (const nurLeitung of ["entwicklung", "talente"]) {
bereicheRouter.use(`/workspace/api/bereich/${nurLeitung}`, (req, res, next) => {
if (fuehrtTeamDogi(req.person)) return next();
return res.status(404).json({ fehler: "nicht_gefunden" });
});
}
/* ---------------------------------------------------------------------
UND UMGEKEHRT: Ein Modi kommt nur in SEINE Bereiche.
Seit dem 10.09.2026 darf er bereich.html oeffnen -- ohne diese Huerde
auch `?b=agentur`, die Ablage der Agentur, die ihn nichts angeht. Die
Kacheln bieten sie ihm nicht an; eine Regel, die nur im Formular
gilt, ist aber keine.
Welche erlaubt sind, steht nicht hier, sondern wird aus seinen
Kacheln abgeleitet (MODI_BEREICHE_ERLAUBT). Zwei Listen waeren die
Stelle, an der es auseinanderlaeuft.
404 wie ueberall: Ein Bereich, den es fuer mich nicht gibt, wirft
keine Fragen auf. */
bereicheRouter.use("/workspace/api/bereich/:bereich", (req, res, next) => {
/* Auch die Stellvertretung. Sie hat dieselben Kacheln wie ein Modi
und damit dieselben erlaubten Bereiche -- ohne diese Zeile kaeme
sie ueber die Adresszeile in die Agentur-Ablage, die sie nichts
angeht. Genau die Luecke, gegen die diese Schranke gebaut wurde,
nur eine Rolle spaeter. */
const b = String(req.params.bereich);
const nein = () => res.status(404).json({ fehler: "nicht_gefunden" });
/* EINE AUSSENROLLE KOMMT NUR IN DEN TREFF (11.09.2026).
Und zwar als ERSTER Zweig, nicht als letzter. Die Zeile darunter
hiess bis heute "wer nicht zum Team gehoert, darf weiter" -- fuer
einen Gast waere das ein Freifahrtschein durch alle achtzehn
Bereiche gewesen, obwohl die Kacheln ihm nur sieben anbieten. Eine
Regel, die nur im Formular gilt, ist keine Regel. */
if (AUSSEN_ROLLEN.has(req.person?.rolle)) {
return TREFF_BRETTER.includes(b) ? next() : nein();
}
/* UND UMGEKEHRT: Wer nicht zum Treff gehoert, kommt nicht hinein.
Das ist derselbe Riegel wie in sichtbarEintrag(), nur eine Ebene
frueher -- dort entscheidet er, welche ZEILEN jemand sieht, hier,
ob die Seite ueberhaupt antwortet. Zwei Schloesser, absichtlich:
Faellt eines weg, haelt das andere. */
if (TREFF_BRETTER.includes(b) && !TREFF_ROLLEN.has(req.person?.rolle)) return nein();
if (!TEAM_DOGI_ROLLEN.has(req.person?.rolle)) return next();
/* Bretter mit eigener Kachel: wer die Kachel hat, darf hinein. */
if (MODI_BEREICHE_ERLAUBT.has(b)) return next();
/* Bretter HINTER einer Seite (entwicklung, talente): nur fuer den,
der die Seite selbst oeffnen darf. Bis zum 19.09.2026 stand hier
eine feste Liste ohne Rollenfrage -- ein Modi kam damit an die
Notizen zu Kandidaten, obwohl talente.html fuer ihn gesperrt ist. */
if (brettHinterSeiteOffen(req.person, b)) return next();
return nein();
});
/* ---------- Die Bereiche sind fuer Creator zum LESEN da ----------------
Wunsch Filipe, 31.08.2026: "die creator sollen da nur die sehen die wir
ihnen eintragen, also dogfather manager und scout."
Vorher durfte ein Creator hier selbst Eintraege anlegen, aendern und
die eigenen wieder loeschen. Das klingt harmlos, hebelt aber den Zweck
dieser Bereiche aus: Sie sind die Betreuungsakte -- LIVE-Auswertungen,
Technikbefunde, Konfliktverlaeufe, Schutzvorfaelle. Was dort steht,
muss der Stand der Betreuung sein und nicht das, was jemand ueber sich
selbst notiert hat. Ein Creator, der eine Auswertung umschreiben oder
eine unbequeme Notiz loeschen kann, macht die Akte wertlos.
Der Creator SIEHT weiterhin alles, was zu ihm gehoert -- vollstaendig,
nichts wird ihm vorenthalten. Er kann es nur nicht veraendern.
Bewusst 403 mit klarem Text und nicht 404: Der Bereich existiert fuer
ihn ja, er steht sogar davor. Ein 404 wuerde hier luegen. (Bei etwas,
das er gar nicht sehen darf, bleibt es weiterhin 404.)
Steht als EINE Schranke vor allen schreibenden Wegen. Die Alternative
-- in jeder der drei Stellen einzeln pruefen -- ist genau die Bauweise,
durch die am 31.08.2026 schon einmal ein Loch entstanden ist: Zwei von
drei Stellen waren abgesichert, die dritte vergessen. */
/* Ein Creator schreibt hier nicht -- MIT EINER AUSNAHME, die am
01.09.2026 dazukam: Was er SELBST angelegt hat, darf er auch
aendern und loeschen.
Die urspruengliche Regel ("hier tragen deine Betreuer ein") bleibt
damit unangetastet: Er kann weiterhin nichts an dem aendern, was
ueber ihn geschrieben wurde -- keine Bewertung, keine Notiz, keinen
Eintrag seines Managers.
Noetig wurde die Ausnahme durch die fertigen Vorlagen: Wenn ein
Creator sich eine Content-Idee uebernimmt, ist das SEINE Idee. Sie
danach nicht umbenennen zu duerfen waere absurd -- er haette einen
Eintrag erzeugt, den nur ein anderer bearbeiten kann.
Entscheidend ist erstellt_von, nicht creator_id: Ein Eintrag, den
sein Betreuer ueber ihn angelegt hat, traegt zwar seine creator_id,
gehoert ihm aber nicht. */
function nichtSchreibendFuerCreator(req, res, next) {
if (req.person?.rolle !== "creator") return next();
/* Neu anlegen bleibt gesperrt -- der Weg dafuer ist "Vorlage
uebernehmen", und der prueft eigene Regeln. */
/* NUR im Bereich content. Das ist der Bereich, in dem der Creator
selbst arbeitet -- seine Ideen, sein Material. LIVE, Technik,
Community und Schutz sind die BETREUUNGSAKTE: Dort schreiben die
Betreuer ueber ihn, und daran aendert er nichts, auch nicht an
etwas, das frueher einmal von ihm stammte. Das war am 31.08.2026
ausdruecklich so entschieden und bleibt so.
Ein erster Anlauf hatte die Ausnahme fuer ALLE Bereiche erlaubt --
die Pruefung pruef-bereiche-lesend hat das sofort gemeldet. */
const bereich = String(req.path).split("/")[4] || "";
if (bereich !== "content") {
return res.status(403).json({
fehler: "Hier tragen deine Betreuer ein. Du siehst alles, was zu dir gehört.",
});
}
const id = Number(String(req.path).split("/").pop());
if (Number.isInteger(id) && id > 0) {
try {
const e = db().prepare("SELECT erstellt_von FROM eintraege WHERE id = ?").get(id);
if (e && e.erstellt_von === req.person.id) return next();
} catch { /* faellt unten auf die Sperre zurueck */ }
}
return res.status(403).json({
fehler: "Das hat deine Betreuung eingetragen – ändern können sie es. "
+ "Was du selbst angelegt hast, kannst du bearbeiten.",
});
}
/* Express 4 -- dort ist der Platzhalter `*`, nicht `*name` wie in
Fassung 5. Mit der Fassung-5-Schreibweise haette der Pfad wortwoertlich
gepasst werden muessen und die Schranke waere NIE gegriffen: kein
Fehler, keine Warnung, nur eine Sperre, die stumm nichts tut. */
for (const weg of ["post", "patch", "delete", "put"]) {
bereicheRouter[weg]("/workspace/api/bereich/*", nichtSchreibendFuerCreator);
}
/* =====================================================================
DIE UMHUELLUNG: was einem Modi gehoert, faellt hier heraus.
Sie sitzt UM die eigentliche Regel und nicht darin -- damit sie auch
fuer Regeln gilt, die es heute noch nicht gibt. Beim ersten Anlauf
war nur der eine bekannte Fall geflickt (Spicy Media); das haette den
naechsten Rollenzweig wieder offen gelassen, und niemand haette es
gemerkt, weil an der geaenderten Stelle nichts davon steht.
DogFather und die Modis gehen unveraendert durch. Fuer alle anderen
kommt die Bedingung dazu -- auch fuer die, deren Regel ohnehin nichts
Fremdes trifft. Das kostet eine Unterabfrage und spart die Frage,
ob es diesmal wirklich niemand treffen kann.
===================================================================== */
export function sichtbar(person) {
const regel = sichtbarRoh(person);
if (!regel) return regel;
/* AUF DER ADRESSE VON TEAM DOGI NUR TEAM DOGI (10.09.2026).
Filipe: "die daten von dieser seite sollen nichts mit den daten am
hut haben von der workspace seite ... komplett von der anderen
getrennt sein."
Die Bedingung steht VOR der Regel fuer das andere Haus und nicht
danach: Beide schliessen sich aus, und wer sie hintereinander
haengt, bekommt auf der Team-Adresse eine Bedingung, die sich
selbst widerspricht -- und damit eine leere Seite, die aussieht
wie ein Fehler.
`person.haus` setzt sitzungLesen() aus der Adresse. Es aendert
keine Rechte, nur den Ausschnitt. */
if (person.haus === "crew") {
return {
wo: `(${regel.wo}) AND ${ohneAgentur("e", ["creator_id", "erstellt_von"])}`,
werte: regel.werte,
};
}
/* ==== DREI FAELLE UND NICHT ZWEI (24.09.2026, nachgebessert) =====
Hier stand bis heute `if (siehtModis(person)) return regel;` --
"wer Modi-Daten sehen darf, bekommt sie ungefiltert". Auf der
AGENTURADRESSE hiess das in der Praxis: DogFather sieht dort auch
Team Dogi. Genau das hat Filipe am 24.09.2026 abgeschafft.
DIE ERSTE FASSUNG DIESER REPARATUR WAR ZU GROB: Ich habe die Zeile
einfach gestrichen. Damit fiel auch der Fall "keine der beiden
Adressen" durch -- also jede Pruefadresse. Gemessen: 19
Fehlschlaege in drei Pruefungen, weil ein Modi seine eigenen
Aufgaben nicht mehr sah. Nicht weil etwas kaputt war, sondern weil
`ohneTeamDogi` dort ploetzlich auf ihn selbst zeigte.
ES SIND DREI LAGEN, und jede bekommt ihre Zeile:
crew -> ohne die Agentur
agentur -> ohne Team Dogi, AUCH fuer DogFather (das ist neu)
kein Haus (localhost, Pruefungen) -> die alte Rollenregel,
unveraendert. Sonst waeren alle Modi-Pruefungen des
Hauses still gruen und blind -- die Falle, vor der
crew-adresse.js dreimal warnt.
`siehtModis` BLEIBT UNVERAENDERT und wird anderswo weiter
gebraucht (Rechtefragen, z.B. in der Checkliste). "Darf ich das
sehen" und "welchen Ausschnitt sehe ich gerade" sind zwei Fragen;
wer sie in eine Funktion legt, kann spaeter nicht mehr sagen,
welche zugeschlagen hat. */
if (person.haus === "agentur") {
return {
wo: `(${regel.wo}) AND ${ohneTeamDogi("e", ["creator_id", "erstellt_von"])}`,
werte: regel.werte,
};
}
if (siehtModis(person)) return regel;
return {
wo: `(${regel.wo}) AND ${ohneTeamDogi("e", ["creator_id", "erstellt_von"])}`,
werte: regel.werte,
};
}
/* Scouts haben mit der Creator-Betreuung nichts zu tun -- sie sehen hier
nichts. Creator sehen ihren eigenen Bereich, das Management alles. */
function sichtbarRoh(person) {
/* NUR DogFather sieht alles (01.09.2026). Vorher stand hier
istLeitung() -- damit sah auch jeder Manager jeden Creator. Ein
Manager faellt jetzt in dieselbe Regel wie ein Scout: nur die
Creator, die ihm zugeteilt sind. Ausdruecklicher Wunsch:
"NUR DIE ROLLE DOGFATHER SOLL WIRKLICH ALLEINE ALLES SEHEN."
Geaendert wird ausschliesslich, wer was SIEHT. Was ein Manager
darf (freigeben, aendern, Personen verwalten), haengt weiterhin an
istLeitung und bleibt unveraendert -- sonst haette dieser eine
Wunsch stillschweigend seine halben Rechte mitgenommen. */
if (istSpicy(person)) return { wo: ohneDogFather("e"), werte: [] };
if (siehtAlles(person)) return { wo: "1=1", werte: [] };
/* "ODER ich habe ihn selbst angelegt" kam am 02.09.2026 dazu -- aus
demselben Grund wie bei den Aufgaben: Ein Eintrag ohne creator_id
(Feld auf "—" gelassen oder seit heute ein freier Name) traf keine
der Bedingungen und war fuer den, der ihn gerade geschrieben hatte,
sofort unsichtbar. Nur DogFather sah ihn noch.
Es sieht weiterhin niemand etwas Fremdes -- nur das Eigene. */
if (person.rolle === "creator") {
return { wo: "(e.creator_id = ? OR e.erstellt_von = ?)", werte: [person.id, person.id] };
}
/* Ein Scout sieht die Bereiche der Creator, die er betreut -- dazu,
was er selbst eingetragen hat. */
/* DAS MODI-TEAM TEILT SICH SEINE EINTRAEGE -- wie die Aufgaben
(Entscheidung Filipe, 09.09.2026: "sie sind untereinander ein
Team"). Ohne diesen Zweig saehe jeder Modi nur, was er selbst
geschrieben hat, und eine gemeinsame Ideensammlung waere keine. */
/* NACHTRAG 10.09.2026: Die Stellvertretung gehoert in denselben
Zweig. Ohne sie faellt sie unten durch und landet bei der
Betreuungsregel -- die fuer sie nichts findet. Ergebnis waere ein
LEERES Ideen-Board und ein leeres Angebote-Brett, und das meldet
niemand: Ein leeres Brett sieht nicht nach Fehler aus. Genau so ist
es am 01.09. dem Manager und am 09.09. dem Modi ergangen. */
if (TEAM_DOGI_ROLLEN.has(person.rolle)) {
/* UND DOGFATHER GEHOERT DAZU (17.09.2026).
Filipe: "die community und alle anderen sollen die neuen sachen
in allen kategorien auch sehen bitte. in allen die sie sehen
soll auch jede aenderung mit gehen, immer nur in denen die ihnen
erlaubt ist zu sehen."
GEMESSEN, und der Befund war groesser als der Anlass:
TEAM_DOGI_ROLLEN ist {hand, modi} -- ohne "admin". Die Bedingung
hier lautete damit woertlich "Eintraege von hand oder modi", und
DogFather fiel heraus. Folge: ALLES, was er in Live, Technik,
Community, Ideen, Angebote oder Rueckmeldung schreibt, war fuer
sein eigenes Team unsichtbar.
Bereich DogFather rechte Hand Modi
live 8 0 0
technik 8 0 0
community 8 0 0
ideen 5 0 0
Das ist nicht erst seit dem Startkatalog so -- der hat es nur
sichtbar gemacht, weil vorher ueberall Null stand und Null gleich
Null aussieht, egal aus welchem Grund.
WARUM NICHT "admin" IN TEAM_DOGI_ROLLEN AUFNEHMEN: Diese Menge
entscheidet an anderer Stelle, WELCHES HAUS jemand bewohnt
(crew statt agentur) und was Spicy Media NICHT sehen darf. Ein
Eintrag dort haette DogFather stillschweigend ins andere Haus
verschoben. Die Liste wird deshalb genau hier erweitert, wo es
um Sichtbarkeit von Eintraegen geht -- und nirgends sonst.
UND ES OEFFNET NICHTS: Welche Bereiche ein Modi ueberhaupt
aufrufen darf, entscheidet der Riegel weiter oben
(MODI_BEREICHE_ERLAUBT plus brettHinterSeiteOffen)
(content, schutz, agentur, entwicklung, talente bleiben 404).
Die Agentur-Trennung haengt an ohneAgentur() und AGENTUR_ROLLEN
-- dort steht "admin" nicht drin, an ihr aendert sich also
ebenfalls nichts. */
const liste = [...TEAM_DOGI_ROLLEN, "admin"].map((r) => `'${r}'`).join(", ");
return { wo: `(e.erstellt_von IN (SELECT id FROM personen WHERE rolle IN (${liste}))`
+ ` OR e.creator_id IN (SELECT id FROM personen WHERE rolle IN (${liste})))`, werte: [] };
}
const b = betreutWo(person, "e.creator_id");
return b
? { wo: `(e.erstellt_von = ? OR ${b.wo})`, werte: [person.id, ...b.werte] }
: { wo: "e.erstellt_von = ?", werte: [person.id] };
}
/* Dieselbe Regel, aber mit der Ausnahme fuer Bereiche, die allen
gehoeren.
BEWUSST EINE EIGENE FUNKTION, NICHT EINE AENDERUNG AN sichtbar():
sichtbar() beantwortet auch Fragen zu Aufgaben, Dateien, Terminen und
Calls (siehe die Aufrufe in workspace-aufgaben.js,
workspace-dateien.js, workspace-kalender.js, workspace-calls.js). Wer
dort "1=1" einschleust, weil er an Agentur-Eintraege dachte, oeffnet
nebenbei fremde Dateien und fremde Termine -- ein Loch, das man dem
Code nicht ansieht, weil an der geaenderten Stelle nichts davon
steht.
Nur Eintraege gehen hier durch, und nur die aus einem Bereich mit
`fuerAlle`. Der Rest faellt woertlich auf die alte Regel zurueck.
`praefix` ist da, weil die Suche dieselbe Tabelle unter demselben
Kuerzel "e" fuehrt -- geht das eines Tages auseinander, faellt es
beim Aufruf auf, nicht erst im Betrieb. */
/* VERTRAULICHE RUECKMELDUNGEN SIEHT NUR DOGFATHER -- UND DER SCHREIBER
(10.09.2026).
Wer beim Schreiben "nur an DogFather" waehlt, muss sich darauf
verlassen koennen. Deshalb steht die Bedingung HIER, in derselben
Funktion, durch die auch das Lesen einer einzelnen Zeile, das Aendern
und das Loeschen gehen -- nicht in der Listenabfrage. Eine Regel, die
nur die Liste filtert, laesst die Zeile ueber ihre Nummer trotzdem
heraus.
"NUR DOGFATHER" HEISST AUCH NICHT DIE RECHTE HAND. Sie sieht sonst
ueberall dasselbe wie er. Hier nicht, und zwar deshalb, weil das
Etikett sonst nicht stimmte: Eine Zusage mit einer Ausnahme im
Kleingedruckten ist keine. Sie kann selbst genauso schreiben -- auch
ueber ihn, und dann sieht er es nicht anders als jeder andere.
`COALESCE(..., 0)`: Alle Zeilen, die es vor heute gab, haben in
dieser Spalte NULL. Ohne den Ersatzwert waere `nur_leitung = 0`
fuer sie UNBEKANNT statt wahr -- und der gesamte alte Bestand waere
von einer Minute auf die andere unsichtbar gewesen. Ein Loch, das
niemand meldet: Ein leeres Brett sieht nicht nach Fehler aus. */
function ohneVertrauliche(regel, person, praefix) {
if (!regel || istDogFather(person)) return regel;
return {
wo: `(${regel.wo}) AND (COALESCE(${praefix}.nur_leitung, 0) = 0`
+ ` OR ${praefix}.erstellt_von = ?)`,
werte: [...regel.werte, person.id],
};
}
/* =====================================================================
DER TREFF HAT ZWEI RIEGEL, UND SIE ZEIGEN IN ENTGEGENGESETZTE
RICHTUNGEN (11.09.2026)
Filipe: "wo die community auch dan nur die sieht und die modis
rechte hand und ich also dogfather sehen die aber auch. die
community aber nur die dann."
Daraus folgen zwei Saetze, und beide muessen gelten:
1. EINE AUSSENROLLE SIEHT NUR DEN TREFF. Nicht "den Treff und was
sonst noch durchfaellt" -- nur ihn. Deshalb steht dieser Zweig
GANZ VORN und baut seine Regel selbst, statt auf der
allgemeinen aufzusetzen. Wer auf einer bestehenden Regel
aufsetzt, erbt jeden Zweig, den sie hat, auch die, die es
morgen erst gibt.
2. DIE AGENTUR SIEHT DEN TREFF NICHT. Creator, Scouts, Manager und
Spicy Media haben mit den Zuschauern dieses Streams nichts zu
tun. Ohne diesen zweiten Riegel haette `fuerAlle` sie
hereingelassen -- genau das Loch, das am 10.09. schon einmal
entstanden ist, nur andersherum.
BEIDE STEHEN HIER UND NICHT IN sichtbar(). Diese Funktion beantwortet
auch Fragen zu Aufgaben, Dateien und Terminen; ein Bereichsname hat
dort nichts zu suchen. Der Kommentar eine Bildschirmseite weiter oben
warnt woertlich davor. */
export function sichtbarEintrag(person, praefix = "e") {
/* RIEGEL 1 -- die Aussenrolle. Eine eigene, vollstaendige Regel:
genau die Bretter des Treffs, sonst nichts. */
if (AUSSEN_ROLLEN.has(person?.rolle)) {
const platz = TREFF_BRETTER.map(() => "?").join(", ");
const grund = { wo: `${praefix}.bereich IN (${platz})`, werte: [...TREFF_BRETTER] };
/* RIEGEL 1b -- WAS NOCH NICHT FREIGEGEBEN IST, GIBT ES NICHT
(11.09.2026). Termine und Highlights erscheinen der Community
erst, wenn jemand aus dem Team sie freigegeben hat.
DIE BEDINGUNG HAENGT HIER UND NICHT AM LESE-WEG, weil sie sonst
nur dort gaelte: Suche, Ausfuhr und jeder kuenftige Weg, der
sichtbarEintrag benutzt, haetten die unfreigegebenen Zeilen
weiterhin geliefert. Genau so ist am 10.09. ein Modi-Eintrag
durch die Suche gekommen, obwohl das Brett zu war. */
const frei = freigabeBedingung(person, praefix);
if (!frei) return grund;
return { wo: `(${grund.wo}) AND ${frei.wo}`, werte: [...grund.werte, ...frei.werte] };
}
const regel = sichtbarRoh2(person, praefix);
/* RIEGEL 2 -- wer nicht zum Treff gehoert, sieht seine Bretter nicht.
Auch DogFather geht hier durch; er steht in TREFF_ROLLEN und faellt
deshalb nicht heraus. */
if (!regel || TREFF_ROLLEN.has(person?.rolle)) return regel;
const platz = TREFF_BRETTER.map(() => "?").join(", ");
return {
wo: `(${regel.wo}) AND ${praefix}.bereich NOT IN (${platz})`,
werte: [...regel.werte, ...TREFF_BRETTER],
};
}
function sichtbarRoh2(person, praefix = "e") {
const regel = sichtbar(person);
if (!regel) return regel;
if (regel.wo === "1=1") return regel; // DogFather sieht ohnehin alles
if (!BEREICHE_FUER_ALLE.length) return ohneVertrauliche(regel, person, praefix);
const liste = BEREICHE_FUER_ALLE.map(() => "?").join(", ");
const mitAllen = {
wo: `(${praefix}.bereich IN (${liste}) OR ${regel.wo})`,
werte: [...BEREICHE_FUER_ALLE, ...regel.werte],
};
/* UND DANACH NOCH EINMAL ZU (10.09.2026).
sichtbar() haengt die Modi-Bedingung bereits an -- aber das ODER
hier oeffnet sie wieder: Ein Eintrag in einem `fuerAlle`-Bereich
kaeme durch, egal wem er gehoert. Heute hat kein Modi eine Kachel
dorthin; ein Aufruf an der Oberflaeche vorbei braucht sie aber
nicht. Eine Regel, die nur im Formular gilt, ist keine Regel. */
if (siehtModis(person)) return ohneVertrauliche(mitAllen, person, praefix);
return ohneVertrauliche({
wo: `(${mitAllen.wo}) AND ${ohneTeamDogi(praefix)}`,
werte: mitAllen.werte,
}, person, praefix);
}
const SPALTEN = `
e.id, e.bereich, e.art, e.titel, e.text, e.datum, e.uhrzeit, e.aus_eintrag_id,
e.quelle_url, e.quelle_kanal, e.quelle_fehlt_seit, e.bewertung,
e.dringlichkeit, e.status, e.creator_id, e.erstellt, e.erstellt_von, e.geaendert,
e.hook, e.format, e.saeule_id, e.geplant,
e.event_ende, e.event_aufgaben, e.event_regeln,
e.creator_extern,
/* Was DogFather dafuer tun muesste -- nur bei den Angeboten
gefuellt, siehe BEREICHE.angebote. */
e.einsatz,
/* 1 = nur DogFather darf das lesen. Die Spalte MUSS mitkommen, auch
wenn die Regel unten schon dafuer sorgt, dass niemand Fremdes die
Zeile bekommt: Der Schreibende soll an seiner eigenen Zeile sehen,
dass sie vertraulich ist. Ohne diese Angabe saehe sie aus wie jede
andere -- und beim naechsten Mal schriebe er offen, was er
vertraulich meinte. */
e.nur_leitung,
/* Wann der Eintrag der Person geschickt wurde -- oder NULL. Die
Oberflaeche baut daraus entweder einen Knopf oder einen Satz; ohne
diese Angabe koennte sie nur einen Knopf zeigen, der beim zweiten
Druecken eine Absage bringt. */
e.gesendet_am,
${externSql("pc.name", "e.creator_extern")} AS creator_name,
pe.name AS erstellt_name,
(SELECT name FROM content_saeulen s WHERE s.id = e.saeule_id) AS saeule_name,
(SELECT slot FROM content_saeulen s WHERE s.id = e.saeule_id) AS saeule_slot`;
/* Passt die gewaehlte Saeule zu dem Creator, um den es geht? Gibt einen
Fehlertext zurueck oder null, wenn alles stimmt. */
function saeulePasst(saeuleId, creatorId) {
if (!saeuleId) return null;
const s = db().prepare("SELECT creator_id FROM content_saeulen WHERE id = ?").get(saeuleId);
if (!s) return "Diese Säule gibt es nicht.";
if (creatorId && s.creator_id !== creatorId) return "Diese Säule gehört zu einem anderen Creator.";
return null;
}
/* =====================================================================
WAS EIN TREFF-BRETT ZUSAETZLICH MITBRINGT (11.09.2026)
Drei Angaben, die es nur dort gibt: wie viele "Will ich auch" ein
Wunsch hat, ob meine Stimme dabei ist, ob die Ansage angeheftet und
ob der Eintrag freigegeben ist.
SIE HAENGEN NICHT AN SPALTEN, sondern werden nur fuer die sieben
Bretter angehaengt. Drei Unterabfragen je Zeile sind hier
bedeutungslos (die Tabellen haben eine Handvoll Zeilen), auf den
Betreuungsbrettern waeren sie es nicht -- und vor allem waeren sie
dort eine Auskunft ueber etwas, das es in diesem Bereich gar nicht
gibt.
DER ROLLENNAME KOMMT MIT (Entscheidung Filipe, 11.09.2026: "voller
Rollenname zeigen"). Er kommt als ROLLE, der Klartext wird erst in
der Antwort gebildet -- eine Zuordnung Rolle -> Name im
ausgelieferten JavaScript waere eine Liste aller Rollen dieses
Hauses auf jedem Rechner der Community.
===================================================================== */
const TREFF_SPALTEN = `,
(SELECT COUNT(*) FROM treff_stimmen ts WHERE ts.eintrag_id = e.id) AS stimmen,
(SELECT COUNT(*) FROM treff_stimmen ts
WHERE ts.eintrag_id = e.id AND ts.person_id = ?) AS meine_stimme,
(SELECT COUNT(*) FROM treff_angeheftet ta WHERE ta.eintrag_id = e.id) AS angeheftet,
(SELECT COUNT(*) FROM treff_freigaben tf WHERE tf.eintrag_id = e.id) AS freigegeben,
pe.rolle AS erstellt_rolle`;
const VERBUND = `
FROM eintraege e
LEFT JOIN personen pc ON pc.id = e.creator_id
LEFT JOIN personen pe ON pe.id = e.erstellt_von`;
/* ---------- Lesen ------------------------------------------------------- */
bereicheRouter.get("/workspace/api/bereich/:bereich", (req, res) => {
try {
const bereich = String(req.params.bereich);
const einstellung = BEREICHE[bereich];
if (!einstellung) return res.status(404).json({ fehler: "nicht_gefunden" });
const regel = sichtbarEintrag(req.sicht || req.person);
if (!regel) return res.status(404).json({ fehler: "nicht_gefunden" });
const treffBrett = TREFF_BRETTER.includes(bereich);
/* DIE REIHENFOLGE GEHOERT ZUM BRETT (11.09.2026).
Am Anschlagbrett steht oben, was angeheftet ist -- sonst waere
das Anheften eine Zierde. Auf der Wunschliste steht oben, was die
meisten wollen; genau das ist der Sinn von "Will ich auch", und
eine Liste nach Datum haette die Abstimmung unsichtbar gemacht.
Ueberall sonst bleibt es, wie es war. */
const reihenfolge = bereich === "anschlag"
? "angeheftet DESC, e.datum DESC, e.id DESC"
: bereich === "wunsch"
/* ENTSCHIEDENES NACH UNTEN -- ABER NICHT WEG (17.09.2026).
Die Sortierung nach Stimmen gibt es seit dem 11.09. Seit es
vier Zustaende gibt, reicht sie nicht mehr: Ein gemachter
Wunsch mit vielen Stimmen stuende dauerhaft ganz oben und
verdraengte die offenen, ueber die noch zu entscheiden ist.
Loeschen waere die falsche Antwort. Gerade der ERFUELLTE
Wunsch ist der Beweis, dass sich Schreiben lohnt -- er
gehoert gesehen, nur nicht an der ersten Stelle. */
? `CASE e.status WHEN 'offen' THEN 0 WHEN 'angenommen' THEN 0 ELSE 1 END,
stimmen DESC, e.datum DESC, e.id DESC`
: `CASE e.status WHEN 'offen' THEN 0 ELSE 1 END,
CASE e.dringlichkeit WHEN 'hoch' THEN 0 WHEN 'mittel' THEN 1 ELSE 2 END,
e.datum DESC, e.id DESC`;
const wer = (req.sicht || req.person)?.id ?? 0;
const eintraege = db().prepare(`
SELECT ${SPALTEN}${treffBrett ? TREFF_SPALTEN : ""} ${VERBUND}
WHERE ${regel.wo} AND e.bereich = ?
ORDER BY ${reihenfolge}`)
.all(...(treffBrett ? [wer] : []), ...regel.werte, bereich);
/* =================================================================
DAS ANSCHLAGBRETT HAELT 24 STUNDEN (22.09.2026)
=================================================================
Filipe: „die sachen sollen in der seite vom anschlagbrett immer
automatisch nach 24h von da verschwinden. weil alles hat seine
kategorie und was nicht ist auch nicht um ewig auf der seite zu
bleiben fertig."
SEINE BEGRUENDUNG IST DIE REGEL: Ein Anschlagbrett sagt, was
GERADE gilt. Was laenger gilt, hat seinen eigenen Bereich -- die
Regeln stehen bei den Regeln, Termine bei „Was ansteht". Eine
Ansage vom letzten Dienstag, die noch haengt, ist keine Ansage
mehr, sondern Papier an der Wand.
AB WANN DIE 24 STUNDEN LAUFEN: ab `erstellt`, also ab dem
Augenblick, in dem jemand sie aufgehaengt hat. Nicht ab `datum`
-- das ist ein vom Team gesetztes Feld und kann in der Zukunft
liegen (es traegt die Termine). Eine Ansage, die morgen gilt,
soll morgen verschwinden und nicht uebermorgen.
SIE VERSCHWINDET VON DER SEITE, NICHT AUS DER WELT.
Filipe sagt „von da verschwinden" -- von DA. Geloescht wird
nichts: Wer eine Ansage geschrieben hat, soll sie
wiederfinden, und eine Ansage rueckwirkend verschwinden zu
lassen waere etwas anderes als sie abzuhaengen. Die aelteren
kommen deshalb mit, aber als `abgehaengt` gekennzeichnet; die
Seite zeigt sie zugeklappt unter einer Zeile.
WARUM DER SERVER DAS ENTSCHEIDET UND NICHT DER BROWSER: Im
Browser waere es eine zweite Fassung derselben Regel -- und die
eine wuerde irgendwann etwas anderes sagen als die andere.
Dieselbe Ueberlegung steht zehn Zeilen tiefer schon einmal, zum
Termin.
================================================================= */
if (bereich === "anschlag") {
const grenze = Date.now() - ANSCHLAG_STUNDEN * 3600 * 1000;
for (const e of eintraege) {
const auf = Date.parse(e.erstellt || "");
/* OHNE LESBARES DATUM BLEIBT SIE HAENGEN. Ein unlesbarer
Zeitstempel ist ein Grund nachzusehen, kein Grund, etwas
verschwinden zu lassen. */
e.abgehaengt = Number.isFinite(auf) ? auf < grenze : false;
}
}
/* STEHT DIESER ZETTEL IM KALENDER? (17.09.2026)
Der Kalender zeigt seit heute, was auf den Brettern steht und
einen Termin hat. Die Verbindung war aber EINSEITIG: Vom
Kalender kam man aufs Brett, vom Brett erfuhr man nichts. Am
Kartenfuss stand bloss ein Datum -- und "24.09.2026" sieht
genauso aus wie "17.09.2026", obwohl das eine ein Termin ist
und das andere der Tag, an dem jemand getippt hat.
DIE ANTWORT KOMMT VOM SERVER und wird nicht im Browser
nachgerechnet: Sonst gaebe es eine zweite Fassung der Regel, und
die Karte behauptete irgendwann etwas, das der Kalender nicht
zeigt. Eine Anzeige, die etwas Falsches sagt, ist schlimmer als
keine -- man glaubt ihr ja.
Kostet keine zusaetzliche Abfrage: Alle vier Felder stehen
ohnehin schon in SPALTEN. */
{
const heute = heuteLokal();
for (const e of eintraege) e.termin = terminVon(e, heute);
}
/* DIE BILDER AN DEN BEITRAEGEN (17.09.2026) -- in EINER Abfrage
fuer die ganze Liste. Vierzig Beitraege einzeln zu fragen waeren
vierzig Anfragen, und die Seite ruckelte sichtbar beim Aufbau;
genau dieselbe Ueberlegung steht schon bei den Rueckmeldungen.
WAS HIER MITKOMMT, IST NUR DIE NUMMER. Ob dahinter wirklich ein
Bild liegt, entscheidet erst der Bildweg selbst -- und zwar an
den ersten Bytes der Datei, nicht am behaupteten Typ. */
if (eintraege.length) {
const platz = eintraege.map(() => "?").join(", ");
const bilder = db().prepare(
`SELECT id, eintrag_id, name_original FROM dateien
WHERE eintrag_id IN (${platz}) ORDER BY id`)
.all(...eintraege.map((e) => e.id));
const je = new Map();
for (const b of bilder) {
if (!je.has(b.eintrag_id)) je.set(b.eintrag_id, []);
je.get(b.eintrag_id).push({ id: b.id, name: b.name_original });
}
for (const e of eintraege) e.bilder = je.get(e.id) || [];
/* DIE KETTE IN BEIDE RICHTUNGEN (17.09.2026). Woher kam dieser
Eintrag -- und was ist aus ihm geworden? Beides in je EINER
Abfrage; vierzig Eintraege einzeln zu fragen waeren achtzig
Anfragen.
WER DEN WUNSCH GESCHRIEBEN HAT, kommt mit: Das ist der ganze
Punkt. Ein Clip, unter dem steht "Euer Wunsch -- von Lena",
ist etwas anderes als ein Clip. */
const quellen = eintraege.map((e) => e.aus_eintrag_id).filter(Boolean);
if (quellen.length) {
const p2 = quellen.map(() => "?").join(", ");
const her = new Map(db().prepare(
`SELECT e.id, e.bereich, e.titel, p.name AS von_name
FROM eintraege e LEFT JOIN personen p ON p.id = e.erstellt_von
WHERE e.id IN (${p2})`).all(...quellen).map((z) => [z.id, z]));
for (const e of eintraege) {
if (e.aus_eintrag_id) e.aus = her.get(e.aus_eintrag_id) || null;
}
}
const p3 = eintraege.map(() => "?").join(", ");
/* `quelle_url` kommt mit, damit die Karte unterscheiden kann:
Aus dem Wunsch ist ein Highlight geworden -- hat es auch schon
ein Video? Sonst waere der Knopf „Video dazu" entweder immer da
(auch wenn es laengst eins gibt) oder nie (sobald irgendein
Highlight daraus entstanden ist). */
const draus = db().prepare(
`SELECT id, bereich, titel, aus_eintrag_id, quelle_url FROM eintraege
WHERE aus_eintrag_id IN (${p3})`).all(...eintraege.map((e) => e.id));
const jeQuelle = new Map();
for (const z of draus) {
if (!jeQuelle.has(z.aus_eintrag_id)) jeQuelle.set(z.aus_eintrag_id, []);
jeQuelle.get(z.aus_eintrag_id).push({
id: z.id, bereich: z.bereich, titel: z.titel,
/* Nur ja/nein -- die Adresse selbst gehoert nicht in eine
Liste, die nur „was wurde daraus" beantworten soll. */
hat_video: !!z.quelle_url,
});
}
for (const e of eintraege) e.wurde = jeQuelle.get(e.id) || [];
/* DIE ANTWORTEN, in EINER Abfrage fuer die ganze Liste. */
if (MIT_ANTWORTEN.has(bereich)) {
const p4 = eintraege.map(() => "?").join(", ");
const alle = db().prepare(
`SELECT a.id, a.eintrag_id, a.text, a.erstellt, a.person_id,
p.name AS von_name, p.rolle AS von_rolle
FROM eintrag_antworten a
LEFT JOIN personen p ON p.id = a.person_id
WHERE a.eintrag_id IN (${p4})
ORDER BY a.id`).all(...eintraege.map((e) => e.id));
const jeE = new Map();
for (const a of alle) {
if (!jeE.has(a.eintrag_id)) jeE.set(a.eintrag_id, []);
/* DEN ROLLENNAMEN MACHT `mitRollenname`, wie ueberall im
Treff. Eine eigene Uebersetzung hier waere eine zweite
Wahrheit ueber dieselbe Sache -- und Rollennamen sind in
diesem Haus die Sorte Angabe, bei der zwei Stellen einmal
zu viel sind. */
jeE.get(a.eintrag_id).push(mitRollenname({
id: a.id, text: a.text, erstellt: a.erstellt,
von_name: a.von_name, von_rolle: a.von_rolle,
meine: a.person_id === (req.sicht || req.person)?.id,
}));
}
for (const e of eintraege) e.antworten = jeE.get(e.id) || [];
}
/* ==== DIE PUNKTE EINES EVENTS (03.10.2026) ====================
Aus dem Fliesstext in event_aufgaben/event_regeln wird eine
Liste, und an die Aufgaben kommen die Haken der eigenen
Person. Zerlegt wird HIER und nicht im Browser: Der Schluessel
eines Punktes entscheidet, wo ein Haken landet -- eine zweite
Rechenvorschrift dafuer waere die, die beim naechsten Umbau
auslaeuft, und zwar still.
IN EINER ABFRAGE FUER DIE GANZE LISTE, wie bei den Bildern und
den Antworten darueber. Ein Event hat ein Dutzend Punkte und
ein Brett ein Dutzend Events; einzeln gefragt waere das bei
jedem Seitenaufbau ein Schwall kleiner Abfragen.
NUR DORT, WO ES EVENTS GIBT. Auf den uebrigen Brettern sind
diese Felder leer, und eine Abfrage mit leerer Liste ist eine
Abfrage ohne Zweck. */
const events = eintraege.filter((e) => e.event_aufgaben || e.event_regeln);
if (events.length) {
const ichId = (req.sicht || req.person)?.id;
const p5 = events.map(() => "?").join(", ");
/* Meine eigenen Haken ... */
const meine = new Map();
for (const z of db().prepare(
`SELECT eintrag_id, punkt FROM event_punkte
WHERE eintrag_id IN (${p5}) AND person_id = ?`)
.all(...events.map((e) => e.id), ichId)) {
if (!meine.has(z.eintrag_id)) meine.set(z.eintrag_id, new Set());
meine.get(z.eintrag_id).add(z.punkt);
}
/* ... und fuer die Leitung: wer macht mit, und wie weit?
NUR FUER DIE LEITUNG. „Wer hat was geschafft" ist eine
Auskunft ueber andere Personen; die gehoert nicht an jede
Karte, die irgendwer aufmacht. Wer nicht zur Leitung gehoert,
bekommt das Feld gar nicht erst -- nicht leer, sondern
ueberhaupt nicht: Ein leeres Feld laedt dazu ein, es spaeter
„versehentlich" zu fuellen. */
const stand = new Map();
if (istLeitung(req.person)) {
for (const z of db().prepare(
`SELECT ep.eintrag_id, ep.person_id, p.name, COUNT(*) AS n
FROM event_punkte ep
LEFT JOIN personen p ON p.id = ep.person_id
WHERE ep.eintrag_id IN (${p5})
GROUP BY ep.eintrag_id, ep.person_id
ORDER BY n DESC, p.name`)
.all(...events.map((e) => e.id))) {
if (!stand.has(z.eintrag_id)) stand.set(z.eintrag_id, []);
stand.get(z.eintrag_id).push({ id: z.person_id, name: z.name, geschafft: z.n });
}
}
for (const e of events) {
const haken = meine.get(e.id) || new Set();
e.event_punkte = punkteAusText(e.event_aufgaben)
.map((p) => ({ ...p, meiner: haken.has(p.schluessel) }));
e.event_regelpunkte = punkteAusText(e.event_regeln);
/* DIE ZAHL KOMMT MIT, statt im Browser gezaehlt zu werden --
sie steht sonst an zwei Stellen, und „2 von 3" ist genau
die Sorte Angabe, die man nicht zweimal haben will. */
e.event_geschafft = e.event_punkte.filter((p) => p.meiner).length;
if (stand.size) e.event_stand = stand.get(e.id) || [];
}
}
}
/* DASS DIES EIN BRETT DES TREFFS IST, SAGT DER SERVER (11.09.2026).
Die Oberflaeche braucht die Auskunft, um ihre Knoepfe zu bauen
("Will ich auch", anheften, freigeben, melden). Sie koennte den
Bereichsnamen gegen eine Liste im Browser halten -- dann stuenden
die Namen aller sieben Bretter in einer ausgelieferten Datei, und
es gaebe eine zweite Wahrheit darueber, welche es sind. So gibt
es weiterhin genau eine (TREFF_BRETTER), und der Browser fragt
sie, statt sie zu kennen. */
/* WEM GEHOERT EIN EINTRAG AUF DIESEM BRETT? (11.09.2026)
Filipe, mit Bildschirmfoto des Feldes "Gilt für: Agentur":
"auf dieser seite soll nichts stehen von agentur, diese seite
hier ist nur für mich meine modis und meine community."
Er hatte recht, und der Fehler war ein fest eingetragenes Wort:
In bereich.js stand woertlich "Agentur" -- richtig auf der
Agenturadresse, falsch auf jeder anderen. Ein Wort in der
Oberflaeche, das eine Tatsache ueber den Server behauptet, ist
genau die Sorte Zweitschrift, die auseinanderlaeuft.
Jetzt sagt der Server es. Er weiss beides: welches Brett es ist
und in welchem Haus die Person gerade steht. */
const gehoert = treffBrett ? "Das Rudel"
: (req.sicht || req.person)?.haus === "crew" ? "Team Dogi"
: "Agentur";
/* DER NAECHSTE SCHRITT -- vom Server, nicht vom Browser (17.09.2026).
Auf dem Brett "Mitmachen" steht, WIE man dazugehoeren kann. Was
fehlte, war die Stelle, an der man es dann auch tut: Filipe,
mit dem Bildschirmfoto dieses Bretts, "ich will dass die leute
sich da anonym bei mir melden koennen".
WARUM DER SERVER DEN KNOPF ENTSCHEIDET und nicht bereich.js:
Weil die Frage "darf diese Person?" an der Rolle haengt, und
Rollennamen stehen in keiner Datei, die jeder herunterlaedt --
bereich.js kann ohne Anmeldung aus dem offenen Netz gelesen
werden (gemessen am 17.09.). Der Browser bekommt hier einen
fertigen Satz oder gar nichts.
UND EIN KNOPF, DEN DER SERVER ABLEHNT, WAERE SCHLIMMER ALS
KEINER. Wer im Team ist, sieht ihn deshalb nicht. */
const weiter = (bereich === "mitmachen"
&& BEWERBUNG_ROLLEN.has((req.sicht || req.person)?.rolle))
? {
titel: "Du willst Modi werden?",
text: "Ein paar Fragen, ehrlich beantwortet. Es liest niemand "
+ "ausser DogFather und der rechten Hand – kein anderes "
+ "Mitglied, kein Modi.",
knopf: "Anfrage stellen",
ziel: "bewerben.html",
}
: null;
/* ==== DIE OBERZEILE KOMMT AUS DER KACHEL (20.09.2026) ==========
Ueber jedem Brett steht eine kleine Zeile, die sagt, wozu es
gehoert. Sie stand FEST im HTML: `<p class="marke">Betreuung</p>`
-- ueberschrieben nur dann, wenn das Brett ein eigenes `ober`
hat.
Gemessen: SECHS Bretter haben keines (live, content, technik,
community, schutz, agentur). Ueber dreien davon -- „Rund ums
Live" eines Modi -- stand damit dauerhaft „Betreuung". Ein Modi
betreut niemanden.
Jetzt faellt sie auf die GRUPPE der Kachel zurueck, mit der
dieser Mensch hierhergekommen ist. Das ist die ehrlichste
Auskunft, die es gibt: Genau dort hat er geklickt. Und sie ist
je Rolle richtig, ohne dass jemand eine zweite Liste pflegt --
dasselbe Brett kann fuer einen Modi in einer anderen Gruppe
stehen als fuer die rechte Hand. */
const meine = bereicheFuer(req.sicht || req.person) || [];
const passend = meine.find((k) => String(k.ziel || "").split("?")[1] === "b=" + bereich);
const ober = einstellung.ober || passend?.gruppe || null;
/* WER ENTSCHEIDET, STEHT AUF DEM BRETT SELBST (21.09.2026).
Filipe: "immer wenn es um was geht was ich machen soll ... dass
ich immer am ende entscheide ob ich was mache oder nicht. ich
kann immer annehmen oder ablehnen. über all auf der website soll
dass bei den vorschlägen erwähnt werden."
DIE VORSCHLAGSKARTEN SIEHT NUR DAS TEAM -- nachgemessen: Die
Community bekommt sie mit 404 gar nicht. Sie liest nur, was
daraus auf dem Brett landet: "Was soll DogFather im naechsten
Stream unbedingt machen?" Genau dort muss der Satz also stehen,
nicht nur ueber den Karten.
WELCHE BRETTER IHN BEKOMMEN, WIRD ABGELEITET: genau die, fuer
die es ueberhaupt Vorschlaege gibt (`STARTKATALOG`). Eine
zweite Liste "Bretter mit Hinweis" waere die naechste, die
altert -- und wer ein Brett in den Katalog aufnimmt, denkt nicht
daran, es auch dort einzutragen.
`null`, wo es keine Vorschlaege gibt: Auf einem Brett fuer
Termine oder Dateien waere der Satz sinnlos, und ein Hinweis,
der ueberall steht, wird nirgends gelesen. */
const entscheidung = STARTKATALOG[bereich] ? VORSCHLAG_HINWEIS : null;
res.json({
bereich, einstellung: { ...einstellung, ober, entscheidung },
treff: treffBrett, gehoert, weiter,
/* WIE LANGE EINE ANSAGE HAENGT -- vom Server, damit die Anzeige
(„seit gestern abgehaengt") und die Regel dieselbe Zahl
benutzen. Nur am Anschlagbrett; ueberall sonst gibt es keine
Frist, und ein Feld, das immer 24 sagt, wuerde irgendwann
irgendwo ausgewertet. */
...(bereich === "anschlag" ? { anschlag_stunden: ANSCHLAG_STUNDEN } : {}),
/* DARF DIESER MENSCH IN DEN KALENDER? Beantwortet von den zwei
Stellen, die es entscheiden -- nicht von einer dritten Regel
im Browser. Die Karte zeigt ihren Termin dann als Text statt
als Link; die Auskunft bleibt, nur der Weg ins Leere faellt
weg. */
kalender_offen: darfSeite(req.person, "/workspace/kalender.html")
&& gehoertAufDieseAdresse(req.person, "/workspace/kalender.html"),
/* DIE KANAELE KOMMEN VOM SERVER (20.09.2026).
Filipe: "die highlights sollen in 3 kategorien sein
nebeneinander, dogfather, hasidog und dogfather clips."
Der Browser hatte dafuer bisher eine eigene kleine Liste
(`KANAL_WORT` in bereich.js) -- in anderer Reihenfolge und
ohne die Handles. Eine zweite Fassung derselben Tatsache ist
die, die beim vierten Account vergessen wird; genau davor
warnt der Kommentar an KANAELE selbst. Deshalb kommt sie von
hier, samt Reihenfolge: DogFather, HasiDog, Clips.
`kanaeleFuer` und nicht `KANAELE`: Wer nicht zum Team gehoert,
hat mit den Accounts nichts zu tun und bekommt die Liste gar
nicht erst. */
kanaele: kanaeleFuer(req.person),
eintraege: treffBrett ? eintraege.map(mitRollenname) : eintraege,
});
} catch (fehler) {
console.error("[workspace] Bereich lesen:", fehler?.message);
res.status(503).json({ fehler: "nicht_verfuegbar" });
}
});
/* =====================================================================
EINEN EINTRAG AN DIE PERSON SCHICKEN (11.09.2026)
Der Entwicklungs-Bereich ist eine Aufzeichnung fuer DogFather und die
rechte Hand; die Person selbst sieht ihn nicht. Diese Route ist die
einzige Bruecke -- und sie geht nur in EINE Richtung, ausdruecklich
und einzeln.
WARUM NICHT EINFACH ALLES SICHTBAR MACHEN: Eine halb sichtbare Akte
ist schlimmer als eine geschlossene. Niemand weiss mehr, was der
andere gerade liest, und man schreibt anders -- vorsichtiger,
weniger, oder gar nicht mehr.
WARUM ES DIESE BRUECKE TROTZDEM BRAUCHT: Die Forschung zu
freiwilligen Moderatoren ist an dieser Stelle eindeutig. Was Menschen
haelt, ist Anerkennung -- Dank und Rueckmeldung erhoehen die
Verweildauer messbar. Ein "Das laeuft gut", das nur in einer Akte
steht, hat niemandem geholfen.
DER WEG IST DER CHAT und keine neue Benachrichtigungsart: Die Person
findet die Nachricht dort, wo sie alles andere auch findet, kann
antworten, und sie steht in ihrem Verlauf. Ein eigener Kanal dafuer
waere ein zweiter Ort mit einer roten Zahl.
EINMAL IST EINMAL. `gesendet_am` haelt fest, wann es geschehen ist --
die Route schickt danach nicht noch einmal. Zweimal dasselbe Lob ist
kein doppeltes Lob, sondern ein Versehen, das jeder bemerkt.
===================================================================== */
bereicheRouter.post("/workspace/api/bereich/entwicklung/:id/senden",
gleicheHerkunft, (req, res) => {
try {
if (!fuehrtTeamDogi(req.person)) return res.status(404).json({ fehler: "nicht_gefunden" });
const id = Number(req.params.id);
if (!Number.isInteger(id)) return res.status(400).json({ fehler: "ungueltig" });
const e = db().prepare(
`SELECT id, bereich, art, titel, text, einsatz, creator_id, gesendet_am
FROM eintraege WHERE id = ?`).get(id);
if (!e || e.bereich !== "entwicklung") {
return res.status(404).json({ fehler: "nicht_gefunden" });
}
if (!e.creator_id) {
return res.status(400).json({
fehler: "Dieser Eintrag gehört zu niemandem – trag zuerst ein, um wen es geht.",
});
}
if (e.gesendet_am) {
return res.status(409).json({ fehler: "Das ist schon geschickt.", am: e.gesendet_am });
}
/* DER TEXT WIRD GEBAUT UND NICHT ROH GESCHICKT. Im Bereich steht
eine Notiz ("Ruhig geblieben, als es kippte"); als Nachricht
ohne Zusammenhang liest sich das wie ein Fetzen. Die Art davor
sagt, was gemeint ist, und der Einsatz dahinter, was daraus
folgen soll -- beides steht ohnehin schon da. */
const art = BEREICHE.entwicklung.arten[e.art] || "";
const stuecke = [
art ? `${art}: ${e.titel}` : e.titel,
e.text || "",
e.einsatz ? `Was daraus folgen soll: ${e.einsatz}` : "",
].filter(Boolean);
const geschickt = nachrichtSchicken(req.person, e.creator_id, stuecke.join("\n\n"));
if (!geschickt) {
return res.status(400).json({
fehler: "Die Nachricht ging nicht raus – ist die Person noch aktiv?",
});
}
const am = jetzt();
db().prepare("UPDATE eintraege SET gesendet_am = ? WHERE id = ?").run(am, id);
protokolliere("entwicklung_geschickt", {
personId: req.person.id, rolle: req.person.rolle, ip: echteIp(req),
detail: `#${id} an #${e.creator_id}`,
});
res.json({ ok: true, am, raum_id: geschickt.raum_id });
} catch (fehler) {
console.error("[workspace] Entwicklung schicken:", fehler?.message);
res.status(503).json({ fehler: "nicht_verfuegbar" });
}
});
/* ---------- Prüfen ------------------------------------------------------- */
function pruefe(bereich, körper, { neu }) {
const einstellung = BEREICHE[bereich];
const fehler = [];
const aus = {};
if (neu || körper.titel !== undefined) {
const t = String(körper.titel ?? "").trim();
if (t.length < 2) fehler.push("Die Überschrift fehlt.");
else if (t.length > TITEL_MAX) fehler.push("Titel ist zu lang.");
else aus.titel = t;
}
if (neu || körper.art !== undefined) {
const a = String(körper.art ?? "");
if (!Object.hasOwn(einstellung.arten, a)) fehler.push("Unbekannte Art.");
else aus.art = a;
}
if (körper.text !== undefined) {
const t = String(körper.text ?? "").trim();
if (t.length > TEXT_MAX) fehler.push("Text ist zu lang.");
else aus.text = t || null;
}
if (neu || körper.datum !== undefined) {
const d = String(körper.datum ?? "").trim();
/* ORTSZEIT, NICHT UTC (01.10.2026). Hier stand
`jetzt().slice(0, 10)` -- der UTC-Tag. Zwischen 00:00 und 02:00
Ortszeit ist das der VORTAG: Ein Eintrag ohne Datum, nachts
angelegt, trug gestern. Bei „Was ansteht" landet er damit im
Abschnitt „Vorbei", und der ist von sich aus zugeklappt -- der
Eintrag ist also da und trotzdem nicht zu sehen. */
if (!d) aus.datum = heuteLokal();
else if (!/^\d{4}-\d{2}-\d{2}$/.test(d) || Number.isNaN(Date.parse(d))) {
fehler.push("Datum ist ungültig.");
} else aus.datum = d;
}
/* DIE UHRZEIT (17.09.2026) -- optional, und leer heisst ausdruecklich
"ohne Uhrzeit" und nicht "unveraendert". Sonst liesse sich eine
einmal gesetzte Zeit nie wieder entfernen, und das faellt erst auf,
wenn ein Termin verschoben wird. */
if (körper.uhrzeit !== undefined) {
const u = String(körper.uhrzeit ?? "").trim();
if (!u) aus.uhrzeit = null;
else if (!/^([01]\d|2[0-3]):[0-5]\d$/.test(u)) fehler.push("Uhrzeit ist ungültig.");
else aus.uhrzeit = u;
}
if (körper.status !== undefined) {
/* JE BEREICH, NICHT GLOBAL (17.09.2026). Die Wunschliste kennt
vier Zustaende, alle anderen zwei. Eine gemeinsame Liste haette
"Diesmal nicht" auch an einem Schutzvorfall erlaubt -- und dort
bedeutet es nichts. */
const erlaubt = einstellung.zustaende
? Object.keys(einstellung.zustaende) : STATUS;
if (!erlaubt.includes(körper.status)) fehler.push("Unbekannter Status.");
else aus.status = körper.status;
}
/* DER GEPLANTE TERMIN eines Wunsches. Bisher gab es das Feld nur in
der Content-Planung; hier traegt es dieselbe Bedeutung und darf
deshalb dasselbe Format haben. Leer heisst "noch kein Termin" und
nicht "unveraendert". */
if (einstellung.mitGeplant && körper.geplant !== undefined) {
const g = String(körper.geplant ?? "").trim();
if (!g) aus.geplant = null;
else if (!/^\d{4}-\d{2}-\d{2}$/.test(g) || Number.isNaN(Date.parse(g))) {
fehler.push("Der geplante Tag ist ungültig.");
} else aus.geplant = g;
}
/* Bewertung und Dringlichkeit gibt es nur dort, wo der Bereich sie
vorsieht -- sonst werden sie stillschweigend verworfen. */
if (einstellung.bewertung && körper.bewertung !== undefined) {
if (körper.bewertung === null || körper.bewertung === "") aus.bewertung = null;
else {
const b = Number(körper.bewertung);
if (!Number.isInteger(b) || b < 1 || b > 5) fehler.push("Bewertung muss 1 bis 5 sein.");
else aus.bewertung = b;
}
}
if (einstellung.dringlichkeit && körper.dringlichkeit !== undefined) {
if (!DRINGLICHKEITEN.includes(körper.dringlichkeit)) fehler.push("Unbekannte Dringlichkeit.");
else aus.dringlichkeit = körper.dringlichkeit;
}
/* Nur dort, wo der Bereich es vorsieht -- sonst koennte man einen
Schutzvorfall oder eine Content-Idee als "vertraulich" markieren
und damit vor den eigenen Leuten verstecken. */
if (einstellung.vertraulich && körper.nur_leitung !== undefined) {
aus.nur_leitung = (körper.nur_leitung === true || körper.nur_leitung === 1
|| körper.nur_leitung === "1") ? 1 : 0;
}
/* Die vier Content-Felder gibt es nur in der Content-Planung. In jedem
anderen Bereich werden sie stillschweigend verworfen -- wie Bewertung
und Dringlichkeit auch. Sonst stuende irgendwann ein Aufhaenger an
einem Schutzvorfall. */
if (bereich === "content") {
if (körper.hook !== undefined) {
const h = String(körper.hook ?? "").trim();
if (h.length > 300) fehler.push("Der Hook ist zu lang.");
else aus.hook = h || null;
}
if (körper.format !== undefined) {
const f = String(körper.format ?? "").trim();
if (f.length > 60) fehler.push("Das Format ist zu lang.");
else aus.format = f || null;
}
if (körper.saeule_id !== undefined) {
if (körper.saeule_id === null || körper.saeule_id === "") aus.saeule_id = null;
else {
const s = Number(körper.saeule_id);
if (!Number.isInteger(s) || s < 1) fehler.push("Unbekannte Säule.");
else aus.saeule_id = s;
}
}
if (körper.geplant !== undefined) {
const g = String(körper.geplant ?? "").trim();
if (!g) aus.geplant = null;
/* Datum ODER Datum mit Uhrzeit -- wer nur den Tag weiss, soll nicht
zu einer erfundenen Uhrzeit gezwungen werden. */
else if (!/^\d{4}-\d{2}-\d{2}(T\d{2}:\d{2})?$/.test(g) || Number.isNaN(Date.parse(g))) {
fehler.push("Der geplante Zeitpunkt ist ungültig.");
} else aus.geplant = g;
}
}
/* ---- Agentur-Events: Zeitraum, Aufgaben, Regeln -------------------
Nur im Agentur-Bereich, nach demselben Muster wie die vier
Content-Felder darueber: anderswo werden sie stillschweigend
verworfen. Sonst haenge eines Tages ein Preisausschreiben an einem
Schutzvorfall. */
if (bereich === "agentur") {
if (körper.event_ende !== undefined) {
const e = String(körper.event_ende ?? "").trim();
if (!e) aus.event_ende = null;
else if (!/^\d{4}-\d{2}-\d{2}$/.test(e) || Number.isNaN(Date.parse(e))) {
fehler.push("Das Ende des Zeitraums ist ungültig.");
} else aus.event_ende = e;
}
for (const [feld, name] of [["event_aufgaben", "Die Aufgaben"], ["event_regeln", "Die Regeln"]]) {
if (körper[feld] === undefined) continue;
const t = String(körper[feld] ?? "").trim();
if (t.length > TEXT_MAX) fehler.push(`${name} sind zu lang.`);
else aus[feld] = t || null;
}
/* "Bis" vor "von" ist kein Zeitraum, sondern ein Tippfehler -- und
einer, den man einer Liste nicht ansieht: Der Eintrag stuende da,
liefe aber schon abgelaufen ein. Geprueft wird gegen das Datum,
das GERADE gesetzt wird; beim Aendern nur einer der beiden Seiten
ergaenzt der Aufrufer die andere mit (siehe PATCH). */
if (aus.event_ende && aus.datum && aus.event_ende < aus.datum) {
fehler.push("Das Ende liegt vor dem Beginn.");
}
}
if (körper.creator_id !== undefined) {
const w = körper.creator_id;
if (w === null || w === "") aus.creator_id = null;
else {
const z = Number(w);
if (!Number.isInteger(z) || z < 1) fehler.push("Ungültige Zuordnung.");
else aus.creator_id = z;
}
}
/* Ein frei eingetragener Name statt eines Creators -- eine Marke, ein
Partner, jemand ohne Konto im Workspace. Er schlaegt die Auswahl:
Wer tippt, meint das Getippte. Der Eintrag gehoert dann zu keinem
Konto; sichtbar bleibt er ueber erstellt_von (siehe sichtbar()). */
externPruefen(körper, aus, "creator", fehler);
/* Das Einsatz-Feld gibt es nur in Bereichen, die es kennen. Ein
Aufruf an der Oberflaeche vorbei soll nicht in jedem Bereich eine
Spalte fuellen koennen, die dort nichts bedeutet. */
if (einstellung.einsatzFeld && körper.einsatz !== undefined) {
const t = String(körper.einsatz ?? "").trim();
if (t.length > TEXT_MAX) fehler.push("Der Einsatz ist zu lang.");
else aus.einsatz = t || null;
}
/* ---- ZU WELCHEM ACCOUNT? (20.09.2026) ---------------------------
Filipe: "und wenn man was hinzufuegt soll man auch den account
auswaehlen koennen."
NUR AUF DEN HIGHLIGHTS und nur gegen die echte Kanalliste geprueft.
Ein Aufruf an der Oberflaeche vorbei soll keinen erfundenen Kanal
in die Spalte schreiben koennen -- danach stuende in der Galerie
eine vierte Spalte, die es nicht gibt, und niemand faende heraus,
woher sie kommt. Eine Regel, die nur im Formular steht, ist keine
Regel (siehe der Absatz gleich darunter).
KEIN PFLICHTFELD: Leer bedeutet "noch offen" -- ein falscher
Eintrag ist schlechter als ein leerer, genau wie an KANAELE
vermerkt. Und wer einen TikTok-Link einfuegt, bekommt den Kanal
ohnehin aus dem Handle abgeleitet; DAS ist genauer als jede
Auswahl, weil niemand sich vertippen kann. Diese Zeilen
ueberschreiben das nicht: Die Video-Route setzt `quelle_kanal`
selbst und geht hier nicht durch. */
if (bereich === "highlight" && körper.quelle_kanal !== undefined) {
const w = String(körper.quelle_kanal ?? "").trim();
if (!w) aus.quelle_kanal = null;
else if (KANAELE.some((k) => k.wert === w)) aus.quelle_kanal = w;
else fehler.push("Diesen Account gibt es nicht.");
}
/* Ein Agentur-Eintrag gehoert NIEMANDEM einzeln (07.09.2026).
Er gilt fuer alle, und genau deshalb sieht ihn auch jeder (siehe
`fuerAlle` oben). Eine Zuordnung waere hier nicht bloss unnoetig,
sie waere irrefuehrend: Ein Event mit dem Namen einer Creatorin
daneben liest sich, als sei es ihres. Die Oberflaeche bietet
deshalb nur noch "Agentur" an -- und diese Zeilen sorgen dafuer,
dass ein Aufruf an der Oberflaeche vorbei zum selben Ergebnis
kommt. Eine Regel, die nur im Formular steht, ist keine Regel.
GANZ ZUM SCHLUSS, und das ist der Punkt: Der freie Name wird eine
Zeile darueber gesetzt. Stuende dieser Riegel vorher -- der
naheliegende Ort, gleich bei der Creator-Zuordnung --, haette
externPruefen ihn danach wieder aufgemacht, und ein getippter Name
stuende trotz allem am Event. Zwei richtige Regeln, falsche
Reihenfolge, kein Fehler zu sehen. */
if (einstellung.ohneCreatorBezug) {
aus.creator_id = null;
aus.creator_extern = null;
}
return { aus, fehler };
}
/* =====================================================================
DER STARTKATALOG (17.09.2026)
Filipe, mit drei Bildschirmfotos leerer Bretter: "ich will fertige
sachen schon drin wo auch die community und alle anderen benutzen
koennen". Es stand sogar im Plan (§5.1): "Acht leere Seiten sind
schlimmer als keine."
NICHT AUTOMATISCH BEIM START. Ein Text, den niemand gelesen hat,
stuende sonst als Ansage des Teams auf einer oeffentlichen Seite.
"Bleibt fair" klingt harmlos, bis jemand fragt, was das im
Streitfall heisst -- und dann muss dahinterstehen, WER es gemeint
hat. Uebernehmen ist eine Entscheidung; automatisch fuellen waere
eine Behauptung.
UND DIE BREMSE GILT HIER NICHT. Sie zaehlt Beitraege pro Stunde und
wuerde beim Uebernehmen von fuenfzehn Regeln nach dem zehnten
abbrechen -- mit einer halb gefuellten Seite und der Meldung, man
habe zu viel geschrieben. Das ist genau die Sorte Sicherung, die das
richtige Verhalten bestraft und deshalb abgeschaltet wird. Der Weg
hier ist eine EINZELNE Handlung des Teams, kein Schreibrausch. */
/* =====================================================================
VORLAGEN FUER DIE COMMUNITY (18.09.2026)
Filipe: „ich will auch dass du fertige und beispiele machst fuer die
community damit die auch start hilfe haben ueberall."
NICHT ZU VERWECHSELN MIT DEM STARTKATALOG darueber. Der ist fuer das
Team: fertige Beitraege, die jemand uebernimmt, damit kein Brett
leer dasteht. Hier geht es um das andere Ende -- ein Mitglied steht
vor einem leeren Feld und weiss nicht, was hineingehoert.
NUR WER SCHREIBEN DARF. Ein Mitglied, das die Sieben-Tage-Frist noch
nicht hinter sich hat, sieht das Formular gar nicht; Vorlagen dazu
waeren ein Angebot fuer eine Tuer, die zu ist. Dieselbe Regel wie
beim Startkatalog, nur mit umgekehrtem Vorzeichen: dort „wer
schreiben darf, bekommt NICHTS", hier „nur wer schreiben darf". */
bereicheRouter.get("/workspace/api/bereich/:bereich/vorlagen", (req, res) => {
try {
const bereich = String(req.params.bereich);
if (!BEREICHE[bereich]) return res.status(404).json({ fehler: "nicht_gefunden" });
if (darfSchreiben(req.person, bereich)) return res.json({ vorlagen: [] });
res.json({ vorlagen: vorlagenFuer(bereich) });
} catch (fehler) {
console.error("[workspace] Vorlagen:", fehler?.message);
res.status(503).json({ fehler: "nicht_verfuegbar" });
}
});
bereicheRouter.get("/workspace/api/bereich/:bereich/start", (req, res) => {
try {
const bereich = String(req.params.bereich);
if (!BEREICHE[bereich]) return res.status(404).json({ fehler: "nicht_gefunden" });
/* Wer hier nicht schreiben darf, bekommt den Katalog gar nicht --
statt ihn zu bekommen und den Knopf ausgeblendet zu sehen. */
if (darfSchreiben(req.person, bereich)) return res.status(404).json({ fehler: "nicht_gefunden" });
const liste = STARTKATALOG[bereich] || [];
/* Was schon dasteht, kommt nicht noch einmal. Verglichen wird ueber
den Titel: Eine eigene Kennung an der Zeile waere eine zweite
Wahrheit, und beim Umformulieren liefe sie auseinander. */
const da = new Set(db().prepare(
"SELECT titel FROM eintraege WHERE bereich = ?").all(bereich).map((z) => z.titel));
/* ==== EIN FENSTER STATT DER GANZEN LISTE (20.09.2026) ===========
Filipe: "fertige vorschlaege, ueberall auf der ganzen kompletten
website, will ich dass man auch immer wieder neuladen kann, so
dass wenn man alle benutzt hat man neue erstellen kann oder wenn
keiner uns gefaellt wir komplett neue erstellen koennen
automatisch ... dass es immer wieder moeglich ist die liste zu
wechseln wenn sie uns nicht gefaellt oder leer ist."
BISHER KAMEN ALLE AUF EINMAL. Damit gab es nichts zu wechseln --
die Liste war entweder ganz da oder ganz weg. Und bei 17
Vorschlaegen (Brett "regeln") ist eine Wand aus Karten das
Gegenteil von "uebernehmen, was passt".
JETZT: vier auf einmal, und ein Knopf holt die naechsten vier.
Ist der Vorrat durch, faengt er von vorn an -- `ab` wird mit
Rest gerechnet, es gibt also kein Ende und keine Sackgasse.
WAS ES NICHT IST: Die Vorschlaege werden nicht ERZEUGT. Sie sind
ein geschriebener Vorrat (113 Stueck auf 16 Brettern), und das
steht auch in der Antwort -- `vorrat` sagt, wie viele es
insgesamt sind. Der Oberflaeche zu erlauben, "neue" zu
versprechen, die es nicht gibt, waere eine Luege mit
Fortschrittsanzeige. */
const FENSTER = 4;
const offeneListe = liste.map((v, nr) => ({ nr, ...v, schon: da.has(v.titel) }))
.filter((v) => !v.schon);
const roh = Number(req.query?.ab);
/* MODULO STATT GRENZE: Wer oft genug weiterklickt, landet wieder am
Anfang -- statt vor einer leeren Liste zu stehen. */
const ab = offeneListe.length
? ((Number.isFinite(roh) ? Math.trunc(roh) : 0) % offeneListe.length
+ offeneListe.length) % offeneListe.length
: 0;
const fenster = [];
for (let i = 0; i < Math.min(FENSTER, offeneListe.length); i++) {
fenster.push(offeneListe[(ab + i) % offeneListe.length]);
}
res.json({
vorschlaege: fenster,
/* `offen` bleibt, was es war: wie viele es NOCH gibt. Die
Oberflaeche zaehlt damit "Alle N uebernehmen" richtig. */
offen: offeneListe.length,
/* NEU: Gibt es ueberhaupt etwas zu wechseln? Ohne diese Angabe
muesste die Seite rechnen, und ein Knopf, der nichts anderes
zeigt, ist ein Knopf, der nichts tut. */
mehr_da: offeneListe.length > FENSTER,
ab,
vorrat: liste.length,
/* DER HINWEIS GEHT IMMER MIT (21.09.2026). Er kommt aus
workspace-treff-start.js, damit es ihn im ganzen Haus genau
einmal gibt -- und damit eine Pruefung ihn gegen die Quelle
halten kann statt gegen eine Abschrift. */
hinweis: VORSCHLAG_HINWEIS,
});
} catch (fehler) {
console.error("[workspace] Startkatalog:", fehler?.message);
res.status(503).json({ fehler: "nicht_verfuegbar" });
}
});
bereicheRouter.post("/workspace/api/bereich/:bereich/start", gleicheHerkunft, (req, res) => {
try {
const bereich = String(req.params.bereich);
const einstellung = BEREICHE[bereich];
if (!einstellung) return res.status(404).json({ fehler: "nicht_gefunden" });
const warum = darfSchreiben(req.person, bereich);
if (warum) return res.status(403).json({ fehler: warum });
const liste = STARTKATALOG[bereich] || [];
if (!liste.length) return res.status(404).json({ fehler: "nicht_gefunden" });
const nr = req.body?.nr;
const gewaehlt = nr === undefined || nr === null || nr === ""
? liste
: [liste[Number(nr)]].filter(Boolean);
if (!gewaehlt.length) return res.status(400).json({ fehler: "Unbekannter Vorschlag." });
const da = new Set(db().prepare(
"SELECT titel FROM eintraege WHERE bereich = ?").all(bereich).map((z) => z.titel));
const neu = gewaehlt.filter((v) => !da.has(v.titel));
let angelegt = 0;
for (const v of neu) {
/* DIE ART MUSS ZUM BEREICH PASSEN. Sie steht im Katalog, aber
geprueft wird sie trotzdem -- sonst traegt ein Tippfehler im
Katalog eine Art in die Datenbank, die es dort nicht gibt, und
die Zeile laesst sich hinterher nicht mehr aendern. */
if (!Object.hasOwn(einstellung.arten, v.art)) continue;
const { lastInsertRowid } = db().prepare(`
INSERT INTO eintraege (bereich, art, titel, text, datum, status, erstellt,
erstellt_von, haus)
VALUES (?,?,?,?,?, 'offen', ?, ?, ?)`)
.run(bereich, v.art, v.titel, v.text ?? null,
/* Der TAG in Ortszeit, der ZEITSTEMPEL in UTC -- das ist kein
Widerspruch: Ein Zeitpunkt ist ueberall derselbe, ein
Kalendertag nicht. */
heuteLokal(), jetzt(), req.person.id, req.person.haus || null);
/* UND SOFORT FREIGEBEN (17.09.2026) -- der Fehler, den Filipe
auf seinem Bildschirm gesehen hat.
Gemessen, BEVOR etwas gebaut wurde: DogFather uebernimmt bei
"Was ansteht" vier Vorschlaege und bei den Highlights drei.
Auf seinem Bildschirm stehen sie. Die Community sah:
Brett DogFather rechte Hand Modi Community
ansteht 4 4 4 0
highlight 3 3 3 0
Beide Bretter verlangen eine Freigabe, bevor jemand von
aussen etwas sieht -- und ein uebernommener Vorschlag hatte
keine. Filipe konnte also fuellen, so viel er wollte; fuer die
Community blieben genau die zwei Bretter leer, auf die es
ankommt. Und es waere niemandem aufgefallen, weil es auf
jedem Team-Bildschirm richtig aussieht.
WARUM DAS KEINE UMGEHUNG DER FREIGABE IST: Die Freigabe fragt
"hat das Team diesen Text gesehen?". Bei einem uebernommenen
Vorschlag lautet die Antwort ja -- jemand aus dem Team hat ihn
ausgesucht und auf "Uebernehmen" gedrueckt. Das IST die
Entscheidung. Eine zweite daneben waere keine Sicherheit,
sondern ein Klick.
NUR FUER TEAM DOGI, und die Bedingung fragt die ROLLE, nicht
den Weg. Duerfte eines Tages jemand von aussen den Katalog
uebernehmen, ginge sein Eintrag wie jeder andere zuerst durch
die Freigabe. */
if (TREFF_FREIGABE_BRETTER.includes(bereich)
&& TREFF_TEAM_ROLLEN.has(req.person?.rolle)) {
db().prepare(
"INSERT OR IGNORE INTO treff_freigaben (eintrag_id, zeitpunkt, von) VALUES (?,?,?)")
.run(Number(lastInsertRowid), jetzt(), req.person.id);
}
angelegt++;
}
protokolliere("bereich_start_uebernommen", {
personId: req.person.id, rolle: req.person.rolle, ip: echteIp(req),
detail: `${bereich} ${angelegt} von ${gewaehlt.length}`,
});
res.status(201).json({ angelegt, schon: gewaehlt.length - angelegt });
} catch (fehler) {
console.error("[workspace] Startkatalog uebernehmen:", fehler?.message);
res.status(503).json({ fehler: "nicht_verfuegbar" });
}
});
/* =====================================================================
DER KREISLAUF (17.09.2026) -- aus dem Plan im Vault, Stufe 8.
Bisher waren die acht Bretter acht Silos. Ein Wunsch wurde
angenommen, irgendwann passierte etwas im Stream, irgendwann lag ein
Clip bei den Highlights -- und nichts davon wusste voneinander. Wer
den Wunsch geschrieben hatte, erfuhr nie, dass er erfuellt wurde.
Wunsch -> Termin bei "Was ansteht" -> Clip bei "Highlights"
DAS IST DER UNTERSCHIED ZWISCHEN EINEM BRIEFKASTEN UND EINER
COMMUNITY. Jemand schreibt einen Wunsch und sieht ihn vier Wochen
spaeter als Clip wieder, mit seinem Namen daneben.
EINE EIGENE ROUTE UND KEIN FELD AM FORMULAR: Der Zusammenhang
entsteht durch eine HANDLUNG ("daraus wird ein Termin"), nicht durch
ein Auswahlfeld, in dem man einen von vierzig Eintraegen sucht. Wer
ein Formular ausfuellt, denkt nicht an den Wunsch von letzter Woche.
===================================================================== */
bereicheRouter.post("/workspace/api/bereich/:bereich/:id/daraus",
gleicheHerkunft, (req, res) => {
try {
const vonBereich = String(req.params.bereich);
const id = Number(req.params.id);
const nach = String(req.body?.nach || "");
if (!BEREICHE[vonBereich] || !BEREICHE[nach] || !Number.isInteger(id)) {
return res.status(404).json({ fehler: "nicht_gefunden" });
}
/* NUR INNERHALB DER COMMUNITY. Eine Kette, die in die
Content-Planung eines Creators fuehrt, waere ein Leck: Dort
steht Arbeit, die die Community nichts angeht. */
if (!TREFF_BRETTER.includes(vonBereich) || !TREFF_BRETTER.includes(nach)) {
return res.status(404).json({ fehler: "nicht_gefunden" });
}
const warum = darfSchreiben(req.person, nach);
if (warum) return res.status(403).json({ fehler: warum });
const regel = sichtbar(req.person);
if (!regel) return res.status(404).json({ fehler: "nicht_gefunden" });
/* DIE QUELLE MUSS SICHTBAR SEIN. Sonst liesse sich durch
Ausprobieren herausfinden, welche Nummern es gibt -- und der
Titel kaeme im neuen Eintrag gleich mit. */
const quelle = db().prepare(
"SELECT id, bereich, titel, erstellt_von FROM eintraege WHERE id = ? AND bereich = ?")
.get(id, vonBereich);
if (!quelle) return res.status(404).json({ fehler: "nicht_gefunden" });
/* SCHON GEMACHT? Dann dieselbe Antwort wie beim Startkatalog:
nichts Neues, kein Fehler. Zwei Termine aus einem Wunsch
waeren ein Versehen, kein Wunsch. */
const schon = db().prepare(
"SELECT id FROM eintraege WHERE aus_eintrag_id = ? AND bereich = ?").get(id, nach);
if (schon) return res.status(200).json({ id: schon.id, schon: true });
const arten = Object.keys(BEREICHE[nach].arten);
const art = arten.includes(String(req.body?.art)) ? String(req.body.art) : arten[0];
const { lastInsertRowid } = db().prepare(`
INSERT INTO eintraege (bereich, art, titel, text, datum, status,
erstellt, erstellt_von, aus_eintrag_id, haus)
VALUES (?,?,?,?,?, 'offen', ?,?,?,?)`)
.run(nach, art, quelle.titel,
String(req.body?.text ?? "").trim().slice(0, TEXT_MAX) || null,
/* DIE STELLE, AN DER ES AUFGEFALLEN IST (01.10.2026).
pruef-kreislauf legt einen Wunsch mit dem heutigen Datum an
und macht daraus einen Termin; gemessen um 01:22 kam
`2026-09-30` heraus statt `2026-10-01`. Der Termin lag
damit in der Vergangenheit, stand auf dem Brett unter
„Vorbei" und war zugeklappt -- waehrend beim Wunsch
„Daraus wurde ein Termin" zu lesen war. */
heuteLokal(), jetzt(), req.person.id, quelle.id,
req.person.haus || null);
protokolliere("bereich_daraus", {
personId: req.person.id, rolle: req.person.rolle, ip: echteIp(req),
detail: `${vonBereich}#${id} -> ${nach}`,
});
res.status(201).json({ id: Number(lastInsertRowid), schon: false });
} catch (fehler) {
console.error("[workspace] Kreislauf:", fehler?.message);
res.status(503).json({ fehler: "nicht_verfuegbar" });
}
});
/* =====================================================================
ANTWORTEN (17.09.2026) -- Stufe 6 des Plans
"Das Rudel" war eine Liste aus Karten. Der einzige Bereich, in dem
Menschen MITEINANDER reden sollen, zwang sie, nebeneinander zu
reden.
DIE BREMSE GILT AUCH HIER. Eine Antwort ist ein Beitrag; wer sie
ausnaehme, haette die Bremse mit drei Klicks umgangen. Sie zaehlt
allerdings ihren EIGENEN Vorrat: Wer zehn Beitraege geschrieben hat,
soll noch antworten koennen -- ein Gespraech, das mitten im Satz
abbricht, ist schlimmer als eins, das nicht angefangen wird. */
const ANTWORTEN_JE_STUNDE = 20;
const ANTWORT_MAX = 1200;
bereicheRouter.post("/workspace/api/bereich/:bereich/:id/antwort",
gleicheHerkunft, (req, res) => {
try {
const bereich = String(req.params.bereich);
const id = Number(req.params.id);
if (!MIT_ANTWORTEN.has(bereich) || !Number.isInteger(id)) {
return res.status(404).json({ fehler: "nicht_gefunden" });
}
const warum = darfSchreiben(req.person, bereich);
if (warum) return res.status(403).json({ fehler: warum });
const text = String(req.body?.text ?? "").trim();
if (!text) return res.status(400).json({ fehler: "Schreib etwas." });
if (text.length > ANTWORT_MAX) return res.status(400).json({ fehler: "Das ist zu lang." });
const regel = sichtbar(req.person);
const e = db().prepare("SELECT id FROM eintraege WHERE id = ? AND bereich = ?")
.get(id, bereich);
if (!e || !regel) return res.status(404).json({ fehler: "nicht_gefunden" });
const seit = new Date(Date.now() - 3600_000).toISOString();
const { anzahl } = db().prepare(
"SELECT COUNT(*) AS anzahl FROM eintrag_antworten WHERE person_id = ? AND erstellt >= ?")
.get(req.person.id, seit);
if (anzahl >= ANTWORTEN_JE_STUNDE) {
return res.status(429).json({
fehler: `Du hast in der letzten Stunde ${anzahl} Antworten geschrieben. `
+ "Mach mal kurz Pause.",
});
}
const { lastInsertRowid } = db().prepare(
"INSERT INTO eintrag_antworten (eintrag_id, person_id, text, erstellt) VALUES (?,?,?,?)")
.run(id, req.person.id, text, jetzt());
res.status(201).json({ id: Number(lastInsertRowid) });
} catch (fehler) {
console.error("[workspace] Antwort:", fehler?.message);
res.status(503).json({ fehler: "nicht_verfuegbar" });
}
});
/* DER PFAD LIEGT AUSSERHALB VON `/bereich/` -- und das ist eine
Reparatur, keine Geschmacksfrage (17.09.2026).
Zuerst hiess er `/api/bereich/antwort/:id`. Darueber liegt aber eine
Middleware auf `/api/bereich/:bereich`, die prueft, ob es den
Bereich gibt und ob die Person hineindarf -- und "antwort" ist kein
Bereich. Ergebnis: Fuer DogFather ging es (ein frueherer Zweig liess
ihn durch), fuer einen Modi kam 404. Ein Weg, der je nach Rolle an
einer voellig anderen Stelle scheitert, sucht man lange.
Gefunden hat es die Pruefung, nicht das Lesen: "das Team loescht
auch fremde" war gruen, "Lena loescht ihre eigene" nicht. */
bereicheRouter.delete("/workspace/api/antwort/:id",
gleicheHerkunft, (req, res) => {
try {
const id = Number(req.params.id);
if (!Number.isInteger(id)) return res.status(400).json({ fehler: "ungueltig" });
const a = db().prepare(
"SELECT id, person_id FROM eintrag_antworten WHERE id = ?").get(id);
if (!a) return res.status(404).json({ fehler: "nicht_gefunden" });
/* DIE EIGENE IMMER, FREMDE NUR DAS TEAM.
HIER STAND `!darfSchreiben(req.person, "treff")` -- und das war
ein Loch. `darfSchreiben` beantwortet "darf diese Person hier
SCHREIBEN", und das duerfen auch Gaeste ab der Stufe "dabei".
Ein Gast haette also jede fremde Antwort loeschen koennen.
Gefunden hat es die Pruefung, nicht das Lesen: Sie verlangte,
dass ein Modi eine fremde Antwort NICHT loeschen kann, und
bekam 200. Die Erwartung war fuer den Modi falsch -- er
moderiert ja --, aber der Weg dorthin hat das echte Loch
freigelegt.
`TREFF_TEAM_ROLLEN` ist die Liste, die im Haus ohnehin
entscheidet, wer im Treff moderiert: modi, hand, admin. */
const darf = a.person_id === req.person.id
|| TREFF_TEAM_ROLLEN.has(req.person?.rolle);
if (!darf) return res.status(403).json({ fehler: "nicht_erlaubt" });
db().prepare("DELETE FROM eintrag_antworten WHERE id = ?").run(id);
res.json({ ok: true });
} catch (fehler) {
console.error("[workspace] Antwort loeschen:", fehler?.message);
res.status(503).json({ fehler: "nicht_verfuegbar" });
}
});
/* ---------- Anlegen ------------------------------------------------------ */
bereicheRouter.post("/workspace/api/bereich/:bereich", gleicheHerkunft, (req, res) => {
try {
const bereich = String(req.params.bereich);
if (!BEREICHE[bereich]) return res.status(404).json({ fehler: "nicht_gefunden" });
const regel = sichtbar(req.person);
if (!regel) return res.status(404).json({ fehler: "nicht_gefunden" });
/* DIE SCHREIBTAFEL DES TREFFS (11.09.2026).
Auf welches der sieben Bretter jemand von aussen schreiben darf,
steht in TREFF_SCHREIBEN -- an einer Stelle, aus der auch die
Oberflaeche ihre Knoepfe holt (/api/treff/lage). Waeren es zwei
Stellen, koennte ein Knopf erscheinen, den der Server ablehnt --
oder, schlimmer, umgekehrt.
DER TEXT WIRD DURCHGEREICHT, nicht durch "nicht_erlaubt" ersetzt:
"Ab Dabei kannst du hier schreiben" beantwortet die Frage, die
der Mensch davor gerade hat. */
const warum = darfSchreiben(req.person, bereich);
if (warum) return res.status(403).json({ fehler: warum });
/* DIE BREMSE (17.09.2026) -- aus dem Plan im Vault, Stufe 4.
Der Treff hatte Stufen (wer ueberhaupt schreiben darf) und
Massnahmen (wer nicht mehr darf), aber nichts dazwischen: WIE
SCHNELL. Ein Stammgast konnte in einer Minute vierzig Beitraege
absetzen -- aus Aerger, aus Versehen oder weil jemand ein Skript
laufen laesst.
Ein Bereich, der waechst und keine Bremse hat, waechst genau
einmal. Deshalb steht diese Stufe im Plan VOR Galerie und
Gespraech: Mehr Sichtbarkeit heisst mehr Angriffsflaeche.
KEINE NEUE TABELLE. Die Antwort steht schon in `eintraege` --
eine Zaehlung ueber die letzte Stunde genuegt. Eine eigene
Tabelle waere ein zweiter Ort fuer dieselbe Wahrheit und muesste
zusaetzlich aufgeraeumt werden.
UND DIE ABSAGE SAGT, WANN ES WEITERGEHT. "Zu viele Beitraege"
ohne Zeitangabe laesst jemanden im Minutentakt weiterprobieren
-- das ist genau die Last, die man verhindern wollte. */
if (treffBereich(bereich)) {
const seit = new Date(Date.now() - 3600_000).toISOString();
/* NUR DIE COMMUNITY-BRETTER ZAEHLEN MIT. Beim ersten Entwurf
stand hier keine Bereichsgrenze -- dann haette eine Creatorin,
die zehn Content-Ideen eintraegt, danach im Treff nichts mehr
schreiben koennen. Eine Bremse, die die falsche Arbeit
bestraft, wird abgeschaltet. */
const felder = TREFF_BRETTER.map(() => "?").join(", ");
const { anzahl, aeltester } = db().prepare(
`SELECT COUNT(*) AS anzahl, MIN(erstellt) AS aeltester
FROM eintraege
WHERE erstellt_von = ? AND erstellt >= ?
AND bereich IN (${felder})`)
.get(req.person.id, seit, ...TREFF_BRETTER);
if (anzahl >= BEITRAEGE_JE_STUNDE) {
const frei = new Date(Date.parse(aeltester) + 3600_000);
const min = Math.max(1, Math.ceil((frei.getTime() - Date.now()) / 60000));
protokolliere("treff_bremse", {
personId: req.person.id, rolle: req.person.rolle, ip: echteIp(req),
detail: `${bereich} ${anzahl} in einer Stunde`,
});
return res.status(429).json({
fehler: `Du hast in der letzten Stunde ${anzahl} Beiträge geschrieben. `
+ `In ${min} ${min === 1 ? "Minute" : "Minuten"} geht es weiter.`,
});
}
}
const { aus, fehler } = pruefe(bereich, req.body || {}, { neu: true });
if (fehler.length) return res.status(400).json({ fehler: fehler.join(" ") });
/* Ein Creator schreibt immer in den eigenen Bereich, egal was im
Aufruf steht. Ein Scout in den eines Creators, den er betreut --
niemals in einen fremden und niemals "auf sich selbst", denn ein
Scout hat gar keinen eigenen Betreuungsbereich. */
if (req.person.rolle === "creator") {
aus.creator_id = req.person.id;
aus.creator_extern = null; // der eigene Bereich gehört ihm, nicht einem Namen
} else if (req.person.rolle === "scout" && !aus.creator_extern) {
/* Der freie Name nimmt diesen Zweig ausdrücklich aus: Wer "Marke
XY" eintippt, will keinen seiner Creator zugeordnet bekommen.
Ohne diese Ausnahme hätte die Notlösung darunter den getippten
Namen stillschweigend durch den erstbesten Creator ersetzt --
der Eintrag stünde dann bei jemandem, der nichts damit zu tun
hat. Sichtbar bleibt er über erstellt_von. */
const w = Number(aus.creator_id);
if (!darfCreator(req.person, w)) {
const erster = betreuteIds(req.person)[0];
if (!erster) return res.status(403).json({ fehler: "Dir ist kein Creator zugeteilt." });
aus.creator_id = erster;
}
}
/* WEM GEHOERT DER EINTRAG? DAS HAENGT AM BEREICH (11.09.2026).
Ueberall sonst zeigt `creator_id` auf einen Creator -- die
Bereichsseiten sind Betreuungsakten. Im Entwicklungs-Bereich
zeigt sie auf ein Mitglied von Team Dogi: Dort steht, was ueber
die Zeit an einem Menschen aus dem Team auffaellt.
Die Spalte heisst weiterhin creator_id. Das ist Geschichte, kein
Inhalt -- sie haelt eine Personennummer, und dieselbe
Ueberlegung steht schon in workspace-checkliste.js.
BEIM ERSTEN ANLAUF FEHLTE DAS, und die Meldung war irrefuehrend
("Zugeordneter Creator existiert nicht" -- die Person existiert
sehr wohl, sie ist nur kein Creator). Gefunden von der Pruefung,
nicht vom Auge. */
/* DIE LINKE HAND GEHOERT DAZU (23.09.2026). Hier stand
`rolle IN ('hand','modi')` -- eine zweite abgeschriebene Liste
derselben Sorte wie in workspace-teamlage.js. Ein Eintrag im
Entwicklungsbereich liess sich der linken Hand nicht zuordnen,
und die Meldung dazu lautete „Diese Person gehoert nicht zum
Team." -- ueber jemanden, der sehr wohl dazugehoert.
Abgeleitet aus TEAM_DOGI_ROLLEN, der einen Liste des Hauses. */
const teamListe = [...TEAM_DOGI_ROLLEN].map((r) => `'${r}'`).join(", ");
const zielRollen = bereich === "entwicklung"
? `rolle IN (${teamListe})`
: "rolle = 'creator'";
if (aus.creator_id
&& !db().prepare(`SELECT 1 FROM personen WHERE id = ? AND ${zielRollen}`)
.get(aus.creator_id)) {
return res.status(400).json({
fehler: bereich === "entwicklung"
? "Diese Person gehört nicht zum Team."
: "Zugeordneter Creator existiert nicht.",
});
}
/* Eine Saeule gehoert immer GENAU EINEM Creator. Ohne diese Pruefung
koennte man ein Video an die Saeule eines fremden Creators haengen
-- und darueber in der Balance-Auswertung Namen sehen, die einen
nichts angehen. Die Sichtbarkeitsregel oben schuetzt die Eintraege,
nicht die Verweise zwischen ihnen. */
const saeuleFehler = saeulePasst(aus.saeule_id, aus.creator_id);
if (saeuleFehler) return res.status(400).json({ fehler: saeuleFehler });
const { lastInsertRowid } = db().prepare(`
INSERT INTO eintraege
(bereich, art, titel, text, datum, uhrzeit, bewertung, dringlichkeit, status,
creator_id, creator_extern, erstellt, erstellt_von, hook, format, saeule_id, geplant,
event_ende, event_aufgaben, event_regeln, einsatz, nur_leitung, haus)
VALUES (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)`).run(
bereich, aus.art, aus.titel, aus.text ?? null, aus.datum, aus.uhrzeit ?? null,
aus.bewertung ?? null, aus.dringlichkeit ?? "mittel", aus.status ?? "offen",
aus.creator_id ?? null, aus.creator_extern ?? null, jetzt(), req.person.id,
aus.hook ?? null, aus.format ?? null, aus.saeule_id ?? null, aus.geplant ?? null,
aus.event_ende ?? null, aus.event_aufgaben ?? null, aus.event_regeln ?? null,
aus.einsatz ?? null,
/* 0 und nicht NULL als Vorgabe: NULL hiesse "unbekannt", und
unbekannt ist bei einer Vertraulichkeit die falsche Antwort.
Wer nichts waehlt, schreibt fuers Team -- das ist der offene
Fall, und der soll der Normalfall sein. */
aus.nur_leitung ?? 0,
/* Das Haus aus der Adresse -- letzte Spalte, letzter Wert. */
req.person.haus || null);
/* DASSELBE VON HAND WIE ÜBER DEN VIDEOWEG (30.09.2026). Wer ein
Highlight selbst anlegt und es auch freigeben dürfte, braucht
dafür keinen zweiten Klick. Termine (`ansteht`) bleiben
unberührt — dort ist die Freigabe der Schalter „Im Treff
zeigen" und damit eine Entscheidung je Termin. */
sofortFreigeben(bereich, req.person, lastInsertRowid);
protokolliere("eintrag_angelegt", {
personId: req.person.id, rolle: req.person.rolle, ip: echteIp(req),
detail: `${bereich} #${lastInsertRowid} ${aus.titel}`.slice(0, 120),
});
res.status(201).json({ id: Number(lastInsertRowid) });
} catch (fehler) {
console.error("[workspace] Eintrag anlegen:", fehler?.message);
res.status(503).json({ fehler: "nicht_verfuegbar" });
}
});
/* ---------- Ändern und Löschen ------------------------------------------- */
/** Darf diese Person diesen Eintrag sehen?
*
* ENTSTANDEN AM 03.10.2026, weil das Banner eines Agentur-Events fuer
* Creator mit 404 beantwortet wurde -- gemessen, nicht vermutet:
*
* workspace.dogfather-universe.com admin Bild=200
* workspace.dogfather-universe.com creator Bild=404
*
* Der Bildweg (workspace-dateien.js) kannte bisher zwei Regeln: die
* Treff-Regel ("wer das Brett sieht, sieht das Bild" -- aber nur fuer
* die sieben Community-Bretter) und sonst die ABLAGE-Regel, die an
* Creator-Zuordnungen haengt. Ein Agentur-Event ist weder das eine
* noch das andere: Es gehoert niemandem, und `agentur` ist kein
* Treff-Brett. Also fiel es durch beide.
*
* Vor dem Umbau fiel das kaum auf -- das Bild war ein Anhang unter
* dem Text. Seit es die Buehne hinter dem Titel ist, saehe eine
* Creatorin eine leere Flaeche an genau der Karte, die fuer sie
* gemacht ist.
*
* WARUM EINE FUNKTION UND KEINE ZWEITE LISTE: Der naheliegende Weg
* waere gewesen, in workspace-dateien.js `|| e.bereich === "agentur"`
* zu ergaenzen. Das waere eine zweite Stelle, an der steht, wer was
* sehen darf -- und die laeuft beim naechsten Brett aus. Hier wird
* stattdessen dieselbe Regel gefragt, die auch das Brett selbst
* benutzt (sichtbarEintrag). Was dort verborgen ist, bleibt es auch
* hier; es gibt keine Rechteausweitung, nur keine Luecke mehr. */
export function darfEintragSehen(person, eintragId) {
if (!person || !Number.isInteger(Number(eintragId))) return false;
const regel = sichtbarEintrag(person);
if (!regel) return false;
return !!db().prepare(`SELECT e.id ${VERBUND} WHERE ${regel.wo} AND e.id = ?`)
.get(...regel.werte, Number(eintragId));
}
function holen(req, id) {
const regel = sichtbarEintrag(req.person);
if (!regel) return null;
return db().prepare(`SELECT e.* ${VERBUND} WHERE ${regel.wo} AND e.id = ?`)
.get(...regel.werte, id);
}
bereicheRouter.patch("/workspace/api/bereich/:bereich/:id", gleicheHerkunft, (req, res) => {
try {
const bereich = String(req.params.bereich);
const id = Number(req.params.id);
if (!BEREICHE[bereich] || !Number.isInteger(id)) return res.status(400).json({ fehler: "ungueltig" });
const eintrag = holen(req, id);
if (!eintrag || eintrag.bereich !== bereich) return res.status(404).json({ fehler: "nicht_gefunden" });
const { aus, fehler } = pruefe(bereich, req.body || {}, { neu: false });
if (fehler.length) return res.status(400).json({ fehler: fehler.join(" ") });
if (!istLeitung(req.person)) delete aus.creator_id;
/* Zeitraum beim AENDERN -- genauso wichtig wie beim Anlegen und
leichter zu uebersehen: pruefe() sieht nur die Felder, die im
Aufruf stehen. Wer nur das Ende verschiebt, schickt kein `datum`
mit; die Pruefung dort haette nichts zu vergleichen und liesse
jedes Ende durch. Deshalb hier gegen den GESPEICHERTEN Wert, und
zwar in beide Richtungen -- man kann den Zeitraum auch dadurch
verdrehen, dass man den Beginn nach hinten schiebt. */
if (bereich === "agentur" && (aus.event_ende !== undefined || aus.datum !== undefined)) {
const von = aus.datum !== undefined ? aus.datum : eintrag.datum;
const bis = aus.event_ende !== undefined ? aus.event_ende : eintrag.event_ende;
if (von && bis && bis < von) {
return res.status(400).json({ fehler: "Das Ende liegt vor dem Beginn." });
}
}
/* Beim Aendern gilt dieselbe Regel -- sonst waere die Pruefung beim
Anlegen wertlos: Man legt ohne Saeule an und haengt sie danach an. */
if (aus.saeule_id !== undefined) {
const zuWem = aus.creator_id !== undefined ? aus.creator_id : eintrag.creator_id;
const saeuleFehler = saeulePasst(aus.saeule_id, zuWem);
if (saeuleFehler) return res.status(400).json({ fehler: saeuleFehler });
}
const felder = Object.keys(aus);
if (!felder.length) return res.status(400).json({ fehler: "nichts_zu_aendern" });
db().prepare(
`UPDATE eintraege SET ${felder.map((f) => `${f} = ?`).join(", ")}, geaendert = ? WHERE id = ?`
).run(...felder.map((f) => aus[f]), jetzt(), id);
protokolliere("eintrag_geaendert", {
personId: req.person.id, rolle: req.person.rolle, ip: echteIp(req),
detail: `${bereich} #${id} ${felder.join(",")}`.slice(0, 120),
});
res.json({ ok: true });
} catch (fehler) {
console.error("[workspace] Eintrag ändern:", fehler?.message);
res.status(503).json({ fehler: "nicht_verfuegbar" });
}
});
/* =====================================================================
EIN BILD AN EINEN BEITRAG (24.09.2026)
Filipe: "mach das man da bitte screenshots oder kurzschnitte von
den live reinposten kann. nach dem selben prinzip wie bei den
anderen nebendran."
"NACH DEM SELBEN PRINZIP" IST WOERTLICH ZU NEHMEN. Die Anzeige gab
es schon: Die Karte zeichnet ihren Bildstreifen aus "e.bilder",
die Auslieferung entscheidet die Sichtbarkeit am BEITRAG (wer das
Brett sehen darf, sieht das Bild), und die Spalte
"dateien.eintrag_id" wird seit dem Video-Einlesen benutzt. Gefehlt
hat genau ein Weg -- dieser.
WER DARF: Wer den Beitrag ueberhaupt sehen darf UND auf diesem
Brett schreiben darf. Beides zusammen, nicht eines davon: "sehen"
allein hiesse, dass die Community Bilder an fremde Beitraege
haengt; "schreiben" allein waere ein Weg, die Existenz eines
Beitrags zu erfahren, den man nicht sehen soll.
DER TYP KOMMT AUS DEM INHALT. dateiErkennen() liest die ersten
Bytes; Dateiname und Content-Type kommen vom Absender und sind
frei erfunden. Dieselbe Funktion wie im Chat und im Support --
eine zweite Fassung waere die, die beim naechsten Format vergessen
wird.
DREI BILDER JE BEITRAG. Nicht als Schikane: Wer fuenf
Bildschirmfotos anhaengt, erklaert damit nichts besser -- er
verschiebt die Arbeit zu dem, der sie ansehen muss. Und der
Bildstreifen einer Karte traegt drei nebeneinander, ohne dass die
Karte auseinanderfaellt.
===================================================================== */
const BILD_MAX_EINTRAG = 12 * 1024 * 1024;
const BILDER_JE_EINTRAG = 3;
/** Vor express.raw: Darf diese Person hier ueberhaupt etwas anhaengen?
*
* Die Berechtigung steht VOR der Annahme des Rumpfes -- sonst
* wanderten zwoelf Megabyte durch die Leitung, nur um danach
* verworfen zu werden, und jeder Angemeldete koennte an jeder
* Beitragsnummer Speicher verbrauchen. Dieselbe Reihenfolge wie beim
* Chat-Anhang. */
function darfBildAnhaengen(req, res, next) {
const bereich = String(req.params.bereich);
const id = Number(req.params.id);
if (!BEREICHE[bereich] || !Number.isInteger(id)) {
return res.status(400).json({ fehler: "ungueltig" });
}
const eintrag = holen(req, id);
if (!eintrag || eintrag.bereich !== bereich) {
return res.status(404).json({ fehler: "nicht_gefunden" });
}
const warum = darfSchreiben(req.person, bereich);
if (warum) return res.status(403).json({ fehler: warum });
req.eintragFuerBild = eintrag;
next();
}
/* =====================================================================
EINEN PUNKT ABHAKEN (03.10.2026)
Filipe: „ich will das viel geiler viel perfekter. und auch wenn man
die eintraegt und so soll viel mehr perfektioniert und
uebersichtlicher sein."
Ein Agentur-Event stellt Bedingungen -- „jeden Tag live",
„22 Live-Stunden", „33k Diamanten". Wer mitmacht, will sehen, wo er
steht, ohne nachzufragen. Genau das ist der Unterschied zwischen
einem Aushang und einer Aktion, an der jemand teilnimmt.
JEDER HAKT NUR FUER SICH SELBST. Es gibt bewusst keinen Weg, einen
Haken bei einer ANDEREN Person zu setzen -- auch nicht fuer die
Leitung. „Ich habe meine 22 Stunden" ist eine Aussage ueber sich,
und wer sie fuer andere treffen koennte, macht aus einer Selbstaus-
kunft eine Bewertung. Die Person steht deshalb nirgends in der
Adresse; sie kommt aus der Sitzung.
KEIN KOERPER BEIM DELETE (gemessen 11.09.2026, steht so schon in
bereich.js): Nodes HTTP-Parser weist ein DELETE mit Koerper mit
einem leeren 400 ab, bevor Express die Anfrage sieht.
===================================================================== */
function punktZugang(req, res, next) {
const id = Number(req.params.id);
const schluessel = String(req.params.punkt || "");
/* Der Schluessel ist 16 Hexzeichen -- was anders aussieht, kommt
nicht aus unserer Liste und hat in der Tabelle nichts zu suchen.
Ohne diese Pruefung koennte jemand beliebigen Text ablegen und die
Tabelle als Notizbuch missbrauchen. */
if (!Number.isInteger(id) || !/^[0-9a-f]{16}$/.test(schluessel)) {
return res.status(400).json({ fehler: "ungueltig" });
}
const eintrag = holen(req, id);
if (!eintrag) return res.status(404).json({ fehler: "nicht_gefunden" });
/* GEHOERT DER PUNKT UEBERHAUPT ZU DIESEM EVENT?
Das ist der eigentliche Grund fuer diesen Waechter. Ohne ihn
koennte man einen beliebigen gueltig aussehenden Schluessel
setzen; die Zahl „3 von 3" waere danach erreichbar, ohne dass eine
der drei Aufgaben je dastand. Eine Zaehlung, die man sich selbst
ausdenken kann, zaehlt nichts.
Gefragt wird die LISTE, nicht der Text: punkteAusText ist die eine
Stelle, die entscheidet, was ein Punkt ist. */
const punkte = punkteAusText(eintrag.event_aufgaben);
if (!punkte.some((p) => p.schluessel === schluessel)) {
return res.status(404).json({ fehler: "punkt_unbekannt" });
}
req.eventEintrag = eintrag;
req.eventPunkt = schluessel;
next();
}
bereicheRouter.put("/workspace/api/eintrag/:id(\\d+)/punkt/:punkt",
angemeldet, gleicheHerkunft, punktZugang, (req, res) => {
try {
/* ON CONFLICT DO NOTHING und kein Fehler beim zweiten Mal: Zwei
Klicks kurz hintereinander (oder ein zweites Geraet) sind kein
Versehen, das man melden muesste -- das Ergebnis ist in beiden
Faellen „der Haken ist gesetzt". */
db().prepare(
"INSERT INTO event_punkte (eintrag_id, person_id, punkt, gesetzt)"
+ " VALUES (?,?,?,?) ON CONFLICT DO NOTHING")
.run(req.eventEintrag.id, req.person.id, req.eventPunkt, jetzt());
res.json(punktStand(req.eventEintrag, req.person.id));
} catch (fehler) {
console.error("[bereich] Punkt setzen:", fehler?.message);
res.status(503).json({ fehler: "nicht_verfuegbar" });
}
});
bereicheRouter.delete("/workspace/api/eintrag/:id(\\d+)/punkt/:punkt",
angemeldet, gleicheHerkunft, punktZugang, (req, res) => {
try {
db().prepare(
"DELETE FROM event_punkte WHERE eintrag_id = ? AND person_id = ? AND punkt = ?")
.run(req.eventEintrag.id, req.person.id, req.eventPunkt);
res.json(punktStand(req.eventEintrag, req.person.id));
} catch (fehler) {
console.error("[bereich] Punkt loeschen:", fehler?.message);
res.status(503).json({ fehler: "nicht_verfuegbar" });
}
});
/** Was nach einem Haken zurueckgeht: der gueltige Stand, vom Server.
*
* NICHT „ok". Der Browser rechnet sonst selbst weiter („war 2, jetzt
* 3") -- und liegt daneben, sobald zwei Fenster offen sind oder eine
* Aufgabe inzwischen umgeschrieben wurde. Die Zahl, die auf der Karte
* steht, kommt immer von hier. */
function punktStand(eintrag, personId) {
const punkte = punkteAusText(eintrag.event_aufgaben);
const meine = new Set(db().prepare(
"SELECT punkt FROM event_punkte WHERE eintrag_id = ? AND person_id = ?")
.all(eintrag.id, personId).map((z) => z.punkt));
return {
gesamt: punkte.length,
/* Nur zaehlen, was AUCH in der Liste steht: Wird eine Aufgabe
umgeschrieben, bleibt ihr alter Haken als Zeile liegen (das ist
richtig, siehe Tabelle) -- mitzaehlen darf er nicht. */
geschafft: punkte.filter((p) => meine.has(p.schluessel)).length,
punkte: punkte.map((p) => ({ ...p, meiner: meine.has(p.schluessel) })),
};
}
bereicheRouter.post("/workspace/api/bereich/:bereich/:id(\\d+)/bild",
gleicheHerkunft,
darfBildAnhaengen,
express.raw({ type: "*/*", limit: BILD_MAX_EINTRAG }),
(req, res) => {
let geschrieben = null;
try {
const eintrag = req.eintragFuerBild;
if (!Buffer.isBuffer(req.body) || !req.body.length) {
return res.status(400).json({ fehler: "Keine Datei empfangen." });
}
const erkannt = dateiErkennen(req.body);
if (!erkannt || erkannt.art !== "bild") {
return res.status(415).json({
fehler: "Hier geht ein Foto - PNG, JPEG, WebP oder GIF.",
});
}
const schon = db().prepare(
"SELECT COUNT(*) AS n FROM dateien WHERE eintrag_id = ?").get(eintrag.id).n;
if (schon >= BILDER_JE_EINTRAG) {
return res.status(409).json({
fehler: "An diesem Beitrag haengen schon "
+ BILDER_JE_EINTRAG + " Bilder. Nimm erst eines weg.",
});
}
mkdirSync(BILD_ORDNER_EINTRAG, { recursive: true });
const dateiname = Date.now().toString(36) + "-"
+ randomBytes(8).toString("hex") + erkannt.endung;
writeFileSync(join(BILD_ORDNER_EINTRAG, dateiname), req.body, { flag: "wx" });
geschrieben = join(BILD_ORDNER_EINTRAG, dateiname);
let roh = "";
try { roh = decodeURIComponent(req.get("x-name") || ""); } catch { roh = ""; }
const name = (roh.replace(/[\u0000-\u001f\u007f]/g, "").trim()
|| ("bild" + erkannt.endung)).slice(0, 120);
const info = db().prepare(
"INSERT INTO dateien (name_original, name_datei, groesse, typ, status,"
+ " notiz, hochgeladen_von, erstellt, eintrag_id, haus)"
+ " VALUES (?,?,?,?,'entwurf',NULL,?,?,?,?)")
.run(name, dateiname, req.body.length, erkannt.typ,
req.person.id, new Date().toISOString(), eintrag.id,
req.person.haus || null);
protokolliere("eintrag_bild", {
personId: req.person.id, rolle: req.person.rolle, ip: echteIp(req),
/* `bereichVon` hatte ich erfunden -- es gibt sie nicht. Der
Bereich steht am Eintrag selbst, und dort ist er auch
richtiger: Er kommt aus der Datenbank, nicht aus der
Adresse. */
detail: (eintrag.bereich + " #" + eintrag.id + " " + name).slice(0, 120),
});
res.status(201).json({
id: Number(info.lastInsertRowid),
name,
weg: "/workspace/api/dateien/" + Number(info.lastInsertRowid) + "/bild",
});
} catch (fehler) {
/* DIE DATEI GEHT MIT, WENN DIE ZEILE NICHT ZUSTANDE KAM. Sonst
sammelt der Ordner Bilder an, auf die nichts zeigt. */
if (geschrieben) { try { unlinkSync(geschrieben); } catch { /* egal */ } }
console.error("[bereich] Bild anhaengen:", fehler?.message);
res.status(503).json({ fehler: "nicht_verfuegbar" });
}
});
/** Ein Bild wieder abnehmen.
*
* WER: wer den Beitrag selbst geschrieben hat -- und wer ihn ohnehin
* loeschen duerfte. Ein Bild, das nicht passt, muss jemand
* abnehmen koennen, ohne den ganzen Beitrag zu entfernen. */
bereicheRouter.delete("/workspace/api/bereich/:bereich/:id(\\d+)/bild/:bild(\\d+)",
gleicheHerkunft, (req, res) => {
try {
const bereich = String(req.params.bereich);
const id = Number(req.params.id);
const eintrag = holen(req, id);
if (!eintrag || eintrag.bereich !== bereich) {
return res.status(404).json({ fehler: "nicht_gefunden" });
}
const treffBrett = TREFF_BRETTER.includes(bereich);
const darf = treffBrett
? TREFF_TEAM_ROLLEN.has(req.person.rolle) || eintrag.erstellt_von === req.person.id
: istLeitung(req.person) || eintrag.erstellt_von === req.person.id;
if (!darf) return res.status(403).json({ fehler: "nicht_erlaubt" });
const bild = db().prepare(
"SELECT id, name_datei FROM dateien WHERE id = ? AND eintrag_id = ?")
.get(Number(req.params.bild), eintrag.id);
if (!bild) return res.status(404).json({ fehler: "nicht_gefunden" });
db().prepare("DELETE FROM dateien WHERE id = ?").run(bild.id);
try { unlinkSync(join(BILD_ORDNER_EINTRAG, bild.name_datei)); } catch { /* schon weg */ }
/* Auch im Ablage-Ordner nachsehen: Coverbilder aus dem
Video-Einlesen liegen dort, nicht im neuen Ordner. */
try { unlinkSync(join(ABLAGE_ORDNER_EINTRAG, bild.name_datei)); } catch { /* egal */ }
protokolliere("eintrag_bild_weg", {
personId: req.person.id, rolle: req.person.rolle, ip: echteIp(req),
detail: (bereich + " #" + eintrag.id + " Bild " + bild.id).slice(0, 120),
});
res.json({ ok: true });
} catch (fehler) {
console.error("[bereich] Bild abnehmen:", fehler?.message);
res.status(503).json({ fehler: "nicht_verfuegbar" });
}
});
bereicheRouter.delete("/workspace/api/bereich/:bereich/:id", gleicheHerkunft, (req, res) => {
try {
const bereich = String(req.params.bereich);
const id = Number(req.params.id);
if (!BEREICHE[bereich] || !Number.isInteger(id)) return res.status(400).json({ fehler: "ungueltig" });
const eintrag = holen(req, id);
if (!eintrag || eintrag.bereich !== bereich) return res.status(404).json({ fehler: "nicht_gefunden" });
/* Löschen darf das Management und wer den Eintrag selbst geschrieben
hat -- sonst könnte ein Creator eine Notiz des Managements über
seinen eigenen Bereich verschwinden lassen. */
/* IM TREFF RAEUMT AUCH EIN MODI AUF (11.09.2026). Er ist dort die
Moderation; waere Aufraeumen der Leitung vorbehalten, bliebe ein
Beitrag stehen, bis jemand Zeit hat -- und genau in dieser Zeit
liest ihn die Community. */
const treffBrett = TREFF_BRETTER.includes(bereich);
const darfWeg = treffBrett
? TREFF_TEAM_ROLLEN.has(req.person.rolle) || eintrag.erstellt_von === req.person.id
: istLeitung(req.person) || eintrag.erstellt_von === req.person.id;
if (!darfWeg) return res.status(403).json({ fehler: "nicht_erlaubt" });
/* DER GRUND WIRD FESTGEHALTEN, BEVOR DER BEITRAG VERSCHWINDET
(DSA Art. 17). Danach waere es zu spaet: Titel und Verfasser
stuenden nirgends mehr, und eine Begruendung ohne den Beitrag,
den sie begruendet, ist keine.
DER GRUND KOMMT AUS DER ADRESSE, und das ist keine Vorliebe,
sondern gemessen (11.09.2026): Nodes HTTP-Parser weist ein
DELETE MIT KOERPER mit einem leeren 400 ab, bevor Express die
Anfrage ueberhaupt sieht -- eine Antwort mit genau einem
Kopffeld ("connection: close") und ohne Text. Wer den Fehler
sucht, sucht ihn in dieser Route, und hier ist keiner.
Der Koerper bleibt als zweite Moeglichkeit stehen: Er schadet
nicht, und wenn ein anderer Weg (ein Werkzeug, eine kuenftige
Fassung von Node) doch einen mitschickt, wird er gelesen. Zwei
Quellen fuer denselben Wert sind hier keine zwei Wahrheiten --
es ist derselbe Wert, nur zwei Briefkaesten. */
const nein = entfernenVorbereiten(req.person, eintrag,
req.body?.grund ?? req.query?.grund);
if (nein) return res.status(400).json({ fehler: nein });
db().prepare("DELETE FROM eintraege WHERE id = ?").run(id);
protokolliere("eintrag_geloescht", {
personId: req.person.id, rolle: req.person.rolle, ip: echteIp(req),
detail: `${bereich} #${id} ${eintrag.titel}`.slice(0, 120),
});
res.json({ ok: true });
} catch (fehler) {
console.error("[workspace] Eintrag löschen:", fehler?.message);
res.status(503).json({ fehler: "nicht_verfuegbar" });
}
});
Reference in New Issue View Git Blame Copy Permalink