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-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: