Version 1.0.0 — Freigabe fuer den Echtbetrieb
Kein neues Modul. Zwoelf Phasen sind fertig, und die Wehr kann ab jetzt echte Daten hineingeben, ohne befuerchten zu muessen, sie beim naechsten Update zu verlieren. Neu dazu, weil beides zum Betrieb gehoert: update.sh aktualisiert auf einem Linux-Server in einem Befehl. Der Ablauf darf an jeder Stelle abbrechen, ohne eine halb aktualisierte Anlage zu hinterlassen: erst nachsehen ob es etwas Neues gibt, dann sichern, dann holen und bauen (schlaegt das fehl, laeuft die alte Fassung unveraendert weiter), dann umschalten, dann pruefen ob die Anwendung antwortet. Tut sie es nicht, stehen die Protokollzeilen da und die Befehle fuer den Rueckweg. docs/KURZANLEITUNG.md ist der Einstieg fuer die Wehr - nach Rollen sortiert, aufgabenorientiert statt nach Modulen, und bei jedem heiklen Punkt steht das Warum dabei. Die vollstaendige Anleitung hat 63 Kapitel; die liest niemand, bevor er das erste Geraet pruefen will. Die Roadmap haelt den Stand JEDER Freigabevoraussetzung fest, auch der offenen: Datenuebernahme entfaellt (die Wehr pflegt von Hand ein), Sicherungskonzept erledigt, Loeschkonzept technisch vollstaendig aber nicht abgenommen, Schulung steht aus, Atemschutzhinweis bewusst stehen gelassen. Eine Freigabe, die abhakt was nicht geprueft wurde, ist keine. Nebenbei die Ursache der Testflackerei gefunden, die sich durch mehrere Phasen zog: zwei Datenbanktests schalteten beim Aufraeumen ihre Trigger mit ALTER TABLE ... DISABLE TRIGGER ab - eine Schemaaenderung, die fuer die ganze Datenbank gilt. Vitest faehrt die Dateien parallel, also pruefte eine Datei gerade dass ein Trigger greift, waehrend eine andere ihn abgeraeumt hatte. Jetzt sitzungslokal ueber session_replication_role. Erstmals in diesem Projekt: fuenf Unit-Testlaeufe hintereinander 601 gruen und ein E2E-Lauf mit 268 gruen ohne Fehlschlag und ohne Flackern. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
co-authored by
Claude Opus 5
parent
9156dcc144
commit
30faa6cb02
+6
-2
@@ -1,7 +1,11 @@
|
||||
# Anleitung
|
||||
|
||||
Bedienung von FLORIAN, Stand Phase 11 (Version 0.12.0). Die Bilder zeigen die
|
||||
Beispielwehr aus dem Seed und werden mit `npm run screenshots` neu erzeugt.
|
||||
Bedienung von FLORIAN, Version 1.0.0. Die Bilder zeigen die Beispielwehr aus
|
||||
dem Seed und werden mit `npm run screenshots` neu erzeugt.
|
||||
|
||||
> **Das hier ist zum Nachschlagen, nicht zum Durchlesen.** Wer anfangen will,
|
||||
> nimmt die [Kurzanleitung](KURZANLEITUNG.md) — nach Rollen sortiert, auf ein
|
||||
> paar Seiten.
|
||||
|
||||
---
|
||||
|
||||
|
||||
+101
-1
@@ -24,7 +24,107 @@ Die aufgewendete Zeit wandert nach jedem Abschnitt in die Spalte
|
||||
| Phase 9 — Kassenverwaltung | 4:10 h | 1 | 04.09.2026 |
|
||||
| Phase 10 — Mandantenfähigkeit | 4:20 h | 1 | 05.09.2026 |
|
||||
| Phase 11 — Freigabereife | 2:40 h | 1 | 05.09.2026 |
|
||||
| **Summe** | **35:30 h** | **14** | |
|
||||
| 1.0.0 — Freigabe | 0:50 h | 1 | 06.09.2026 |
|
||||
| **Summe** | **36:20 h** | **15** | |
|
||||
|
||||
---
|
||||
|
||||
## 2026-09-06 · 1.0.0 — Freigabe
|
||||
|
||||
**09:20 – 10:10 · 0:50 h · Version 1.0.0**
|
||||
|
||||
### Was entstanden ist
|
||||
|
||||
Kein Modul. Zwei Dinge, die zum Betrieb gehören, und eine Entscheidung.
|
||||
|
||||
| Was | Wofür |
|
||||
|---|---|
|
||||
| `update.sh` | Aktualisieren auf einem Linux-Server, in einem Befehl |
|
||||
| `docs/KURZANLEITUNG.md` | Der Einstieg für die Wehr, nach Rollen sortiert |
|
||||
| Version 1.0.0 | Ab hier semantische Versionierung |
|
||||
|
||||
### Entscheidungen
|
||||
|
||||
**Das Update-Skript sichert, bevor es irgendetwas anfasst.** Ein Update ist
|
||||
der häufigste Anlass, eine Sicherung zu brauchen — und der Moment, in dem
|
||||
niemand daran denkt. `--ohne-sicherung` gibt es, aber mit einer Warnung und
|
||||
nicht als Vorgabe.
|
||||
|
||||
**Die Reihenfolge ist so gewählt, dass ein Abbruch harmlos bleibt.** Holen und
|
||||
Bauen passieren, bevor umgeschaltet wird: schlägt der Bau fehl, läuft die alte
|
||||
Fassung unverändert weiter. Erst danach wird umgeschaltet, und ab da nennt die
|
||||
Fehlerbehandlung die Befehle für den Rückweg.
|
||||
|
||||
**Die Kurzanleitung ist aufgabenorientiert, nicht modulorientiert.** Die große
|
||||
Anleitung hat 63 Kapitel und ist nach Funktionsbereichen sortiert — richtig
|
||||
zum Nachschlagen, unbrauchbar zum Anfangen. Die Kurzanleitung fragt stattdessen
|
||||
„was willst du tun": ein Gerät prüfen, einen Kontoauszug einlesen, einen
|
||||
Termin absagen.
|
||||
|
||||
**Sie erklärt bei jedem heiklen Punkt das Warum.** Warum ein abgeschlossenes
|
||||
Prüfprotokoll nicht änderbar ist, warum gegengebucht statt korrigiert wird,
|
||||
warum der Atemschutzhinweis stehen bleibt. Wer den Grund kennt, sucht nicht
|
||||
nach dem Weg drumherum.
|
||||
|
||||
**Die Roadmap hakt nicht alles ab.** Zwei Freigabevoraussetzungen sind
|
||||
organisatorisch und stehen aus — die Abnahme des Löschkonzepts und die
|
||||
Schulung. Sie stehen mit ihrem Stand dort, statt stillschweigend als erledigt
|
||||
zu gelten. Eine Freigabe, die abhakt, was nicht geprüft wurde, ist keine.
|
||||
|
||||
### Wo es gehakt hat
|
||||
|
||||
**Die Ursache der Testflackerei gefunden — nach elf Phasen.**
|
||||
|
||||
Beim abschließenden Durchlauf fielen wieder einmal fünf, dann sechs, dann ein
|
||||
Test aus, in wechselnder Besetzung. Dieses Mal habe ich nicht weitergemacht,
|
||||
sondern fünf Läufe hintereinander mitgeschrieben: betroffen waren immer
|
||||
Zusicherungen über Trigger — „Wiki-Fassungen bleiben", „Mandantentrennung",
|
||||
„abgeschlossene Prüfprotokolle".
|
||||
|
||||
`ki-datenbank.test.ts` und `atemschutz-datenbank.test.ts` schalteten beim
|
||||
Aufräumen ihre Trigger mit `ALTER TABLE ... DISABLE TRIGGER USER` ab. Das ist
|
||||
eine Schemaänderung: sie gilt für die ganze Datenbank und für alle. Vitest
|
||||
fährt die Testdateien parallel — während also die eine Datei abräumte, prüfte
|
||||
die andere gerade, dass genau dieser Trigger greift, und sah keinen.
|
||||
|
||||
`SET LOCAL session_replication_role = 'replica'` bewirkt dasselbe, aber nur in
|
||||
der eigenen Transaktion. Danach: fünf Läufe hintereinander 601 grün.
|
||||
|
||||
Rückwirkend erklärt das eine Reihe von Ausfällen, die ich als Flackern
|
||||
abgetan habe — sie waren keines. Die Lehre ist unbequem: „läuft einzeln durch,
|
||||
also Umgebung" ist eine bequeme Erklärung und oft die falsche.
|
||||
|
||||
| Weiteres | Ursache | Lösung |
|
||||
|---|---|---|
|
||||
| Ein Datenbanktest ließ sich nur einmal ausführen | `mandanten-datenbank.test.ts` räumte nur am Ende auf; ein abgebrochener Lauf legte den nächsten lahm | Räumt jetzt auch am Anfang auf — dasselbe Muster wie in Phase 10 bei `ki-datenbank` |
|
||||
|
||||
### Abweichung von der Vorgabe
|
||||
|
||||
**`update.sh` ist nicht auf einem Linux-Server erprobt.** Entwickelt wurde
|
||||
unter Windows; geprüft sind die Syntax (`bash -n`), die Hilfe, die
|
||||
Argumentbehandlung und der Wächter gegen unverbuchte Änderungen — alles unter
|
||||
Git Bash. Der eigentliche Ablauf (fetch, build, up, Gesundheitsprüfung) läuft
|
||||
erst dort, wo FLORIAN wirklich steht.
|
||||
|
||||
Das ist keine Nachlässigkeit, sondern die Grenze dieser Umgebung. Beim ersten
|
||||
echten Update gehört `./update.sh --pruefen` vorangestellt: es holt nichts und
|
||||
ändert nichts, zeigt aber, ob Docker, git und die `.env` gefunden werden.
|
||||
|
||||
### Nachweise
|
||||
|
||||
- `npm run typecheck` — ohne Ausgabe
|
||||
- `npm run lint` — ohne Befund
|
||||
- `npm run test` — 601 Tests grün
|
||||
- `bash -n update.sh` — Syntax in Ordnung
|
||||
- `./update.sh --help` und `--quatsch` — Ausgabe und Ablehnung wie vorgesehen
|
||||
- Der Wächter gegen unverbuchte Änderungen greift (an einem schmutzigen
|
||||
Arbeitsverzeichnis geprüft)
|
||||
- Alle acht Bilder der Kurzanleitung existieren
|
||||
- `npm run test` **fünfmal hintereinander** — jedes Mal 601 grün. Das war
|
||||
nach elf Phasen der erste Lauf, bei dem ich das behaupten kann
|
||||
- `npm run test:e2e` — **268 grün, kein Fehlschlag, kein Flackern.** Ebenfalls
|
||||
der erste vollständig saubere Durchlauf in diesem Projekt
|
||||
- `npm run build` — sauber
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -0,0 +1,283 @@
|
||||
# FLORIAN — Kurzanleitung
|
||||
|
||||
Alles, was man am Anfang braucht, auf ein paar Seiten. Nach Rollen sortiert:
|
||||
such dir den Abschnitt, der zu dir gehört, und lies den Rest später.
|
||||
|
||||
Ausführlich steht alles in der [Anleitung](ANLEITUNG.md) — 63 Kapitel, zum
|
||||
Nachschlagen, nicht zum Durchlesen.
|
||||
|
||||
---
|
||||
|
||||
## Für alle
|
||||
|
||||
### Anmelden
|
||||
|
||||
FLORIAN läuft im Browser. Die Adresse bekommst du vom Kommandanten.
|
||||
|
||||

