9 Commits

Include renames

Author	SHA1	Message	Date
Harlekin	bd750f26d0	Statuswechsel als Karte statt als wandernde Auswahlliste ... Das Auswahlfeld enthielt nur die gerade erreichbaren Zustaende. Damit sah man weder, wo die Akte steht, noch welche Zustaende es ueberhaupt gibt - und nach jedem Wechsel standen andere Eintraege darin. Eine Auswahl, die ihre Eintraege tauscht, ist keine Orientierung. Jetzt stehen immer alle sieben da, in der Reihenfolge des Lebenszyklus: Entwurf, Offen, In Pruefung, Abgeschlossen, Archiviert als eine Linie, darunter Ruhend und Versiegelt als Nebenwege. Der jetzige Zustand ist markiert, erreichbare sind Knoepfe, gesperrte bleiben blass stehen statt zu verschwinden - mit dem Grund als Titel daran. Der Grund ist dabei nicht dasselbe wie die Sperre: "von hier fuehrt kein Weg dorthin" laesst sich durch kein Recht beheben, "dir fehlt case.close" schon. Wer das verwechselt, sucht an der falschen Stelle. Was ein Wechsel verlangt, steht jetzt vorher da statt als Absage danach: die Pflichtbegruendung beim Wiedereroeffnen und beim Versiegeln, und dass vor dem Abschluss die noetigen Abschnitte gefuellt sein muessen. Bei Pflichtbegruendung bleibt der Knopf gesperrt, bis sie dasteht. Die Rechtepruefung rechnet der Server, mit derselben Funktion, die der Dienst beim Wechsel anwendet - vorher zeigte die Liste auch Ziele, die danach abgelehnt wurden. Zwei Pruefungen halten das fest, und zwar in beide Richtungen: nichts angeboten, was scheitern wuerde, und nichts verschwiegen, was ginge. Die zweite ist die wichtigere, weil ihr Fehlen nicht auffaellt.	2026-09-04 16:26:29 +02:00
Harlekin	6b2b4c4c8c	Personalakten und Abteilungen als vollstaendiges Dossier speichern ... Bisher liess sich eine einzelne Fallakte und ein einzelnes Dokument als PDF sichern. Wer den Stand zu einer Person brauchte, rief beides einzeln ab, legte es von Hand zusammen und wusste danach nicht, ob er alles hatte. Ein Dossier ist die Personalakte, dahinter alle ihre Dokumente, dahinter alle Fallakten, in denen die Person vorkommt - jeweils in derselben Druckdarstellung wie einzeln. Fuer eine Abteilung dasselbe, je Mitglied getrennt: eine Abteilung hat keine eigenen Fallakten, sie hat Mitglieder, die in Fallakten vorkommen. Alles in einen Topf geschuettet staende dieselbe Akte mehrfach da, ohne dass man saehe, ueber wen sie dort steht. Der Abrufer waehlt die hoechste Stufe, die aufgenommen wird. Das ist keine Zugriffspruefung, sondern eine Entscheidung ueber den Umfang - und beides darf nie durcheinandergeraten: - Was ueber der Freigabestufe des Abrufers liegt, existiert fuer ihn nicht. Es steht nicht im Abzug, wird nicht gezaehlt und nicht erwaehnt. - Was er selbst ausgeschlossen hat, steht als Vermerk im PDF, nach Stufe aufgeschluesselt. Eine gekuerzte Mappe darf nicht wie eine vollstaendige aussehen, und der Deckel steht zusaetzlich auf jeder Seite im Wasserzeichen. Beide Grenzen laufen in der Datenbankabfrage, nicht danach in JavaScript. Alles wird als eine Druckseite gerendert statt als mehrere zusammengeheftete PDFs. So laufen Seitenzahlen, Kopfzeile und Wasserzeichen durch, und es gibt keinen zweiten Weg, der irgendwann anders aussieht als der erste. Dafuer sind die vorhandenen Druckansichten zu Bausteinen geworden - CaseSheet und DocumentSheet stehen jetzt in components/print und werden von den alten Seiten wie vom Dossier benutzt. Der Zwischenspeicherschluessel traegt den Deckel, sonst bekaeme ein Abruf bis Stufe 1 die Datei eines Abrufs bis Stufe 4. Und der Stand ist der spaeteste ueber alle enthaltenen Akten, nicht der der Kopfdaten allein - sonst gaebe der Zwischenspeicher einen Abzug heraus, in dem ein inzwischen geaendertes Dokument im alten Wortlaut steht. Jeder Abruf steht mit seinem Deckel im Protokoll. Ohne den sagt der Eintrag, dass jemand etwas ausser Haus gegeben hat, aber nicht wie viel.	2026-09-04 15:34:32 +02:00
Harlekin	e0b03ea336	Gedankenstriche durch Bindestriche ersetzt ... 375 Vorkommen in 210 Dateien. Betrifft Kommentare, Oberflaechentexte und die README; an keiner Stelle Bedeutung, nur Zeichensetzung.	2026-09-04 08:54:52 +02:00
Harlekin	18c9a71fda	Export ohne Vier-Augen, Wiedervorlage setzbar, Druckansicht mit Weg zurück ... **Export.** Das Vier-Augen-Verfahren ab Stufe 3 ist weg. Wer exportiert, entscheidet jetzt allein die Freigabestufe: mindestens die des Ziels. Das ist strenger als das Lesen - wer als Beteiligter ausnahmsweise in eine höher eingestufte Akte darf, darf sie deshalb noch nicht ausser Haus geben. Dabei fiel eine Lücke auf: hängte man sich an einen laufenden Auftrag, entstand kein Protokolleintrag. „Jeder Export wird protokolliert" heisst jeder Abruf, nicht jeder Rendervorgang - wer dieselbe Datei bekommt, muss genauso darin stehen. **Fristen.** dueAt wurde überall gelesen - Übersicht, Suchfilter, Ausdruck - und nirgends gesetzt. Es gab keine Stelle, an der man ein Datum einträgt, deshalb stand unter „Fristen" immer „Nichts steht an". Jetzt im Kopf der Akte, mit Protokolleintrag und ohne Verlaufseintrag: eine Wiedervorlage ist eine Merkhilfe, keine Aussage über den Fall. **Statuswechsel.** Aus einem Entwurf führt laut Lebenszyklus nur „Offen" heraus, deshalb standen dort nie mehr als zwei Ziele. Das sah aus wie ein Fehler und war keiner - jetzt steht die Erklärung daneben und an jeder Option. **Druckansicht.** Sie hatte kein eigenes Layout: das weisse Blatt lag auf dem dunklen Thema und es gab keinen Weg zurück. Jetzt heller Grund, eine Leiste mit Zurück und Drucken, beides beim Drucken ausgeblendet. Das Ziel wird aus dem Pfad abgeleitet, damit es auch beim direkten Aufruf stimmt. **Abteilungsstatistik.** Eine Abteilung ohne Freigabe wird als „Ohne Freigabe" geführt statt weggelassen - sonst summierten sich die Anteile nicht auf die Zahl daneben. Mehrere ergeben ein Stück, sonst stünde dort, wie viele es sind. Dazu: Dienstgrad in eckigen Klammern vor dem Namen und in dessen Grösse, in einer eigenen Spalte; Knopfform für „Personalakte anlegen"; die abgeschnittene Anzahl im Kopf der Personalaktenliste; „Zuletzt geöffnet" ohne die zwei Hinweistexte, leer als Zeichen statt als Satz.	2026-09-04 00:14:07 +02:00
Harlekin	738330cee5	Vollständiger Statusfilter, Beteiligte beim Anlegen, Knöpfe in den Listen ... Vier Sachen aus der Durchsicht. **Der Statusfilter zeigte fünf von sieben Zuständen.** DRAFT und SEALED fehlten - ausgerechnet die beiden, die in der Liste am häufigsten standen; man konnte nach dem, was man sah, gerade nicht filtern. Das erklärt auch die Frage, was „In Prüfung" und „Ruhend" bedeuten: die Zustände standen nirgends in der Oberfläche. Jetzt alle sieben in der Reihenfolge des Lebenszyklus, mit einer Erklärung als title, und Versiegelt nur für den, der Versiegeltes lesen darf. Ein Test verlangt zu jedem Zustand einen Namen und eine Erklärung. **Beliebig viele Beteiligte beim Anlegen.** Das Formular kannte genau eine „betroffene Person", und die Rolle war auf SUBJECT festgelegt. Jetzt beliebig viele Zeilen mit je einer Rolle, Konten und Personalakten in einer Auswahl, wie auf der Aktenseite. Die Zerlegung steht als parseParticipantDrafts in lib/cases/terms.ts und nicht in der Server Action: seit die Rolle über den Zugriff entscheidet, darf eine erfundene Rolle nicht durchrutschen. **Die Filterleisten sind Knöpfe** wie überall sonst, mit gefülltem aktivem Filter. **Keine leere Kennungsspalte mehr.** In „Zuletzt geöffnet" stand bei einer Person nichts, wo sonst das Aktenzeichen steht - jetzt steht dort „Personalakte". Nebenbei zwei Stellen zurückgenommen, an denen die Spaltenklasse im Seitenkopf gelandet war statt in einer Zeile.	2026-09-03 23:38:56 +02:00
Harlekin	89bbed8679	Suche zeigt alle Arten, nur Arbeitsrollen öffnen die Akte ... 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.	2026-09-03 19:16:17 +02:00
Harlekin	89edaa6ae1	Protokoll im Adminbereich, ein Knopf für das ganze Blatt ... Die restlichen zwei Änderungswünsche. **Protokoll.** „Wer was wo macht" stand seit dem ersten Tag in AuditLog - harte Regel 3 sorgt dafür. Was fehlte, war die Ansicht darauf. /admin/protokoll ist genau das und keine zweite Aufzeichnung: filterbar nach Person, Aktion, Art und Zeitraum, rückwärts blätternd. Nur für die Leitung. Eine Zeile nennt Aktenzeichen und Namen, und schon die Existenz einer Zeile verrät, dass es einen Vorgang gibt; ein gefiltertes Protokoll für alle wäre ein Weg, die Sichtbarkeitsregeln von hinten aufzurollen. Aus demselben Grund werden Kennungen ohne Sichtbarkeitsfilter zu Aktenzeichen aufgelöst - ein Protokoll aus UUIDs liest niemand, und eines, das niemand liest, ist keine Kontrolle. **Speichern.** Jedes Feld trug seinen eigenen Knopf: ein Arbeitsvertrag mit zwölf Feldern hiess zwölfmal speichern. Der Knopf steht jetzt am Blatt. Geschrieben wird trotzdem je Feld und nicht als Transaktion, und das folgt aus dem Datenmodell: Abschnitte sind einzeln versioniert, weil mehrere Leute gleichzeitig an einer Akte arbeiten. Als Transaktion blockierte ein einziges zwischenzeitlich geändertes Feld das ganze Blatt - elf gute Änderungen verloren, weil jemand das zwölfte angefasst hat. So geht durch, was durchgeht, und die Rückmeldung sagt, was offen blieb und wo. Lichtbilder bleiben ausgenommen: ein Upload mit Prüfkette ist keine Feldänderung. lib/audit.ts liegt jetzt als lib/audit/write.ts neben lib/audit/query.ts.	2026-09-03 15:16:10 +02:00
Harlekin	d2a7910861	Fallakte in Reiter geteilt ... Akte, Beteiligte, Dokumente, Änderungen, Export - als eigene Seiten unter einem gemeinsamen Layout, nicht als umgeschaltete Blöcke. Ein Reiter, der im Client nur ein- und ausgeblendet wird, kostet dasselbe wie vorher; nur eigene Seiten trennen den Code wirklich. Der Schnitt folgt der Fachlichkeit: die drei Ebenen aus docs/05 - Kopfdaten, Abschnitte, Verlauf - bleiben zusammen, samt Aktenchat. Das Umfeld der Akte braucht man selten gleichzeitig mit dem Sachstand. Kopf, Stempel und die Knöpfe für Status und Umklassifizierung stehen im Layout und damit auf jedem Reiter. Grösste Route 116,2 statt 119,8 von 120 kB, die neuen Reiter bei 110,7 und 110,9. Damit ist wieder Luft für Phase 9. 48 e2e-Tests, 178 im Web-Paket unverändert grün.	2026-09-03 10:15:14 +02:00
Harlekin	55bcb0d95c	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.	2026-09-02 20:27:22 +02:00