12 Commits
Author SHA1 Message Date
DogFatherGitandClaude Opus 5 14d6f5000c Der Titel heisst wieder "Zentrale" -- und gehoert jetzt der Adresse
Filipe: "anstatt irrenanstalt soll da auch Zentrale stehen bitte. auch
getrennt von der team dogi seite da steht was anderes und soll auch so
bleiben."

NACHGEMESSEN, BEVOR ETWAS GEAENDERT WURDE -- und es stand NICHT etwas
anderes. `crewWeiche` biegt fuer das Teamhaus sechs Dinge um (Manifest,
App-Symbole, Zugangswand, Buehnen, Marke, Haus-CSS); `start.html` ist
nicht dabei, und kein Skript hat `#ztitel` je angefasst. Auf BEIDEN
Adressen stand seit dem 22.09.2026 derselbe fest eingebaute Titel.
Verschieden war nur die Zierzeile darueber -- "Spicy Media" gegen
"Team Dogi" --, und die hat vermutlich den Eindruck gemacht.

WAS JETZT GILT
  * In start.html steht "Zentrale". Das ist die Vorgabe und gilt fuer
    das Agenturhaus.
  * Das Wort des Teamhauses kommt vom Server (`titelFuer`, direkt neben
    `markeFuer`, nach demselben Muster). Dort bleibt damit woertlich
    stehen, was vorher dastand -- ab dem 24.09. wird jeder Umbau je
    Haus getrennt gefuehrt, und dies ist der des Agenturhauses. Ob
    Filipe dort etwas anderes will, entscheidet er; geraten wird es
    nicht.

NACH DER ADRESSE UND NICHT NACH DER ROLLE, anders als bei der Marke:
Ein Titel sagt, WO man ist, eine Marke sagt, zu WEM man gehoert. Auch
der Sicht-Umschalter aendert ihn nicht -- wer eine fremde Sicht oeffnet,
wechselt die Zahlen, nicht das Haus.

UND ER STEHT NICHT MEHR IN EINER DATEI, DIE JEDER HERUNTERLAEDT.
Derselbe Grund wie bei MODI_MARKE zwei Zeilen darueber: Was nur das
Teamhaus angeht, gehoert nicht in start.html, die jeder Creator beim
Oeffnen bekommt. Die Schreibweise mit grossem A in der Mitte ist
weiterhin so gewollt und steht jetzt in workspace.js.

GEMESSEN
  * pruef-haus-trennung 97 -> 100 Pruefungen, 0 Fehler. Die drei neuen
    verlangen den UNTERSCHIED, nicht den Wortlaut: auf crew. ein
    eigener Titel vom Server, auf workspace. keiner (dort gilt die
    Seite), und die Zierzeilen sind ebenfalls verschieden. Ein
    Vergleich mit "Zentrale" waere beim naechsten Umbenennen rot, ohne
    dass etwas kaputt ist -- diese Sorte Fehlalarm hatte ich heute
    schon einmal.
  * pruef-start-ansicht 157, pruef-deutsche-texte 12 -- unveraendert.
  * Angesehen bei 1280 px und 390 px: "◆ SPICY MEDIA ◆" darueber,
    "Zentrale" darunter.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-25 00:03:19 +02:00
DogFatherGitandClaude Opus 5 9863645952 Die zwei Häuser sind getrennt -- und die Tür geht in beide Richtungen
Filipe: "ich will dass du zuerst die komplette site vn der workspace
seite trennst. da soll nichts verknüpft sein. wenn ich bei der einen
was mache soll nichts bei der anderen passieren. … es soll nur für
dogfather eine kachel geben wo er mit einem einfachen klick von der
einen auf die anderen seite kommt aber sonst garnichts."

