Files

T

Florian WildeandClaude Opus 5 4b3021bb50 Kassenverwaltung als Phase 9 ergaenzen, Festlegungen dokumentieren

Die Rolle KASSIER war seit Phase 0 angelegt, ein Kassenmodul fehlte in der
Planung. Phase-9.md beschreibt es jetzt: Konten, Buchungen mit Beleg,
Beitragslauf mit Mahnstufen, Rechnungen, Kassenabschluss und Auswertungen.
Geschaetzt 8-11 PT, Version 0.10.0.

Zwei Festlegungen aus der Spezifikation, weil sie den Rest bestimmen: eine
festgeschriebene Buchung ist unveraenderbar und wird nur ueber eine
Gegenbuchung korrigiert; der Kassenabschluss friert seinen Zeitraum ein.

Ausserdem als entschieden festgehalten:
- Berechtigung bleibt ohne organisationId. Die Tabelle ist der systemweite
  Katalog dessen, was die Software kann; mandantenbezogen wird es erst ueber
  RolleBerechtigung.
- Die Loeschausnahme im Audit-Log bleibt. UPDATE ist dauerhaft gesperrt,
  DELETE nur im gekennzeichneten Aufbewahrungslauf des Workers.

Roadmap, Aufwandsschaetzung, Versionierung, README und die Seitenleiste sind
entsprechend ergaenzt.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-09-03 07:11:37 +02:00

4.2 KiB

Raw Blame History

Versionierung

Versionsnummern

FLORIAN folgt Semantic Versioning in der Form MAJOR.MINOR.PATCH.

Solange die Hauptversion 0 ist, gilt die Software als im Aufbau: es gibt keine Zusage, dass eine Schnittstelle stabil bleibt.

Stelle	wird erhöht, wenn
`MAJOR`	Bestehendes bricht — Datenmodell, REST-API unter `/api/v1` oder Konfiguration ändern sich so, dass eine bestehende Installation Handarbeit braucht. Ab `1.0.0`.
`MINOR`	Eine Phase ist abgeschlossen oder ein Funktionsbereich kommt hinzu.
`PATCH`	Fehlerbehebungen, Textkorrekturen, Abhängigkeits-Updates — alles ohne neue Funktion.

Zuordnung Phase zu Version

Jede abgeschlossene Phase bekommt eine Minor-Version. Das macht aus der Versionsnummer eine Aussage über den Funktionsumfang.

Version	Phase
`0.1.0`	Phase 0 — Fundament
`0.2.0`	Phase 1 — Stammdaten
`0.3.0`	Phase 2 — Wartung und Prüfung
`0.4.0`	Phase 3 — Einsätze und Übungen
`0.5.0`	Phase 4 — Kiosk-PWA
`0.6.0`	Phase 5 — Atemschutz
`0.7.0`	Phase 6 — Kartenmodule
`0.8.0`	Phase 7 — Benachrichtigungen und Termine
`0.9.0`	Phase 8 — Lokale KI
`0.10.0`	Phase 9 — Kassenverwaltung
`1.0.0`	Freigabe für den Wirkbetrieb durch die Wehr

0.10.0 ist nach SemVer korrekt größer als 0.9.0 — die Stellen werden als Zahlen verglichen, nicht als Text.

1.0.0 ist bewusst an die Freigabe gebunden, nicht an die letzte Phase. Erst wenn eine Wehr die Software im Echtbetrieb einsetzt, darf die analoge Überwachung zurücktreten — und erst dann ist eine Zusage über Stabilität ehrlich.

Wo die Version steht

package.json → version ist die Wahrheit.
CHANGELOG.md bekommt je Version einen eigenen Abschnitt.
Git-Tag in der Form v0.1.0.

npm version minor -m "Version %s — Phase 1 abgeschlossen"
git push --follow-tags

Changelog

Format nach Keep a Changelog, auf Deutsch. Überschriften je Abschnitt:

Hinzugefügt — neue Funktionen
Geändert — Verhalten, das anders geworden ist
Veraltet — bleibt vorerst, verschwindet aber
Entfernt — ist weg
Behoben — Fehlerbehebungen
Sicherheit — alles, was Sicherheitsbezug hat

Einträge beschreiben, was sich für die Wehr ändert, nicht welche Datei angefasst wurde. Also: „Prüfprotokolle lassen sich als PDF ablegen" statt „PdfService ergänzt".

Was noch nicht veröffentlicht ist, sammelt sich unter [Unveröffentlicht] und bekommt beim Setzen des Tags die Versionsnummer und das Datum.

Branches

Branch	Zweck
`main`	immer lauffähig. Tests grün, Build durch.
`feat/<nr>-<kurz>`	neue Funktion, `<nr>` ist die Issue-Nummer
`fix/<nr>-<kurz>`	Fehlerbehebung
`chore/<kurz>`	Aufräumen, Abhängigkeiten, Werkzeuge

Nie direkt auf main committen. Jede Änderung läuft über einen Branch und einen Pull Request.

Commits

Deutsch, Imperativ, erste Zeile höchstens 72 Zeichen. Die letzte Zeile verweist auf das Issue:

Prüfprotokoll als PDF über Gotenberg erzeugen

Das Protokoll wird nach dem Abschluss unveränderlich in MinIO abgelegt.
Korrekturen erzeugen ein neues Protokoll mit Verweis auf das ursprüngliche.

Refs #42

Der Text des Pull Requests enthält Closes #42.

Datenbankmigrationen

Eine Migration wird nach dem Anwenden nie verändert. Ein Fehler wird mit einer neuen Migration behoben.
Der Ordnername sagt, worum es geht: 20260902000100_rls_policies.
Jede Migration beginnt mit einem Kommentarblock, der erklärt warum sie existiert — nicht nur was sie tut.
Migrationen, die Daten verlieren können, werden im Changelog unter Sicherheit oder Geändert ausdrücklich genannt.

Was vor einem Tag erledigt sein muss

npm run typecheck ohne Ausgabe
npm run test grün
npm run test:e2e grün
npm run build durch
docker compose -f docker-compose.yml up -d startet sauber
Changelog-Abschnitt geschrieben
Devlog-Eintrag mit der aufgewendeten Zeit ergänzt
Aufwandsschätzung um den Ist-Wert ergänzt
Bildschirmfotos neu erzeugt, falls sich die Oberfläche geändert hat

4.2 KiB Raw Blame History