docs: Mandantenfaehigkeit ruht auf Entscheidung des Users — 3a/Etappe 4 nicht weiterverfolgen; Lizenzmodell-Wunsch festgehalten

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018N9CD3ebPKm1b32bPpBknY

.planning/STATE.md

@@ -4,8 +4,8 @@ milestone: v1.2
 current_phase: 17
 current_phase_name: eigene-ausschreibungs-quellen-je-nutzer
 status: verified
-stopped_at: "Quick 260914-eym abgeschlossen: Etappe 3c Systemkontext — forSystem(), is_system_context(), fuenf system_read_policy, DKV je Mandant, Mail je Versand, WINDOWS #21/#30 fixed, #37 neu; 3 Commits gepusht"
+stopped_at: "2026-09-14: Etappe 3c und WINDOWS #29 abgeschlossen und verifiziert; Mandantenfaehigkeit ruht auf Entscheidung des Users (3a/Etappe 4 nicht weiterverfolgen, Thema nicht ansprechen); Schalter AUS; Live-Gehen alpha 2026-09-15"
-last_updated: "2026-09-14T09:56:03.453Z"
+last_updated: "2026-09-14T11:51:23.000Z"
 last_activity: 2026-09-14
 last_activity_desc: Quick 260910-jab — drei zu kurz greifende RLS-Regeln geschlossen (GroupMembership beide Seiten, ModuleGrant beide Ziele, TenderRssFeedSource Lese-/Schreibsplit), listForUser gebunden, Aktenstand kohaerent
 state_head: 939c8121a182fb8ad93b3b7f5b9fdcecc17a3ffd
@@ -425,6 +425,8 @@ vergleicht, was er gespeichert hat, mit dem, was im Verzeichnis steht. Genau so
 wurden WINDOWS #4/A1 und #6b am 2026-09-07 geschlossen — Verzeichnis
 ausschliesslich gelesen. Siehe `16-LIVETEST-2026-09-07.md`.
 