Das kehrt die Entscheidung vom 10.09.2026 um ("getrennt wird das
AUSSEHEN, nicht der Bestand"). Wer den alten Kommentar liest, liest
einen überholten Stand -- das steht jetzt an jeder betroffenen Stelle.

WAS GEMESSEN WAR, BEVOR ETWAS GEBAUT WURDE
  * Nur drei Module trennten nach Haus (Aufgaben, Bereiche, Dateien).
    Chat, Kalender, Wissen, Material, Personenlisten und der Rest nicht.
  * Die Trennung war EINSEITIG: nurHaus() griff nur auf crew.
  * siehtModis() hebelte sie für DogFather auf der Agenturseite aus --
    in seiner Gesprächsliste standen dort beide Häuser nebeneinander.
  * Keine haus-Spalte in der Datenbank.
  * Der Bestand kreuzte aber kaum: 0 von 86 Terminen gemischt, 0 von 7
    Zweier-/Gruppengesprächen, genau EIN Kanal.

WAS JETZT DASTEHT
  * Drei Rollenmengen in crew-adresse.js (crew / agentur / beide) und
    hausVonRolle(); eine unbekannte Rolle bekommt null, kein Haus.
  * Spalte `haus` an acht Wurzeltabellen, nachgetragen aus Belegen:
    238 Zeilen eindeutig, die Wissensablage geschlossen der Agentur,
    vier Restzeilen namentlich, der gemischte Kanal aufgelöst
    (die zwei Scouts gehen heraus, die 7 Nachrichten sind alle vom
    Team). Offen bleiben: null.
  * nurHaus, hausBedingung und darfAnlegen gelten in BEIDE Richtungen.
  * Der siehtModis-Durchgriff ist weg -- aber in DREI Fällen, nicht
    zwei: Prüfadressen bekommen gar kein Haus und verhalten sich exakt
    wie vorher. Die erste Fassung hatte das übersehen und 19 Prüfungen
    umgeworfen, an denen nichts kaputt war.
  * Kalender: getrennt, aber "belegt" bleibt (Filipes Entscheidung).
    Die Blöcke tragen NUR Beginn und Dauer -- kein Titel, keine Person.
    Gebaut als Gegenstück zur Liste (meine Termine MINUS die sichtbaren),
    damit beide nicht auseinanderlaufen können.
  * Die Wissens-Kachel ist auf der Team-Adresse weg UND die Route
    antwortet dort mit 404 -- eine fehlende Kachel ist nur eine Bitte.
  * Die Wechsel-Kachel für DogFather geht jetzt in beide Richtungen.

GEPRÜFT: pruef-haus-trennung 97 statt 81, 0 Fehler (vorher 7, alle
haben die alte Regel behauptet). Die neuen Abschnitte sind DORT
eingezogen statt in eine zweite Datei -- `pruef-haustrennung.mjs` hätte
sich von `pruef-haus-trennung.mjs` um einen Bindestrich unterschieden.
Dazu grün: haus-seiten, crew-adresse, chat, chat-kanaele,
kanal-besetzung, kalender, serien, treffchat, wissen-neu,
modi-checkliste, modi-katalog, rechtetafel, personen-liste, sicht,
verborgen, fremde-sicht, alle-wege.

NICHT VON MIR: pruef-treff (3) und pruef-kachel-universum (2) waren
schon vorher rot -- beim Treff auf dem Stand 40b48e89 nachgemessen,
bei den Farben steht dieselbe Zahl im Kopf der Prüfung selbst.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-24 20:40:20 +02:00
DogFatherGit 82335c783d Die rechte Hand legt selbst Personen an -- und sieht die Codes
Filipe: "dan will ich dass die rechte hand auch neue personen
hinzufuegen kann. also neue erstellen kann und die codes genau so
sieht wie dogfather, damit sie das auch machen kann wenn er live ist."

WAS SIE DARF: Modis und Community anlegen, und deren Codes neu setzen.
Die Liste ist ABGELEITET aus ROLLEN_ZUM_AENDERN -- dieselben zwei
Rollen, die sie ohnehin vergeben darf. Zwei Listen waeren zwei
Gelegenheiten, eine davon zu aendern und die andere zu vergessen.

WAS SIE NICHT DARF: eine zweite rechte Hand, eine linke Hand oder
einen zweiten DogFather anlegen -- und an einer linken Hand auch
nichts aendern. Ohne die zweite Schranke haette sie den Code einer
linken Hand neu setzen koennen und damit einen Zugang in der Hand, der
fast so viel darf wie sie selbst. Die alte Schranke kannte nur "admin"
und "manager".

NUR DIE RECHTE, NICHT DIE LINKE. `istHand()` haette beide getroffen;
fuer die linke Hand ist "legt niemanden an" eine ausdrueckliche
Entscheidung vom 21.09.

VIER STELLEN IN DER OBERFLAECHE, die alle an Rollennamen hingen:

  `nurLesen = ich.rolle === 'hand'` -- sie bekam die Liste und kein
  Formular. Jetzt abgeleitet aus `darf_anlegen`.

  Die Wache darueber warf sie auf die Startseite, sobald `nurLesen`
  falsch wurde. Die Seite ging fuer sie einfach nicht auf, ohne
  Meldung.

  Der Sendeweg hing an `ich.rolle === 'admin'`. Fuer sie gab es damit
  GAR KEINEN: Die Seite antwortete "Fuer die Rolle modi gibt es hier
  keinen Weg" -- ein Satz, der wie ein Formularfehler klingt und eine
  fehlende Zeile war.

  UND EIN ECHTER FUND: `rollenwahlErgaenzen()` hing jede Zusatzrolle an
  das Formular, die mit der Personenliste kam -- ohne zu fragen, ob man
  sie anlegen darf. Solange nur DogFather das Formular sah, fiel es
  nicht auf: Er darf sie alle. Der rechten Hand bot es "rechte Hand"
  und "linke Hand" an. Der Server haette es abgelehnt -- aber der Knopf
  verriet eine Rolle, die sie nicht vergeben soll.

Zwei Pruefungen waren dabei selbst kaputt: pruef-personen-formular
erwartete sieben Rollen (seit "linke" am 21.09. sind es acht) und
suchte den Namen im sichtbaren Text -- die Abschnitte sind zugeklappt
und zeigen nur Anfangsbuchstaben. Beides abgeleitet statt gezaehlt.

Geprueft: pruef-personen-formular 43/0 (war 34 ok / 2 FEHL), davon
neun am echten Bildschirm auf der Crew-Adresse -- anmelden, Formular
oeffnen, anlegen, Code lesen, Person in der Liste wiederfinden.
pruef-haus-trennung 81/0 (war 72 ok / 2 FEHL), pruef-rollen-anlegen
11/0.
2026-09-22 01:39:12 +02:00
DogFatherGitandClaude Opus 5 8a214ecd0e Keine Mischung mehr -- Team Dogi nur noch bei Team Dogi
Filipe: "ich will dass du im workspace alles von team dogi weg nimmst.
nur was ich im kalender eintrage soll ich im workspace sehen und im
team dogi. aber die kacheln von team dogi soll ich nur bei team dogi
sehen und die von workspace nur bei workspace bitte. ich will keine
mischung mehr von kacheln. wie gesagt nur die der kalender soll
verbunden sein von dogfather sonst nichts."

GEMESSEN, WIE SCHLIMM ES WAR: Auf der Agenturadresse bekam DogFather
0 eigene Kacheln ueber die Schnittstelle und 17 fremde -- Dein Team,
Ideen-Board, Rueckmeldung, Wer sieht was, Entwicklung, Werdegang,
Talente und den ganzen Treff samt Moderation. Zwei Betriebe auf einer
Seite.

Das Bittere daran: Dieselbe Datei hatte den Fehler fuer die ANDERE
Richtung am 10.09. schon erkannt und behoben ("Fuenfundzwanzig
Kacheln, von denen zwei Drittel Creator, Scouts und Agentur betreffen,
waeren dort Fenster in ein Haus, in dem er gerade nicht ist"). Nur
andersherum stand es weiter so.

DIE AUSNAHME BRAUCHTE NICHTS: Nachgemessen filtern die Terminabfragen
in workspace-kalender.js NICHT nach Haus. Was er eintraegt, steht
ohnehin auf beiden Adressen. Die Verbindung, die er will, existierte
schon -- sie musste nur nicht zerschnitten werden.

STATT SIEBZEHN BRETTERN STEHT DORT EINE TUER. Ohne sie waere von der
Agenturadresse aus kein Weg mehr zu Team Dogi sichtbar; er muesste die
Adresse tippen. Das ist die Sorte Sackgasse, die dieses Haus nicht
baut. Eine Tuer ist keine Mischung: Sie zeigt kein Brett, sie geht
hinueber. Und sie kommt vom Server, nur fuer `admin` -- in keiner
ausgelieferten Datei steht sie.

MEIN ERSTER ENTWURF GAB SIE AUCH DER RECHTEN HAND UND DER MODERATION.
pruef-modi-checkliste hat es sofort gemeldet: "Modi bekommt 1
Zusatzkachel(n), erwartet keine". Wer NUR zu Team Dogi gehoert, hat
auf der Agenturadresse nichts zu suchen -- die Tuer waere dort seine
einzige Kachel gewesen, also eine Seite, die aus nichts als einem
Ausgang besteht.

VIER PRUEFUNGEN VERLANGTEN DANACH DIE ALTE WELT. Keine davon war ein
Mangel; alle vier haben am falschen Ort gesucht:

  pruef-haus-trennung  verlangte woertlich, dass die Team-Kachel AUCH
     auf der Agenturadresse steht. Sie prueft jetzt die Trennung in
     beide Richtungen -- kein Brett von Team Dogi drueben, aber die
     eine Tuer -- und leitet die Namen aus der Antwort von crew. ab,
     statt sie abzuschreiben.
  pruef-start-ansicht  zaehlte acht Gruppennamen in fester
     Reihenfolge. Gemeint war eine Ordnung ("die Community steht ganz
     unten, denn dort stehen Namen und Saetze von Zuschauern"), und
     die wird jetzt als Regel geprueft -- bedingt, mit drittem Ausgang
     auf Adressen, wo es diese Gruppen gar nicht gibt.
  pruef-treff und pruef-rueckmeldung fragten ueber die Agenturadresse
     nach Brettern, die dort nicht mehr stehen. Sie fragen jetzt dort,
     wo diese Bretter zuhause sind.

EINE HALBE STUNDE WAERE DABEI FAST VERLOREN GEGANGEN: `fetch` kann den
Host-Kopf nicht setzen -- er ist ein verbotener Kopfzeilenname und
wird STILLSCHWEIGEND verworfen. Die Anmeldung ueber die Crew-Wand
genuegt nicht; jede einzelne Abfrage braucht die Adresse. Deshalb geht
die Messung jetzt ueber http.request, so wie es `anmelden()` in
derselben Datei laengst tut.

pruef-haus-trennung 74/0 · pruef-modi-checkliste 75/0 · pruef-treff
72/0 · pruef-rueckmeldung 30/0 · pruef-start-ansicht 153/0 ·
pruef-haus-seiten 34/0 · pruef-entwicklung 46/0 · pruef-befinden
113/0 · pruef-rechte-umstellen 46/0

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-21 14:00:14 +02:00
DogFatherGitandClaude Opus 5 67a0eb8717 DogFather konnte einen zweiten DogFather nicht mehr herabstufen
Gefunden beim Durchsehen der schnellen Pruefungen: pruef-haus-trennung
stand auf 60 ok / 6 Fehler. Drei Ursachen, eine davon ein echter
Rueckschritt von gestern.

--- 1. DER RUECKSCHRITT ---------------------------------------------

In darfRolleAendern stand seit gestern:

  if (person.rolle === "admin") return ziel.rolle !== "admin";

Das macht aus "DogFather ist nicht mehr VERGEBBAR" ein "an einem
DogFather ist nichts mehr zu aendern". Ein zweiter Zugang liess sich
damit nie wieder zuruecksetzen -- er waere fuer immer DogFather
geblieben. Die Pruefung sagte es woertlich: "solange es zwei gibt,
darf einer wechseln (403)".

Die beiden echten Gefahren haengen woanders und bleiben unberuehrt:
Niemand KANN 'admin' vergeben, und der LETZTE DogFather laesst sich
nicht herabstufen.

--- 2. ZWEI SCHLOESSER FUER DIESELBE TUER ---------------------------

Ich hatte gestern `rollenZumAendern` mit 403 VOR die vorhandene
Pruefung gesetzt, die mit 400 "Unbekannte Rolle." antwortet. Damit war
die Luecke wieder offen, vor der der Kommentar vom 17.09. direkt
daneben warnt: Zwei verschiedene Antworten -- "gibt es nicht" gegen
"darfst du nicht" -- verraten beim Durchprobieren, WELCHE Rollen
existieren.

Jetzt eine Regel an einer Stelle. `darfAnlegen` ist dort raus, weil
Vergeben und Anlegen seit gestern verschiedene Dinge sind. Gemessen:

  admin   anlegen = aendern (sieben Rollen)
  spicy   anlegen = aendern (vier)
  hand    anlegen = —        aendern = modi, gast
  manager anlegen = creator  aendern = —

Und die eigene Zeile bekommt jetzt 400 mit einem Satz statt 403:
Es ist keine Rechtefrage, sondern eine unsinnige Bitte.

--- 3. DREI ERWARTUNGEN, DIE AELTER WAREN ALS DIE REGEL --------------

Die Pruefung verlangte 403, wo seit dem 17.09. 400 richtig ist --
ihre Zeile stammt vom 10.09., sieben Tage aelter als die Regel. Und
sie verlangte 404 fuer "die rechte Hand vergibt keine Rolle", was bis
vorgestern stimmte.

Dabei fiel auf, dass NICHTS geprueft hat, ob die rechte Hand ihre neue
Faehigkeit ueberhaupt ausueben kann -- nur, dass sie es nicht darf.
Eine Pruefung, die nur das Verbotene misst, laesst offen, ob das
Erlaubte geht. Jetzt beide Richtungen:

  an einer anderen rechten Hand aendert sie nichts (403)
  und an DogFather erst recht nicht (403)
  einen Modi macht sie sehr wohl zur Community (200)
  und es steht so in der Datenbank (gast)
  eine zweite rechte Hand ernennt sie nicht (400)

Nebenbei: `unbekannte_kachel` (gestern eingefuehrt) hatte keinen Satz
in meldung.js -- die Kennung waere woertlich auf dem Bildschirm
gelandet. pruef-meldungen hatte es gemeldet.

Und ein Absturz beim Bauen: `const anlegen = await hole(...)` weiter
unten im selben Block verdeckt die gleichnamige Funktion im GANZEN
Block, auch oberhalb seiner eigenen Zeile.

pruef-haus-trennung: 70 ok, 0 Fehler (vorher 60/6).
Dazu gruen: rollen-anlegen 11/0, personen-loeschen 40/0,
rechte-umstellen 46/0, verteilen 11/0, meldungen 8/0.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-20 23:13:27 +02:00
DogFatherGitandClaude Opus 5 6e46a08543 Portnummern werden abgeleitet, nicht mehr vergeben
Gemessen: 165 Pruefdateien, 129 verschiedene Nummern -- NEUNZEHN
doppelt, vier davon dreifach. Niemand hatte das gewollt; jede neue
Pruefung wurde von einer vorhandenen abgeschrieben, und die Nummer kam
mit. Meine eigene Notiz sagte "sieben" -- auch eine Bestandsliste
altert.

Der Waechter faengt den Schaden ab, aber er kann nur melden, was schon
passiert ist: Zwei Pruefungen mit derselben Nummer koennen nie
gleichzeitig laufen, und ein liegengebliebener Prozess der einen laesst
die andere abbrechen mit einer Meldung, die wie ein Befund aussieht.
Genau das ist mir am 20.09. zweimal passiert.

Jetzt leitet jede Datei ihre Nummer aus ihrer STELLE IM ALPHABET ab
(eigenerPort in helfer-port.mjs), zwei je Datei. Nicht ueber eine
Pruefsumme: Bei 165 Namen in 4900 Nummern waeren nach dem
Geburtstagsproblem rund DREI Zusammenstoesse zu erwarten -- ein Hash
tauscht eine sichtbare Doppelung gegen eine unsichtbare. Die Stelle im
Alphabet ist eindeutig von der Bauart her.

--- ZWEI FEHLER AUF DEM WEG, BEIDE LEHRREICH -------------------------

1. DER ERSTE VERSUCH WAR GRUEN UND KAPUTT. Ersetzt wurde mit einem
   Muster: "([^"]*4231[^"]*)". Das hielt

     { host: "127.0.0.1", port: 4231, path: "/404.html" }

   fuer eine Zeichenkette -- ein Muster kann eine oeffnende nicht von
   einer schliessenden Anfuehrung unterscheiden. Heraus kam

     { host: "127.0.0.1`, port: ${PORT}, path: `/404.html" }

   also GUELTIGER Code ohne port-Feld. `node --check` sagte gruen fuer
   alle 164 Dateien. Aufgefallen ist es erst, weil ich vier Vertreter
   gegen eine vorher gemessene Grundlinie laufen liess: pruef-schranke
   39/0 vorher, 38/1 nachher.

   Alles zurueckgenommen und mit einem Zerleger neu gemacht, der weiss,
   ob eine Stelle Code, Zeichenkette, Vorlage, Kommentar oder
   regulaerer Ausdruck ist. In pruef-ics stand die Nummer in einem
   regulaeren Ausdruck -- der wird jetzt gebaut statt hingeschrieben.

2. EIN MODUL, DAS BEIM IMPORTIEREN ARBEITET, IST EINE FALLE. Der
   zweite Durchgang importierte den ersten, um seine Mechanik zu
   benutzen -- und fuehrte dessen Hauptlauf gleich mit aus. Die
   zweiten Nummern wurden dadurch als erste behandelt, zwei Aufrufe
   bekamen dieselbe Nummer, und in pruef-content stand `const PORT`
   zweimal.

--- WAS DAS DAUERHAFT HAELT -----------------------------------------

pruef-portnummern.mjs (neu, 8 Pruefungen) fragt nicht "welche Nummern
sind doppelt", sondern "wer traegt ueberhaupt noch eine von Hand ein"
und "wer startet einen Server, ohne seine Nummer abzuleiten". Die
zweite Frage hat sofort etwas gefunden, das in KEINER Doppelungsliste
stand: pruef-push-weg belegte 4341 und 4342, rief den Waechter aber
gar nicht auf -- dieselbe Nummer wie pruef-agentur. Eine Liste zeigt
nur, was auf ihr steht.

Mit Gegenprobe: Eine unbekannte Datei bekommt keine geratene Nummer,
sondern einen Abbruch, und eine dritte Nummer je Datei gibt es nicht.

--- NACHGEMESSEN ----------------------------------------------------

Sechzehn Pruefungen gegen ihre vorher gemessene Grundlinie, je eine
Vertreterin jeder umgestellten Bauweise (eine Nummer, zwei Nummern,
Nummer in einer Zeichenkette, in einer Vorlage, in einem regulaeren
Ausdruck, dynamische Einfuhr, Nachtlauf mit zwei Laeufen):

  crew-adresse 132/0 · schranke 39/0 · content 45/0 · entwicklung 46/0
  anruf 127/0 · ics 37/0 · push-weg 20/0 · arten 28/0 · video 67/0
  kanalzeile 14/0 · agentur 62/0 · spicy 83/0 · creator-anlegen 50/0
  push-ziel 10/0 · portnummern 8/0

Alle exakt wie vorher. Zwei waren schon vorher rot und sind es
unveraendert geblieben (crew-wand-bild 41/4, teilen 14/3) -- per
`git stash` belegt, nicht angenommen.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-20 22:51:21 +02:00
DogFatherGitandClaude Opus 5 0207b05da6 Die Rechte Hand steht ueber den Modis -- sortiert statt geschrieben
Filipe, mit dem Bildschirmfoto: "rechte hand soll immer ueber modi
stehen bitte."

DIE REIHENFOLGE STAND AN ZWEI STELLEN, und die zweite war falsch
herum: ROLLEN_REIHE hatte die Rechte Hand laengst vor den Modis (und
die SQL-Sortierung leitet sich daraus ab) -- aber `zusatzrollen` in
workspace-personen.js schrieb sie von Hand, und dort kam Modi zuerst.
Genau diese Liste baut die Abschnitte auf der Personenseite und die
zusaetzlichen Knoepfe im Anlegen-Formular.

Das ist an diesem Tag das VIERTE Mal dieselbe Sache: eine Aussage,
zwei Listen, und die zweite ist die, die abweicht. Vorher: der
Zeitraum-Schutz (an einer von drei Stellen), die Dauer-Einheit
(dieselbe), das Recht zum Aufloesen (Liste kannte es, Nachrichtenweg
nicht).

Deshalb wird jetzt SORTIERT und nicht geschrieben: Die Liste geht durch
ROLLEN_REIHE. Wer die Reihenfolge aendern will, aendert sie dort --
und alles andere zieht nach, statt nachgezogen werden zu muessen. Was
in ROLLEN_REIHE nicht vorkommt (heute "gast"/Community), wandert ans
Ende statt stillschweigend nach vorn.

pruef-haus-trennung 63 -> 66. GEPRUEFT WIRD DIE REIHENFOLGE, NICHT DIE
ANWESENHEIT: "beide sind da" waere auch dann gruen gewesen, wenn sie
vertauscht sind -- und genau das war der Fall. Dazu eine Zeile, die
nachweist, dass die Reihenfolge wirklich aus ROLLEN_REIHE kommt und
nicht nur zufaellig stimmt; sonst haette jemand sie auch von Hand
andersherum schreiben koennen: richtig im Ergebnis, falsch im Aufbau,
und beim naechsten Mal wieder auseinander.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-14 14:28:06 +02:00
DogFatherGitandClaude Opus 5 e3aeeb01cd Rollen wechseln: auch Spicy Media -- und DogFather ist nicht mehr vergebbar
Filipe: "ich will dass die rolle spicy und dogfather, auch die rollen
wechseln koennen wenn die personen schon drin sind. von alle
kategorien, creator, scouts, manager spicy. dogfather soll man nicht
auswaehlen koennen. das ist die einzige die man nicht auswaehlen kann
bitte."

ZWEI AENDERUNGEN, BEIDE IN EINER LISTE (ANLEGBAR):
  admin: alles AUSSER der eigenen Rolle
  spicy: spicy, manager, scout, creator   (vorher ohne spicy)

Weil die Oberflaeche ihre Knoepfe aus derselben Auskunft baut
(`darf_anlegen` in /api/ich), verschwindet DogFather damit von selbst
aus JEDER Auswahl -- beim Anlegen wie beim Wechseln, bei Spicy Media
wie bei DogFather. Eine Liste, zwei Formulare, kein Nachziehen.

WAS DAS BEDEUTET, damit es niemand spaeter sucht: Es laesst sich kein
zweiter DogFather-Zugang mehr anlegen und niemand mehr zu einem
befoerdern. Der bestehende ist durch Sicherung 3 geschuetzt (nie den
letzten herabstufen) und kann nicht versehentlich verschwinden.
Zurueckdrehen laesst sich das nur in ANLEGBAR.

DIE TUER: /verwaltung haengt an nurAdmin, und dort steht jetzt eine
DRITTE enge Ausnahme -- PUT auf genau /personen/<Ziffern>/rolle, fuer
genau die Rollen aus darfRollenWechseln(). Gleiche Bauweise wie die
beiden davor (Liste fuer Spicy Media, Liste fuer die rechte Hand). Was
NICHT mitgeht: Codes, Sperren, Loeschen, Zuteilung, Protokoll.

EINE NEUE SICHERUNG, weil sich die Tuer geoeffnet hat: An einer
DogFather-Zeile aendert nur DogFather. Die bestehenden Pruefungen sehen
auf die ZIEL-Rolle ("darfst du 'manager' vergeben?") -- dass die
BETROFFENE Person DogFather ist, kam darin bis heute nicht vor.
Sicherung 3 haette es heute zufaellig abgefangen, weil es genau einen
gibt; eine Sperre, die nur wegen einer Zahl im Bestand haelt, ist
keine.

DIE OBERFLAECHE: "Rolle aendern" und "Loeschen" hingen an EINER Zeile
(`ich.rolle === 'admin'`). Sie gehoeren nicht zusammen -- Loeschen
bleibt bei DogFather. Und die CSS-Regel, die fuer Spicy Media die ganze
Knopfreihe ausblendete, ist weg: Welche Knoepfe es gibt, entscheidet
jetzt personen.js, und was nicht entsteht, muss man nicht verstecken.

pruef-spicy 62 -> 83. Gemessen wird jede der vier Kategorien EINZELN
(waere nur eine offen, saehe "geht" genauso aus), dazu: admin weder von
Spicy Media noch von DogFather vergebbar, an DogFathers Zeile aendert
sie nichts (und er ist danach nachweislich noch admin), ein Manager
kommt an den Weg nicht, loeschen bleibt zu -- und im Browser, dass der
KNOPF da ist, nicht nur das Recht. Genau daran war heute frueh im Chat
eine Stunde draufgegangen.

Dabei zwei eigene Messfehler gefunden: Die Knoepfe entstehen erst in
einer AUFGEKLAPPTEN Kategorie (vorher zu frueh gemessen), und /api/ich
wird jetzt als Vorbedingung geprueft.

DREI PRUEFUNGEN GEDREHT, KEINE GELOESCHT:
- pruef-personen-formular: 7 Karten, `admin` fehlt (eigene Aussage).
  Die Zeichenpruefung verglich die rechte Hand gegen die Admin-KARTE --
  die es nicht mehr gibt; sie lief gegen `undefined`. Ersatz ist das
  Zeichen selbst, und der Kommentar sagt, dass das schwaecher ist.
- pruef-haus-trennung: Der zweite DogFather entsteht jetzt im Bestand
  statt ueber die Schnittstelle, und DASS die Schnittstelle ihn
  ablehnt, ist der erste Prueffall geworden. Sonst waere "nie den
  letzten DogFather" ab heute ungeprueft -- weil ihre Voraussetzung
  schwerer herzustellen ist.
- pruef-creator-anlegen: aus einer Aussage zwei (die vier sind da UND
  admin fehlt).

Gruen: personen-liste, personen-kachel, verborgen, manager-sicht,
creator-anlegen, haus-trennung, personen-formular, spicy, rollen.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-12 00:25:47 +02:00
DogFatherGitandClaude Opus 5 bea1bb7194 Die rechte Hand meldet wie das Team, die Leiste wird ein Universum, sein Kalender bleibt ganz
Drei Wuensche aus zwei Bildschirmfotos und einem Satz.

=== 1. SIE DARF SAGEN, WAS PASST UND WAS NICHT ===

Filipe: "die rechte hand soll bei diesen aufgaben auch wie die modis
sagen koennen ob es passt oder nicht ... die rechte hand ist da um mir
zu helfen aber auch wie die modis um mir zu sagen was passt und nicht
wo die denken bedarf oder nicht. perfektionier das alles."

SIE KONNTE ES NICHT, UND ZWAR AN DREI STELLEN GLEICHZEITIG -- die
zweite und dritte kamen erst zum Vorschein, nachdem die erste behoben
war. Genau deshalb steht "perfektionier das alles" ueber diesem Commit
und nicht "eine Zeile geaendert":

  ERSTENS: Die Frage "an wessen Liste arbeitest du?" kannte nur Creator
  und Modis (dann die eigene). Sie fiel durch beide Zweige und konnte
  ueberall antworten, nirgends urteilen.

  ZWEITENS: Nach der Reparatur durfte sie -- und bekam den KATALOG DER
  CREATOR. Ihre Meldung trug einen Schluessel, den der Eingang gar
  nicht kennt, und wurde dort stillschweigend uebersprungen. Die
  Pruefung meldete "sie darf urteilen (200)" und eine Zeile spaeter
  "ihre Meldung steht NICHT in DogFathers Eingang". Beides stimmte.

  DRITTENS: Der Eingang sammelt aus der Liste der Teammitglieder, und
  die hiess `rolle = 'modi'`. Sie war die Empfaengerin dieser Seite und
  kam auf ihr selbst nicht vor. Wer nicht in der Liste steht, kann
  melden, so viel er will -- es erreicht niemanden.

Jetzt steht sie in derselben Liste (aber `id <> ich`: eine Karte ueber
sich selbst ist kein Ueberblick, sondern ein Spiegel), bekommt
denselben Beobachtungskatalog wie die Modis und meldet in denselben
Eingang. Alle Rollenvergleiche kommen dabei aus der vorhandenen Menge
TEAM_DOGI_ROLLEN statt als zwei Vergleiche danebengeschrieben -- sonst
steht dort beim naechsten Mal einer zu wenig.

=== 2. DIE LEISTE ===

Filipe: "der hintergrund dieser leiste soll extrem speziell aussehen
wie ein universum und soll von lila auf babyblau wechseln, von links
nach rechts ... der husky links soll auch babyblau strahlen und nicht
rot und der rechts lila. dan brauch ich auch noch einen teilen button."

DIE RICHTUNG IST DIE EIGENTLICHE AENDERUNG: Der Schein lief von UNTEN
nach oben (die Glut der Agenturseite, nur in Lila). Jetzt von LINKS
nach rechts, mit zwei Nebeln und sieben Sternen -- als Verlaufslagen
und nicht als Elemente: Sieben Punkte waeren sieben Knoten im Baum auf
jeder der zwanzig Seiten, nur fuer Zierde.

DIE ZEICHEN TAUSCHEN DIE SEITEN. Links stand ein warmes Rot, fest
hingeschrieben in start.css; rechts strahlte der zweite Husky babyblau.
Jetzt umgekehrt -- so hat jede Seite der Leiste beide Farben, statt
dass jede nur eine hat. Beim rechten wird die FUELLUNG mitgetauscht,
nicht nur der Schein: Ein lila Schein um ein blaues Zeichen waere ein
Rand, keine Farbe.

"UEBERTRIEBEN GEIL" HAT EINE GRENZE, und sie ist gemessen, nicht
geschaetzt. Erster Anlauf: .30 -- der Verlauf war zu ahnen, nicht zu
sehen, Kontrast 5,26:1. Zweiter: .40 -- sichtbar, aber 4,79:1 in der
Mitte, bei einer Grenze von 4,5 zu knapp. Jetzt kraeftige Enden und
eine zurueckhaltende Mitte: 5,92 / 5,26 / 7,06:1 an drei Stellen des
Verlaufs, gemessen an echten Bildpunkten. Die Farbe liest das Auge an
den Enden; in der Mitte gewinnt die Lesbarkeit.

DER TEILEN-KNOPF fehlte, weil `DARF_TEILEN` Leitung und Scouts kennt --
die rechte Hand ist keins von beidem. Gefragt wird jetzt nicht nach der
Rolle, sondern nach `ich.marke`: Die setzt der Server genau dann, wenn
jemand zu Team Dogi gehoert. Der Rollenname bleibt damit aus einer
Datei heraus, die jeder herunterlaedt -- und die Frage lautet ohnehin
"gehoert diese Person hierher?".

=== 3. SEIN KALENDER BLEIBT GANZ ===

Filipe: "mein kalender (dogfather) auf dieser seite hier soll komplett
verbunden sein mit dem kalender in der workspace seite ABER NUR IN DER
DOGFATHER ROLLE BEI DOGFATHER: NICHT BEI VANVAN."

Bei Aufgaben, Bereichen und Dateien ist die Haustrennung eine Hilfe --
man will das andere Haus dort gerade nicht sehen. Beim Kalender waere
sie eine Falle: Wer auf der Team-Seite einen Termin eintraegt und die
Haelfte seines Tages nicht sieht, legt ihn auf eine Zeit, in der er
schon woanders sitzt. Ein Kalender, der nur die halbe Wahrheit zeigt,
ist schlimmer als keiner.

Geprueft wird die ROLLE und nicht der Name -- ein Name waere die
Stelle, an der es beim naechsten Menschen bricht.

=== WAS DIE PRUEFUNGEN GEZEIGT HABEN ===

Eine Erwartung war seit Stunden stumm rot: pruef-modi-checkliste
verlangte GENAU EINE Zusatzkachel, und seit dem Ideen-Board sind es
drei. Ich hatte sie nach der Aenderung nicht noch einmal laufen lassen.
Sie zaehlt jetzt nicht mehr auf eine feste Zahl, sondern prueft die
AUSSAGE: Wer welche bekommen soll, bekommt welche -- und jede gehoert
in die Gruppe "Team Dogi". Eine Pruefung, die bei jeder neuen Kachel
rot wird, erzieht dazu, ihr Rotwerden zu ignorieren.

Zwei weitere Erwartungen haben sich gedreht und sind im Quelltext
begruendet: Der Kalender auf crew. zeigt DogFather jetzt alles (die
Pruefung unterscheidet dafuer ER-ja/SIE-nein statt einer einzelnen
Antwort -- das ist mehr, nicht weniger), und "aus dem Eingang
verschwunden" fragt jetzt nach Schluessel UND Person: Seit die rechte
Hand denselben Katalog benutzt, koennen zwei Menschen denselben Punkt
melden, und die Pruefung meldete einen Fehler, den es nicht gab.

Und eine war wertlos: "die rechte Hand sieht den Agenturtermin nicht"
lief gegen einen leeren Kalender -- sie sah ueberhaupt nichts. Sie hat
jetzt zwei eigene Termine, einen aus jedem Haus; erst damit sagt die
Messung etwas.

pruef-modi-checkliste 59 -> 70 · pruef-team-stufen 24 -> 26 ·
pruef-team-ampel 32 · pruef-haus-trennung 61 -> 62 · pruef-rollen 278 ·
pruef-css-klassen gruen · pruef-modi-wortleck 5.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-11 00:51:56 +02:00
DogFatherGitandClaude Opus 5 da7ddf7b5e Alle Kategorien in der Personenliste -- und die rechte Hand liest mit
Filipe, mit Bildschirmfoto der Team-Seite: "ich muss alle kategorien da
sehen. und ich will dass die rechte hand auch alle sieht."

AUF DEM BILD STAND EIN EINZIGER ABSCHNITT: DogFather. VanVan war in
derselben Minute zur rechten Hand geworden (im Protokoll darunter zu
sehen: "#4 VanVan: admin -> hand") -- und damit aus der Liste
VERSCHWUNDEN.

Nicht aus der Antwort des Servers. Der schickte sie die ganze Zeit mit.
`assets/js/personen.js` gruppiert nach einer Liste mit fuenf Rollen, und
wer dort nicht steht, wurde nicht gezeichnet: kein Fehler, keine
Luecke, kein Hinweis. Dieselbe stille Lücke wie vorgestern in der
Personenauswahl des Chats, an einer anderen Stelle -- und dieselbe
Ursache: Die Namen der verborgenen Rollen duerfen in keiner
ausgelieferten Datei stehen, also kannte der Browser sie nicht.

DIE LOESUNG IST DIESELBE: Der Server schickt die Ueberschriften mit
(`zusatzrollen` -- es gab sie schon, sie waren bisher nur die Auswahl
beim Anlegen). Der Browser braucht dafuer keinen Rollennamen zu kennen,
er bekommt einen Text.

UND DARUNTER EIN AUFFANGBECKEN, das ist der eigentliche Fortschritt:
Kaeme morgen eine siebte Rolle und niemand daechte an diese Stelle,
stuenden ihre Leute trotzdem auf der Seite -- unter ihrem Rollennamen,
sichtbar, statt lautlos zu fehlen. Ein Abschnitt mit einer unschoenen
Ueberschrift ist tausendmal besser als ein Mensch, den es auf dem
Bildschirm nicht gibt.

DIE RECHTE HAND LIEST MIT -- LESEND. Das ist sein eigenes Wort
("sieht"): Codes, Sperren, Loeschen, Rollen vergeben und das Protokoll
bleiben bei DogFather. Die Ausnahme im Server ist Wort fuer Wort so
gebaut wie die, die Spicy Media schon hat: eine Methode, eine Adresse,
eine Rolle. Zwei Fassungen derselben Ausnahme waeren zwei Regeln, und
die zweite laesst irgendwann mehr durch als gedacht.

DREI SCHICHTEN MUSSTEN ZUSTIMMEN, und die dritte hatte ich uebersehen:
die Kachel, die Schnittstelle -- und die SEITE selbst. In der
Rollentabelle in workspace.js stand personen.html fuer spicy, admin und
manager; die rechte Hand flog von der Seite auf die Startseite zurueck,
obwohl Kachel und Daten schon stimmten.

Gefunden hat das nicht das Auge, sondern pruef-rollen. Sie geht jede
Kachel jeder Rolle ab und schaut nach, wo man landet: "Rechte Hand
Kachel personen.html LANDET AUF start.html". Das ist der Wert dieser
Pruefung -- der Fehler war unsichtbar, solange man nicht selbst als
rechte Hand auf die Kachel drueckt.

EINE ERWARTUNG HAT SICH GEDREHT, und das steht jetzt im Quelltext:
pruef-haus-trennung verlangte vor einer Stunde noch, dass die Kachel
bei ihr NICHT steht und die Seite sie abweist -- richtig, solange sie
die Seite nicht durfte. Die Pruefung ist dadurch nicht schwaecher
geworden: Sie verlangt weiterhin, dass Kachel und Zugang DASSELBE
sagen. Sie sagen jetzt beide ja statt beide nein.

DIE NEUE MESSUNG VERGLEICHT ZAHL GEGEN ZAHL: wie viele Menschen der
Server liefert, wie viele Zeilen auf dem Bildschirm stehen. Nicht
"steht VanVan da" -- das waere ein Name, den man beim naechsten Umbau
so lange anpasst, bis die Pruefung wieder passt. Eine Pruefung, die nur
die Antwort des Servers ansieht, waere hier uebrigens gruen gewesen.

Beim Schreiben dieser Messung ist sie zuerst viermal falsch
angeschlagen: Die Abschnitte stehen zugeklappt da, und zugeklappt sind
ihre Zeilen gar nicht im Dokument. Vier Fehler, die es nicht gab -- die
Pruefung klappt jetzt erst auf, dann liest sie.

pruef-personen-formular 27 -> 35 · pruef-haus-trennung 53 -> 61 ·
pruef-rollen 277 -> 278 · pruef-modi-verborgen 80 · pruef-start-ansicht
143 · pruef-css-klassen gruen · pruef-modi-wortleck 5.

ANMERKUNG ZUR TEAM-ADRESSE: Dort zeigt die Liste weiterhin nur Team
Dogi -- so, wie er es eine Stunde vorher verlangt hat ("bitte nur
basiert auf diese seite"). "Alle Kategorien" heisst also: alle des
Teams. Wenn er dort auch die Agentur sehen will, ist das eine Zeile,
aber es waere eine andere Entscheidung.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-11 00:11:36 +02:00
DogFatherGitandClaude Opus 5 670ce4a5c1 Personen & Zugaenge auf der Team-Seite -- und eine Rolle laesst sich endlich aendern
Filipe wollte VanVan die Rolle "Rechte Hand" geben. Auf die Frage nach
ihrem Code: "die kategorie personen & zugaenge fehlt also muss das
hinzugefuegt werden und bitte nur basiert auf diese seite."

BEIM NACHSEHEN KAMEN ZWEI DINGE HERAUS, und das zweite war das
eigentliche:

  Die Kachel fehlte, weil ich sie mit den Agenturkacheln entfernt hatte
  -- ausgerechnet die, mit der man jemandem eine Rolle gibt. Die
  Team-Adresse war damit eine Seite, auf der man das Team nicht
  verwalten kann.

  UND ES GAB DIE FUNKTION GAR NICHT. Im ganzen Server aendert keine
  einzige Stelle `personen.rolle`. Anlegen ja, sperren ja, loeschen ja
  -- aendern nirgends, seit dem ersten Tag. Wer jemandem eine andere
  Aufgabe geben wollte, musste ihn loeschen und neu anlegen, und daran
  haengen seine Aufgaben, seine Nachrichten, seine Eintraege, sein
  ganzer Verlauf. Kapitel 4 des Pflichtenhefts verlangt ausdruecklich
  das Gegenteil.

  (Nebenbefund aus derselben Messung, ihm gemeldet: Auf dem Server gibt
  es KEINE Rolle 'hand'. VanVan ist ein zweiter DogFather-Zugang. Die
  Rueckmeldungen mit "nur an DogFather" wuerde sie deshalb heute
  mitlesen -- die Regel fragt "ist das DogFather?", und ihre Rolle
  antwortet ja.)

DIE KACHEL traegt Namen, Zeichen und Farbton der Agenturseite. Es ist
dieselbe Seite mit demselben Zweck; ein zweiter Name dafuer waere ein
zweites Ding, das es nicht gibt.

SIE STEHT NUR DORT, WO SIE AUCH FUNKTIONIERT. Die Personenseite haengt
serverseitig an `nurAdmin`. In der Kachelliste der rechten Hand haette
sie auf eine 404 gefuehrt -- ein Knopf, der eine Absage bringt, ist
schlimmer als kein Knopf. Wenn sie das duerfen soll, ist das eine
eigene Entscheidung und gehoert an dieselbe Stelle wie nurAdmin.

"NUR BASIERT AUF DIESE SEITE" steht nicht in der Kachel, sondern im
Server: Auf crew. liefert die Liste nur Team Dogi, und angelegt werden
koennen nur Team-Rollen. Beides kommt aus Funktionen, die es schon gab
(hausBedingung, darfAnlegen) -- und `darfAnlegen` baut auch die Knoepfe
in der Oberflaeche, weshalb die anderen Rollen dort von selbst
verschwinden statt eine Absage zu bringen.

DER ROLLENWECHSEL HAT FUENF SICHERUNGEN, und jede hat ihren Grund:

  NUR DOGFATHER -- wer Rollen vergeben kann, kann sich selbst zum
  DogFather machen.

  NIE DIE EIGENE. Wer sich selbst herabstuft, sperrt sich aus; die
  Funktion zum Zurueckdrehen haengt an der Rolle, die er gerade
  abgegeben hat. Das ist keine Warnung wert, das ist eine Tuer, die
  zubleibt.

  NIE DEN LETZTEN AKTIVEN DOGFATHER. Gezaehlt werden die AKTIVEN: Ein
  gesperrter kann niemanden hereinlassen, ihn mitzuzaehlen waere eine
  Sicherung, die sich selbst beluegt.

  ALLE SITZUNGEN DIESER PERSON ENDEN. Eine Sitzung gehoert seit dem
  10.09.2026 zu einer ADRESSE, und welche das ist, entscheidet die
  Rolle. Wer eben noch DogFather war und jetzt rechte Hand ist, saesse
  sonst mit einer Sitzung da, die auf der Agenturadresse laeuft und
  dort nicht mehr hingehoert -- ein halb gueltiger Zustand, der erst
  beim naechsten Klick auffaellt.

  DER CODE BLEIBT. Er haengt am Menschen, nicht an der Rolle. Ihn
  mitzutauschen waere bequem und falsch: Dann muesste jede
  Rollenaenderung von einem Gespraech begleitet sein, und wer das
  vergisst, sperrt jemanden aus, ohne es zu merken.

Und es steht im Protokoll, mit beiden Rollen im Klartext.

DIE AUSWAHL IM BROWSER wird nicht noch einmal gebaut, sondern aus dem
Anlege-Formular gelesen. Dort stehen genau die Rollen, die der Server
dieser Person zugesteht -- einschliesslich derer, die in keiner
ausgelieferten Datei stehen duerfen und erst nachtraeglich dazukommen.
Eine zweite Liste waere die, in der eine Rolle fehlt oder eine zu viel
steht, und beides faellt erst auf, wenn jemand sie braucht.

EINE PRUEFUNG WAR WERTLOS UND IST ES NICHT MEHR: "ihre Sitzungen sind
beendet" lief gegen einen leeren Bestand -- ein gruener Haken ueber
einer Null. Jetzt meldet sich die Person vorher an, und die Zahl davor
muss groesser als null sein.

pruef-haus-trennung 32 -> 53 · pruef-rollen 277 · pruef-personen-formular
27 · pruef-css-klassen 30 · pruef-start-ansicht 143 ·
pruef-modi-verborgen 78 · pruef-modi-wortleck 5.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-10 23:47:13 +02:00
DogFatherGitandClaude Opus 5 9c99a5b9c3 Zwei Haeuser auf einer Datenbank -- die Team-Adresse zeigt nur das Team
Filipe, mit Bildschirmfoto der Zentrale: "die daten von dieser seite
sollen nichts mit den daten am hut haben von der workspace seite bitte,
die hier soll ihre eigene daten haben und komplett von der anderen
getrennt sein. dogfather soll die daten auch auf der anderen seite
sehen in der team dogi kategorie aber auch nur er und vanvan."

GETRENNT WIRD DER AUSSCHNITT, NICHT DER BESTAND. Eine zweite Datenbank
haette den zweiten Satz unmoeglich gemacht -- er will dieselben Daten
auf beiden Adressen sehen. Es bleibt also alles an einem Ort, und die
ADRESSE entscheidet, welcher Ausschnitt davon herauskommt.

ALLES HAENGT AN EINEM WERT: `person.haus`, gesetzt in sitzungLesen()
aus dem Hostnamen. Von dort reist er mit der Person durch jede
Sichtbarkeitsregel im Haus. Der Grund ist ein praktischer: Die Regeln
bekommen ueberall dieselbe Person gereicht -- sichtbar(person),
sichtbareCreatorIds(person), bereicheFuer(person). Ein zusaetzliches
Argument haette an ueber dreissig Aufrufstellen mitgeschleift werden
muessen, und die eine vergessene waere das Loch gewesen.

RECHTE AENDERT ES NICHT. Es entscheidet, WAS jemand sieht, nicht, was
er darf -- wie die Sicht eines anderen (sichtPerson) das auch nicht tut.

DER FILTER IST DER SPIEGEL EINES VORHANDENEN. Es gab schon
`ohneTeamDogi` ("alles ausser dem Team") fuer Spicy Media. Dazu kommt
jetzt `ohneAgentur` -- gleiche Bauweise, andere Rollenmenge, GEMEINSAME
Implementierung. In der steckt die NULL-Falle (`IS NULL OR NOT IN`,
denn `NULL NOT IN (...)` ist weder wahr noch falsch), und die sieht man
einer Abschrift nicht an.

WARUM NICHT "MINDESTENS EINE SPALTE ZEIGT AUF TEAM DOGI": Das waere die
naheliegende Formulierung und sie waere falsch. Eine Aufgabe, die
DogFather fuer einen Creator anlegt, haette ueber `erstellt_von` (er
gehoert zum Haus) trotzdem gepasst und stuende auf der Team-Seite.
Andersherum stimmt es: Sobald IRGENDEINE Spalte auf Creator, Scout,
Manager oder Spicy Media zeigt, gehoert die Zeile ins andere Haus.

VIER TUEREN, EINE FORM. Aufgaben, Bereiche, Dateien und der Kalender
haben je eine eigene sichtbar()-Funktion. Alle vier bekommen dieselbe
Bedingung an derselben Stelle, in derselben Schreibweise -- damit keine
davon anders aussieht als die anderen. Beim Kalender steht sie in
termineSichtbar() in workspace.js und nicht im Kalendermodul: Sonst
haetten Termine, Wiederholungen und der ICS-Abruf sie einzeln
gebraucht, und der ICS-Abruf ist der, den man vergisst -- er laeuft
ohne Bildschirm.

ZWEI ABFRAGEN GEHEN ABSICHTLICH NICHT DURCH DIE LISTENFUNKTIONEN, und
genau die standen im Bildschirmfoto: der Ring der Zentrale ("9 IM
TEAM", obwohl das Team drei Leute hat -- gezaehlt wurde das ganze Haus)
und die Hinweiszeile darunter ("Creator-Profile sind noch leer"). Im
Quelltext der Zentrale steht sogar ausdruecklich, dass sie die einzige
solche Stelle ist; gefunden habe ich sie trotzdem erst, weil ich der
Zahl im Bild nachgegangen bin. Beide bekommen die Bedingung jetzt aus
derselben Funktion (`hausBedingung`), nicht aus einer zweiten
Rollenliste.

Die Hinweis-Bedingung sitzt am BLOCK und nicht an den vier Abfragen
darin: Wer eine fuenfte hinzufuegt, bekommt sie dadurch mit, ohne daran
zu denken.

DIE KACHELN: Auf crew. liefert der Server dieselbe Liste wie der
rechten Hand -- nicht eine dritte. Fuenfundzwanzig Kacheln, von denen
zwei Drittel Creator und Agentur betreffen, waeren dort Fenster in ein
Haus, in dem er gerade nicht ist, und hinter jedem stuende seit heute
eine leere Liste. Auf workspace. bleibt alles, wie es war: Dort schickt
der Server weiterhin `bereiche: null` ("nimm die Liste aus der Datei").

JEDE MESSUNG STEHT ZWEIMAL DA. Die Trennung kann auf zwei Arten falsch
sein: Sie greift nicht (dann steht die Agentur weiter auf der
Team-Seite, und niemand merkt es, weil alles funktioniert), oder sie
greift zu weit (dann verschwindet auf der Agenturseite etwas -- der
gefaehrlichere Fall, denn eine zu kurze Liste sieht aus wie "nichts zu
tun"). Deshalb folgt auf jede Messung auf crew. dieselbe Messung auf
workspace., mit DERSELBEN Sitzung; der einzige Unterschied ist der
Host-Kopf. Dazu zwei Gegenproben zur Regel selbst: 127.0.0.1 bleibt
unberuehrt (sonst waeren alle Pruefungen im Haus stillschweigend blind
geworden), und eine erfundene Adresse oeffnet kein drittes Haus.

NEBENBEI ZWEI EIGENE FEHLER BEHOBEN: pruef-chat-kanaele und
pruef-rueckmeldung liefen auf Ports, die schon vergeben waren (4359
neben pruef-modi-verborgen, 4371 neben pruef-crew-adresse). Beide sind
umgezogen. Fuenf weitere Doppelungen zwischen fremden Pruefdateien
(4186, 4188, 4189, 4193, 4198) bleiben stehen und sind gemeldet -- an
Dateien zu greifen, an denen gerade eine zweite Sitzung arbeitet, waere
genau der Fehler, den diese Doppelungen ohnehin schon zeigen.

pruef-haus-trennung 32 (neu) · pruef-rollen 277 · pruef-modi-verborgen
78 · pruef-chat gruen · pruef-rueckmeldung 30 · pruef-modi-ideen 30 ·
pruef-crew-adresse 129 · pruef-start-ansicht gruen ·
pruef-zwischenspeicher 21 · pruef-modi-wortleck 5.

BERICHTIGUNG zum vorigen Commit: Dort steht "pruef-rueckmeldung 34".
Es sind 30. Ich hatte die Zeilen geschaetzt statt sie zu lesen.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-10 23:24:34 +02:00