Die rechte Hand steht ueberall an zweiter Stelle - und im Kalender ueberhaupt

Filipe, mit Bildschirmfoto der Liste "Wen gehst du durch?" (Diene, Dogi,
VanVan - alphabetisch, die rechte Hand ganz rechts): "rechte hand soll
immer als erstes sein. ueberall. wie in dem sinne soll sie ganz links
sein. ausser bei personen und zugaenge soll sie ueber jedem aber unter
dogfather sein. ich will dass auch ueberall immer nach der hirarchie
gearbeitet wird."

EINE REIHENFOLGE, NICHT ZWEI REGELN

ROLLEN_REIHE in workspace.js ist jetzt:
  Spicy Media > DogFather > Rechte Hand > Manager > Scout > Creator > Modi

Er hat zwei Faelle beschrieben, aber es braucht nur eine Reihenfolge: In
den Team-Listen kommt DogFather gar nicht vor (er beurteilt, er wird
nicht beurteilt) - dort steht sie dadurch automatisch ganz vorn. In
"Personen & Zugaenge" steht er drin, also steht sie dort hinter ihm.
Zwei Sonderfaelle waeren zwei Stellen, an denen es auseinanderlaeuft.

Dass Spicy Media davor bleibt, ist seine ausdrueckliche Entscheidung auf
Nachfrage. 'gast' steht bewusst nicht in der Liste und faellt ans Ende.

ROLLEN_SORTIERUNG (der SQL-Ausdruck) wird jetzt aus ROLLEN_REIHE
ABGELEITET statt danebengeschrieben. Bis heute stand die Reihenfolge
zweimal da; beim Hochziehen der rechten Hand haetten beide geaendert
werden muessen. Eine Liste, die niemand pflegt, kann nicht veralten -
derselbe Grundsatz wie beim Spaltenverlust vom 06.09.

WAS DABEI AUFFIEL, OHNE DASS JEMAND DANACH GESUCHT HAT

Der Server sortierte laengst richtig. DREI Auswahllisten im Browser
haben seine Reihenfolge wieder verworfen und nach einer eigenen Liste
mit fuenf Agentur-Rollen neu gezeichnet - Team Dogi kommt darin nicht
vor und DARF es nicht (bereiche.js laedt jeder herunter).

  - Chat-Auswahl und Sicht-Umschalter: Team Dogi landete in einem
    Nachzuegler-Block ganz unten, hinter jedem Creator.
  - Teilnehmerwahl im Kalender: dort gab es nicht einmal einen
    Nachzuegler-Block. Die rechte Hand und die Modis standen GAR NICHT
    zur Auswahl. DogFather konnte sein eigenes Team zu keinem Termin
    einladen, und auf dem Bildschirm sah das vollkommen normal aus.

Das ist derselbe Fehler zum vierten Mal (Chat 10.09., Personenliste
10.09., Sicht-Umschalter 11.09., Kalender 11.09.). Deshalb keine vierte
Einzelreparatur, sondern eine Stelle: window.Bereiche.gruppieren()
gruppiert in genau der Reihenfolge, in der der Server die Menschen
schickt - ohne einen einzigen Rang zu kennen. Fehlt der Helfer, wird
eine Gruppe mit allen gezeichnet: nicht schoen, aber sichtbar, und
niemand verschwindet. Der Kalender-Weg schickt die Ueberschrift jetzt
mit, wie der Chat es laengst tut.

PRUEFUNGEN

  pruef-nachwuchs   109 -> 123 (Abschnitt 12: die Reihenfolge, mit der
                    Gegenprobe, dass sie NICHT alphabetisch ist -- Rieke
                    steht alphabetisch hinten, mit "Anna" waere jede
                    Zeile gruen ohne etwas zu messen)
  pruef-dabei-optik misst die Wahl jetzt im Browser: ist Team Dogi
                    ueberhaupt da, und steht es vorn
  pruef-rollen      315 (vorher 312), 423 s gemessen. Die Notbremse lag
                    bei 480 s und hat angeschlagen - kein Haenger,
                    sondern zu wenig Luft, seit die rechte Hand vier
                    Kacheln mehr hat. Jetzt 900 s, mit der Messung
                    daneben und dem Hinweis, beim naechsten Mal nicht
                    die Zahl zu erhoehen, sondern nachzusehen.

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

server/pruef-rollen.mjs

@@ -49,7 +49,25 @@ await import("./index.js");
    richtig fuer den Betrieb, fatal fuer eine Pruefung. Ohne diese
    Zeile bleibt der Prozess nach einem Fehler ewig stehen, weil der
    Server ihn am Leben haelt (siehe helfer-notbremse.mjs). */
-notbremse(480_000, "pruef-rollen");
+/* DIE FRIST MUSS ZUR ARBEIT PASSEN -- 900 s seit dem 11.09.2026.
+
+   Diese Pruefung besucht JEDE Kachel JEDER Rolle einzeln und wartet
+   dabei auf networkidle. Ihre Dauer haengt also an der Zahl der
+   Kacheln, und die ist heute gewachsen: Die rechte Hand hat vier
+   dazubekommen (Entwicklung, Talente, Wer sieht was, Wie geht es dir).
+
+   Bei 480 s ist der Lauf danach in die Notbremse gelaufen -- mitten im
+   Zaehlen, nichts haing. Gemessen am 11.09.2026 auf diesem Rechner:
+   423 s fuer 315 Pruefungen, also 12 % Luft. Das ist zu knapp; eine
+   Notbremse, die bei normaler Arbeit ausloest, ist keine Notbremse,
+   sondern ein Fehlalarm -- und ein Fehlalarm, der regelmaessig kommt,
+   wird ueberlesen (siehe die Projektnotiz zur Loeschwarnung).
+
+   900 s sind gut das Doppelte der Messung. Wer hier wieder anstoesst,
+   soll NICHT die Zahl erhoehen, sondern zuerst nachsehen, ob der Lauf
+   noch vorankommt: eine Frist, die man dreimal hochsetzt, misst
+   irgendwann gar nichts mehr. */
+notbremse(900_000, "pruef-rollen");
 await new Promise((r) => setTimeout(r, 700));
 const BASIS = "http://127.0.0.1:4193";
 setTimeout(() => { console.log("ABBRUCH"); process.exit(1); }, 540_000).unref?.();