docs(quick-261008-w5w): Modul-Changelog in Anleitungen und CHANGELOG

- Entwicklung: Abschnitt Modulversion und Modul-Changelog pflegen
- Betrieb: Pruefung vor der Freigabe, Anwender: Abschnitt Aenderungen

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

docs/anleitung-anwender.md

@@ -108,7 +108,7 @@ Für Uhr, Suchleiste, Kalender, Notizen, Favoriten, Bilderrahmen, XFrame und Pro
 - **Aktiviert** — das Modul wurde vom Administrator für Ihr Unternehmen freigeschaltet.
 - **Verfügbar** — das Modul existiert, ist aber noch nicht aktiviert.
 
-Über die Suche und die Filter (Status, Kategorie) lässt sich die Liste eingrenzen. Ein Klick auf eine Kachel öffnet die Detailseite mit einer ausführlicheren Beschreibung.
+Über die Suche und die Filter (Status, Kategorie) lässt sich die Liste eingrenzen. Ein Klick auf eine Kachel öffnet die Detailseite mit einer ausführlicheren Beschreibung. Darunter steht der Abschnitt **„Änderungen“**: Er zeigt, was sich von Modulversion zu Modulversion geändert hat, gegliedert in Neu, Geändert und Behoben. Die neueste Version steht oben, ist mit „Aktuell“ gekennzeichnet und aufgeklappt; ältere Versionen klappen Sie mit einem Klick auf.
 
 **Aktivieren und Freigeben sind zwei unterschiedliche Dinge:** Nur Administratoren können ein Modul für das gesamte Unternehmen **aktivieren**. Ob Sie persönlich das Modul danach auch sehen und öffnen können, hängt zusätzlich davon ab, ob Ihnen oder Ihrer Gruppe der Zugriff **freigegeben** wurde. Ein Modul kann also für das Unternehmen aktiv sein, ohne dass Sie selbst Zugriff darauf haben. Versuchen Sie in diesem Fall, das Modul zu öffnen, erscheint statt des Moduls die Meldung „Kein Zugriff auf dieses Modul" mit dem Hinweis „Sie haben für dieses Modul keine Freigabe. Wenden Sie sich an Ihren Administrator." In diesem Fall wenden Sie sich an Ihren Administrator, damit er Ihnen (direkt oder über eine Gruppe) die Freigabe für das Modul erteilt.
 

docs/anleitung-betrieb.md

@@ -484,9 +484,13 @@ Zeilen einmal ergänzt.
 Das Freigeben erledigt Claude; Sie sagen nur „Version X freigeben“. Zur Einordnung,
 was dabei passiert:
 
