Geprüft: das Modell trägt Fallarten, aber keine Dokumentarten

Vor Phase 3 geprüft, ob neue Dokumentarten ohne Code auskommen. Ergebnis:
für Fallarten ja, für alles andere nein.

CaseSection hängt fest an caseId. Ein Bußgeld ist keine Ermittlung, ein
Sonderarbeitsvertrag erst recht nicht. PersonnelFile.fields ist ein nacktes
JSON-Feld ohne Vorlage: ein Vertrag dort hätte keine Versionierung, keinen
Diff, keine Begründungspflicht, kein minClearance je Feld und keinen Eintrag
im Zugriffsprotokoll — genau die Eigenschaften, wegen derer das System gebaut
wird. Und würde man solche Dokumente behelfsweise als Case führen, stünden sie
in Fallliste, Fallzählung und Suche nach Ermittlungen.

Dazu ein zweiter Befund aus den beiden Beispieldokumenten: sie sind
grundverschieden gebaut. Der Vorfallsbericht ist ein Formular und wird von den
vorhandenen Feldtypen vollständig abgedeckt. Der Sonderarbeitsvertrag ist
fester Vertragstext mit Platzhaltern, Paragraphen und Unterschriftenzeilen —
dafür reicht eine Feldliste nicht.

Empfehlung in docs/13: eine gemeinsame Dokumentebene, additiv, mit denselben
Zusicherungen wie CaseSection. Case, CaseSection und CaseEntry bleiben
unangetastet.

Nichts davon gebaut. Die Entscheidung steht als erster Punkt in Phase 3.

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

docs/13-entscheidungen.md

@@ -180,6 +180,76 @@ Präfix und ihre Stellenzahl mit, der Nummernkreis läuft je Präfix und Jahr. `
 bekommt dafür einen zusammengesetzten Schlüssel aus Präfix und Jahr statt nur dem Jahr.
 Bestehende Aktenzeichen bleiben, wie sie sind.
 
+## Offen: Dokumentarten über die Fallakte hinaus
+
+**Noch nicht entschieden, noch nichts gebaut.** Geprüft vor Phase 3, weil die Antwort den
+Zuschnitt von Phase 3 und 4 bestimmt.
+
+Langfristig sollen weitere Dokumentarten dazukommen: Vorfallsberichte, Bußgelder,
+Sonderarbeitsverträge, Beurteilungen. Die Frage ist, ob das Modell das trägt, ohne dass für
+jede neue Art Code geschrieben wird.
+
+### Was heute schon trägt
+
+Eine neue **Fallart** braucht keine Zeile Code. `CaseTemplate.fields` ist ein JSON-Feld,
+Vorlagen sind versioniert, und das Rendern der Abschnitte wird datengetrieben gebaut. Eine
+neue Vorlage anzulegen ist eine Zeile in der Datenbank, kein Deployment. Mit dem Präfix je
+Vorlage bekommt jede Fallart auch ihren eigenen Nummernkreis.
+
+### Was heute nicht trägt
+
+`CaseSection` hängt fest an `caseId`. **Alles, was kein Ermittlungsfall ist, hat keinen
+Platz.** Ein Bußgeld gegen einen Mitarbeiter ist keine Ermittlung. Ein Sonderarbeitsvertrag
+erst recht nicht.
+
+`PersonnelFile.fields` ist ein nacktes JSON-Feld ohne Vorlage. Ein Vertrag, der dort landet,
+hätte nichts von dem, was eine Fallakte selbstverständlich hat: keine Versionierung, keinen
+Diff, keine Begründungspflicht, kein `minClearance` je Feld, keinen Eintrag im
+Zugriffsprotokoll. Genau die Eigenschaften, um derentwillen das System gebaut wird.
+
+Würde man Bußgelder und Verträge behelfsweise als `Case` führen, stünden sie in der
+Fallliste, in der Fallzählung und in der Suche nach Ermittlungen. Das ist kein Schönheits-
+fehler, sondern eine falsche Aussage über den Bestand.
+
+### Zwei Bauformen von Dokument, nicht eine
+
+Die beiden vorliegenden Beispiele sind grundverschieden aufgebaut:
+
+| | Vorfallsbericht | Sonderarbeitsvertrag |
+|---|---|---|
+| Aufbau | beschriftete Felder, ausgefüllt | fester Vertragstext mit Platzhaltern |
+| Vorlage liefert | Feldliste | den Wortlaut selbst, samt Paragraphen |
+| Nutzer trägt ein | Werte | `[Name]`, `[Datum]`, `[Tätigkeit]` |
+| Ausgabe | eine Seite | mehrere Seiten mit Unterschriftenzeilen |
+
+Die Feldtypen aus `docs/05-akten-und-vorlagen.md` decken den **Bericht vollständig** ab
+(`multiselect` für die Berichtsart, `select` für die Gefahreneinschätzung, `date`, `person`,
+`longtext`). Für den **Vertrag reichen sie nicht**: fester Fließtext, Überschriften und
+Unterschriftenzeilen sind keine Formularfelder. Dafür braucht die Vorlage einen Textkörper
+mit Platzhaltern statt einer Feldliste.
+
+### Empfehlung
+
+Eine gemeinsame Dokumentebene, additiv statt als Umbau:
+
+- `DocumentTemplate` — was heute `CaseTemplate` ist, plus `scope` (Fall, Person,
+  eigenständig), `numberPrefix`, und `kind` (Formular oder Textkörper)
+- `Document` — eine Ausfertigung, mit Vorlage, Klassifizierung, Nummer und einem Besitzer:
+  Fall, Personalakte oder nichts
+- `DocumentSection` und `DocumentSectionVersion` — dieselben Zusicherungen wie bei
+  `CaseSection`: versioniert, `minClearance` je Feld, Diff, Protokoll
+
+`Case`, `CaseSection` und `CaseEntry` bleiben unangetastet. Eine Fallakte kann Dokumente
+tragen, eine Personalakte auch, und ein Bußgeld steht für sich.
+
+Damit ist eine neue Dokumentart wieder das, was sie sein soll: **ein Datensatz, kein
+Deployment.**
+
+Zu klären, bevor gebaut wird: ob die Abschnitte einer Fallakte langfristig ebenfalls über
+diese Ebene laufen sollen. Dafür spräche, dass es dann nur einen Mechanismus gibt; dagegen,
+dass `docs/04` und `docs/05` `CaseSection` ausdrücklich benennen und der Umbau bestehende
+Akten anfasst.
+
 ## Prisma 7
 
 Die Dokumente nennen nur „Prisma + PostgreSQL 16". Eingesetzt wird Prisma 7, die