Phase 11: Freigabereife #16

2026-09-05T15:17:01Z

florian.wilde commented

2026-09-05 15:17:01 +00:00

Kein Modul, sondern die drei Software-Voraussetzungen für 1.0.0: Auskunft nach Art. 15 DSGVO, ein geprüftes Sicherungskonzept und eine Pipeline. Version 0.12.0.

Auskunft nach Art. 15 DSGVO

person.export stand seit Phase 0 im Berechtigungskatalog und war dem Kommandanten zugewiesen — implementiert war nichts. Die Löschseite gab es, die Auskunftsseite nicht, und ohne Art. 15 ist ein Löschkonzept nicht abnehmbar.

Auf der Seite eines Mitglieds gibt es jetzt Datenauskunft. Ein Durchgang liefert die Anzeige, ein PDF für die Akte und JSON nach Art. 20 — bewusst nicht drei Knöpfe, von denen zwei vergessen werden können.

Über jedem der dreizehn Abschnitte steht, wozu die Daten vorliegen. Art. 15 Abs. 1 verlangt nicht nur die Daten, sondern auch Zwecke, Empfänger und den Hinweis auf die weiteren Rechte. Eine bloße Liste sieht aus wie eine Auskunft und ist keine.

Zwei Festlegungen bestimmen den Zuschnitt:

Was über die Person gespeichert ist, steht vollständig drin — auch der gemahnte Beitrag und die nicht bestandene G26. Gesundheitsdaten sind als besondere Kategorie nach Art. 9 gekennzeichnet.
Was die Person getan hat, steht als Zahl drin. Die zwölf Prüfprotokolle gehören zum Nachweisbestand der Wehr; vollständig ausgeliefert käme jeder über eine Selbstauskunft an die Geräteakten. Die Trennlinie ist nicht „viel oder wenig", sondern „über mich" gegen „von mir".

Leere Abschnitte bleiben stehen — „dazu liegt nichts vor" ist eine Auskunft. Der Vorgang wird protokolliert.

Sicherung — und was die Probe zutage gefördert hat

npm run sicherung sichert Datenbank und Dateien aus demselben Moment. npm run wiederherstellen spielt zurück, mit Probelauf als Vorgabe.

Der erste Rückspielversuch lief sauber durch und hatte dabei sämtliche Unveränderlichkeitsgarantien der Datenbank entfernt.

Die Ursache liegt tiefer als das offensichtliche --no-acl: docker/postgres/10-init-app-role.sh richtet eine Vorgabeprivilegierung ein, damit neue Tabellen aus Migrationen automatisch nutzbar sind. pg_restore legt die Tabellen aber ebenfalls neu an — die Vorgabe greift also auch dort, und die GRANT-Zeilen aus dem Dump können nur hinzufügen, nie wegnehmen.

Die Anwendungsrolle durfte danach das Audit-Log ändern, Wiki-Fassungen löschen und Kiosk-Vorgänge umschreiben. Nichts an der Anwendung hätte darauf hingewiesen. Gefunden haben es vier Datenbanktests unmittelbar nach der Probe — also genau die Probe, wegen der 1.0.0 sie verlangt.

Behoben: das Skript setzt die Sperren nach dem Zurückspielen neu und prüft danach nach. scripts/sicherung-sperren.ts ist die eine Liste, aus der Wiederherstellen und Prüfen entstehen; ein Test gleicht sie gegen die migrierte Datenbank ab, damit sie nicht lautlos auseinanderläuft.

Die Pipeline — geschrieben, aber nicht erprobt

.gitea/workflows/pruefung.yml, zwei Aufträge: pruefung (typecheck, lint, Migrationen, Seed, Unit-Tests) bei jedem Push, oberflaeche (E2E) auf main und in Pull Requests. Die Datenbank wird aus docker/postgres gebaut, weil FLORIAN PostGIS und pgvector braucht — ein postgres:17 ließe die Migrationen durch und scheiterte erst bei der ersten Umkreissuche.

Das musst du wissen: In Gitea ist kein act_runner registriert — die Actions-API antwortet, aber es gibt weder Workflows noch Läufe. Ohne Runner erscheinen die Läufe als „wartend" und laufen nie. Der Ablauf ist geschrieben und syntaktisch geprüft, aber nicht im Betrieb erprobt. Das steht so im README und im Devlog, damit sich niemand auf eine Prüfung verlässt, die nicht stattfindet. Einen Runner einzurichten ist ein Handgriff auf dem Server; sag Bescheid, wenn ich dabei helfen soll.

Nachweise

npm run typecheck — ohne Ausgabe
npm run lint — ohne Befund
npm run test — 601 Tests grün, davon 18 neu
npm run build — sauber
Auskunft von Hand erzeugt: 13 Abschnitte, 28 Angaben, 58 kB PDF
Sicherung und Wiederherstellung vollständig durchgeführt: ein nach der Sicherung angelegter Datensatz war danach weg, alle Zahlen stimmten wieder, und die 601 Tests liefen nach dem Zurückspielen grün — einschließlich derer, die die Sperren prüfen
npm run test:e2e — 260 grün. Zwei Ausfälle in termine.spec.ts waren ein Test, der klickte, bevor die Seite hydriert war; behoben, die Datei läuft auf beiden Projekten grün (34/34)