-1. **Änderungsliste abschließen:** In `CHANGELOG.md` wird der Abschnitt
-   „Unveröffentlicht“ in „X.Y.Z – JJJJ-MM-TT“ umbenannt, darüber ein neues, leeres
-   „Unveröffentlicht“ angelegt, und das Ganze auf `main` committet und gepusht.
+1. **Änderungsliste abschließen:** Zuerst wird geprüft, ob jedes seit dem letzten
+   Tag geänderte Modul einen unveröffentlichten Eintrag in seinem Modul-Changelog
+   hat (Prüfbefehl und Regeln: Entwicklungsanleitung, Abschnitt „Modulversion und
+   Modul-Changelog pflegen“); die unveröffentlichten Modul-Einträge bekommen das
+   Freigabedatum. Dann wird in `CHANGELOG.md` der Abschnitt „Unveröffentlicht“ in
+   „X.Y.Z – JJJJ-MM-TT“ umbenannt, darüber ein neues, leeres „Unveröffentlicht“
+   angelegt, und das Ganze auf `main` committet und gepusht.
    Erst dann wird zusammengeführt und getaggt:
 
 ```bash

docs/anleitung-entwicklung.md

@@ -284,7 +284,7 @@ Jedes Modul-`Module` (NestJS) seedet sich beim Start selbst in die Datenbanktabe
 await moduleRegistryService.seedModule({
   slug: 'domaincheck',
   name: 'Domaincheck',
-  version: '1.0.0',
+  version: latestVersion(DOMAINCHECK_CHANGELOG),
   category: 'domain-tools',
   description: { de: '...', en: '...' },
   isSystem: true,
@@ -296,6 +296,70 @@ macht daraus ein Upsert auf `slug` — bei jedem API-Start wird der Registry-Ein
 nicht dupliziert. Ein Modul erscheint im Marktplatz (`GET /modules`, `GET /modules/catalog`), sobald
 dieser Seed einmal gelaufen ist — unabhängig von der Mandanten-Aktivierung.
 
+### Modulversion und Modul-Changelog pflegen
+
+Jedes eingebaute Modul hat einen eigenen Changelog. Er ist die **einzige Quelle** für die
+Versionsnummer des Moduls: In keiner Seed-Datei steht eine fest eingetragene Versionszeichenkette.
+
+**Wo was liegt.** Der Changelog liegt als `<ordner>/<seed-name>.changelog.ts` direkt neben der
+Seed-Datei (zum Beispiel `apps/api/src/dkv/dkv.changelog.ts`, `apps/api/src/tenders/tenders.changelog.ts`).
+Die Typen (`ModuleChangelog`, `ModuleChangelogRelease`, `ModuleChangelogItem`) sowie `compareSemver`
+und `latestVersion` stehen in `apps/api/src/module-registry/module-changelog.ts`, das Register
+`MODULE_CHANGELOGS` (Slug auf Changelog) in `module-changelog.registry.ts`. Die Seed-Datei liest ihre
+Version ausschließlich mit `latestVersion(<NAME>_CHANGELOG)`. Der Marktplatz zeigt die Einträge auf der
+Detailseite über `GET /modules/changelog/:slug`; unbekannte und eigene Module liefern eine leere Liste,
+die Detailseite zeigt dann keinen Abschnitt „Änderungen“.
+
+**Die Regel.** Jede für Benutzer sichtbare Moduländerung bekommt einen Eintrag. Ein Eintrag mit
+Neu-Punkt ergibt einen Minor-Sprung (1.2.0 auf 1.3.0). Enthält er nur Behoben- oder Geändert-Punkte
+(Fehler, Texte, Aussehen), ist es ein Patch-Sprung (1.2.0 auf 1.2.1). Ein Major-Sprung kommt nur bei
+einem grundlegenden Umbau vor. Reine Test-, Refactor-, Doku- und Chore-Änderungen ohne sichtbare
+Wirkung brauchen keinen Eintrag.
+
+**Höchstens ein Sprung je Modul zwischen zwei Tessera-Freigaben.** Ein Eintrag gilt als
+unveröffentlicht, solange sein Datum nach dem Datum der letzten Tessera-Version in `CHANGELOG.md`
+liegt. Kommt eine weitere Änderung hinzu, solange der oberste Eintrag noch unveröffentlicht ist,
+ergänzen Sie diesen Eintrag, statt eine neue Version anzulegen; kommt dabei ein Neu-Punkt hinzu,
+heben Sie die Stufe von Patch auf Minor an. Bei der Freigabe einer Tessera-Version bekommen
+unveröffentlichte Einträge das Freigabedatum (siehe Betriebsanleitung, „Eine Version freigeben“).
+
+**Schreibweise.** Kurz (ein Satz, höchstens zwei), aus Sicht der Benutzer, in Alltagssprache und
+mit „Sie“. Jeder Punkt hat einen deutschen (`de`) und einen gleichwertigen englischen (`en`) Text,
+die Art ist `new`, `changed` oder `fixed`. Deutsche Texte mit echten Umlauten, ohne
+Mandanten- oder Lizenzbegriffe. Die Texte erscheinen nur als einfacher Text, ohne HTML oder Markdown.
+
+**Checkliste für ein neues Modul.**
+
+1. `<ordner>/<seed-name>.changelog.ts` anlegen und eine erste Version `1.0.0` mit dem heutigen Datum
+   eintragen (Export `<SLUG_MIT_UNTERSTRICH>_CHANGELOG`, Typ `ModuleChangelog`).
+2. Den Changelog in `module-changelog.registry.ts` eintragen (alphabetisch nach Slug).
+3. In der Seed-Datei `version: latestVersion(<NAME>_CHANGELOG)` verwenden.
+
+**Der Wächter.** `apps/api/src/module-registry/module-changelog.spec.ts` findet alle
+`apps/api/src/*/*.seed.ts` selbstständig, ruft jede `seed*Module`-Funktion mit einer Attrappe auf und
+schlägt fehl, wenn ein Seed-Modul keinen Changelog hat, ein Changelog zu keinem Seed gehört, die
+Seed-Version nicht dem obersten Eintrag entspricht, Versionen nicht streng absteigen, ein Datum kein
+echtes Kalenderdatum ist oder nicht absteigt, ein Eintrag keinen Text in `de` oder `en` hat,
+Ersatzschreibungen (zum Beispiel „fuer“, „Aenderung“) oder Mandanten- und Lizenzbegriffe vorkommen.
+So lässt sich die Versionsanpassung nicht vergessen, ohne dass ein Test rot wird.
+
+**Warum keine CI-Prüfung „Modulordner geändert, Changelog nicht“.** Sie ließe sich nicht ohne
+Fehlalarme bauen: Reine Test-, Refactor- und Kommentar-Commits verlangen keinen Versionssprung,
+plattformweite Commits berühren viele Modulordner zugleich, und ein Push bündelt mehrere Commits
+(gebündeltes Pushen ist hier Projektpraxis). Stattdessen läuft vor jeder Freigabe dieser
+Prüfbefehl je Modul, und jedes Modul mit Treffern braucht einen unveröffentlichten Eintrag:
+
+```bash
+git log --oneline <letzter-tag>..HEAD -- apps/api/src/<ordner> \
+  "apps/web/src/app/(portal)/modules/<slug>" apps/web/src/components/<name>
+```
+
+Zusätzliche Modulpfade sind die Dashboard-Kachel `apps/web/src/components/dashboard/widgets/<slug>-widget.tsx`
+(Proxmox), `apps/web/src/lib/nextcloud-files-api.ts` (Dateien) sowie bei Handelsware und
+Kantinenabrechnung `apps/api/src/accounting` und `apps/web/src/components/accounting`. Treffer
+beurteilen Sie nach der Regel oben: Steckt eine sichtbare Änderung dahinter, gehört ein Eintrag in
+den Changelog.
+
 ### Zweistufiges Zugriffsmodell
 
 Zugriff auf ein Modul besteht aus zwei unabhängigen Stufen: