Personalakte als Aktenblatt, Status als Etiketten, Verknüpfen von beiden Seiten

Das Formular der Personalabteilung ist übernommen, nicht durch eine
Bildschirmansicht ersetzt: schwarzer Rahmen, Kopf mit Kennung und
Klassifizierungsbalken, Raster aus fünf Spalten, Unterschriftenzeilen,
Fußzeile. Es steht bewusst außerhalb des Design-Systems — es wird gedruckt und
muss auf Papier aussehen wie das Blatt daneben.

Datengetrieben bleibt es trotzdem. Kein Feld steht im Programm: sheetTitle und
sheetSubtitle an der Vorlage, span für die Zellbreite, rows für das Lichtbild,
dateKey für das Datum unter einer Unterschrift, slot für den
Klassifizierungsbalken. Eine weitere Dokumentart mit layout = DOSSIER braucht
keine Zeile Code.

Der Balken zeigt die Foundation-Stufe aus der neuen Tabelle
FoundationClearance. Sie ist Inhalt, kein Zugriff — was jemand sehen darf,
entscheidet weiterhin allein die interne Stufe. Ohne Auswahl bleibt der Balken
neutral, statt eine Einstufung zu behaupten.

Die Dienstnummer ist entfallen, es gibt sie nicht. Der Status ist zu mehreren
Etiketten geworden: "Gekündigt" und "Verhaftet" schließen einander nicht aus.
Unbekannte Schlüssel werden verworfen und die Reihenfolge kommt aus der
Konfiguration, nicht aus der Eingabe.

PersonnelAssignment hängt AfiS-Mitglieder an eine Person — Aktenführung,
Ermittler, Ansprechpartner — und ist zugleich der ausnahmsweise Zugang, wie
CaseParticipant bei der Fallakte. Betroffen zu sein gibt weiterhin keinen
Zugang: das ist eine Eigenschaft der Person, die Zuordnung eine Entscheidung
der Abteilung.

Fall und Person lassen sich von beiden Seiten verknüpfen und schon beim
Anlegen einer Fallakte. Alle drei Wege laufen in addParticipant zusammen.

Noch offen: das Lichtbild. Feldtyp und Platz stehen, hochladen kommt mit der
Prüfkette in Phase 5 — ein Bild als Data-URL im Abschnittswert verstiesse
gegen harte Regel 4.

102 Tests im Web-Paket, davon sechs auf dem gerenderten Blatt selbst.

packages/db/prisma/schema.prisma

