Gemessen statt vermutet: die Datenschicht war nie das Problem. resolvePermissions
unter 1 ms, loadDashboard 11 ms, searchCases 5 ms, die Abteilungsabfragen 3–4 ms.
Die Sekunden kamen aus zwei Ecken.
**Fehlende Ladegrenzen.** Den meisten Routen fehlte loading.tsx - unter anderem
der Übersicht, der Suche und dem gesamten Adminbereich. Ohne diese Datei hat
der Router keine Grenze, wartet stumm auf die fertige Serverantwort, und bis
dahin steht die alte Seite: man klickt, und scheinbar passiert nichts. Neunzehn
Skelette nachgetragen, jede Route hat jetzt eine.
Dazu quittiert der geklickte Link den Klick selbst, mit einem ruhig
pulsierenden Punkt statt eines Kreisels. Regel 5 verbietet den
Blockade-Spinner, der Inhalt ersetzt; eine Quittung im Link ersetzt nichts, und
die eigentliche Antwort auf das Warten bleibt das Skelett.
**Webpack.** Der Entwicklungsserver übersetzte jede Route beim ersten Aufruf
neu: 8 s für die Übersicht, 2,8 s für die Fallliste. Mit Turbopack sind es
0,43 s beim ersten Aufruf und 0,1 s danach. Nur pnpm dev, der Produktionsbau
bleibt unverändert. Gegengeprüft, dass die Anmeldeseite mit CSS und ohne
Fehler im Log rendert.
Nebenbei die eine Abfrage, die schlecht skalierte: die Übersicht zählte
ungelesene Nachrichten mit einer Abfrage je Ort - bei hundert Akten hundert
Hin- und Rückwege. Jetzt ein einziges groupBy mit der Lesemarke im ODER-Zweig
des jeweiligen Ortes. Ein Test prüft, was dabei leicht verrutscht: die Marke
gilt je Ort, und eigene Nachrichten zählen nie mit.
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.
Vier der acht Änderungswünsche.
**Knöpfe.** Rund vierzig der siebzig Knöpfe waren blosser Text in Akzentfarbe,
von einem Link nicht zu unterscheiden. Jeder trägt jetzt Rahmen und
Grundfläche, über die Klasse .btn an einer Stelle definiert statt siebzigmal
als Klassenkette. Beim Drücken zieht der Knopf sich zusammen und bekommt einen
inneren Ring - er wirkt kurz dicker, ohne dass die Rahmenbreite sich ändert und
das Umfeld springt; die Rückmeldung setzt ohne Verzögerung ein und klingt
langsam ab, sonst bliebe ein kurzer Klick unsichtbar.
Dazu die neue Regel: Flächen bleiben eckig, alles Bedienbare ist rund. Damit
ist die Rundung eine Auskunft und keine Verzierung.
**Verwaltung.** Rollen, Vorlagen und Änderungsrichtlinie waren drei Einträge in
der Kopfzeile für etwas, das man selten und dann zusammenhängend braucht. Jetzt
ein Eintrag /admin mit Reiterleiste, dazu eine gemeinsame Tabs-Komponente, die
auch der Fallakte zeigt, welcher Reiter offen ist.
**Kanäle.** Ersatzlos entfernt, mitsamt Tabelle. Der Chat gehört dorthin, wo
der Vorgang steht; ein eigener Reiter mit freien Räumen war der Rückweg nach
Discord. Die Personalakte hat jetzt denselben Chat wie die Fallakte - ohne
„als Vermerk übernehmen", denn dafür braucht es einen Verlauf, und Meldungen
gehen nur an Erwähnte, nie in den allgemeinen Kanal: dass es zu jemandem eine
Personalakte gibt, ist selbst eine Auskunft. Ein CHECK erzwingt jetzt, dass
eine Nachricht zu genau einem Ort gehört.
**Kopfzeile.** Suchbalken statt Suchlink, als gewöhnliches Formular ohne ein
Byte im Bündel. Thema, Benachrichtigungen und Abmelden sitzen hinter dem
Profilbild, das von Discord kommt; wer keins hat, bekommt seine Initialen.
Nebenbei: Aktenzeichen in Tests waren nur auf vier Stellen eindeutig und
kollidierten zwischen Läufen, weil Akten nicht löschbar sind.
Die letzte offene Zeile aus TASKS.md. Sie blieb offen, weil eine Spur über
jeden Aktenaufruf schnell etwas anderes wird als eine Bequemlichkeit.
Vier Festlegungen halten sie auf der richtigen Seite:
- Kein Verlauf. Der Primärschlüssel (userId, targetType, targetId) lässt je
Nutzer und Datensatz genau eine Zeile zu, die überschrieben wird. Die
Tabelle kann nicht sagen, wie oft oder in welcher Reihenfolge gearbeitet
wurde. Zwanzig Einträge, älteres fällt hinten heraus.
- Nur die eigene. Keine Ansicht, kein Adminbereich, keine Funktion mit
fremder Kennung. Jede Abfrage nimmt p.userId.
- Jederzeit löschbar, ohne Rückfrage und ohne Grabstein.
- Vorabrufe zählen nicht. Ohne die Prüfung auf next-router-prefetch stünde
dort, worüber jemand mit der Maus gefahren ist.
Gelesen wird über dieselben Sichtbarkeitsfragmente wie überall: eine
vorgemerkte Kennung ist keine Berechtigung. Steigt eine Akte über die
Freigabestufe, verschwindet sie ohne Lücke und ohne Platzhalter; Personalakten
brauchen zusätzlich personnel.read. Das Zugriffsprotokoll bleibt unberührt und
bleibt die einzige Auskunft darüber, wer wann was gelesen hat.
Sie steht auf der Übersicht und im leeren Feld der Kommandopalette. Der zweite
Ort ist der eigentliche.
Nebenbei: NEXT_DIST_DIR, damit ein Build neben einem laufenden
Entwicklungsserver nicht dasselbe .next-Verzeichnis abräumt.
Die Übersicht beantwortet vier Fragen, die man morgens hat: woran arbeite ich,
was ist fällig, wo hat jemand geschrieben, was hat sich getan. Jede Liste
läuft durch visibleCaseWhere - das ist der Ort, an dem eine unachtsame
Abfrage am ehesten eine Akte verrät. Ein Test prüft jede einzeln gegen eine zu
hoch eingestufte Akte. Der bisherige Inhalt ("Dein Zugang") steht jetzt unter
/zugang.
Beobachten ist eine Merkliste, kein Recht: nur was sichtbar ist, lässt sich
merken, und steigt eine Akte später über die eigene Stufe, verschwindet sie
aus der Liste, ohne dass jemand aufräumt.
Das helle Thema tauscht nur die semantische Ebene; die Grundpalette bleibt.
Die Klassifizierungsfarben sind für hellen Grund eine Spur dunkler, im Farbton
aber dieselben - eine Stufe muss in beiden Themen wiedererkennbar sein. Drei
Zustände, "wie das System" ist der Auslieferungszustand, und ein Skript im
Kopf setzt die Wahl, bevor das erste Mal gemalt wird.
Die Messung misst nicht den Nutzer. web-vitals schickt Zahlen und das
Routenmuster, keine Kennung und keinen konkreten Pfad: wer wann welche Akte
geöffnet hat, steht im Zugriffsprotokoll, und eine zweite Spur daneben wäre
eine Überwachungsfunktion ohne Auftrag. Ausgewertet wird Median und 75.
Perzentil, nicht der Mittelwert.
Mobil: die breiten Tabellen scrollen in sich, statt die Seite breiter zu
machen. Ein e2e-Test hält fest, dass keine Seite waagerecht überläuft.
scripts/restore-test.sh spielt eine Sicherung in eine Wegwerf-Datenbank und
prüft ausdrücklich, dass Regeln und Trigger mitkommen: eine Wiederherstellung
ohne entry_no_delete wäre eine Datenbank ohne die Zusicherung, um derentwillen
das System gebaut wird. Einmal durchgespielt, alles angekommen.
186 Tests im Web-Paket, 17 in der Datenbank, 7 im Worker, 54 e2e.
Grösste Route 116,2 von 120 kB.
Harlekin