Profilfotos im Chat, rechte Hand zuerst, Karten lesbar

---- SCREEN 9: DIE FOTOS -------------------------------------------

Filipe: "da soll man im chat auch die profilfotos von den leuten sehen
wenn die schon eins drin haben."

ZWEI Luecken, beide an Stellen, wo ein Feld weggeworfen wurde:

1. Die GESPRAECHSLISTE bekam kein Bild. `teilnehmerVon` liest es aus
   der Datenbank, die Detailansicht nimmt es mit -- die Zeile fuer die
   Liste warf es weg. Folge: im offenen Gespraech ein Gesicht, in der
   Liste daneben ein Buchstabe. Vom selben Menschen.

2. Eine FRISCH GESENDETE Nachricht trug kein Bild. Der Verlauf beim
   Laden schon. Folge: Wer gerade zusieht, bekommt einen Buchstaben;
   wer neu laedt, ein Gesicht -- der Unterschied haengt nur daran, wann
   man geschaut hat.

Der Buchstabe bleibt als Unterlage LIEGEN und wird nicht ersetzt: Laedt
das Bild nicht, steht dort weiterhin etwas Sinnvolles statt eines
kaputten Bildsymbols. Vier Stellen, ein Verhalten.

---- SCREEN 3: REIHENFOLGE UND AUSSEHEN ----------------------------

Filipe: "ich will dass hier wie ueberall die reihenfolge immer rechte
hand und dan erst die modis."

Die Abfrage sortierte nach `aktiv DESC, name` -- die ROLLE wurde nicht
einmal mitgelesen. Die Seite konnte gar nicht wissen, wer rechte Hand
ist; sie sortierte alphabetisch, und damit stand Diene vor Funny, weil
D vor F kommt. Jetzt mit ROLLEN_SORTIERUNG -- derselben Regel, die auch
Personenliste, Chat und Rechtetafel benutzen.

"die kiste von rechte hand soll auch noch vieeeeeel krasser und
spezieller aussehen ... der hintergrund von den kacheln soll auch viel
krasser und geiler sein und so dass man texte und so besser erkennt.
weil gerade ist es schwer lesbar."

ZUERST DAS LESEN: Der Grund fuer die schlechte Lesbarkeit war der
durchscheinende Untergrund -- die Karten lagen auf dem Buehnenbild, und
ein Foto wird stellenweise hell. Sie bekommen jetzt eine DECKENDE
Unterlage und erst darueber die Verlaeufe. Die Verlaeufe sieht man
weiterhin, nur nicht mehr das Bild dahinter.

DANN DAS BESONDERE: Die rechte Hand bekommt einen goldenen Ton, eine
deutlich hellere Kante und eine schmale Leiste an der linken Seite --
man sieht den Rang aus zwei Metern, ohne ein Wort zu lesen. KEIN
zweiter Bauplan: dieselbe Karte, dieselben Felder, nur ein Merkmal am
Element. Zwei Karten zu bauen hiesse, jede kuenftige Aenderung zweimal
zu machen.

---- EINE PRUEFUNG, DIE EINE POSITION FESTNAGELTE ------------------

`ok(leute[0]?.id === idMarina, "die Aktiven stehen oben")` wurde rot,
sobald die rechte Hand nach vorn sortierte. Richtig wurde sie dadurch
nicht: Die Aussage "die Aktiven stehen oben" hat mit Marinas Platz
nichts zu tun. Jetzt prueft sie die EIGENSCHAFT (keine Pause vor einer
Aktiven) -- eine Pruefung, die eine Position festnagelt, verbietet jede
Umsortierung, auch die gewollte.

GEPRUEFT: pruef-team-stufen 28/0 (zwei Aussagen mehr),
pruef-erwaehnung 69/0 (zwei mehr: das Bild kommt in der Liste an, und
wer keines hat, bekommt auch keines vorgegaukelt), pruef-css-klassen.

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

server/workspace-chat.js

@@ -160,6 +160,20 @@ function istDrin(raumId, person) {
    wurde damit zu Programmtext, und die Datei liess sich nicht mehr
    lesen. Ein Kommentar, der die Zeichenkette schliesst, in der er
    steht. */
+/** Der Weg zum Profilbild dieser Person -- oder null.
+ *
+ *  ALS EIGENE FUNKTION, weil die Zeile
+ *  `bild ? "/workspace/api/steckbrief/bild/" + bild : null`
+ *  sonst an drei Stellen steht. Die dritte Abschrift ist die, die
+ *  den Pfad falsch schreibt, und ein kaputter Bildpfad sieht aus wie
+ *  "die Person hat halt kein Bild". */
+function bildWegFuer(personId) {
+  try {
+    const z = db().prepare("SELECT bild FROM personen WHERE id = ?").get(personId);
+    return z?.bild ? `/workspace/api/steckbrief/bild/${z.bild}` : null;
+  } catch { return null; }
+}
+
 function teilnehmerVon(raumId) {
   return db().prepare(`
     SELECT t.person_id AS id, p.name, p.rolle, p.bild, t.leitung, t.gelesen_bis
@@ -545,7 +559,18 @@ chatRouter.get("/workspace/api/chat/raeume", (req, res) => {
            Stellen steht; genau daran ist es beim ersten Anlauf
            gescheitert. */
         darf_aufloesen: darfAufloesen(r, req.person),
-        teilnehmer: leute.map((t) => ({ id: t.id, name: t.name, rolle: t.rolle })),
+        /* DAS BILD GEHOERT DAZU (20.09.2026).
+
+           Filipe: "da soll man im chat auch die profilfotos von den
+           leuten sehen wenn die schon eins drin haben."
+
+           Es fehlte genau hier: `teilnehmerVon` liest das Bild aus der
+           Datenbank, und diese Zeile warf es weg. Die Detailansicht
+           weiter unten nimmt es mit -- die LISTE nicht. Deshalb stand
+           im offenen Gespraech ein Gesicht und in der Liste daneben ein
+           Buchstabe, vom selben Menschen. */
+        teilnehmer: leute.map((t) => ({ id: t.id, name: t.name, rolle: t.rolle,
+          bild: t.bild })),
         letzte: letzte ? {
           /* Ein Anhang ohne Begleittext hätte hier eine leere Zeile
              hinterlassen. "Foto"/"PDF" ist die Vorschau, die man in
@@ -1061,6 +1086,13 @@ chatRouter.post("/workspace/api/chat/raeume/:id/nachrichten", gleicheHerkunft,
 
       const nachricht = {
         id, raum_id: raumId, von_id: req.person.id, von: req.person.name,
+        /* DAS BILD MUSS MIT (20.09.2026). Der Verlauf beim Laden bringt
+           `von_bild` mit -- diese Nachricht hier nicht, und sie ist die,
+           die per Ereignisstrom bei allen anderen ankommt. Folge: Wer
+           gerade zusieht, bekommt einen Buchstaben; wer die Seite neu
+           laedt, ein Gesicht. Derselbe Mensch, zwei Darstellungen, und
+           der Unterschied haengt nur daran, wann man geschaut hat. */
+        von_bild: bildWegFuer(req.person.id),
         rolle: req.person.rolle, text, erstellt: n, zurueckgenommen: false,
         antwort: zitat ? {
           id: antwortAuf, von: zitat.von || "Gelöscht",