Punkt 1 und 2 der Wünsche, plus zwei Lücken, die dabei sichtbar wurden.
**Suche.** Wer nach Alvarez sucht, landet auf den Fallakten und erfährt nie,
dass es dazu auch eine Personalakte gibt: die Suche fand sie, aber hinter einem
Reiter, auf den nichts hindeutete. Die Reiter tragen jetzt ihre Trefferzahl,
und ein leeres Ergebnis nennt ausdrücklich, wo etwas liegt.
Dabei fiel auf, dass searchPersonnel das Recht personnel.read nicht prüfte. Die
Kommandopalette tat es, die Aktenseite tat es, die Suche nicht — über
/suche?kind=personnel kam jeder mit ausreichender Stufe an eine Liste aller
Personalakten mit Namen, Dienstgrad und Etiketten. Die Prüfung steht jetzt
dort, wo diese Akten herausgegeben werden. Die Trefferzahl einer Art, die es
für den Nutzer nicht gibt, ist null und nicht 0: eine Null wäre die Auskunft
„hier ist nichts", und die steht ihm nicht zu.
**Täter und Mittäter** als Beteiligtenrollen — und damit wurde eine ältere
Lücke offensichtlich: ein Beteiligter durfte die Akte lesen, gleich in welcher
Rolle. Bei „Betroffener" fiel das nicht auf, bei „Täter" wäre es offensichtlich
falsch. Der Beschuldigte hätte die Ermittlung gegen sich selbst mitgelesen.
Die Beteiligtenliste beantwortet zwei Fragen: wer bearbeitet den Fall, und um
wen geht es darin. Nur die erste ist eine Berechtigung. WORKING_ROLES nennt die
drei, die die Akte öffnen; Zeuge, Betroffener, Täter und Mittäter öffnen
nichts. Das gilt an allen vier Stellen, die auf Beteiligung prüften:
Aktenzugriff, Dokumentzugriff über die besitzende Akte, „meine Fälle" und der
Filter „nur meine".
Zwei bestehende Tests hatten die alte Annahme festgeschrieben und benutzten
WITNESS, um Zugriff zu belegen; sie prüfen jetzt mit INVESTIGATOR.
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>
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>
