Der vertrauliche Meldeweg vergisst jetzt -- und sagt, bis wann

Zwei Entscheidungen, die offenstanden. Beide getroffen, nachdem
gemessen war, was wirklich da ist.

1. WIE LANGE BLEIBEN ABGESCHLOSSENE FAELLE?  90 Tage.

Die Entscheidung war bereits getroffen: `AUFBEWAHRUNG_TAGE = 90` steht
seit dem 19.09. in hilfe-tabellen.js, mit Begruendung ("ein Fall kommt
manchmal wieder auf"). Nur hat sie NIEMAND durchgesetzt --
`hilfeAufraeumen()` gab es, und der einzige Aufrufer war ihre eigene
Pruefung. Der Kommentar darueber behauptete "Wird beim Start
aufgerufen (siehe index.js)"; das war nie wahr.

Jetzt steht die Regel in workspace-aufbewahrung.js, dem Loeschkonzept,
das sich selbst durchsetzt -- beim Start und danach taeglich. Die
zweite Fassung in workspace-hilfe.js ist WEG, nicht doppelt: Zwei
DELETEs auf dieselben Daten waeren morgen verschieden, und der
Unterschied fiele erst auf, wenn er zaehlt.

GEMESSEN VOR DEM EINSCHALTEN:
  In der echten Datenbank steht heute KEIN einziger Fall. Der erste
    Lauf loescht nichts, und der erste Fall kann fruehestens in drei
    Monaten 90 Tage alt werden. Jetzt einschalten ist frei -- spaeter
    waere es der riskante Moment gewesen.
  PRAGMA foreign_keys steht im Dienst auf 1, und hilfe_nachrichten
    traegt ON DELETE CASCADE. An einem echten Fall mit Nachricht
    nachgemessen: vorher 1/1, nachher 0/0. Ohne diese Messung waere
    der Fall verschwunden und der eigentliche Text liegengeblieben.

2. SOLL EIN GESCHLOSSENER FALL WIEDER ZU OEFFNEN SEIN?  Nein.

Im Kopf von workspace-hilfe.js steht: "EIN GESCHLOSSENER FALL IST
GESCHLOSSEN. Auch fuer die Leitung -- sonst ist 'zugemacht' eine
Meinung und keine Tatsache." Das ist eine gute Regel, und sie bleibt.

Nachgemessen, dass sie auch traegt: Ein Melder kann seinen
geschlossenen Fall weiter LESEN, und ein geschlossener Fall zaehlt
nicht gegen das Limit von drei offenen. Wer eine Wiederholung melden
will, kann das also jederzeit -- die Bauweise ist stimmig.

NUR WUSSTE DAS NIEMAND. Dort stand ein Satz: "Dieser Fall ist
abgeschlossen (Datum)." Jetzt stehen drei -- und sie beantworten die
drei Fragen, die man in dem Moment hat:
  Kann ich noch schreiben?   Nein, und er laesst sich nicht oeffnen.
  Bleibt das hier stehen?    Bis zum TT.MM.JJJJ, dann geloescht.
  Und wenn es wieder passiert? Neu melden, der alte zaehlt nicht mit.

Das Datum kommt vom Server (`lesbar_bis`), die Frist ebenso -- sie
steht nur an EINER Stelle. Und sie steht jetzt auch im Dialog BEIM
Schliessen: Wer eine Uhr startet, soll das vorher wissen, nicht
danach.

OHNE UHRZEIT, und das ist kein Schoenheitsgrund: Ein Fall, der am
20.09. um 14:04 (Sommerzeit) geschlossen wird, verfaellt 90 Tage
spaeter um 13:04 -- die Uhr wird dazwischen zurueckgestellt. Richtig
gerechnet, sieht aus wie ein Fehler. Wer eine Stunde sucht, die es
nicht gibt, hat Zeit verloren.

UND DIE URSACHE, DAMIT ES NICHT WIEDER PASSIERT:
hilfe_faelle kam am 19.09. dazu, das Loeschkonzept ist vom 15.09., und
nichts hat die beiden je verglichen. Neue Pruefung in
pruef-aufbewahrung: Jede Tabelle mit einer Spalte, die "hier ist etwas
zu Ende" sagt, MUSS im Konzept stehen.
  Kein "jede Tabelle muss drinstehen": 46 Tabellen, 41 mit
  Personenbezug -- das gaebe 38 Meldungen, von denen fast alle falsch
  waeren (sie sind ueber personen_geloescht gedeckt). Eine Pruefung,
  die 38-mal meldet, wo einmal richtig waere, wird abgeschaltet.
  Gesucht wird das schmale Merkmal: GENAU ZWEI Tabellen im Haus tragen
  so eine Spalte. Beide jetzt im Konzept -- hilfe_faelle mit Frist,
  aufgaben ausdruecklich OHNE (erledigte Aufgaben sind
  Arbeitsdokumentation, keine Meldung ueber einen Menschen).

pruef-hilfe 84/0 (war 59) -- darunter zehn neue am Bildschirm:
"drei Saetze statt einem", "sie stehen untereinander, nicht
nebeneinander" (ein <p> in einem <p> waere ungueltig, der Container
ist jetzt ein <div>), "und WANN, mit Datum".
pruef-aufbewahrung 45/0 (war 41), mit Gegenprobe.

