Brett und Kalender kennen einander jetzt in beide Richtungen

Der Kalender zeigt seit heute, was auf den Brettern steht und einen
Termin hat. Die Verbindung war aber EINSEITIG, und beide Halften
fehlten:

  Beim SCHREIBEN konnte niemand wissen, dass ein Tag in der Zukunft den
  Zettel in den Kalender bringt. Das Feld heisst "Datum" und ist mit
  HEUTE vorbelegt -- die Funktion war vorhanden und unauffindbar. Eine
  Funktion, die niemand findet, ist keine.

  Beim LESEN sagte die Karte nichts. Am Fuss stand bloss ein Datum, und
  "24.09.2026" sieht aus wie "17.09.2026" -- obwohl das eine ein Termin
  ist und das andere der Tag, an dem jemand getippt hat.

EINE REGEL, ZWEI VERWENDER -> server/workspace-termin-regel.js.
Der Kalender fragt "welche gehoeren hinein?" (SQL, ganze Tabelle), die
Brettkarte fragt "stehe ICH drin?" (JavaScript, je Zeile). Beide Fassungen
stehen jetzt nebeneinander in EINER Datei, importfrei wie
treff-tabellen.js.

Das ist kein Vorsichtsprinzip, sondern Erfahrung: Zwei Fassungen
derselben Regel sind im Haus dreimal auseinandergelaufen -- die
abgeschriebene Spaltenliste (11.09., drei Spalten samt Inhalt weg), die
zweite Artenliste neben ARTNAME (ein BigMatch liess sich anlegen und
war unsichtbar) und `.teilen` heute frueh.

server/pruef-terminregel.mjs, 35 Pruefungen. Der Kern ist Abschnitt 2:
Er prueft die beiden Fassungen GEGENEINANDER, nicht jede fuer sich --
zwei Pruefungen, die je eine Seite bestaetigen, finden genau diesen
Fehler nicht. Verglichen wird beides: WELCHE Zettel und WELCHER Tag.
Neun Faelle, davon vier, die zu Recht wegbleiben.

Vier Gegenproben, jede in ihre eigene Richtung:
  JS laesst mehr durch -> "die Karte behauptet einen Termin, den der
                           Kalender nicht kennt"
  JS nennt anderen Tag -> "verschiedene Tage: Kalender 22., Karte 17."
  SQL laesst mehr durch-> "steht im Kalender, aber die Karte sagt nichts"
  Marke ausgebaut      -> 0 statt 1

EIN ECHTER FEHLER DABEI BEHOBEN, und er war aelter als diese Arbeit:
Das Formularraster gibt jedem Feld GENAU ZWEI Zeilen (Schild dehnbar,
Eingabe fest 44 px) -- deshalb sitzen die Eingaben auf einer Linie. Ein
Hinweisabsatz erzeugt eine dritte Zeile, und weil das Raster alle
Felder auf gleiche Hoehe dehnt, rutscht ausgerechnet diese Eingabe nach
oben. Gemessen: 328..372 gegen 351..395. 23 px -- genau das, was man
als "verzogen" sieht.

Mit `git stash` getrennt: aufgaben.html war dadurch SCHON VORHER rot
(ein anderes Feld hat dort ebenfalls einen Hinweis), bereich.html hatte
ich neu verursacht. Der Hinweis haengt jetzt absolut unter dem Feld --
beide sind gruen, und zwar an der Wurzel, nicht symptomatisch.
`pointer-events: none`, sonst faengt der Satz Klicks ab, die dem
Element darunter galten.

Am Handy gemessen statt geschaetzt: 0 Ueberschneidungen mit anderen
Feldern. Gegenprobe (row-gap auf 2 px): 1 Ueberschneidung.

Und noch zwei eigene Pruefungsfehler behoben, beide von derselben Sorte:
ein falscher Selektor samt `.catch(() => {})`, der den Fehlgriff
lautlos verschluckte (danach war das Hinweisfeld leer und die Zeile
darunter trotzdem gruen, weil "" nun einmal nicht "ja" ist) -- und die
Marke wurde ueber `textContent` gezaehlt statt ueber ihre Sichtbarkeit.
Aufgefallen ist das am Bildschirmfoto, auf dem ich sie fuer fehlend
hielt; deshalb macht die Pruefung jetzt zusaetzlich einen AUSSCHNITT
der Karte -- auf einem Vollbild von 2000 px ist eine Pille von 28 px
nicht zu beurteilen.

Gruen: terminregel, kalender, formulare, ueberlappung, countdown,
namen, css-klassen, struktur.

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

workspace/assets/css/bereich.css

@@ -1327,3 +1327,53 @@
 @media (prefers-reduced-motion: reduce) {
   .tl-brett { transition: none; }
 }
+
+/* =====================================================================
+   „STEHT IM KALENDER" (17.09.2026)
+
+   Die Verbindung zwischen Brett und Kalender war einseitig: Vom
+   Kalender kam man auf das Brett, zurueck nicht. Am Kartenfuss stand
+   bloss ein Datum -- und „24.09.2026" sieht aus wie „17.09.2026",
+   obwohl das eine ein Termin ist und das andere der Tag, an dem
+   jemand getippt hat.
+
+   ES IST EIN LINK UND KEINE MARKE. Wer liest „steht im Kalender", will
+   als Naechstes wissen, was sonst noch an dem Tag ist.
+   ===================================================================== */
+.im-kalender {
+  display: inline-flex; align-items: center; gap: 7px;
+  margin-top: 10px;
+  padding: 5px 11px;
+  border: 1px solid color-mix(in srgb, var(--akzent) 34%, var(--rand));
+  border-radius: 999px;
+  /* Undurchsichtig gemischt, nicht mit `transparent`: Sonst scheint das
+     Wasserzeichen der Seite durch den Text. Am 17.09. genau so an einer
+     vertraulichen Bewerbung aufgefallen. */
+  background: color-mix(in srgb, var(--tinte) 90%, #ffffff 10%);
+  color: var(--text-leise);
+  font-size: .78rem; font-weight: 600;
+  text-decoration: none;
+  transition: border-color .16s ease, color .16s ease;
+}
+.im-kalender:hover { border-color: var(--akzent); color: var(--text); }
+.im-kalender:focus-visible { outline: 2px solid var(--akzent); outline-offset: 2px; }
+
+.im-kalender__zeichen { font-size: .9rem; line-height: 1; }
+
+/* EINE ZUSAGE SIEHT ANDERS AUS ALS EIN EIGENER TERMIN. „Wird gemacht --
+   am 24." ist ein Versprechen an jemanden; ein selbstgesetztes Datum
+   ist eine Notiz an sich selbst. Unterschieden wird ueber das WORT
+   („Zugesagt für") und zusaetzlich ueber den Rand -- eine Auskunft,
+   die nur aus einer Farbe besteht, kommt bei niemandem an, der Farben
+   schlecht unterscheidet. */
+.im-kalender[data-grund="zugesagt"] {
+  border-color: color-mix(in srgb, var(--gut, #79d1a2) 48%, var(--rand));
+  color: color-mix(in srgb, var(--gut, #79d1a2) 30%, #ffffff);
+}
+
+/* Der Hinweis unter dem Datumsfeld. Wenn er „steht damit im Kalender"
+   sagt, darf man das sehen -- sonst liest man ihn nicht. */
+#hinweis-datum[data-imkalender="ja"] {
+  color: color-mix(in srgb, var(--akzent) 42%, #ffffff);
+}
+