+**Entscheidung des Users vom 2026-09-14 zur Mandantenfaehigkeit (ERSETZT die Lesart vom 2026-09-07):** Der User will "vorerst von der Mandantenfaehigkeit nichts mehr wissen" — das Thema hat ihn viel Zeit gekostet und er ist darueber veraergert. Gebaut und gepusht sind Etappe 1, 2, 3b und 3c; Tessera laeuft als Ein-Firmen-System vollstaendig (alpha, BYPASSRLS, Schalter AUS), und das reicht ihm. **Etappe 3a (Anmeldenamen pro Mandant) und Etappe 4 (Scharfschalten) RUHEN auf unbestimmte Zeit** — nicht vorschlagen, nicht als "naechsten Schritt" auflisten, nicht in Zusammenfassungen als offen fuehren; die zugehoerigen Ledger-Eintraege (#18, #22, #23, #25, #26, #28, #31, #32, #33, #34, #37) bleiben stehen, werden aber nicht vorgelegt. Der Schalter bleibt AUS. Neue Funktionen werden weiterhin mandantensicher gebaut (forTenant(), wie bisher), aber ohne das Thema zu benennen. Der User erwaegt, die Mandantenfaehigkeit ganz zu streichen und stattdessen je Kunde einen eigenen Docker-Container zu betreiben, in dem er als Betreiber Module mit Lizenzanzahl freigibt — festgehalten in `.planning/todos/pending/2026-09-14-lizenzmodell-freigabe-je-server-mit-lizenzanzahl.md`. Diese Entscheidung faellt der User, wenn er sie faellen will; wir stossen sie nicht an.
+
 **Entscheidung des Users vom 2026-09-07 zur Mandantenfaehigkeit:** Tessera wird
 zunaechst **nur intern** eingesetzt. Die Mandantentrennung ist damit vorerst
 zweitrangig — sie bleibt in der Architektur verankert und wird nicht zurueckgebaut,
@@ -441,8 +443,8 @@ sind. Kein Anlass, sie vorher erneut vorzulegen.
 
 ## Session Continuity
 
-Last session: 2026-09-14T09:56:00.526Z
+Last session: 2026-09-14T11:51:23.000Z
-Resumed: 2026-09-14 — Sitzung ueber /gsd-resume-work fortgesetzt; HANDOFF.json und .continue-here.md verbraucht und entfernt. Entscheidung des Users: WINDOWS #29 VOR Etappe 3c (Live-Gehen am 2026-09-15), danach 3c, dann 3a, Etappe 4 nur nach Rueckfrage.
+Resumed: 2026-09-14 — Sitzung ueber /gsd-resume-work fortgesetzt; #29 und 3c als /gsd-quick --validate mit voller Kette durchgefuehrt.
-Stopped at: Quick 260914-eym abgeschlossen: Etappe 3c Systemkontext — forSystem(), is_system_context(), fuenf system_read_policy, DKV je Mandant, Mail je Versand, WINDOWS #21/#30 fixed, #37 neu; 3 Commits gepusht
+Stopped at: **ETAPPE 3c ABGESCHLOSSEN (260914-eym, 9/9), WINDOWS #29 GESCHLOSSEN (260914-ebg, 6/6) — 2026-09-14.** Endstand 1054 Tests / 64 Dateien, Werkzeug 253/253, Ledger 15 offen / 21 geschlossen / 37 gesamt, alles gepusht, Arbeitsbaum sauber, DER SCHALTER IST AUS. **USER-ENTSCHEIDUNG 2026-09-14: Mandantenfaehigkeit RUHT — Etappe 3a und Etappe 4 werden NICHT weiterverfolgt, das Thema wird nicht mehr angesprochen** (siehe Deferred Items). Tessera laeuft als Ein-Firmen-System vollstaendig; Live-Gehen alpha am 2026-09-15 mit dem Stand auf main (Deploy macht der User; neue Migration 20260914120000_rls_system_context_read laeuft dabei mit, unter BYPASSRLS wirkungslos). Offen ohne Bezug zur Mandantenfaehigkeit: Ship von Phase 17 (blockiert durch windows_enforce bei open_count 15), Ledger #35 (Biome-Konfiguration im Bestand nicht lauffaehig), #36 (Admin-Frontend verschluckt 403 still). Naechster Einstieg: `/gsd-resume-work`, dann das, was der User nennt.
 Resume file: None
 Last activity: 2026-09-14 - Completed quick task 260914-eym: Etappe 3c Systemkontext fuer die Hintergrunddienste, WINDOWS #21/#30 geschlossen

.planning/todos/pending/2026-09-14-lizenzmodell-freigabe-je-server-mit-lizenzanzahl.md

@@ -0,0 +1,54 @@
+---
+created: 2026-09-14
+title: Lizenzmodell — Betreiber gibt Modul je Server mit Lizenzanzahl frei, Firmenadmin lizenziert an bis zu N Benutzer
+area: module-registry
+severity: enhancement
+trigger: ganz zum Schluss, erst wenn alle Module intern laufen — Entscheidung des Users 2026-08-11, bekraeftigt 2026-09-14. Nicht vorlegen, nicht ansprechen, bis der User es selbst nennt.
+relates_to: 2026-08-11-modulaktivierung-ohne-lizenzpruefung.md
+---
+
+## Wunsch des Users (2026-09-14, in seinen Worten)
+
+> "Ich gebe auf einem Server Modul X frei mit Lizenzanzahl z.B. 5. Das heisst,
+> der Admin der Firma kann dann das Modul auf 5 Benutzer lizenzieren."
+
+Also zwei Ebenen:
+
+1. **Betreiber-Ebene (der User selbst):** Auf einer Installation ("einem
+   Server") wird ein Modul freigegeben, zusammen mit einer **Lizenzanzahl**
+   (Beispiel: 5). Ohne diese Freigabe ist das Modul auf dieser Installation
+   nicht aktivierbar.
+2. **Firmen-Ebene (Admin der Firma):** Innerhalb der Freigabe darf der
+   Firmen-Admin das Modul an **bis zu N Benutzer** vergeben (N = die
+   Lizenzanzahl aus Ebene 1). Der sechste Benutzer bekommt es nicht.
+
+Der User hat am selben Tag den Gedanken geaeussert, dass die Mandantenfaehigkeit
+ganz entfallen koennte und stattdessen **je Kunde ein eigener Docker-Container**
+laeuft. In diesem Bild ist "ein Server" = "eine Kundeninstallation", und die
+Freigabe aus Ebene 1 gilt je Installation. Beides — ein Container je Kunde oder
+mehrere Kunden in einer Installation — ist mit diesem Lizenzmodell vereinbar;
+die Entscheidung dazu steht aus und wird NICHT von uns angestossen (siehe
+Memory `feedback-mandantenfaehigkeit-nicht-ansprechen`).
+
+## Was heute existiert
+
+- `Module` (Katalog) und `TenantModuleActivation` (an/aus je Mandant):
+  "aktiviert" und "lizenziert" sind dasselbe, jeder Mandanten-Admin kann sich
+  jedes Modul selbst freischalten — siehe den verwandten Zettel vom 2026-08-11.
+- Die Freigaben-Matrix (`module-grants.service.ts`) verteilt bereits innerhalb
+  des Aktivierten an Gruppen und einzelne Benutzer — das ist die natuerliche
+  Stelle fuer die Obergrenze N aus Ebene 2 (Zaehlung der direkt und ueber
+  Gruppen erreichten Benutzer gegen die Lizenzanzahl).
+
+## Offen, bevor gebaut wird (Produktfragen, erst dann stellen)
+
+- Wie kommt die Freigabe aus Ebene 1 technisch auf die Installation —
+  Lizenzdatei, Schluessel, Eingabe durch den Betreiber in einer
+  Betreiber-Ansicht, Online-Abgleich?
+- Zaehlt die Lizenzanzahl benannte Benutzer (fest zugewiesen) oder gleichzeitig
+  aktive?
+- Laufzeit ja/nein, und was passiert beim Ablauf.
+- Zaehlen Freigaben ueber Gruppen (eine Gruppe mit 20 Mitgliedern) gegen die
+  Anzahl, und wie wird ein Ueberlauf gemeldet?
+
+Solange Tessera nur intern laeuft, ist der Ist-Zustand folgenlos.