Die goldene Regel: was nicht in der Tafel steht, ist verboten

Filipe: "egal welche rolle oder person hinzugefuegt wird soll immer nur
das sehen wass ich erlaube. mehr nicht. soll nichts so sein dass wenn
mann eine rolle oder jemanden hinzufuegt dass er dan alles sieht."

DER BEFUND -- GEZAEHLT, NICHT GESCHAETZT

NEUN von zwanzig Seiten standen auf `null`, und `null` hiess "jede
angemeldete Rolle": Start, Uebersicht, Aufgaben, Chat, Kalender,
Dateien, Calls, Start-Check, Wissen. Eine neue Rolle erbte sie alle,
ohne dass jemand etwas erlaubt haette.

UND EIN ZWEITES LOCH, das ich vorher nicht gemessen hatte: Die Schranke
las `const erlaubt = GESCHUETZT[pfad]` und prueffte `if (erlaubt && ...)`.
Eine Seite, die GAR NICHT in der Tabelle stand, ergab `undefined`, fiel
durch dieselbe Bedingung und war damit ebenfalls fuer jede angemeldete
Rolle offen. Am 11.09.2026 betraf das keine einzige Seite (nachgezaehlt:
22 Dateien = 20 Eintraege + 2 Zugangswaende) -- aber jede NEUE waere so
entstanden.

Die Rolle wird im Haus an 74 Stellen in 20 Modulen abgefragt, und die
Endzweige widersprechen einander: Aufgaben enden mit `default: 0=1`
(sieht nichts), Bereiche und Dateien fallen in "eigene plus betreute".
Drei Module, drei Antworten auf dieselbe Frage.

WARUM NICHT "DIE LISTE DURCHGEHEN"

Das waere die naheliegende Antwort und die falsche. Im Code stand seit
dem 10.09. genau dieser Satz -- "Wer eine Rolle hinzufuegt, muss diese
Liste durchgehen" -- und einen Tag spaeter standen immer noch neun
Seiten auf `null`. Ein Satz, der sich auf ein Gedaechtnis verlaesst, ist
keine Sicherung. Dazu: eine vergessene Erlaubnis MELDET SICH NIE. Die
Seite laedt ja. In der anderen Richtung ist es schlimmer -- eine Seite,
die zu viel zeigt, sieht aus wie eine Seite, die funktioniert.

WAS JETZT GILT

server/rechte.js traegt die Tafel, `darfSeite()` liest sie, und sie
kennt zwei Antworten: Seite in der Tafel UND Rolle darin -> ja. Alles
andere -> nein. Kein `null`, kein `undefined`, kein Zweig, der etwas
durchlaesst.