@@ -47,6 +47,7 @@ model User {
   sessions       Session[]
   personnelFiles PersonnelFile[]
   participations CaseParticipant[]
+  assignments    PersonnelAssignment[]
   exclusions     CaseExclusion[]
   watches        Watch[]
   readMarkers    ReadMarker[]
@@ -157,6 +158,12 @@ model DocumentTemplate {
   /// Bestimmt allein das Aussehen, nicht den Zugriff. Siehe docs/08.
   layout DocumentLayout @default(FORM)
 
+  /// Kopfzeilen des Aktenblatts (layout = DOSSIER). Stehen in der Vorlage,
+  /// damit eine weitere Dokumentart dieselbe Bauform mit eigener Beschriftung
+  /// verwenden kann.
+  sheetTitle    String?
+  sheetSubtitle String?
+
   /// Muster des Aktenzeichens, siehe docs/13-entscheidungen.md. Die Abteilung
   /// fuehrt gewachsene Praefixe wie "AKT-PA"; der Nummernkreis laeuft je
   /// Praefix und Jahr, damit zwei Fallarten sich nicht in die Quere kommen.
@@ -192,6 +199,9 @@ enum DocumentLayout {
   PROSE
   /// ein einzelnes Freitextfeld, dargestellt wie ein Vermerk
   NOTE
+  /// Aktenblatt der Foundation: schwarzer Rahmen, Kopf mit Kennung,
+  /// Klassifizierungsbalken, Feldraster, Unterschriftenzeilen, Fusszeile
+  DOSSIER
 }
 
 // ---------------------------------------------------------------------------
@@ -439,16 +449,22 @@ enum LinkKind {
 // Personalakten
 // ---------------------------------------------------------------------------
 
+/// Akte zu einer Person. Ueberwiegend zu **Externen** — Sicherheitsdienst,
+/// Zeugen, Vertragspartner — die kein Discord-Konto haben. `userId` bleibt
+/// deshalb der Ausnahmefall, nicht die Regel.
 model PersonnelFile {
-  id             String  @id @default(uuid(7))
-  userId         String? // null bei Personen ohne Discord-Konto
-  displayName    String
-  serviceNumber  String? @unique
-  rank           String?
-  department     String?
-  status         String?
-  classification Int     @default(1)
-  fields         Json    @default("{}")
+  id          String  @id @default(uuid(7))
+  userId      String? // null bei Personen ohne Discord-Konto
+  displayName String
+  rank        String?
+  department  String?
+
+  /// Mehrere Etiketten zugleich: "Gekuendigt" und "Verhaftet" schliessen
+  /// einander nicht aus. Die Werte sind Schluessel aus PersonnelStatusTag.
+  statusTags String[] @default([])
+
+  classification Int  @default(1)
+  fields         Json @default("{}")
   /// Freitext im Kopf der Akte, etwa "kein Discord-Konto, Aktenlage aus 2025".
   note           String?
 
@@ -458,17 +474,71 @@ model PersonnelFile {
 
   searchVector Unsupported("tsvector")?
 
-  user         User?             @relation(fields: [userId], references: [id])
+  user         User?                 @relation(fields: [userId], references: [id])
   participants CaseParticipant[]
   documents    Document[]
+  assignments  PersonnelAssignment[]
 
   @@index([displayName])
   @@index([userId])
   @@index([classification])
+  @@index([statusTags], type: Gin)
   @@index([searchVector], map: "personnel_search_idx", type: Gin)
   @@index([displayName(ops: raw("gin_trgm_ops"))], map: "personnel_name_trgm_idx", type: Gin)
 }
 
+/// Auswahl der Status-Etiketten, im Adminbereich pflegbar. Die Namen sind
+/// Daten, keine Oberflaechentexte — siehe CLAUDE.md, Sprachkonvention.
+model PersonnelStatusTag {
+  key        String  @id // "tot", "gekuendigt"
+  name       String // "Tot", "Gekuendigt"
+  colorToken String  @default("stamp-0")
+  sortOrder  Int     @default(0)
+  isActive   Boolean @default(true)
+
+  @@index([isActive, sortOrder])
+}
+
+/// Ein AfiS-Mitglied, das an dieser Personalakte haengt: Bearbeiter,
+/// ermittelnder Beamter, Ansprechpartner.
+///
+/// Wie `CaseParticipant` bei der Fallakte ist das zugleich der Weg zum
+/// **ausnahmsweisen Zugang**: wer hier eingetragen ist, liest die Akte
+/// unabhaengig von seiner Freigabestufe. Siehe docs/13-entscheidungen.md.
+model PersonnelAssignment {
+  id              String            @id @default(uuid(7))
+  personnelFileId String
+  userId          String
+  role            AssignmentRole
+  addedById       String?
+  createdAt       DateTime          @default(now())
+
+  personnelFile PersonnelFile @relation(fields: [personnelFileId], references: [id], onDelete: Cascade)
+  user          User          @relation(fields: [userId], references: [id], onDelete: Cascade)
+
+  @@unique([personnelFileId, userId, role])
+  @@index([userId])
+}
+
+enum AssignmentRole {
+  /// fuehrt die Akte
+  HANDLER
+  /// ermittelt gegen oder ueber die Person
+  INVESTIGATOR
+  /// Ansprechpartner, ohne eigene Ermittlung
+  CONTACT
+}
+
+/// Die Freigabestufen der Foundation, wie sie im Kopf eines Dokuments stehen.
+/// **Sie steuern keinen Zugriff** — das tut allein ClearanceLevelConfig.
+/// Siehe docs/13-entscheidungen.md, "Zwei Freigaben im Kopf".
+model FoundationClearance {
+  level     Int    @id // 1..5
+  name      String // "Streng Geheim"
+  colorHex  String // Balkenfarbe im Aktenblatt
+  sortOrder Int    @default(0)
+}
+
 // ---------------------------------------------------------------------------
 // Dokumente
 // ---------------------------------------------------------------------------