Die Druckansicht ist die einzige Vorlage für den Export: kein zweites Layout
von Hand in einer PDF-Bibliothek. Der Playwright-Dienst ruft genau diese Seite
auf und bekommt dafür ein signiertes, kurzlebiges Zeichen statt eines
Sitzungscookies. Es gilt nur, solange der Auftrag läuft, ist an den Anfragenden
gebunden, und die Stufe wird beim Einlösen frisch aufgelöst und auf die im
Zeichen vermerkte gedeckelt.
Der Export darf nie sauberer aussehen als die Akte: gesperrte Felder erscheinen
als Balken mit Vermerk statt zu fehlen, geänderte Einträge tragen ihre Version,
zurückgezogene stehen als Grabstein. Wasserzeichen mit Name, Zeitstempel und
Stufe auf jeder Seite.
Die Stufe steckt im Zwischenspeicherschlüssel. Ohne sie bekäme ein Leser der
Stufe 1 das PDF, das für Stufe 4 gerendert wurde.
Ab Stufe 3 wartet der Auftrag auf Freigabe durch ein zweites Augenpaar — und
der Anfragende darf sich nicht selbst freigeben, auch nicht mit dem Recht
dazu. Offene Freigaben stehen auf der Übersicht.
Dazu Einzeldokumente als PDF (Aktenblatt bleibt Aktenblatt), ZIP-Sammelexport
mit eigenem achtzigzeiligem Schreiber statt einer Abhängigkeit, und der
JSON-Vollabzug ohne Stufenfilterung — die einzige Stelle, an der die
Klassifizierung nicht greift, deshalb hinter einem eigenen Admin-Endpunkt.
Zwei Funde unterwegs, beide in docs/13 festgehalten:
Die Druckansicht warf notFound(), und das Skelett aus dem Wurzel-loading.tsx
blieb im Browser stehen — der PDF-Dienst hätte leere Blätter gedruckt.
Gefunden nur, weil der e2e-Test auf den Inhalt prüft und nicht auf den
Statuscode. Sie rendert die Auskunft jetzt selbst.
Und die Entdopplung der Anhänge verwies auf Dateien, ohne nachzusehen, ob sie
noch daliegen. Nach einem geleerten /tmp zeigte jeder weitere Upload desselben
Inhalts stumm ins Leere.
178 Tests im Web-Paket, 17 in der Datenbank, 7 im Worker, 44 e2e.
Fallakte bei 119,8 von 120 kB — das Budget ist aufgebraucht.
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.
Harlekin