Kalender: was auf den Brettern steht und einen Termin hat

Filipe, zu einer Clip-Karte: "ich will dass die auch in einer kalender
drin sind, aber ich will dass es richtig geil ist und perfektionier das
bitte."

Gemessen vor dem Bau: /workspace/api/termine lieferte `termine` und
`fristen`. Die Zettel von den achtzehn Brettern kamen nirgends vor --
obwohl `eintraege` seit langem VIER Zeitfelder hat: datum, uhrzeit,
geplant, event_ende.

WELCHE HINEINGEHOEREN, IST DIE GANZE FRAGE -- und sie laesst sich
messen statt raten. `datum` ist ein Pflichtfeld und faellt auf HEUTE
zurueck, wenn niemand eins waehlt. Alle Eintraege hineinzukippen hiesse
also: jeder je getippte Zettel steht an dem Tag, an dem ihn jemand
getippt hat. Nach einem Monat waere der Kalender ein Protokoll und kein
Plan -- und ein Kalender, in dem alles steht, sagt nichts mehr.

GEZEIGT WIRD NUR, WOFUER JEMAND EINE ZEIT BESTIMMT HAT:
  geplant        eine Zusage ("Wird gemacht -- am 24.09.")
  event_ende     ein Zeitraum
  uhrzeit        niemand tippt aus Versehen 20:00
  datum > heute  der Rueckfall ist IMMER heute oder frueher
Erledigtes bleibt draussen. Der vierte Fall ist der wichtigste und der
unauffaelligste: kein neues Feld, keine Umgewoehnung.

RECHTE: dieselbe Funktion wie die Bretter selbst (`sichtbarEintrag`),
nicht eine zweite Meinung. Im Kalender steht nur eine kleine Pille mit
einem Titel -- dass darin ein vertrauliches Vorhaben steckt, faellt
niemandem auf, der nicht danach sucht. Genau so kam am 03.09. eine
Managerin an fremde Aufgabenfristen.

DREI FEHLER AM BILDSCHIRMFOTO GEFUNDEN, nicht an einer Zahl:
  1. Der Brettname stand VOR dem Titel -- aus "Clip am Wochenende"
     wurde "Cli...". Das Etikett verdraengte, was es einordnen sollte.
     Jetzt zweite Zeile: Hoehe ist im Monatsraster der billigere Platz.
  2. Am Handy (45px Zellbreite) wurde daraus ein "Co..." -- Hoehe ohne
     Information. Jetzt eine CONTAINER-Abfrage: entschieden wird nach
     der Breite der ZELLE, nicht des Fensters. Eine Fensterschwelle
     waere wieder die Rechnung von gestern (September, Kopfleiste,
     zweimal).
  3. .64rem = 10,24px -- unter der Hausgrenze 11,5px, gefunden von
     pruef-css-klassen. Gedaempft wird jetzt ueber Farbe und Gewicht,
     nicht ueber Groesse.

EIN ECHTER FEHLER VERHINDERT: In der Listenansicht waeren die Zettel im
Termin-Zweig gelandet -- mit Wecker, "erledigt" und "loeschen". Der
Knopf haette PATCH /api/termine/b12 geschickt: eine Nummer, die es dort
nicht gibt, an eine Schnittstelle, die davon nichts weiss. Still, ohne
Wirkung, ohne Meldung.

DER WEG FUEHRT AUF DEN ZETTEL, nicht nur auf das Brett -- ueber
`?zeigen=` (kopf.js), den Weg, den das Haus dafuer schon hat. Zwischen
zwanzig Eintraegen waere der gesuchte sonst von Hand zu suchen.

pruef-kalender: +25 Pruefungen. Sieben Gegenproben, jede zielgenau:
  Schnitt weg            -> 6 rot   Erledigtes rein      -> 6 rot
  Rechteregel ausgehebelt-> 1 rot   COALESCE weg         -> 1 rot
  Termin-Knoepfe an      -> 2 rot   Container-Regel weg  -> 1 rot
  Sprung-Zweig weg       -> 3 rot

UND SIEBEN FESTE ZAHLEN ABGELEITET. Die alten Pruefungen zaehlten
"alle fünf Einträge", "vier Arten", "vier Filter" -- mit den neuen
Testdaten wurden daraus zehn, und sieben Pruefungen je Bildschirmgroesse
wurden rot, ohne dass am Kalender etwas kaputt war. Mit `git stash`
nachgemessen (ohne meine Aenderung: 0 Fehler), also nicht angepasst,
sondern gerechnet: jede Zahl kommt jetzt aus den Testdaten darueber.

Zwei eigene Pruefungsfehler dabei behoben: ein falscher Umschalter-
Selektor liess `every()` auf einem leeren Feld laufen (gruen ohne
Daten), und die Sichtbarkeit der zweiten Zeile wurde ueber
`textContent` gemessen -- das liefert auch, was `display: none`
ausblendet.

Gruen: kalender, sprung, namen, css-klassen, struktur.

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

workspace/assets/css/kalender.css