|
||||
|
||||
Nach der Anmeldung landest du auf der Übersicht: was ansteht, was fällig ist,
|
||||
was gemeldet wurde.
|
||||
|
||||
**Das Passwort gehört nach der ersten Anmeldung geändert.** Oben rechts auf
|
||||
deinen Namen.
|
||||
|
||||
### Was du überall findest
|
||||
|
||||
| Links in der Leiste | Wofür |
|
||||
|---|---|
|
||||
| **Übersicht** | Die Startseite: Fristen, Mängel, nächste Termine |
|
||||
| **Termine** | Übungsabende, Lehrgänge, Versammlungen — mit Rückmeldung |
|
||||
| **Dienstausweis** | Dein Ausweis mit QR-Code, auch fürs Handy |
|
||||
| **Wissen** | Merkblätter und Dienstanweisungen der Wehr |
|
||||
|
||||
Du siehst nur, was zu deiner Rolle gehört. Fehlt dir etwas, sag dem
|
||||
Kommandanten Bescheid — Rollen werden dort vergeben.
|
||||
|
||||
### Zu einem Termin zurückmelden
|
||||
|
||||
**Termine** öffnen, den Termin anklicken, **Zusagen** oder **Absagen**. Fertig.
|
||||
Wer absagt, kann einen Grund angeben; das hilft dem Ausbilder bei der Planung.
|
||||
|
||||
### Am Terminal im Gerätehaus
|
||||
|
||||
Am Wandtablet meldest du dich mit **PIN oder Ausweiskarte** an — nicht mit
|
||||
E-Mail und Passwort. Deine PIN bekommst du vom Kommandanten.
|
||||
|
||||

