Eine Vorlage ist eine geordnete Liste von Bausteinen: Eingabefelder und feste Textbausteine mit Platzhaltern. Damit trägt dieselbe Struktur den Vorfallsbericht und den Sonderarbeitsvertrag. Die Startvorlagen bilden jetzt den echten Bericht der Abteilung ab, samt Berichtsart, Gefahreneinschätzung und Foundation-Freigabe — letztere als gewöhnliches Feld ohne Wirkung auf den Zugriff. Abschnitte werden gerendert und bearbeitet, Entwürfe alle zwei Sekunden lokal gesichert. Gespeichert wird auf Knopfdruck: ein Abschnitt ist der Sachstand der Akte, kein Chatbeitrag. Die geladene Version geht mit; weicht sie ab, gibt es kein stilles Überschreiben, sondern beide Fassungen nebeneinander mit "Meine übernehmen" und "Fremde übernehmen". Felder über der Stufe des Lesers werden serverseitig durch einen Platzhalter ersetzt, Schwärzungen im Fliesstext kommen als Segmente. Beides so, dass der echte Wert den Server nicht verlässt — nicht als Ausblenden im Client. Der Wortdiff ist selbst geschrieben statt eingekauft: ein Dutzend Zeilen gegen 30 kB im Bündel für etwas, das nur serverseitig läuft. Beim Bauen des Vorlagen-Editors riss das Bündel-Budget auf 127,9 kB, weil zod über das Vorlagenmodul in den Client geriet. Typen und Validierung sind jetzt getrennt: fields.ts ohne zod für Client und Server, schema.ts nur serverseitig. Wieder bei 111,9 kB von 120. 85 Tests, 22 E2E. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
7.1 KiB
Bauplan
Phasen in Reihenfolge abarbeiten. Am Ende jeder Phase muss
pnpm lint && pnpm typecheck && pnpm test durchlaufen und die Anwendung startbar sein.
Phase 0 — Gerüst
- Next.js 15 mit TypeScript strict, Tailwind, pnpm-Workspace mit
web/undworker/ - Prisma, Postgres im Compose, erste Migration
- Design-Tokens aus
docs/10-design-system.mdals CSS-Variablen, IBM Plex selbst gehostet lib/i18n/de.tsmit den ersten Texten, Konvention: keine deutschen Strings im JSX- Vitest und Playwright eingerichtet, ein rauchender Test je Ebene
.env.examplegefüllt,compose.yamlausdocs/11-betrieb.mdals Dockge-Stack lauffähig (zunächst nurweb,db,pgbouncer)- Dockerfiles für
web,workerundpdf, GitHub-Actions-Workflow schiebt die Images in die GitHub Container Registry /api/healthprüft Datenbank, Discord-Gateway und ClamAV, wird vom Healthcheck genutzt
Phase 1 — Anmeldung und Rechte
Das ist der schwierigste Teil. Wenn er steht, ist der Rest Formularbau.
- Auth.js mit Discord-Provider, Scope
identify, state und PKCE - Bot-Client mit Bot-Token, Guild-Mitgliedschaftsprüfung im Callback
- Eigene Session in der Datenbank, Cookie-Einstellungen wie in
docs/03-auth-und-rechte.md worker/: discord.js am Gateway, Ereignisse plus Voll-Abgleich alle 5 Minutenpg_notifybei Rollenänderung, Cache-Invalidierung in der Web-AppEffectivePermissionsmit prozesslokalem CacheBOOTSTRAP_ADMIN_IDSals Notfallzugang- Adminseite Rollen-Mapping: Tabelle der Discord-Rollen, Stufe per Auswahl, Rechte per Kästchen, Vorschau „Was sieht Stufe 2?"
- Sessions werden bei Rollenverlust oder Serveraustritt beendet
- Zwischenstand: eingeloggte Seite zeigt Name, Rollen, errechnete Stufe und Rechte
- Negativtests aus
docs/03-auth-und-rechte.mdgrün, soweit sie ohne Akten prüfbar sind. Die vier zu nachträglichen Änderungen an Verlaufseinträgen gehören zu Phase 2 entry.edit_own,entry.edit_any,entry.retractundcase.edit_closedals Rechte angelegt, im Auslieferungszustand keiner Rolle zugeordnet
Phase 2 — Akten
- Datenmodell für
Case,CaseSection,CaseEntry, Beteiligte, Ausschlüsse lib/access/mit Where-Fragmenten, überall verwendet, nirgends Nachfilterung- Aktenzeichen-Vergabe kollisionsfrei über
CaseCounter - Fallliste mit Filtern, cursorbasiert,
loading.tsxmit Skelett - Aktenansicht: Kopfdaten sofort, Verlauf in eigener Suspense-Grenze (Chat: Phase 6)
- Vermerk anlegen, optimistisch, mit clientseitiger UUIDv7
- Statusübergänge mit Rechteprüfung und automatischem Systemeintrag
- Schreibgrenzen nach
docs/03-auth-und-rechte.md: keine Akte über der eigenen Stufe anlegen, Ändern nur mit Lesezugriff, Klassifizierung nachträglich änderbar bis zur eigenen Stufe. Kein Löschen von Akten, nurARCHIVEDundSEALED - Umklassifizierung erzeugt
SYSTEM-Eintrag undAuditLogmit alter und neuer Stufe - Negativtests dazu: Stufe 2 kann keine Stufe-4-Akte anlegen, nicht ändern, nicht hochstufen, auch nicht über einen direkten Aufruf der Server Action
- Audit-Log für alle schreibenden Aktionen und Lesezugriffe ab Stufe 3
- Nachträgliche Änderungen an Verlaufseinträgen nach
docs/05-akten-und-vorlagen.md:CaseEntryVersion, Karenzzeit, Pflichtbegründung,bearbeitet · vNmit Diff-Historie - Zurückziehen mit Grabstein und Pflichtbegründung, kein hartes Löschen
- Postgres-Regeln gegen
DELETEaufCaseEntryundCaseEntryVersion - Änderungsübersicht als Reiter an der Akte
- Adminseite für
AppSetting: Änderungsrichtlinie, Karenzzeit, Markierungsverhalten
Phase 3 — Vorlagen und Abschnitte
-
Entschieden: jede Akte trägt Kurzvermerke und Dokumente, die Fallakte zusätzlich Abschnitte. Siehe
docs/13-entscheidungen.md -
Feldtypen für Textkörper-Vorlagen ergänzen: fester Fließtext, Überschrift, Platzhalter, Unterschriftenzeile — der Sonderarbeitsvertrag ist kein Formular
-
CaseTemplatemit Feldtypen ausdocs/05-akten-und-vorlagen.md -
Aktenzeichen-Muster je Vorlage: Präfix und Stellenzahl, Nummernkreis je Präfix und Jahr
-
Feld „Foundation-Freigabe" als gewöhnliches Vorlagenfeld, ohne Wirkung auf den Zugriff
-
Vorlagen-Editor im Adminbereich, versioniert, mit Vorschau
-
Abschnitte rendern und bearbeiten, Autosave lokal alle 2 Sekunden
-
Versionierung mit Diff-Ansicht
-
Konflikterkennung über mitgesendete Version, 409 mit Vergleichsansicht
-
minClearancepro Feld, serverseitige Ersetzung durch Platzhalter -
Schwärzungs-Auszeichnung im Freitext, Parser in
lib/redaction.ts -
Seed mit vier Startvorlagen
Phase 4 — Personalakten und Verknüpfungen
PersonnelFile, auch für Personen ohne Discord-Konto- Dokumente an der Personalakte aus Vorlagen, z. B. Sonderarbeitsvertrag
- Beteiligte einer Akte mit Rolle
- Rückverweise auf der Personalakte, durch die Sichtbarkeitsprüfung gefiltert
- Verknüpfungen zwischen Akten
- Test: Stufe-1-Nutzer sieht auf einer Personalakte keinen Hinweis auf Stufe-3-Fälle
Phase 5 — Dateien
- Upload-Endpunkt mit Quarantäne, Limits, Kontingent
- Typprüfung über Magic Bytes, Whitelist
- ClamAV-Container angebunden
- Neu-Kodierung mit sharp und qpdf, Vorschaubild und Blurhash
- Auslieferung über
/api/files/[id]mit Rechteprüfung und harten Headern - Upload-UI: lokale Vorschau, Fortschrittsbalken, Zustand „Wird geprüft"
- SSE-Ereignis
attachment.scannedaktualisiert die Anzeige
Phase 6 — Chat und Echtzeit
- SSE-Endpunkt mit
LISTEN/NOTIFY, Heartbeat, Reconnect mitLast-Event-ID - Aktenchat mit Antworten, Reaktionen, Bearbeiten, Zurückziehen
- Optimistisches Senden mit Dedupe über Client-ID
- Aktenzeichen-Erkennung mit serverseitig aufgelöster Vorschaukarte
- Ungelesen-Markierung und Trennlinie
- Freie Kanäle mit eigener Mindeststufe
- „Als Vermerk übernehmen"
- Discord-Benachrichtigungen über den Worker, ohne Inhalte
Phase 7 — Suche
search_vectormit Trigger und Gewichtung, GIN-Index- Suchseite mit Filtern, Debounce, AbortController, gedimmte alte Treffer
- Sichtbarkeitsprüfung in derselben Abfrage, auch für Facettenzähler
- Kommandopalette auf Strg+K
- Gespeicherte Ansichten
Phase 8 — Export
- Druckansicht
/faelle/[caseNumber]/druckmit@media print - Playwright-Container erzeugt PDF, Ergebnis gecacht
- Schwärzung und Wasserzeichen im Export
- Freigabeverfahren ab Stufe 3
- Einzeldokument als PDF, ohne Verlauf, Aussehen aus der Vorlage
- ZIP-Sammelexport und JSON-Vollexport für Admins
Phase 9 — Schliff
- Dashboard: meine Fälle, Fristen, ungelesene Chats, letzte Aktivität
- Beobachtungsliste
- Helles Thema
- Mobile Ansicht durchgehen, besonders Akte und Chat
- Web-Vitals-Erfassung und Anzeige im Adminbereich
- Bundle-Analyse, Budget aus
docs/09-performance-und-ux.mdeinhalten - Backup-Wiederherstellung einmal von Hand testen