Abteilungen als Ebene über der Personalakte

Punkt 3 der Wünsche.

Die Abteilung stand als Freitext in der Personalakte. Damit liess sich nichts
fragen: „SHD", „Shd" und „Sicherheitsdienst" waren drei Abteilungen. Sie ist
jetzt ein eigenes Modell, im Adminbereich verwaltbar, und die drei vorhandenen
Freitexte sind in der Migration zu Abteilungen geworden.

**Eine Fallakte trägt keine Abteilung.** Sie gehört zu einer, wenn eine
beteiligte Person ihr angehört — abgeleitet über CaseParticipant und die
Personalakte. Eine eingetragene Zuordnung wäre nach zwei Wochen falsch: Leute
wechseln, Beteiligte kommen dazu, und niemand pflegt das nach. Dasselbe gilt
für die Dokumente: ein Dokument unmittelbar an der Abteilung wäre halb
verdrahtet, weil die Vorlagen über TemplateUse nur Fall- und Personalakte
kennen.

Die Abteilungsseite zeigt Mitglieder, abgeleitete Fälle und Dokumente,
Vermerke, Chat und ein Kreisdiagramm der Fallarten; die Übersicht eines über
alle Abteilungen. Das Diagramm ist serverseitig gerendertes SVG — eine
Bibliothek wäre das Teuerste auf der Seite gewesen. Die Segmente sind
Abstufungen von --steel und nicht die Stufenfarben: ein Tortenstück in Oxidrot
würde als „streng geheim" gelesen.

Die Zusammenfassung ist die gefährliche Stelle. Eine Abteilungsseite fasst
zusammen, was einzeln längst geschützt ist, und eine Zusammenfassung, die nicht
filtert, verrät mehr als jede Einzelansicht. Deshalb läuft hier jede Liste und
jede Zahl durch dieselben Fragmente wie überall; ein Test prüft, dass die Summe
der Diagrammanteile mit der Länge der Liste übereinstimmt. Wo jemand
Personalakten gar nicht sehen darf, steht null und keine Null.

Vermerke erben Regel 2 unverändert: kein DELETE, Version bei jeder Änderung,
Grabstein bei jeder Zurücknahme, als Regel und Trigger in der Datenbank. Ohne
Korrekturkette, Anhänge und Karenzzeit — was Beweiswert hat, gehört in eine
Fallakte.

Nebenbei: das Zugriffsprotokoll hängt jetzt am dafür vorgesehenen Recht
audit.read statt an admin.

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

packages/db/prisma/schema.prisma

