Florian WildeandClaude Opus 5
2f247b3617
Vier Meilensteine fuer v0.3.0, 34 h geschaetzt: bedingte Schritte und Abschnitte (M23), Vier-Augen-Freigabe (M24), PDF-Uebergabeprotokoll (M25), weitere Schritt-Typen (M26). Die Reihenfolge ist begruendet: M23 zuerst, weil es als einziges am Datenmodell und an der Abschlussregel arbeitet; M26 zuletzt, weil UNTERSCHRIFT erst im PDF einen Zweck hat. Jedes Issue nennt die Entscheidungen, die zu treffen sind, mit Empfehlung und Begruendung. Bei M23 ist die entscheidende: eine Bedingung auf einer Variable liesse sich beim Start festschreiben wie bei #031, eine auf einem Schrittergebnis nicht — die Antwort entsteht erst waehrend der Arbeit. Beim Nummernvergeben einen Fund: vier Codestellen, sechs Changelog-Zeilen und der Doku-Pruefer nannten dreistellig die Tracker-Nummern 39 und 40 — gemeint waren die Issue-Dateien 025 und 026. Solange es diese Dateien nicht gab, fiel es niemandem auf; mit Phase 3 waere es eine falsche Spur geworden, und zwar in Kommentaren, die eine Codestelle begruenden. Behoben, und pruefe:doku prueft es ab jetzt: jeder dreistellige Verweis muss auf eine Issue-Datei zeigen. Gegenprobe mit einer erfundenen Nummer schlaegt an. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
69 lines
4.1 KiB
Markdown
69 lines
4.1 KiB
Markdown
# #040 M24 – Vier-Augen-Freigabe
|
||
|
||
**Status:** offen
|
||
**Im Tracker:** –
|
||
**Meilenstein:** v0.3.0
|
||
**Labels:** phase-3, backend, frontend
|
||
**Geschätzt:** 8 h **Tatsächlich:** –
|
||
|
||
## Ziel
|
||
|
||
Manche Arbeiten soll nicht derselbe abschließen, der sie gemacht hat: ein Firewall-Rollout, ein
|
||
Restore-Test, das Löschen eines Kontos. Heute kann jeder `TECHNIKER` jeden Lauf abschließen und
|
||
archivieren.
|
||
|
||
Gebraucht wird: eine Vorlage kann sagen „dieser Lauf braucht eine Freigabe“, und dann schließt ihn
|
||
ein **Zweiter** ab — nachweisbar im Protokoll.
|
||
|
||
## Zu entscheiden
|
||
|
||
- [ ] **Freigabe am Lauf oder am Schritt?** Empfehlung: **am Lauf**, gesetzt von der Vorlage.
|
||
Am Schritt wäre feiner und verführt zu Checklisten, in denen an fünf Stellen jemand warten
|
||
muss; am Lauf ist es eine Aussage über die Arbeit als Ganzes und erklärt sich von selbst.
|
||
Schritt-Freigaben bleiben möglich, wenn sich der Bedarf zeigt — `VorlagenSchritt.konfig` ist
|
||
ein Json.
|
||
- [ ] **Wer darf freigeben?** Empfehlung: ein eigenes Recht `freigeben`, standardmäßig bei `ADMIN`
|
||
und `REDAKTEUR` — **nicht** bei `TECHNIKER`. Begründung: die Vier-Augen-Regel soll nicht
|
||
davon abhängen, dass zufällig ein zweiter Techniker greifbar ist; und wer sie umgehen will,
|
||
braucht dann ein zweites Konto mit mehr Rechten, was im Protokoll steht.
|
||
- [ ] **Darf der Bearbeiter sich selbst freigeben?** **Nein**, und das ist der ganze Sinn. Geprüft
|
||
wird gegen `Schrittergebnis.aktualisiertVonId` **und** `Lauf.erstelltVonId`: wer irgendetwas
|
||
daran getan hat, gibt nicht frei. Ein `ADMIN`, der allein im Haus ist, kommt damit nicht
|
||
weiter — das ist eine bewusste Härte, und die Anleitung sagt es.
|
||
- [ ] **Was, wenn die Freigabe verweigert wird?** Empfehlung: ein Zustand „zurückgewiesen“ mit
|
||
Pflichtnotiz. Der Lauf geht zurück auf `IN_ARBEIT`, die Notiz steht im Protokoll und an der
|
||
Abarbeitungsansicht. Kein eigener `LaufStatus` — das wäre eine Änderung an einem Enum, das
|
||
vier Jahre halten soll; es genügt ein Feld plus Protokolleintrag.
|
||
|
||
## Aufgaben
|
||
|
||
- [ ] Migration: `freigabePflicht Boolean` an `VorlagenVersion`, dazu `freigegebenVonId`,
|
||
`freigegebenAm` und `freigabeNotiz` am `Lauf`; CHECK, dass `freigegebenVonId` und
|
||
`freigegebenAm` zusammen gesetzt sind (wie bei `abgeschlossenAm`)
|
||
- [ ] CHECK: `freigegebenVonId` ist **nicht** `erstelltVonId` — die Regel gehört in die Datenbank,
|
||
nicht nur in den Dienst (CLAUDE.md)
|
||
- [ ] Recht `freigeben` in `RECHTE`, Rollenmatrix-Test erweitern
|
||
- [ ] Dienst: `laufFreigeben(laufId, benutzer, notiz?)` und `laufZurueckweisen(laufId, benutzer,
|
||
notiz)`; Abschluss verlangt die Freigabe, wenn die Version sie fordert
|
||
- [ ] Die Prüfung „wer hat daran gearbeitet“ an **einer** Stelle, wie `laufMussVeraenderbarSein`
|
||
- [ ] Benachrichtigung: ein neuer `Meldeanlass` `LAUF_FREIGABE_OFFEN` an die Rollen mit dem Recht —
|
||
sonst wartet ein Lauf, von dem niemand weiß
|
||
- [ ] Oberfläche: Hinweis am Lauf („wartet auf Freigabe durch einen Zweiten“), Knöpfe für Freigeben
|
||
und Zurückweisen, Notizfeld; die Übersicht bekommt einen Filter „wartet auf meine Freigabe“
|
||
- [ ] Editor: Häkchen „dieser Lauf braucht eine Freigabe“ an der Version
|
||
- [ ] Druckansicht und PDF nennen Freigeber und Zeitpunkt
|
||
- [ ] Anleitung: Kapitel 02 (Läufe abarbeiten) und 04 (Vorlagen), mit dem Hinweis, dass ein
|
||
Einzelkämpfer sich nicht selbst freigeben kann
|
||
|
||
## Akzeptanzkriterien
|
||
|
||
- [ ] Test: ein Lauf mit Freigabepflicht lässt sich nicht abschließen, solange keine Freigabe steht
|
||
- [ ] Test: der Bearbeiter kann **nicht** freigeben — auch nicht als `ADMIN`
|
||
- [ ] Test: die Datenbank weist es ebenfalls ab (CHECK), nicht nur der Dienst
|
||
- [ ] Test: eine Rolle ohne `freigeben` wird abgewiesen, über jede Server Action
|
||
- [ ] Test: Zurückweisen verlangt eine Notiz und setzt den Lauf auf `IN_ARBEIT`
|
||
- [ ] Test: die Meldung geht an die Rollen mit dem Recht und nicht an alle
|
||
- [ ] Test: ein Lauf **ohne** Freigabepflicht verhält sich unverändert — bestehende Läufe und
|
||
Vorlagen merken nichts
|
||
- [ ] Am Handy kein horizontales Scrollen
|