server/workspace-aufbewahrung.js

@@ -38,6 +38,11 @@
    ===================================================================== */
 
 import express from "express";
+/* Die Frist steht dort, wo auch die Begruendung steht -- in
+   `hilfe-tabellen.js`. Sie hier ein zweites Mal hinzuschreiben hiesse
+   zwei Wahrheiten, von denen eine veraltet. `hilfe-tabellen.js`
+   importiert absichtlich nichts, es kann also kein Kreis entstehen. */
+import { AUFBEWAHRUNG_TAGE as HILFE_TAGE, FALL_STAND } from "./hilfe-tabellen.js";
 import {
   db, sitzungLesen, istDogFather, protokolliere, echteIp,
   einstellung, einstellungSetzen,
@@ -92,6 +97,62 @@ function zaehle(d, sql, ...werte) {
    DIE TAFEL
    ===================================================================== */
 export const FRISTEN = [
+  {
+    /* =================================================================
+       DER VERTRAULICHE MELDEWEG (nachgetragen am 20.09.2026)
+
+       DIESE TABELLE FEHLTE HIER -- und das ist der teuerste Eintrag,
+       den man vergessen kann: In `hilfe_nachrichten` stehen die
+       empfindlichsten Texte des ganzen Hauses. Jemand beschreibt ein
+       Problem, oft mit anderen Menschen darin.
+
+       Die Frist selbst war nie strittig: `AUFBEWAHRUNG_TAGE = 90`
+       steht seit dem 19.09. in `hilfe-tabellen.js`, mit Begruendung.
+       Und `hilfeAufraeumen()` gab es auch. Nur hat sie NIEMAND
+       aufgerufen: Gesucht im ganzen Verzeichnis war der einzige
+       Aufrufer ihre eigene Pruefung. Der Kommentar darueber behauptete
+       „Wird beim Start aufgerufen (siehe index.js)" -- das war nie
+       wahr. Die Pruefung war gruen und bewies nichts ueber den
+       Betrieb.
+
+       Jetzt steht es hier, wo es sich selbst durchsetzt: Diese Datei
+       ist beides -- die Uebersicht, was wie lange aufgehoben wird, UND
+       das Programm, das es tut. Nebenbei taucht der Meldeweg damit in
+       der Auskunft auf (Art. 15 DSGVO), und das gehoert sich: Wer
+       gemeldet hat, darf erfahren, wie lange das noch gespeichert ist.
+
+       GEMESSEN VOR DEM EINSCHALTEN: In der echten Datenbank steht
+       heute KEIN einziger Fall. Der erste Lauf loescht also nichts,
+       und der erste Fall kann fruehestens in drei Monaten 90 Tage alt
+       werden. Einschalten ist jetzt frei -- spaeter waere es der
+       riskante Moment gewesen.
+
+       DIE NACHRICHTEN GEHEN MIT: `hilfe_nachrichten.fall_id` traegt
+       `ON DELETE CASCADE`, und `PRAGMA foreign_keys` steht im Dienst
+       auf 1. Beides nachgemessen an einem echten Fall mit Nachricht:
+       vorher 1/1, nachher 0/0. Ohne diese Messung waere der Fall
+       verschwunden und der eigentliche Text liegengeblieben. */
+    schluessel: "hilfe_geschlossen",
+    was: "Abgeschlossene vertrauliche Meldungen samt Verlauf",
+    art: "raeumen",
+    frist: `${HILFE_TAGE} Tage nach dem Abschluss`,
+    zweck: "Ein abgeschlossener Fall kommt manchmal wieder auf "
+      + "(oft Monate spaeter) – dann muss man nachlesen "
+      + "können, was damals vereinbart wurde.",
+    grundlage: "Art. 6 Abs. 1 lit. f DSGVO – berechtigtes Interesse "
+      + "(Schutz der Mitglieder), Art. 5 Abs. 1 lit. e – Speicherbegrenzung",
+    wirkung: "Der Fall und ALLE Nachrichten darin verschwinden ganz. "
+      + "Offene Fälle werden nie geräumt – nur abgeschlossene, und erst "
+      + `${HILFE_TAGE} Tage danach.`,
+    offen: (d) => zaehle(d,
+      "SELECT COUNT(*) AS n FROM hilfe_faelle WHERE stand = ?"
+      + " AND geschlossen_am IS NOT NULL AND geschlossen_am < ?",
+      FALL_STAND.zu, vorTagen(HILFE_TAGE)),
+    raeumen: (d) => d.prepare(
+      "DELETE FROM hilfe_faelle WHERE stand = ?"
+      + " AND geschlossen_am IS NOT NULL AND geschlossen_am < ?")
+      .run(FALL_STAND.zu, vorTagen(HILFE_TAGE)).changes,
+  },
   {
     schluessel: "protokoll_ip",
     was: "IP-Adressen im Protokoll",
@@ -170,6 +231,37 @@ export const FRISTEN = [
     offen: (d) => zaehle(d,
       "SELECT COUNT(*) AS n FROM personen WHERE alter_bestaetigt_am IS NOT NULL"),
   },
+  {
+    /* ERLEDIGTE AUFGABEN (nachgetragen am 20.09.2026)
+
+       Aufgefallen beim Suchen nach dem naechsten `hilfe_faelle`:
+       Genau ZWEI Tabellen im ganzen Haus tragen eine Spalte, die
+       sagt „hier ist etwas zu Ende" -- `hilfe_faelle.geschlossen_am`
+       und `aufgaben.erledigt_am`. Die erste war gar nicht im Konzept,
+       die zweite ebenso wenig.
+
+       Hier ist die Antwort aber eine andere: Sie BLEIBEN. Eine
+       erledigte Aufgabe ist Arbeitsdokumentation, keine Meldung ueber
+       einen Menschen -- und wer im Dezember wissen will, was im
+       September verabredet war, findet es sonst nicht mehr.
+
+       `aufgaben.verantwortlich_id` traegt ON DELETE SET NULL, nicht
+       CASCADE: Wird eine Person geloescht, bleibt die Aufgabe stehen
+       und verliert nur den Namen. Auch das ist Absicht -- eine
+       Aufgabe, die verschwindet, weil jemand das Team verlaesst,
+       reisst die Geschichte des Projekts mit. */
+    schluessel: "aufgaben_erledigt",
+    was: "Erledigte und abgebrochene Aufgaben",
+    art: "bleibt",
+    frist: "unbefristet",
+    zweck: "Nachlesen können, was wann verabredet und getan wurde.",
+    grundlage: "Art. 6 Abs. 1 lit. f DSGVO – berechtigtes Interesse an "
+      + "nachvollziehbarer Zusammenarbeit",
+    wirkung: "Bleiben. Beim Löschen einer Person verlieren sie nur den Namen "
+      + "(ON DELETE SET NULL) – die Aufgabe selbst bleibt lesbar.",
+    offen: (d) => zaehle(d,
+      "SELECT COUNT(*) AS n FROM aufgaben WHERE erledigt_am IS NOT NULL"),
+  },
   {
     schluessel: "personen_geloescht",
     was: "Daten einer gelöschten Person",