|
||||
|
||||
Dort geht: anmelden zum Dienst, einen Mangel melden, eine Fahrt eintragen,
|
||||
Schutzkleidung zur Reinigung geben.
|
||||
|
||||
---
|
||||
|
||||
## Für den Gerätewart
|
||||
|
||||
Das ist der Bereich, in dem FLORIAN am meisten abnimmt.
|
||||
|
||||
### Der wichtigste Bildschirm: Prüfungen
|
||||
|
||||

|
||||
|
||||
Unter **Prüfungen** steht, was wann fällig wird. Rot heißt überfällig, gelb
|
||||
heißt demnächst. Die Fristen rechnet FLORIAN selbst aus den Prüfintervallen
|
||||
der Gerätetypen aus — du musst nichts nachhalten.
|
||||
|
||||
### Ein Gerät prüfen
|
||||
|
||||
1. **Prüfungen** → das fällige Gerät anklicken → **Prüfung durchführen**.
|
||||
2. Die Checkliste durchgehen. Sie kommt aus der Wartungsvorlage des Gerätetyps.
|
||||
3. Ergebnis eintragen, unterschreiben, abschließen.
|
||||
|
||||

|
||||
|
||||
Danach entsteht ein **Prüfprotokoll als PDF** — das ist der Nachweis gegenüber
|
||||
der Unfallkasse.
|
||||
|
||||
> **Achtung:** Ein abgeschlossenes Protokoll lässt sich nicht mehr ändern. Das
|
||||
> ist Absicht — ein nachträglich änderbarer Nachweis wäre keiner. Ist etwas
|
||||
> falsch, wird eine neue Prüfung erfasst.
|
||||
|
||||
### Ein Gerät anlegen
|
||||
|
||||
**Geräte** → **Gerät anlegen**. Pflicht sind nur Inventarnummer und
|
||||
Bezeichnung; der Rest kann nachkommen.
|
||||
|
||||
Wähle möglichst einen **Gerätetyp** — daran hängen Prüfintervall und
|
||||
Lebensdauer, und ohne Typ rechnet FLORIAN keine Frist.
|
||||
|
||||
### Einen Mangel bearbeiten
|
||||
|
||||
Mängel kommen meist vom Terminal — jemand meldet sie beim Einrücken.
|
||||
|
||||
**Mängel** → anklicken → jemandem zuweisen → nach der Behebung **erledigen**.
|
||||
Ein Gerät mit einem schweren Mangel wird automatisch gesperrt.
|
||||
|
||||
### Was noch dazugehört
|
||||
|
||||
| Wo | Wofür |
|
||||
|---|---|
|
||||
| **Rückrufe** | Herstellerrückrufe: welche eurer Geräte betroffen sind |
|
||||
| **Lebensdauer** | Helme, Schläuche, Schutzkleidung mit Höchstalter |
|
||||
| **Fahrzeuge** | Beladung nach Geräteräumen |
|
||||
|
||||
---
|
||||
|
||||
## Für den Atemschutzgerätewart
|
||||
|
||||
> **Der wichtigste Satz zuerst:** Die Überwachungstafel am Fahrzeug bleibt
|
||||
> führend. FLORIAN ergänzt sie, ersetzt sie nicht. Das steht auch dauerhaft
|
||||
> über jeder Ansicht, und es soll dort stehen.
|
||||
|
||||
### Wer darf unter Pressluftatmer?
|
||||
|
||||

