4 Commits

Include renames

Author	SHA1	Message	Date
HarlekinandClaude Opus 5	3466215e2c	Phase 9 abgeschlossen: Übersicht, Beobachtungsliste, helles Thema, Messung ... 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. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-03 10:28:50 +02:00
HarlekinandClaude Opus 5	34a8b96dd3	Phase 6 abgeschlossen: Aktenchat, Kanäle, Echtzeit, Benachrichtigungen ... Ein Ereignisstrom mit Themen (/api/stream), in dem der Dateistrom aus Phase 5 aufgegangen ist. Zwei Prüfungen: beim Verbinden, welche Themen der Nutzer abonnieren darf, und je Ereignis wird der Inhalt mit seinen Rechten geladen. Das zweite ist nicht nur Vorsicht — eine Umklassifizierung wirkt dadurch in einer offenen Verbindung sofort. In der pg_notify-Nutzlast steht nie ein Inhalt, nur Thema, Art und Kennung. Der Aktenchat sendet optimistisch mit clientseitiger UUIDv7, die zugleich Idempotenzschlüssel ist. Antworten, vier feste Reaktionen, Bearbeiten mit sichtbarem editedAt, Zurückziehen mit Platzhalter — Löschen gibt es nicht, und eine Regel in der Datenbank hält das fest. Eine zurückgezogene Nachricht kommt ohne Text an, nicht ausgeblendet. Aktenzeichen im Text werden zu Vorschaukarten, serverseitig aufgelöst. Eine Akte, die der Leser nicht sehen darf, sieht darin genauso aus wie eine, die es gar nicht gibt. "Als Vermerk übernehmen" steht sichtbar an jeder Nachricht. Der Vermerk gehört dem Verfasser, nicht dem Übernehmenden; ein Systemeintrag nennt den Ursprung, damit der Wortlaut später nicht für die Akte geschrieben wirkt. Bei den Discord-Benachrichtigungen entscheidet die Web-App, wer was erfährt, und der Worker liefert nur aus. Die Alternative hätte geheissen, die Sichtbarkeitsprüfung im Worker ein zweites Mal zu bauen. In meta steht ein Titel nur, wenn er hinaus darf — ab Stufe 3 keiner. Postausgang als Tabelle, angestossen über LISTEN, mit Takt als Sicherheitsnetz. Nebenbei riss das Budget der Fallakte erneut (122 kB). Drei Schritte zurück auf 119,6: Chattexte in eine eigene i18n-Datei, ein gemeinsames AddPanel statt viermal derselbe Aufklapp-Code, und eine eigene UUIDv7 statt des Pakets — die Sortierbarkeit, auf der die Nachlieferung beruht, steht damit im eigenen Code und hat Tests. Unterwegs habe ich NotifyMode und User.notifyMode ein zweites Mal angelegt, obwohl es beides seit dem Grundgerüst gibt. Die Migration schlug fehl und die Datenbank musste von Hand aufgeräumt werden; die Lehre steht in docs/13. 155 Tests im Web-Paket, 15 in der Datenbank, 7 im Worker, 32 e2e. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-02 21:06:03 +02:00
HarlekinandClaude Opus 5	5f58d9b96f	Phase 5 abgeschlossen: Dateien mit vollständiger Prüfkette ... Upload → quarantine/ → Typprüfung → ClamAV → Neukodierung → store/. Es gibt keinen Pfad, auf dem eine Datei ungeprüft in store/ landet, und keinen Schalter, der die Kette abschaltet. Die Typprüfung liest Magic Bytes aus einer eigenen Signaturtabelle statt aus file-type: bei einer Positivliste aus fünf Formaten hilft es nicht, hundert erkennen zu können. Die Signatur muss an Position 0 stehen — ein Vorspann vor %PDF- ist der klassische Weg, eine Datei für zwei Programme zugleich lesbar zu machen. Wer trotzdem durchkommt, kommt als text/plain durch und wird unter der Endung des erkannten Typs ausgeliefert, nicht unter der hochgeladenen. Drei Ausgänge statt zwei: BLOCKED heisst "ist gefährlich", FAILED heisst "wissen wir nicht". Nur FAILED lässt sich freigeben, und die Freigabe wiederholt die Kette ohne den Scanner — Typprüfung und Neukodierung laufen dabei mit. Ein fehlender clamd macht damit keine Datei sauber; ein Test hält das fest. Auslieferung nur über /api/files/[id], mit Sichtbarkeitsprüfung der zugehörigen Akte, Protokoll ab Stufe 3 und den harten Kopfzeilen aus docs/07. Vorschaubilder dürfen inline, weil sie serverseitig als WebP neu kodiert wurden. Das Lichtbild im Aktenblatt ist damit gefüllt: der Feldwert ist die Kennung eines geprüften Anhangs, serverseitig zu einer Adresse aufgelöst. /api/events liefert attachment.scanned über pg_notify — die Grundlage, auf der Phase 6 den Aktenchat aufsetzt. Die Sichtbarkeit wird je Ereignis geprüft, sonst verriete schon die Kennung die Existenz. Nebenbei riss das Bündelbudget (121 kB gegen 120 erlaubte): lib/i18n/de.ts war ein Objekt, und eine Client-Komponente zieht die ganze Datei mit. Die Texte stehen jetzt in sechs Dateien nach Bereichen, de.ts setzt sie nur zusammen. Grösste Route wieder bei 118 kB, und sie wächst nicht mehr mit jedem neuen Bereich mit. 133 Tests im Web-Paket, 15 in der Datenbank, 28 e2e. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-02 20:27:22 +02:00
HarlekinandClaude Opus 5	51984f17d4	Workspace und Datenmodell ... pnpm-Workspace mit web/, worker/, pdf/ und packages/db. Das Datenbankpaket ist eigenständig, weil Web-App und Worker denselben Prisma-Client brauchen. Schema nach docs/04-datenmodell.md, mit drei Abweichungen, die dort begründet sind: CaseParticipant bekommt einen eigenen Schlüssel statt eines zusammengesetzten mit NULL-Spalten, die Aktenzeichen laufen über CaseCounter statt über eine Sequenz pro Jahr, und ServiceHeartbeat kommt dazu, damit /api/health den Gateway-Zustand kennt, ohne Discord zu fragen. Die zweite Migration enthält, was Prisma nicht ausdrücken kann: - kein DELETE auf CaseEntry, CaseEntryVersion und AuditLog - authorId, createdAt, caseId und type eines Eintrags sind unveränderlich - an einer Eintragsversion darf nur minClearance angehoben werden - Volltextsuche mit deutscher Konfiguration; geschwärzte Bereiche werden vor dem Indizieren entfernt, sonst verrät ein Treffer den Inhalt - pg_notify bei Rollen- und Mapping-Änderungen Acht Tests prüfen diese Regeln gegen eine echte Postgres-Instanz, nicht gegen die Anwendungslogik. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-01 00:01:29 +02:00