Zum Testen

Mitglieder → ein Mitglied → Datenauskunft → Auskunft erstellen. Dann PDF ansehen: steht über jedem Abschnitt ein Zweck? Ist die G26 als besondere Kategorie gekennzeichnet? Stehen die Tätigkeiten nur als Zahl da?
Danach unter Protokoll nachsehen — der Vorgang muss dort stehen.
npm run sicherung, dann npm run wiederherstellen -- --quelle sicherungen/<Ordner> (ohne --wirklich): es darf nichts passieren.
Wenn du magst, mit --wirklich. Danach npm run test — die Sperren-Tests sind der eigentliche Beweis.

🤖 Generated with Claude Code

Kein Modul, sondern die drei Software-Voraussetzungen für 1.0.0: Auskunft nach Art. 15 DSGVO, ein geprüftes Sicherungskonzept und eine Pipeline. Version **0.12.0**. ## Auskunft nach Art. 15 DSGVO `person.export` stand seit Phase 0 im Berechtigungskatalog und war dem Kommandanten zugewiesen — implementiert war nichts. Die Löschseite gab es, die Auskunftsseite nicht, und ohne Art. 15 ist ein Löschkonzept nicht abnehmbar. Auf der Seite eines Mitglieds gibt es jetzt **Datenauskunft**. Ein Durchgang liefert die Anzeige, ein PDF für die Akte und JSON nach Art. 20 — bewusst nicht drei Knöpfe, von denen zwei vergessen werden können. **Über jedem der dreizehn Abschnitte steht, wozu die Daten vorliegen.** Art. 15 Abs. 1 verlangt nicht nur die Daten, sondern auch Zwecke, Empfänger und den Hinweis auf die weiteren Rechte. Eine bloße Liste sieht aus wie eine Auskunft und ist keine. Zwei Festlegungen bestimmen den Zuschnitt: - **Was über die Person gespeichert ist, steht vollständig drin** — auch der gemahnte Beitrag und die nicht bestandene G26. Gesundheitsdaten sind als besondere Kategorie nach Art. 9 gekennzeichnet. - **Was die Person getan hat, steht als Zahl drin.** Die zwölf Prüfprotokolle gehören zum Nachweisbestand der Wehr; vollständig ausgeliefert käme jeder über eine Selbstauskunft an die Geräteakten. Die Trennlinie ist nicht „viel oder wenig", sondern **„über mich" gegen „von mir"**. Leere Abschnitte bleiben stehen — „dazu liegt nichts vor" ist eine Auskunft. Der Vorgang wird protokolliert. ## Sicherung — und was die Probe zutage gefördert hat `npm run sicherung` sichert Datenbank und Dateien aus demselben Moment. `npm run wiederherstellen` spielt zurück, mit Probelauf als Vorgabe. > **Der erste Rückspielversuch lief sauber durch und hatte dabei sämtliche Unveränderlichkeitsgarantien der Datenbank entfernt.** Die Ursache liegt tiefer als das offensichtliche `--no-acl`: `docker/postgres/10-init-app-role.sh` richtet eine Vorgabeprivilegierung ein, damit neue Tabellen aus Migrationen automatisch nutzbar sind. `pg_restore` legt die Tabellen aber ebenfalls neu an — die Vorgabe greift also auch dort, und die `GRANT`-Zeilen aus dem Dump können nur hinzufügen, nie wegnehmen. Die Anwendungsrolle durfte danach das Audit-Log ändern, Wiki-Fassungen löschen und Kiosk-Vorgänge umschreiben. **Nichts an der Anwendung hätte darauf hingewiesen.** Gefunden haben es vier Datenbanktests unmittelbar nach der Probe — also genau die Probe, wegen der 1.0.0 sie verlangt. Behoben: das Skript setzt die Sperren nach dem Zurückspielen neu und prüft danach nach. `scripts/sicherung-sperren.ts` ist die eine Liste, aus der Wiederherstellen und Prüfen entstehen; ein Test gleicht sie gegen die migrierte Datenbank ab, damit sie nicht lautlos auseinanderläuft. ## Die Pipeline — geschrieben, aber nicht erprobt `.gitea/workflows/pruefung.yml`, zwei Aufträge: `pruefung` (typecheck, lint, Migrationen, Seed, Unit-Tests) bei jedem Push, `oberflaeche` (E2E) auf `main` und in Pull Requests. Die Datenbank wird aus `docker/postgres` gebaut, weil FLORIAN PostGIS **und** pgvector braucht — ein `postgres:17` ließe die Migrationen durch und scheiterte erst bei der ersten Umkreissuche. > **Das musst du wissen:** In Gitea ist kein `act_runner` registriert — die Actions-API antwortet, aber es gibt weder Workflows noch Läufe. Ohne Runner erscheinen die Läufe als „wartend" und laufen nie. Der Ablauf ist geschrieben und syntaktisch geprüft, **aber nicht im Betrieb erprobt**. Das steht so im README und im Devlog, damit sich niemand auf eine Prüfung verlässt, die nicht stattfindet. Einen Runner einzurichten ist ein Handgriff auf dem Server; sag Bescheid, wenn ich dabei helfen soll. ## Nachweise - `npm run typecheck` — ohne Ausgabe - `npm run lint` — ohne Befund - `npm run test` — **601 Tests grün**, davon 18 neu - `npm run build` — sauber - Auskunft von Hand erzeugt: 13 Abschnitte, 28 Angaben, 58 kB PDF - **Sicherung und Wiederherstellung vollständig durchgeführt:** ein nach der Sicherung angelegter Datensatz war danach weg, alle Zahlen stimmten wieder, und die 601 Tests liefen nach dem Zurückspielen grün — einschließlich derer, die die Sperren prüfen - `npm run test:e2e` — 260 grün. Zwei Ausfälle in `termine.spec.ts` waren ein Test, der klickte, bevor die Seite hydriert war; behoben, die Datei läuft auf beiden Projekten grün (34/34) ## Zum Testen 1. **Mitglieder** → ein Mitglied → **Datenauskunft** → *Auskunft erstellen*. Dann PDF ansehen: steht über jedem Abschnitt ein Zweck? Ist die G26 als besondere Kategorie gekennzeichnet? Stehen die Tätigkeiten nur als Zahl da? 2. Danach unter **Protokoll** nachsehen — der Vorgang muss dort stehen. 3. `npm run sicherung`, dann `npm run wiederherstellen -- --quelle sicherungen/<Ordner>` (ohne `--wirklich`): es darf nichts passieren. 4. Wenn du magst, mit `--wirklich`. Danach `npm run test` — die Sperren-Tests sind der eigentliche Beweis. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