|
||||
|
||||
**Atemschutz** zeigt jeden Träger mit seinem Stand: G26, Belastungsübung,
|
||||
Einsatzübung. Wer eine der Voraussetzungen nicht erfüllt, steht rot da — mit
|
||||
Klartext, woran es liegt, nicht nur mit einer Farbe.
|
||||
|
||||
### Eine G26 eintragen
|
||||
|
||||
**Atemschutz** → **Nachweise** → Person wählen → G26 erfassen. Untersuchungsdatum,
|
||||
Ergebnis und Gültigkeit reichen; den Befund speichert FLORIAN bewusst nicht.
|
||||
|
||||
Dasselbe für Belastungsübungen.
|
||||
|
||||
### Eine Überwachung führen
|
||||
|
||||
**Atemschutz** → **Überwachung eröffnen**. Trupp zusammenstellen, Druckwerte
|
||||
in Intervallen eintragen, Rückzugsdruck im Blick behalten. FLORIAN rechnet den
|
||||
Rückzugsdruck und warnt, bevor es knapp wird.
|
||||
|
||||

|
||||
|
||||
Nach dem Ende entsteht ein vollständiges Protokoll als PDF.
|
||||
|
||||
> Solange ein Trupp im Einsatz ist, lässt sich die Überwachung nicht beenden.
|
||||
|
||||
---
|
||||
|
||||
## Für den Kommandanten
|
||||
|
||||
### Mitglieder und Rollen
|
||||
|
||||
**Mitglieder** → Person anklicken → Rollen vergeben.
|
||||
|
||||
Neun Rollen, jede mit festem Rechteumfang. Die wichtigsten: Gerätewart,
|
||||
Atemschutzgerätewart, Kassier, Schriftführer, Ausbilder.
|
||||
|
||||
**Jemand kommt nicht hinein?** Dann hat die Person eine Akte, aber kein Konto.
|
||||
Konten verwaltet, wer den Server betreibt — unter *Wehren und Konten*.
|
||||
|
||||
### Einen Einsatz erfassen
|
||||
|
||||
**Einsätze** → **Einsatz anlegen**. Die sechs Zeitstempel (Alarmierung,
|
||||
Ausrücken, Eintreffen, Einsatzende, Einrücken, Einsatzbereitschaft), die
|
||||
beteiligten Fahrzeuge und die Mannschaft.
|
||||
|
||||

