Die Dokumentebene aus docs/13 ist gebaut, additiv: Document, DocumentSection
und DocumentSectionVersion neben Case, CaseSection und CaseEntry. Ein Dokument
hängt an einer Fallakte, an einer Personalakte oder an nichts, höchstens an
einem — gesichert durch eine CHECK-Bedingung. Es gibt kein DELETE; eine
Zurücknahme lässt einen Grabstein stehen, der auch für den Admin zu ist.
Eine neue Dokumentart ist damit ein Datensatz, kein Deployment. Im Seed stehen
vier: vermerk, vorfallsbericht, sonderarbeitsvertrag (mehrseitiger Vertragstext
mit Platzhaltern und Unterschriftenzeilen) und bussgeld.
Zwei Umbenennungen, beide von Hand migriert, damit die vorhandenen Zeilen und
Zählerstände stehen bleiben:
- CaseTemplate -> DocumentTemplate, plus uses[] und layout
- CaseCounter -> NumberSeries, ein Nummernkreis je Präfix für Aktenzeichen
und Dokumentnummern
Die Regeln für Abschnitte stehen jetzt einmal in lib/sections/render.ts und
gelten für Fallakten und Dokumente gleichermaßen. Die Frage aus docs/13, ob
CaseSection langfristig in die Dokumentebene wandert, ist damit verneint und
begründet.
Rückverweise auf der Personalakte laufen durch visibleCaseWhere, die Zahl
daneben entsteht aus dem gefilterten Ergebnis. Auch die Rollengruppe
verschwindet mit, sonst verriete "Betroffener" ohne Eintrag die Ermittlung.
Die eigene Personalakte ist keine Ausnahme von der Freigabestufe.
Vier neue Rechte: document.create, .edit, .finalize, .retract. Das letzte
steht bei den zurückgehaltenen, es greift in Geschriebenes ein.
91 Tests im Web-Paket, 15 in der Datenbank, 28 e2e. Größte Route 118 kB
gegen das Budget von 120 kB — die Luft wird knapp.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Entschieden und festgehalten: jede Akte trägt Kurzvermerke und Dokumente, die
Fallakte zusätzlich ihre Abschnitte. Die Trennung aus docs/05 bleibt damit
bestehen.
Eine Vorlage ist jetzt eine geordnete Liste von Bausteinen. Manche nehmen eine
Eingabe entgegen, andere liefern festen Text mit Platzhaltern. Damit tragen
dieselbe Struktur ein Vorfallsbericht, der fast nur aus Eingaben besteht, und
ein Sonderarbeitsvertrag, der fast nur aus Paragraphen und Unterschriftenzeilen
besteht. Eine neue Dokumentart bleibt ein Datensatz, kein Deployment.
Der Schwärzungs-Parser gibt Segmente zurück, nicht den vollen Text mit einem
Sichtbarkeits-Flag: was der Client ausblenden müsste, hat er dann schon. Die
Balkenlänge wird auf ein Raster von acht Zeichen gerundet, sonst verrät sie,
wie lang der geschwärzte Name war.
Ein Test vergleicht den TypeScript-Parser gegen die SQL-Funktion
strip_redactions aus der Migration. Laufen die beiden auseinander, findet die
Suche einen Begriff, den die Ansicht verbirgt — und der Treffer allein verrät
ihn dann.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
Aus den echten Dokumenten der Abteilung, die bisher als Google Docs geführt
wurden.
Die Dokumente tragen zwei Angaben nebeneinander, "Foundation-Freigabe" und
"Interne Freigabe". Den Zugriff steuert allein die interne Freigabe; die
Foundation-Freigabe wird ein gewöhnliches Vorlagenfeld. Mit zwei sperrenden
Achsen bekäme jede Sichtbarkeitsprüfung, jede Trefferzahl und jeder
Negativtest eine zweite Dimension — Sichtbarkeit wird an genau einer Stelle
entschieden, sonst ist sie nicht mehr nachweisbar.
Das Aktenzeichen der Abteilung lautet AKT-PA-2026-62843, das Glossar schrieb
AfiS-2026-0042 vor. Das Muster gehört zur Vorlage, nicht ins Programm:
Präfix und Stellenzahl je Fallart, Nummernkreis je Präfix und Jahr.
docs/08 kannte nur den Export einer ganzen Akte. Dokumente wie der
Sonderarbeitsvertrag hängen aber an einer Person, nicht an einer Ermittlung,
und brauchen einen eigenen Weg: Deckblatt, Dokument, Fußzeile, kein Verlauf.
Stufe des Abrufers, Wasserzeichen und Protokollierung gelten dort genauso.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Zwei Festlegungen, beide in docs/13-entscheidungen.md begründet.
case.delete ist gestrichen. Der Lebenszyklus kennt ARCHIVED und SEALED, und
eine Akte mit Verlaufseinträgen liesse sich ohnehin nicht hart löschen, weil
CaseEntry nach Regel 2 unlöschbar ist und der Fremdschlüssel das Kaskadieren
blockiert. Das ist die konsequente Fortsetzung von Regel 2 eine Ebene höher.
Niemand klassifiziert eine Akte höher als die eigene Freigabestufe. Sonst
entstehen Akten, die ihr Urheber nicht mehr sehen kann, und die Frage "wer
konnte das lesen" wird im Nachhinein schwer beantwortbar.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Lesen war geregelt, Schreiben nicht: bisher stand nirgends, dass jemand mit
Stufe 2 keine Stufe-4-Akte anlegen darf. Ohne die Regel erzeugt man Akten, die
man selbst nicht mehr sehen kann, und umgeht die Sichtbarkeitsprüfung.
Festgehalten in docs/03-auth-und-rechte.md, als Aufgaben in Phase 2:
Klassifizierung nie über der eigenen Stufe, Ändern und Löschen nur mit
Lesezugriff, Umklassifizierung mit SYSTEM-Eintrag und AuditLog. Eine
Herabstufung ist der heikelste Vorgang im System — sie macht Inhalte für Leute
sichtbar, die sie vorher nicht sehen durften.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die Testläufe hatten dort 70 erfundene Rollen, 112 Nutzer und 40 Akten
hinterlassen. Die Rollenverwaltung zeigte deshalb "Gast" siebzehnmal, echte
Rollen doppelt und in willkürlicher Reihenfolge.
Aufräumen allein reicht nicht: CaseEntry, CaseEntryVersion und AuditLog lassen
sich nach harter Regel 2 nicht löschen. Was ein Test dort anlegt, bleibt für
immer stehen — in Phase 2 hätte das die Fallliste unbrauchbar gemacht.
Tests laufen deshalb gegen <datenbank>_test auf demselben Server. pnpm test legt
sie an, migriert und seedet sie vorher. Über TEST_DATABASE_URL lässt sich ein
anderes Ziel setzen.
Dazu die Abschnitte der Rollenverwaltung in der Reihenfolge, in der die
Abteilung ihre Rollen aufzählt: Ränge, Zugehörigkeit, Zugang. Innerhalb eines
Abschnitts entscheidet die Position auf dem Discord-Server, oben die höchste.
Damit steht die Hierarchie an einer Stelle, die ohnehin gepflegt wird.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Auth.js übernimmt nur den OAuth-Ablauf mit state und PKCE, Scope identify. Das
Zugangstoken des Nutzers wird danach verworfen: die Rollen holt der Bot mit
seinem eigenen Token. Die Sitzung steht in der Datenbank, im Cookie liegt nur
userId und sessionId. Ohne die Zeile in Session ist das Cookie wertlos, und nur
so lässt sich eine Sitzung zurückziehen.
Wer sich anmelden darf, steckt in lib/auth/signInPolicy.ts statt im Callback:
das ist die Regel, an der alles hängt, und sie gehört einzeln prüfbar. Kein
Guild-Mitglied, kein Zugang. Keine Rolle mit grantsMembership, kein Zugang.
Notfall-Admins umgehen die Rolle, aber nicht die Guild-Mitgliedschaft.
RoleMapping trägt jetzt grantsMembership, category und isPresent. Der Worker
spiegelt jede Rolle der Guild hierher, damit im Adminbereich nichts von Hand
eingetragen werden muss. Gelöschte Rollen werden nicht entfernt, sondern auf
isPresent = false gesetzt: beim Umzug auf den echten Server bleiben sie als
Vorlage stehen.
Der Worker gleicht über Gateway-Ereignisse und zusätzlich alle fünf Minuten
voll ab. Verliert jemand seine AfiS-Rolle, beendet er dessen Sitzungen sofort
und setzt isActive auf false — der Datensatz bleibt, damit Autorenangaben in
alten Akten gültig bleiben. Das passiert im Worker und nicht in der Web-App,
weil es dort erst beim nächsten Request des Betroffenen griffe.
Zwei Widersprüche der Dokumente aufgelöst, festgehalten in
docs/13-entscheidungen.md: der Ausschluss schlägt auch den Admin (das
Codebeispiel in 03-auth-und-rechte.md übergeht ihn, die Reihenfolge eine Zeile
darüber nicht), und versiegelte Akten fallen im Where-Fragment heraus statt in
einer Prüfung danach.
45 Tests, davon die Negativfälle aus docs/03 gegen eine echte Datenbank: Stufe 2
sieht die Stufe-4-Akte nicht und findet sie auch nicht in der Trefferzahl, ein
Ausgeschlossener mit Stufe 5 kommt nicht heran, ein Rollenentzug beendet die
Sitzungen, und ein Ausfall der Discord-API sieht nicht aus wie eine verweigerte
Mitgliedschaft.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Der Discord-Server hat drei Sorten Rollen, die Dokumente kannten nur eine:
Zugehörigkeit (AfiS, Personalabteilung) als Türsteher, Rangrollen für die
Rechte, Zugangsrollen für die Freigabestufe. Das bestehende RoleMapping trägt
das fast, es fehlt nur der Türsteher. Die beiden Felder dafür kommen mit
Phase 1, die Struktur ist in docs/13-entscheidungen.md festgehalten.
Die Freigabestufen heißen jetzt wie die Zugangsrollen: Unclassified,
Restricted Access, Confidential Access, Sensitive Access, Critical Operations,
Executive Oversight. Fachbegriffe der Domäne bleiben englisch, auch in einer
deutschen Oberfläche.
Die Bezeichnungen sind damit Daten in ClearanceLevelConfig, nicht mehr
Oberflächentext in lib/i18n/de.ts: sie sind im Adminbereich änderbar, und was
der Leiter ändern kann, gehört nicht in eine Übersetzungsdatei. StampMark
bekommt den Namen hereingereicht.
Vier neue Tests prüfen den Zustand, den der Seed herstellt, gegen die
Datenbank statt gegen eine Konstante im Code.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
CLAUDE.md und README.md verweisen auf docs/, die Dateien lagen aber im
Wurzelverzeichnis. Verschoben.
docs/13-entscheidungen.md hält fest, wo die Dokumente sich widersprechen und
wie es aufgelöst wurde. Der wichtigste Punkt: 04-datenmodell.md verlangt eine
Regel, die jedes UPDATE auf CaseEntryVersion verwirft, 05-akten-und-vorlagen.md
verlangt, dass eine Umklassifizierung rückwirkend auf alle Versionen wirkt.
Beides zusammen geht nicht. Aufgelöst über einen Trigger, der die Tabelle
anhängend hält, aber das Anheben von minClearance zulässt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