@@ -475,7 +475,10 @@ model PersonnelFile {
   userId      String? // null bei Personen ohne Discord-Konto
   displayName String
   rank        String?
-  department  String?
+  /// Die Abteilung, der diese Person angehoert. Vorher stand hier ein
+  /// Freitext; als Beziehung laesst sich fragen, was es zu einer Abteilung
+  /// insgesamt gibt. Siehe docs/13-entscheidungen.md.
+  departmentId String?
 
   /// Mehrere Etiketten zugleich: "Gekuendigt" und "Verhaftet" schliessen
   /// einander nicht aus. Die Werte sind Schluessel aus PersonnelStatusTag.
@@ -493,6 +496,7 @@ model PersonnelFile {
   searchVector Unsupported("tsvector")?
 
   user         User?                 @relation(fields: [userId], references: [id])
+  department   Department?           @relation(fields: [departmentId], references: [id], onDelete: SetNull)
   messages     ChatMessage[]
   participants CaseParticipant[]
   documents    Document[]
@@ -500,6 +504,7 @@ model PersonnelFile {
 
   @@index([displayName])
   @@index([userId])
+  @@index([departmentId])
   @@index([classification])
   @@index([statusTags], type: Gin)
   @@index([searchVector], map: "personnel_search_idx", type: Gin)
@@ -721,6 +726,7 @@ model ChatMessage {
   id              String @id // clientseitig erzeugt, UUIDv7
   caseId          String?
   personnelFileId String?
+  departmentId    String?
   authorId    String
   body        String
   replyToId   String?
@@ -736,12 +742,14 @@ model ChatMessage {
 
   case          Case?          @relation(fields: [caseId], references: [id], onDelete: Cascade)
   personnelFile PersonnelFile? @relation(fields: [personnelFileId], references: [id], onDelete: Cascade)
+  department    Department?    @relation(fields: [departmentId], references: [id], onDelete: Cascade)
   replyTo   ChatMessage?   @relation("replies", fields: [replyToId], references: [id])
   replies   ChatMessage[]  @relation("replies")
   reactions ChatReaction[]
 
   @@index([caseId, createdAt(sort: Desc)])
   @@index([personnelFileId, createdAt(sort: Desc)])
+  @@index([departmentId, createdAt(sort: Desc)])
   @@index([authorId])
   @@index([replyToId])
   @@index([mentions], type: Gin)
@@ -837,6 +845,82 @@ model NotificationOutbox {
   @@index([caseId])
 }
 
+/// Eine Abteilung der Foundation.
+///
+/// Fast jede Person gehoert einer an, und die Abteilung ist die Ebene ueber
+/// der Personalakte: was zu ihr aktenkundig ist, ergibt sich aus ihren
+/// Mitgliedern. Deshalb traegt eine Fallakte **keine** Abteilung — die
+/// Zuordnung entsteht ueber die Beteiligten und deren Personalakten und ist
+/// damit immer aktuell. Siehe docs/13-entscheidungen.md.
+model Department {
+  id          String  @id @default(uuid(7))
+  key         String  @unique // "SHD"
+  name        String
+  description String?
+
+  /// Wer diese Stufe nicht hat, sieht die Abteilung nicht. Sie steht auf 0,
+  /// solange nichts dagegen spricht: dass es den Sicherheitsdienst gibt, ist
+  /// kein Geheimnis. Was in ihm aktenkundig ist, filtert weiterhin jede Liste
+  /// fuer sich.
+  minClearance Int     @default(0)
+  isArchived   Boolean @default(false)
+
+  createdById String?
+  createdAt   DateTime @default(now())
+  updatedAt   DateTime @updatedAt
+
+  members   PersonnelFile[]
+  messages  ChatMessage[]
+  entries   DepartmentEntry[]
+
+  @@index([isArchived, name])
+}
+
+/// Ein Vermerk an einer Abteilung.
+///
+/// Dieselbe Zusicherung wie beim Verlauf einer Akte, in schmalerer Form: es
+/// gibt kein DELETE, jede Aenderung erzeugt eine Version, jede Zuruecknahme
+/// laesst einen Grabstein stehen. Was fehlt, sind die Teile, die nur eine
+/// Ermittlung braucht — Korrekturkette, Anhaenge, Karenzzeit. Ein
+/// Abteilungsvermerk ist ein laufendes Protokoll, kein Beweismittel.
+model DepartmentEntry {
+  id           String   @id // clientseitig erzeugt, UUIDv7
+  departmentId String
+  body         String
+  minClearance Int      @default(0)
+  authorId     String // unveraenderlich
+  createdAt    DateTime @default(now()) // unveraenderlich
+
+  version    Int       @default(1)
+  editedAt   DateTime?
+  editedById String?
+
+  retractedAt      DateTime?
+  retractedById    String?
+  retractionReason String?
+
+  department Department               @relation(fields: [departmentId], references: [id], onDelete: Cascade)
+  versions   DepartmentEntryVersion[]
+
+  @@index([departmentId, createdAt(sort: Desc)])
+  @@index([authorId])
+}
+
+/// Strikt anhaengend, enthaelt jeweils den VORHERIGEN Stand.
+model DepartmentEntryVersion {
+  id           String          @id @default(uuid(7))
+  entryId      String
+  version      Int
+  body         String
+  minClearance Int
+  editedById   String
+  editedAt     DateTime        @default(now())
+  entry        DepartmentEntry @relation(fields: [entryId], references: [id])
+
+  @@unique([entryId, version])
+  @@index([entryId, version(sort: Desc)])
+}
+
 /// Suchindex, **je Freigabestufe ein Vektor**.
 ///
 /// Der Vektor zur Stufe N enthaelt alles, was ein Leser dieser Stufe sehen