|
||||
|
||||
Daraus entsteht der **Einsatzbericht als PDF** und die Statistik fürs Jahr.
|
||||
|
||||
### Kostenersatz abrechnen
|
||||
|
||||
Fehlalarm einer Brandmeldeanlage, Öleinsatz mit Verursacher, vermieteter
|
||||
Schulungsraum: **Kasse** → **Rechnungen** → *Rechnung schreiben*. Die Nummer
|
||||
vergibt FLORIAN fortlaufend.
|
||||
|
||||
### Wenn jemand Auskunft über seine Daten verlangt
|
||||
|
||||
Kommt selten vor, hat aber eine Frist von einem Monat.
|
||||
|
||||
**Mitglieder** → Person → **Datenauskunft** → *Auskunft erstellen*. Daraus
|
||||
entsteht ein PDF mit allem, was über die Person gespeichert ist. Ausdrucken
|
||||
und aushändigen, fertig.
|
||||
|
||||
---
|
||||
|
||||
## Für den Kassier
|
||||
|
||||

|
||||
|
||||
### Buchen
|
||||
|
||||
**Kasse** → **Buchungen** → *Buchung erfassen*. Der Betrag ist immer positiv;
|
||||
ob Einnahme oder Ausgabe, sagen die beiden Knöpfe daneben.
|
||||
|
||||
FLORIAN schlägt eine Kategorie vor — meist die richtige, weil er nachsieht,
|
||||
wie ihr dieselbe Sache zuletzt gebucht habt.
|
||||
|
||||
### Kontoauszug einlesen
|
||||
|
||||
Statt fünfzig Umsätze abzutippen: im Online-Banking den **Umsatzexport**
|
||||
herunterladen (CAMT.053 oder MT940), dann **Kasse** → **Buchungen** →
|
||||
*Kontoauszug*.
|
||||
|
||||
Es entstehen **Entwürfe**, keine fertigen Buchungen — durchsehen musst du sie.
|
||||
Umsätze, die schon in der Kasse stehen, erkennt FLORIAN und hakt sie nicht
|
||||
noch einmal ab.
|
||||
|
||||
### Beiträge
|
||||
|
||||
Einmal im Jahr: **Kasse** → **Beiträge** → *Beitragslauf*. Vorher steht da, wie
|
||||
viele Beiträge entstehen — und wer keinen passenden Satz hat.
|
||||
|
||||
Zahlungen hakst du in der Liste ab; dabei entsteht gleich die Buchung.
|
||||
|
||||
### Festschreiben — und was das bedeutet
|
||||
|
||||
Eine neue Buchung ist erst einmal ein **Entwurf** und änderbar. Mit
|
||||
*Festschreiben* wird sie unveränderbar.
|
||||
|
||||
Ist danach etwas falsch, wird **gegengebucht**: eine zweite Buchung in die
|
||||
andere Richtung, mit Begründung. Beide bleiben stehen. Das sieht nach mehr
|
||||
Aufwand aus und ist genau der Punkt — eine verschwundene Buchung kann ein
|
||||
Kassenprüfer nicht prüfen, eine berichtigte schon.
|
||||
|
||||
### Kassenprüfung
|
||||
|
||||
**Kasse** → **Abschluss** → *Kassenprüfung anlegen*. Links steht der Bestand
|
||||
laut Buch, rechts trägst du ein, was gezählt wurde.
|
||||
|
||||
Bleibt eine Differenz, muss sie erklärt werden — sonst lässt sich der Abschluss
|
||||
nicht festschreiben. In fünf Jahren weiß sonst niemand mehr, woher sie kam.
|
||||
|
||||
Danach entsteht der **Kassenprüfbericht als PDF** mit Unterschriftsfeldern.
|
||||
|
||||
---
|
||||
|
||||
## Für den, der den Server betreibt
|
||||
|
||||
### Sichern
|
||||
|
||||
```bash
|
||||
npm run sicherung
|
||||
```
|
||||
|
||||
Sichert Datenbank **und** Dateien. Das Ergebnis gehört auf ein anderes Gerät —
|
||||
eine Sicherung auf derselben Festplatte hilft gegen einen Festplattenfehler
|
||||
nicht.
|
||||
|
||||
### Einmal im Jahr proben
|
||||
|
||||
```bash
|
||||
npm run wiederherstellen -- --quelle sicherungen/<Ordner>
|
||||
```
|
||||
|
||||
So passiert nichts, es wird nur angezeigt, was geschähe. Erst mit `--wirklich`
|
||||
wird zurückgespielt.
|
||||
|
||||
> Eine Sicherung, die nie zurückgespielt wurde, ist eine Vermutung. Der Ordner
|
||||
> kann leer sein, der Auszug abgeschnitten — man erfährt es sonst an dem Tag,
|
||||
> an dem man es nicht erfahren will.
|
||||
|
||||
### Aktualisieren
|
||||
|
||||
```bash
|
||||
./update.sh --pruefen # nachsehen, ob es etwas Neues gibt
|
||||
./update.sh # einspielen
|
||||
```
|
||||
|
||||
Das Skript sichert von sich aus, bevor es etwas anfasst, und sagt bei einem
|
||||
Fehler, wie der vorherige Stand zurückkommt.
|
||||
|
||||
---
|
||||
|
||||
## Wenn etwas nicht geht
|
||||
|
||||
| Was | Woran es meist liegt |
|
||||
|---|---|
|
||||
| **Anmeldung geht nicht** | Nach fünf Fehlversuchen ist das Konto fünf Minuten gesperrt. Kurz warten. |
|
||||
| **Ein Menüpunkt fehlt** | Die Rolle fehlt. Der Kommandant vergibt sie unter *Mitglieder*. |
|
||||
| **Ein PDF entsteht nicht** | Es wird im Hintergrund erzeugt; nach ein paar Sekunden die Seite neu laden. |
|
||||
| **Das Terminal meldet niemanden an** | PIN falsch, oder das Tablet ist nicht mehr eingerichtet. |
|
||||
| **Eine Buchung lässt sich nicht ändern** | Sie ist festgeschrieben. Gegenbuchen. |
|
||||
|
||||
Steht die Antwort nicht dabei: [Anleitung, letztes Kapitel](ANLEITUNG.md).
|
||||
|
||||
---
|
||||
|
||||
*FLORIAN läuft auf einem Server, den die Feuerwehr selbst betreibt. Es gibt
|
||||
keine Telemetrie, keine Cloud und keine Weitergabe an Dritte — die Daten
|
||||
bleiben im Gerätehaus.*
|
||||
+29
-9
@@ -21,7 +21,7 @@ Phase 8 ████████████████████ fertig
|
||||
Phase 9 ████████████████████ fertig 0.10.0
|
||||
Phase 10 ████████████████████ fertig 0.11.0
|
||||
Phase 11 ████████████████████ fertig 0.12.0
|
||||
Freigabe ░░░░░░░░░░░░░░░░░░░░ offen 1.0.0
|
||||
Freigabe ████████████████████ fertig 1.0.0
|
||||
```
|
||||
|
||||
---
|
||||
@@ -310,17 +310,37 @@ also genau die Probe, wegen der 1.0.0 sie verlangt.
|
||||
**Die Wehr kann jetzt:** eine Selbstauskunft erteilen, ihren Bestand sichern
|
||||
und ihn nachweislich zurückholen.
|
||||
|
||||
## 1.0.0 — Freigabe
|
||||
## 1.0.0 — Freigabe · am 06.09.2026 erteilt
|
||||
|
||||
Kein neues Modul, sondern eine Entscheidung: die Wehr setzt FLORIAN im
|
||||
Echtbetrieb ein. Voraussetzungen:
|
||||
Echtbetrieb ein.
|
||||
|
||||
- Datenübernahme aus der bisherigen Verwaltung abgeschlossen und abgeglichen
|
||||
- ~~Sicherungskonzept steht und ist einmal wiederhergestellt worden~~ — mit Phase 11 erledigt
|
||||
- Schulung von Kommandant, Gerätewart und Atemschutzgerätewart erfolgt
|
||||
- Löschkonzept nach DSGVO abgenommen (die Auskunftsseite dazu gibt es seit Phase 11)
|
||||
- Der Hinweis zur analogen Atemschutzüberwachung wird bewusst und
|
||||
dokumentiert abgeschaltet — oder bewusst stehen gelassen
|
||||
**Damit das nicht zur Formalie wird, hier der Stand jeder Voraussetzung — auch
|
||||
der offenen.** Eine Freigabe, die alles abhakt, was ohnehin nicht geprüft
|
||||
wurde, ist keine.
|
||||
|
||||
| Voraussetzung | Stand |
|
||||
|---|---|
|
||||
| Datenübernahme aus der bisherigen Verwaltung | **entfällt.** Die Wehr pflegt den Bestand von Hand ein; es gibt kein Altsystem, aus dem übernommen würde. Für Mitglieder, Fahrzeuge und Geräte steht der Import-Assistent bereit, falls sich das ändert. |
|
||||
| Sicherungskonzept steht und ist einmal wiederhergestellt worden | **erledigt** mit Phase 11. Die Probe hat dabei einen Fehler gefunden, der sonst erst im Notfall aufgefallen wäre. |
|
||||
| Löschkonzept nach DSGVO | **technisch vollständig** seit Phase 11: Auskunft nach Art. 15, Anonymisierung im Aufbewahrungslauf, konfigurierbare Fristen. Die Abnahme durch die Wehr ist ein organisatorischer Schritt und steht aus. |
|
||||
| Schulung von Kommandant, Gerätewart und Atemschutzgerätewart | **steht aus.** Sie läuft nach der Freigabe; Grundlage ist die [Kurzanleitung](KURZANLEITUNG.md). |
|
||||
| Hinweis zur analogen Atemschutzüberwachung | **bewusst stehen gelassen.** `ATEMSCHUTZ_HINWEIS=true`. FLORIAN bleibt damit ergänzend; die Tafel am Fahrzeug ist führend. Das Abschalten verlangt ohnehin einen Kommandantenbeschluss samt Fundstelle. |
|
||||
|
||||
Die beiden offenen Punkte sind **organisatorisch, nicht technisch**: an der
|
||||
Software hängt nichts davon ab. Sie stehen hier, damit später nachlesbar ist,
|
||||
was zum Zeitpunkt der Freigabe erledigt war und was nicht.
|
||||
|
||||
### Was 1.0.0 bedeutet — und was nicht
|
||||
|
||||
**Bedeutet:** Der Funktionsumfang ist vollständig, die Datenbank ist stabil,
|
||||
Migrationen sind aufwärtskompatibel, und ab hier gilt semantische
|
||||
Versionierung. Ein Update bricht nichts, ohne dass es in der Hauptnummer
|
||||
steht.
|
||||
|
||||
**Bedeutet nicht:** dass keine Fehler mehr da sind. Es bedeutet, dass die
|
||||
Wehr echte Daten hineingeben kann, ohne befürchten zu müssen, sie beim
|
||||
nächsten Update zu verlieren.
|
||||
|
||||
---
|
||||
|
||||
|
||||
Reference in New Issue
Block a user