@@ -1546,3 +1546,86 @@
   .k-schritt { border: 1px solid ButtonText; background: ButtonFace; color: ButtonText; }
   .k-ansicht { border: 1px solid ButtonText; }
 }
+
+/* =====================================================================
+   WAS VOM BRETT KOMMT (17.09.2026)
+
+   Filipe: „ich will dass die auch in einer kalender drin sind, aber ich
+   will dass es richtig geil ist."
+
+   ZWEI ZEILEN, NICHT ZWEI SPALTEN. Der erste Anlauf stellte den
+   Brettnamen neben den Titel -- und das Bildschirmfoto zeigte sofort,
+   dass daraus „CONTENT-IDEEN Cli…" wird. Das Etikett verdraengte genau
+   die Information, die es einordnen sollte.
+
+   Jetzt steht der Titel in seiner Zeile und das Brett darunter, klein
+   und gedaempft. Es beantwortet „was ist das?", ohne dem Titel Platz
+   wegzunehmen.
+   ===================================================================== */
+.k-pille__brett {
+  display: block;
+  margin-top: 1px;
+  /* 11,52 px -- gerade eben ueber der Hausgrenze von 11,5 px.
+     Der erste Anlauf stand auf .64rem (10,24 px) und wurde von
+     pruef-css-klassen gefunden: eine Stelle mehr als die Grundlinie.
+
+     GEDAEMPFT WIRD UEBER FARBE UND GEWICHT, NICHT UEBER GROESSE. Eine
+     Nebenzeile darf leiser sein als der Titel -- sie darf nicht
+     schlechter lesbar sein. Das ist der Unterschied zwischen
+     „zurueckhaltend" und „zusammengekniffen", und die Hausregel
+     „augenschonend" meint genau den. */
+  font-size: .72rem; font-weight: 600;
+  letter-spacing: .01em;
+  /* Gedaempft, aber nicht per `opacity`: Das macht die ganze Zeile
+     durchsichtig, und der Hintergrund des Tages scheint hindurch. Eine
+     leisere FARBE tut dasselbe, ohne die Flaeche anzufassen. */
+  color: color-mix(in srgb, var(--pfarbe, #7f9cc0) 55%, var(--text-still));
+  overflow: hidden; text-overflow: ellipsis; white-space: nowrap;
+}
+
+/* DER HAKEN VOR DEM TITEL -- fuer das, was jemandem zugesagt wurde.
+   Er ist ein Zeichen UND eine Farbe, nicht nur eine Farbe: Eine
+   Rueckmeldung, die allein aus einem Farbwechsel besteht, kommt bei
+   niemandem an, der Farben schlecht unterscheidet. */
+.k-pille__zusage {
+  margin-inline-end: 4px;
+  font-weight: 800;
+  color: color-mix(in srgb, var(--pfarbe, #7f9cc0) 30%, #ffffff);
+}
+
+/* In der Listenansicht steht das Brett ohnehin neben dem Titel
+   (k-zeile__art). Dort waere die zweite Zeile eine Dopplung. */
+.k-zeile .k-pille__brett { display: none; }
+
+/* DIE ZWEITE ZEILE NUR, WO SIE LESBAR IST (17.09.2026).
+
+   Am Handy ist eine Monatszelle rund 45 px breit. Dort wurde aus
+   „Content-Ideen" ein „Co…" -- eine Zeile, die Hoehe kostet und nichts
+   sagt. Am Bildschirmfoto in 390 px sofort zu sehen, an keiner Zahl.
+
+   GEMESSEN STATT GESCHALTET: Entschieden wird nach der Breite der
+   ZELLE, nicht nach der des Fensters. Eine Fensterschwelle waere
+   wieder die Rechnung von gestern -- sie muesste bei jeder Aenderung
+   am Raster nachgezogen werden (und genau das ist im September an der
+   Kopfleiste zweimal schiefgegangen). Eine Zellenabfrage stimmt auch
+   dann noch, wenn das Raster morgen eine Spalte mehr oder weniger hat.
+
+   110 px ist die Breite, ab der ein Brettname mehr als drei Buchstaben
+   zeigt. Darunter steht nur der Titel -- und das Brett weiterhin im
+   Tooltip, in der Listenansicht und im Tagesdialog. */
+.k-tag { container-type: inline-size; }
+
+.k-pille__brett { display: none; }
+@container (min-width: 110px) {
+  .k-pille__brett { display: block; }
+}
+
+/* Ausserhalb einer Zelle -- Wochenspalte, Zeitstrahl -- gibt es keinen
+   Container, und `@container` greift nicht. Dort ist Platz, also steht
+   der Name da. `:not()` ueber den Vorfahren geht in CSS nicht; deshalb
+   die umgekehrte Richtung: erst ueberall aus (oben), dann dort wieder
+   an, wo es passt. */
+.k-wochentag .k-pille__brett,
+.k-strahl .k-pille__brett { display: block; }
+.k-zeile .k-pille__brett { display: none; }
+