# CLAUDE.md – LBM Brennpunkt-Manager

Projektspezifische Regeln. Ergänzt/überschreibt die globale `~/.claude/CLAUDE.md`.
Frameworkloses PHP (kein Craft/Kirby-Template) – die Vorlagen-Konventionen aus
`template-toolkit` gelten hier nicht.

## Versionierung & Releases

Abweichend vom SemVer-Default der globalen CLAUDE.md: LBM ist eine intern
deployte Web-App ohne öffentliche API (Deploy = `git pull`). „Breaking Change"
ist hier kaum definierbar, deshalb **CalVer im Stil `YYYYx`** (tz-/Olson-Datenbank:
`2026a`, `2026b`, … – Jahr plus fortlaufender Buchstabe je Release; neues Jahr
beginnt wieder bei `a`).

- **Datum daneben führen**, damit Nutzer beides sehen: `## [2026a] — 2026-09-15`.
- **Erste Version erst beim ersten echten Deploy** schneiden. Bis dahin sammelt
  alles unter `## [Unreleased]` (sowohl in `CHANGELOG.md` als auch in
  `RELEASE-NOTES.md`).
- **`package.json` NICHT als App-Version bumpen.** Sie versioniert nur das
  Frontend-Asset-Bündel (`lbm-frontend-assets`), nicht die Anwendung. Der
  Versions-Commit trägt die CalVer als Commit-Message und als annotiertes Tag
  (`git tag -a 2026a -m "2026a"`), ohne `package.json` anzufassen.

## Zwei Änderungs-Dokumente (zwei Zielgruppen)

- **`CHANGELOG.md`** – technisch, für Entwickler/Betrieb (Keep a Changelog,
  Sektionen Hinzugefügt/Geändert/Behoben …). **Kein git-log-Abzug**, keine
  einzelnen Commits darin.
- **`RELEASE-NOTES.md`** – nutzerverständlich, kuratiert; speist die In-App-Seite
  „Was ist neu" (`/was-ist-neu`, `App\Content\UpdateLog`). Pro Release ein Block,
  je Änderung `- Titel: kurzer Text`. Kein Datum je Eintrag – das Datum gehört
  zur Release.

Beim Release beide Dateien gemeinsam pflegen: `[Unreleased]` → `[YYYYx] — Datum`.

## Umgebung

ddev (`ddev …` für alle Container-Befehle). Produktion läuft aktuell PHP 7.2,
Ziel 8.4; DB teils latin1 bei utf8-Verbindung (utf8mb4-Migration geplant) –
latin1-sicher bleiben. Details und offene Punkte: `docs/`.