florian.wilde added 1 commit 2026-09-05 15:17:01 +00:00

Phase 11: Freigabereife

Pruefung / oberflaeche (pull_request) Canceled after 0s

Details

Pruefung / pruefung (pull_request) Canceled after 0s

Details

9156dcc144

Kein Modul, sondern die drei Software-Voraussetzungen fuer 1.0.0:
Auskunft nach Art. 15 DSGVO, ein geprueftes Sicherungskonzept und eine
Pipeline.

Das Auskunftsrecht war ein Versprechen ohne Umsetzung: `person.export`
stand seit Phase 0 im Katalog und war dem Kommandanten zugewiesen,
implementiert war nichts. Ohne Auskunftsseite ist ein Loeschkonzept nicht
abnehmbar. Jetzt sammelt FLORIAN dreizehn Abschnitte ueber eine Person,
mit dem Zweck ueber jedem - Art. 15 verlangt nicht nur die Daten, sondern
auch Zwecke und Rechte, und eine blosse Liste erfuellt die Pflicht nicht.
Ein Durchgang liefert Anzeige, PDF und JSON nach Art. 20.

Die Trennlinie ist "ueber mich" gegen "von mir": was ueber die Person
gespeichert ist, steht vollstaendig drin, auch das Unangenehme. Was sie
getan hat, steht als Zahl drin - die Pruefprotokolle gehoeren zum
Nachweisbestand der Wehr, und vollstaendig ausgeliefert kaeme jeder ueber
eine Selbstauskunft an die Geraeteakten.

Die Rueckspielprobe hat sich sofort bezahlt gemacht: der erste Versuch
lief sauber durch und hatte dabei saemtliche Unveraenderlichkeitsgarantien
der Datenbank entfernt. Die Vorgabeprivilegierung aus dem Init-Skript gibt
jeder von pg_restore neu angelegten Tabelle wieder alle Rechte, und GRANT
kann nur hinzufuegen. Die Anwendungsrolle durfte danach das Audit-Log
aendern, Wiki-Fassungen loeschen, Kiosk-Vorgaenge umschreiben - und nichts
haette darauf hingewiesen. Gefunden haben es vier Datenbanktests
unmittelbar nach der Probe, also genau die Probe, wegen der 1.0.0 sie
verlangt.

Die Pipeline ist geschrieben, aber NICHT erprobt: in Gitea ist kein
act_runner registriert. Das steht so im README und im Devlog, damit sich
niemand auf eine Pruefung verlaesst, die nicht stattfindet.

601 Unit-Tests gruen; Sicherung und Wiederherstellung einmal vollstaendig
durchgefuehrt und die Tests danach erneut gruen.

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

florian.wilde merged commit 14cc4de9b8 into main

2026-09-06 20:05:50 +00:00

florian.wilde deleted branch feat/phase-11-freigabereife

2026-09-06 20:05:50 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: florian.wilde/FireAdministration#16