DIE TABELLE IST UMGEZOGEN, NICHT NEU GESCHRIEBEN. In ihren Kommentaren
steckt das Gedaechtnis des Hauses -- jede Zeile traegt ein Datum und
einen Satz von Filipe ("nimm die kategorie zahlen bei jedem weg", "die
manager sollen diese kategorien garnicht sehen", "ich will dass die
rechte Hand auch alle sieht"). Die wegzurefactoren waere der teuerste
Fehler dieses Umbaus gewesen.

VERHALTENSGLEICH FUER DIE SIEBEN VORHANDENEN ROLLEN. Die neun
`null`-Seiten tragen jetzt alle sieben Namen. Eine Umkehrung, die
nebenbei Rechte entzieht, waeren zwei Aenderungen in einer -- und man
wuesste hinterher nicht, welche etwas kaputtgemacht hat. Enger stellen
ist ein eigener Schritt.

pruef-rechtetafel.mjs (NEU, 19 Pruefungen, Port 4397) macht daraus eine
Garantie statt einer Absicht:

  * Jede Rolle braucht einen Eintrag -- sonst rot. Man kann eine Rolle
    nicht mehr hinzufuegen, ohne zu entscheiden, was sie sieht.
  * Jede Seite braucht einen Eintrag -- verglichen gegen das
    DATEISYSTEM, nicht gegen eine zweite Liste. Eine neue Seite ist
    damit erst einmal fuer NIEMANDEN offen statt fuer alle.
  * Eine Phantomrolle kommt auf keine der zwanzig Seiten.
  * Gegenprobe: jede ECHTE Rolle kommt irgendwo hin (spicy 18, admin 20,
    manager 17, scout 16, creator 15, hand 13, modi 11) -- sonst waere
    die Zeile darueber auch gruen, wenn schlicht alles zu waere.
  * Am Server: eine Seite ohne Eintrag wird abgewiesen statt
    ausgeliefert, und alle 20 Seiten der DogFather-Rolle liefern wirklich.
  * Zerstoerende Probe ganz am Ende (die Lektion vom 09.09.: in der
    Mitte verbiegt sie alles danach).

ZWEI EIGENE FEHLER UNTERWEGS. `node --check` meldete "Syntax in
Ordnung", das Modul lud aber nicht -- beim Umzug war eine Konstante
verlorengegangen. Syntax ist kein Beweis. Und ein Kommentar behauptete
danach noch das Alte ("eine neue Seite ist mindestens nur fuer
Angemeldete"); der Rueckfall ist jetzt "fuer niemanden", und das steht
da auch so.

Gruen: pruef-rechtetafel 19 (neu), pruef-rollen 287, pruef-sicht 84,
pruef-crew-adresse 129, pruef-modi-verborgen 80, pruef-haus-trennung 62.
Stempel 202609111617.

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

server/workspace.js

@@ -27,6 +27,7 @@ import { dirname, join } from "node:path";
 import { fileURLToPath, pathToFileURL } from "node:url";
 import { mkdirSync } from "node:fs";
 import { createRequire } from "node:module";
+import { darfSeite } from "./rechte.js";
 import { sitzungPasstZurAdresse, istOhneModiAdresse, istCrewAdresse,
   TEAM_DOGI_ROLLEN } from "./crew-adresse.js";
 /* Weitergereicht, damit die Fachmodule sie wie alles andere aus
@@ -3104,169 +3105,20 @@ function sitzungSetzen(res, person, req) {
 
 export const workspaceRouter = express.Router();
 
-/* Schutz der angemeldeten Seiten. Serverseitig, nicht nur im Browser --
-   sonst könnte man die Seite einfach direkt aufrufen. */
-/* Pfad -> erlaubte Rollen. `null` heisst: jede angemeldete Rolle.
+/* DIE ZUGANGSTABELLE STEHT SEIT DEM 11.09.2026 IN rechte.js.
 
-   Die Rolle wird hier mitgeprueft und nicht nur in der Schnittstelle.
-   Sonst bekommt z. B. ein Creator die Verwaltungsseite zwar ausgeliefert
-   (HTTP 200) und sieht ihr Geruest, auch wenn sie danach leer bleibt und
-   das Skript ihn wegschickt. Sichtbar sein soll sie gar nicht. */
-const GESCHUETZT = {
-  "/workspace/start.html": null,
-  "/workspace/uebersicht.html": null,
-  /* AUSDRUECKLICH OHNE 'modi' (10.09.2026). Vorher stand hier `null`
-     ("jede angemeldete Rolle") -- und mit der neuen Rolle hiess das
-     auch: sie. Die Seite laedt dann zwar, ihre Schnittstelle antwortet
-     ihm aber mit 404, weil `content` nicht zu seinen Bereichen gehoert.
-     Eine Seite, die man oeffnen kann und die dann leer bleibt, sieht
-     aus wie ein Fehler -- und ist einer.
+   Sie ist dorthin UMGEZOGEN, nicht kopiert -- samt jeder
+   Begruendung, die hier ueber den Jahren entstanden ist. Zwei
+   Tabellen waeren zwei Wahrheiten, und die zweite haette niemand
+   gepflegt.
 
-     Das ist die Kehrseite von "geschuetzt ist die Regel, nicht die
-     Ausnahme": Eine NEUE ROLLE erbt jedes `null` automatisch. Wer eine
-     Rolle hinzufuegt, muss diese Liste durchgehen -- der Kachel-Durchgang
-     in pruef-rollen findet die Faelle, die dabei auffallen. */
-  "/workspace/content.html": ["spicy", "admin", "manager", "scout", "creator"],
-  "/workspace/aufgaben.html": null,
-  /* Chat (06.09.2026): jede Rolle. WEN man erreicht, entscheidet
-     schreibbareIds() -- nicht der Zugang zur Seite. Ein Creator, der
-     die Seite nicht öffnen dürfte, könnte auch nicht antworten, und
-     genau das Antworten ist der Zweck. */
-  "/workspace/chat.html": null,
-  /* NUR DogFather (07.09.2026). Wunsch Filipe: "nimm die kategorie
-     zahlen bei jedem weg, nur die rolle dogfather soll die sehen."
+   Der Grund fuer den Umzug: `null` hiess "jede angemeldete Rolle",
+   und ein FEHLENDER Eintrag hiess dasselbe. Beides ist jetzt
+   "niemand". Was nicht in der Tafel steht, ist verboten.
+   pruef-rechtetafel.mjs macht daraus eine Garantie: eine Rolle
+   ohne Eintrag und eine Seite ohne Eintrag machen den Prueflauf
+   rot. */
 
-     Bis heute stand hier `null` -- jede Rolle durfte die Seite oeffnen,
-     und WESSEN Zahlen jemand sah, entschied sichtbareCreatorIds().
-     Die Begruendung dafuer war gut (es sind SEINE Zahlen), sie ist
-     jetzt aber nicht mehr meine Entscheidung.
-
-     WICHTIG: Die Kachel wegzunehmen haette NICHT gereicht. Eine Kachel
-     ist ein Weg, keine Schranke -- wer die Adresse kennt oder ein altes
-     Lesezeichen hat, waere weiterhin hineingekommen. Beides gehoert
-     zusammen: bereiche.js zeigt sie nur noch DogFather, diese Zeile
-     laesst nur ihn hinein. */
-  /* JETZT WIEDER FUER ALLE (11.09.2026). Filipe, mit der Kachel im
-     Bild: "jetzt soll jede rolle diese kachel sehen. spicy, dogfather,
-     manager, scout und creator. aber die creator kriegen dan quasi nur
-     ihre daten zu sehen und der manager scout dogfather oder spicy
-     koennen eintragen."
-
-     Die Zeile stand seit dem 07.09.2026 auf ["admin"] -- erst "nimm
-     die kategorie zahlen bei jedem weg", dann die Praezisierung, dass
-     auch Spicy Media sie nicht sieht. Beides ist damit aufgehoben.
-
-     AUSDRUECKLICH ALS LISTE, NICHT ALS `null`. `null` hiesse "jede
-     angemeldete Rolle" -- und damit automatisch auch jede Rolle, die
-     es noch gar nicht gibt. Genau das ist am 10.09. bei content.html
-     schiefgegangen. Hier stehen die fuenf, die Filipe genannt hat.
-
-     WER WAS DARF, steht NICHT hier. Diese Zeile oeffnet nur die Tuer.
-     Dahinter gilt weiterhin: sichtbareCreatorIds() entscheidet, WESSEN
-     Zahlen jemand sieht (ein Creator sieht genau sich selbst), und
-     darfEintragen() entscheidet, wer schreiben darf (Leitung + Scout,
-     also NICHT der Creator). Beides war schon vorher so gebaut und
-     bleibt unangetastet -- es war nur niemand da, der es benutzen
-     konnte. */
-  "/workspace/leistung.html": ["spicy", "admin", "manager", "scout", "creator"],
-  /* NUR DogFather (02.09.2026). Die Rollenauswahl verspricht das seit
-     jeher ("Manager -- dieselben Rechte, ausser der
-     Personenverwaltung"), die Schranke hielt sich nur nicht daran.
-     Wunsch: "die manager sollen diese kategorien garnicht sehen". */
-  /* PERSONEN & ZUGAENGE: jetzt auch fuer Manager und Spicy Media
-     (07.09.2026).
-
-     Filipe: "die manager sehen immer noch nicht die kachel personen &
-     zugangscode, wo sie dan die neuen creator hinzufuegen koennen ...
-     und die sollen in der kategorie wo die jetzt sehen werden auch noch
-     das mit den hinzufuegen sehen, alles andere auf der seite sollen die
-     weiterhin nicht sehen."
-
-     DIE SEITE OEFFNET SICH, DIE SCHNITTSTELLEN NICHT. Das ist der ganze
-     Trick und der Grund, warum das hier ungefaehrlich ist: Alles unter
-     /workspace/api/verwaltung haengt weiterhin an `nurAdmin` -- Rollen
-     aendern, Codes neu setzen, sperren, loeschen, Protokoll lesen
-     bleiben zu und antworten mit 404. Wer die Seite oeffnet, bekommt
-     also genau die Teile zu sehen, fuer die es auch einen Weg gibt.
-
-     Eine Seite ist kein Schutz, sie ist ein Weg. Der Schutz steht in den
-     Schnittstellen, und der ist unveraendert. */
-  /* 'hand' kam am 10.09.2026 dazu. Filipe: "ich will dass die rechte
-     Hand auch alle sieht."
-
-     ES WAR DIE DRITTE SCHICHT, DIE ZUSTIMMEN MUSSTE. Die Kachel stand
-     da, die Schnittstelle liess sie lesen -- und die Seite selbst warf
-     sie auf die Startseite zurueck. Gefunden hat das nicht das Auge,
-     sondern pruef-rollen: Sie geht jede Kachel jeder Rolle ab und
-     schaut, wo man landet ("Rechte Hand Kachel personen.html LANDET
-     AUF start.html").
-
-     Dass die Seite aufgeht, gibt ihr nichts, was die Schnittstellen ihr
-     nicht ohnehin geben: Alles unter /workspace/api/verwaltung ausser
-     der Liste antwortet ihr weiterhin mit 404. Eine Seite ist kein
-     Schutz, sie ist ein Weg. */
-  "/workspace/personen.html": ["spicy", "admin", "manager", "hand"],
-  "/workspace/profil.html": ["spicy", "admin", "manager", "scout", "creator"],
-  /* Der eigene Steckbrief -- jede Rolle hat einen. Ein Creator wird
-     dort nicht hingeschickt (er sieht seinen auf profil.html), darf die
-     Seite aber aufrufen: Sie zeigt ihm dasselbe, nur ohne die Akte. */
-  /* 'modi' kam am 10.09.2026 dazu. Der Steckbrief ist die EIGENE Seite
-     ("Dein Bild und deine Kanäle"); profil.html daneben ist der
-     Entwicklungsplan eines Creators und fuer ihn sinnlos. Der erste
-     Anlauf hatte genau das verwechselt -- die Kachel hiess "Mein
-     Profil" und fuehrte auf eine Seite, deren Schnittstelle mit 404
-     antwortet, weil sie ausdruecklich nur Creator kennt. Gefunden vom
-     neuen Kachel-Durchgang in pruef-rollen. */
-  "/workspace/steckbrief.html": ["spicy", "admin", "manager", "scout", "creator", "hand", "modi"],
-  "/workspace/kalender.html": null,
-  "/workspace/dateien.html": null,
-  /* 'modi' kam am 10.09.2026 dazu -- und es war ein echter Fund: Ohne
-     diese Zeile leiteten VIER seiner Kacheln (Live-Ablauf, Community,
-     Technik, Ideen-Board) wortlos auf die Startseite zurueck. Der
-     Rollen-Rundgang meldete sie trotzdem als "ok": Eine Umleitung ist
-     kein Fehler, die Seite laedt ja -- nur eben eine andere. Seither
-     prueft pruef-rollen fuer JEDE Rolle, dass jede Kachel, die sie
-     bekommt, auch wirklich dort ankommt.
-
-     WELCHE Bereiche ein Modi oeffnen darf, entscheidet die Liste
-     seiner Kacheln (MODI_BEREICHE_ERLAUBT) -- sonst kaeme er ueber die
-     Adresszeile auch in die Agentur-Ablage. */
-  "/workspace/bereich.html": ["spicy", "admin", "manager", "scout", "creator", "hand", "modi"],
-  "/workspace/report.html": ["spicy", "admin", "manager", "scout", "creator"],
-  "/workspace/scouting.html": ["spicy", "admin", "manager", "scout"],
-  /* DIE ARBEITSLAGE DES TEAMS (09.09.2026).
-
-     Filipe: "so eine kategorie wie ueber die creator will ich dass nur
-     fuer die spicy und dogfather rolle auch ueber manager und scouts
-     gibt."
-
-     Nur diese beiden Rollen. Ein Manager sieht seine eigene Zeile hier
-     ausdruecklich NICHT -- das ist kein Versehen: Eine Uebersicht ueber
-     die Arbeit der Kollegen gehoert der Leitung, nicht der Reihe. Der
-     Schutz steht ohnehin in der Schnittstelle (workspace-team.js);
-     diese Zeile sorgt nur dafuer, dass niemand vor einer leeren Seite
-     steht. */
-  "/workspace/team.html": ["spicy", "admin"],
-  "/workspace/calls.html": null,
-  "/workspace/startcheck.html": null,
-  "/workspace/wissen.html": null,
-  /* Ebenfalls nur DogFather: Was von allein passiert, bestimmt, was
-     allen anderen zugeschoben wird. */
-  /* AUTOMATIONEN BLEIBEN BEI DogFather (07.09.2026). Ausdruecklich:
-     "bei automationen sollen die nicht sehen." Dahinter liegen
-     Sicherungen, die KI und der Zustand des Servers -- das ist Betrieb,
-     nicht Betreuung. */
-  "/workspace/automation.html": ["admin"],
-  /* Die gemeinsame Lage des Teams -- nur die DogFather-Rolle, also
-     Filipe und VanVan (10.09.2026). Fuer alle anderen leitet die
-     Schranke auf die Startseite; die Schnittstelle dahinter antwortet
-     zusaetzlich mit 404. Zwei Schloesser, absichtlich: Faellt eines
-     weg, haelt das andere. */
-  /* Der Eingang: DogFather und seine rechte Hand. Blueprint 3.1 --
-     "Kann im Alltag vertretend Entscheidungen treffen." Genau das
-     passiert auf dieser Seite. */
-  "/workspace/teamlage.html": ["admin", "hand"],
-};
 
 /* Die einzige Seite unter /workspace, die offen sein MUSS -- man kann
    sich schlecht anmelden, wenn die Anmeldeseite eine Anmeldung verlangt. */
@@ -3327,10 +3179,19 @@ function schrankenPfad(roh) {
    damit offen ins Netz, ohne dass irgendwo etwas rot wird. Genau diese
    Sorte Fehler faellt erst auf, wenn jemand danach sucht.
 
-   Jetzt gilt: JEDE .html unter /workspace ist geschuetzt, ausser den
-   ausdruecklich offenen. Die Liste oben sagt nur noch, WELCHE ROLLEN
-   zusaetzlich eingeschraenkt sind. Eine neue Seite ist dadurch von
-   selbst mindestens "nur fuer Angemeldete" -- der sichere Rueckfall. */
+   Seit dem 06.09.2026 gilt: JEDE .html unter /workspace ist
+   geschuetzt, ausser den ausdruecklich offenen.
+
+   UND SEIT DEM 11.09.2026 AUCH FUER DIE ROLLE. Bis dahin sagte die
+   Liste nur, welche Rollen ZUSAETZLICH eingeschraenkt sind -- eine
+   neue Seite war damit "nur fuer Angemeldete", also fuer JEDE Rolle.
+   Das war der sichere Rueckfall gegen Fremde, aber keiner gegen eine
+   Rolle, die man gerade erst angelegt hat.
+
+   Jetzt ist der Rueckfall "fuer niemanden". Eine neue Seite ohne
+   Eintrag in rechte.js oeffnet sich fuer keine Rolle, auch nicht fuer
+   DogFather -- und pruef-rechtetafel meldet sie, statt dass man es
+   beim Ausprobieren merkt. */
 workspaceRouter.use((req, res, next) => {
   const pfad = schrankenPfad(req.path);
   if (!pfad.startsWith("/workspace/") || !pfad.endsWith(".html")) return next();
@@ -3338,8 +3199,15 @@ workspaceRouter.use((req, res, next) => {
 
   const person = sitzungLesen(req);
   if (!person) return res.redirect(302, "/workspace/");
-  const erlaubt = GESCHUETZT[pfad];
-  if (erlaubt && !erlaubt.includes(person.rolle)) {
+  /* EIN FEHLENDER EINTRAG HEISST JETZT NEIN.
+
+     Vorher stand hier `if (erlaubt && ...)` -- und `erlaubt` war
+     `undefined`, sobald eine Seite gar nicht in der Tabelle stand.
+     Die Bedingung fiel dann durch, und die Seite war fuer jede
+     angemeldete Rolle offen. Am 11.09.2026 betraf das keine einzige
+     Seite (nachgemessen: 20 in der Tabelle, 2 Zugangswaende, 22
+     Dateien) -- aber jede NEUE waere so entstanden. */
+  if (!darfSeite(person, pfad)) {
     return res.redirect(302, "/workspace/start.html");
   }
   return next();