Files
Laufzettel/docs/architektur.md
T
florian.wildeandClaude Opus 5 ab5777a57e
Prüfung / pruefung (push) Canceled after 0s
Prüfung / e2e (push) Canceled after 0s
feat(archiv): Uebersicht, Volltextsuche und Druckansicht
Der Einstieg am Schreibtisch und das Gedaechtnis der Anwendung. Die Uebersicht
sortiert nach Dringlichkeit — ueberfaellig zuerst, und das ist das Einzige in
Warnfarbe; alles andere auf der Seite ist Auskunft.

Das Archiv sucht ueber Titel, Notizen, erfasste Werte und Kommentare in einer
SQL-Anweisung: `Schrittergebnis.wert` ist ein Json, und nur `("wert")::text`
trifft den Trigramm-Index aus #006. Vor allem aber gehoert die Fundstelle zum
Treffer — ein Treffer ohne sichtbaren Grund ist fuer den Suchenden wertlos.

Die Druckansicht ist ein eigenes Lesemodell und kein Schalter an
`laufZumAbarbeiten`: dort entsteht beim Fuellen der Befehle ein Passwort, und auf
einem Blatt, das jemand abheftet, darf keines stehen. Vom Mitarbeiter holt sie
nur Name, UPN und Abteilung — nicht alles und dann gefiltert.

Der unabhaengige Review fand zwei Blocker, beide im Dashboard: „ueberfaellig“
verglich mit dem Augenblick statt mit dem Tagesbeginn, und der Schnellstart
zaehlte Laeufe fremder Kunden mit. Was „ueberfaellig“ heisst, steht seitdem in
`src/lib/fristen.ts` — eine Regel fuer Lesemodell und Anzeige.

Closes #15

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-25 20:59:38 +00:00

17 KiB
Raw Blame History

Architektur und Entscheidungen

Ergänzt CLAUDE.md, das die verbindlichen Konventionen enthält. Hier steht das Warum.

1. Zwei Betriebsmodi, ein Codepfad

Einstellung.modus ist INTERN oder DIENSTLEISTUNG und liegt in der Datenbank, nicht in der Umgebung — der Admin schaltet ohne Neustart um.

Der Kern der Entscheidung: jede kundenbezogene Zeile trägt immer eine kundeId, auch im Modus INTERN. Dort ist es die eine Organisation mit isteigeneOrganisation = true, die in keiner Liste, keinem Filter, keinem Formular und auf keinem Etikett erscheint. Dadurch ist der Wechsel nach DIENSTLEISTUNG eine Datenänderung (die eigene Organisation wird zum ersten Kunden) und keine Migration.

Es gibt daher nicht zwei Codepfade für Geräte oder Läufe, sondern ein- und ausgeblendete Felder und Filter. Zwei Funktionen tragen das:

  • betriebsmodus() — gecachter Zugriff, den alle Listen und Formulare fragen
  • kundeErmitteln(eingabe) — liefert im Modus INTERN immer die eigene Organisation und verwirft eine mitgeschickte kundeId. Das ist eine Sicherheitsgrenze, kein Komfort.

2. Schichtung

Server Component ──► queries/*  ──► prisma
Server Action    ──► services/* ──► prisma
                     └─ rechtErforderlich(), Zod, Regeln, Protokoll

services/* hält die Regeln und wirft eigene …Fehler-Klassen. queries/* hält Lesemodelle und wendet Rollen- und Mandantensicht selbst an, damit kein Aufrufer sie vergessen kann. actions/* sind Dreizeiler: Recht prüfen, Schema anwenden, Service rufen.

Der Grund für die Trennung von Action und Service: die Regeln sollen ohne Next.js testbar sein. Vitest ruft den Service direkt.

3. Anmeldung: kein Auth.js

Der Auftrag nannte Auth.js. Beim Prüfen der Lage am 2026-09-24:

  • next-auth v5 steht auf 5.0.0-beta.32, seit Jahren ohne GA
  • authjs.dev führt das Projekt im Wartungsmodus („The Auth.js project is now part of Better Auth"), die Maintainer schreiben „no immediate plans for v5“
  • @auth/prisma-adapter deklariert @prisma/client nur bis >=6 — wir fahren Prisma 7

Entschieden wurde deshalb der Eigenbau mit stabilen Bausteinen, wie in ProxLedger:

  • openid-client 6.x für generisches OIDC mit Discovery (Ziel: authentik)
  • jose für ein signiertes Sitzungs-Cookie (HS256 aus APP_SECRET)
  • @node-rs/argon2 für den lokalen Notfallzugang

Rolle und Aktiv-Status werden pro Anfrage aus der Datenbank gelesen, nicht aus dem Token. Eine Rollenänderung greift damit sofort, und ein deaktivierter Benutzer wird auch mit gültigem Cookie abgewiesen.

4. Versionierung und Archiv

Zwei Regeln tragen die Nachvollziehbarkeit:

  1. Eine veröffentlichte VorlagenVersion wird nie verändert. „Bearbeiten“ erzeugt eine tiefe Kopie als Entwurf. Ein Lauf auf Version 1 zeigt für immer die Schritte aus Version 1, auch wenn längst Version 5 veröffentlicht ist.
  2. Ein archivierter Lauf ist schreibgeschützt. Die Sperre sitzt in genau einer Funktion, laufMussVeraenderbarSein(lauf), die vor jeder Änderung an Kopfdaten, Schrittergebnis und Kommentar gerufen wird. Nur ADMIN holt einen Lauf zurück, mit Protokoll-Eintrag.

Beides ist durch Tests abgedeckt, nicht durch Disziplin.

Abgeschlossen ist nicht archiviert, und der Unterschied ist Absicht. „Abgeschlossen“ ist ein Arbeitszustand: fertig für jetzt. Eine nachgetragene Notiz, ein Kommentar mit dem, was beim Nachfassen herauskam, eine korrigierte Seriennummer — das passiert danach, und zwar oft. Würde schon der Abschluss sperren, bräuchte jede Kleinigkeit einen Administrator, und die Technikerin würde Läufe schlicht nicht mehr abschließen; das Archiv wäre danach nicht genauer, sondern leerer. Unveränderlich wird ein Lauf durch das Archivieren, eine ausdrückliche zweite Handlung. Damit „abgeschlossen“ trotzdem nicht lügt, nimmt der Abschluss sich selbst zurück, sobald eine Änderung einen Pflichtschritt wieder offen lässt.

Der Aufbau einer Version wird als Ganzes gespeichert, nicht Schritt für Schritt: der Editor hält den Baum im Speicher und sortiert per Drag & Drop, ein Teil-Update wäre dort ständig mit dem Sortieren im Streit. Dasselbe Zod-Schema (src/lib/vorlagen-format.ts) beschreibt den Entwurf im Editor, den JSON-Export und den Import — drei getrennte Schemata würden auseinanderlaufen, und der Import wäre der Ort, an dem das erst auffiele. Das Format ist in docs/vorlagen-format.md beschrieben.

Die eingebauten Platzhalter stehen als Liste in src/lib/platzhalter.ts — Daten, kein Code. Der Editor zeigt sie als Hilfe, die Warnung vor unbekannten Platzhaltern vergleicht dagegen, und die Auflösung in #012 baut darauf auf. Eine zweite Aufzählung an anderer Stelle würde unweigerlich auseinanderlaufen: ein Platzhalter, der in der Hilfe steht, aber nicht aufgelöst wird, bliebe im fertigen PowerShell-Befehl als {{…}} stehen.

Die Warnung ist ausdrücklich keine Ablehnung. Ein Tippfehler soll im Editor auffallen und nicht erst dem Techniker im Lauf; es kann aber gute Gründe geben, einen Platzhalter stehen zu lassen — etwa weil die Variable gleich noch kommt. Speichern und Veröffentlichen bleiben deshalb erlaubt.

5. Der Weg zu Phase 4 (Aktionen)

Die in den Vorlagen vorbereiteten PowerShell-Befehle sind bewusst die Vorstufe ausführbarer Schritte. Damit der Schritt dorthin keine Migration braucht:

  • VorlagenSchritt.typ ist ein Enum, dem AKTION hinzugefügt wird; konfig (Json) trägt dann Connector und Parameter
  • Schrittergebnis.wert ist ein Json, das ein Aktionsergebnis mit Log, IDs und Zeitstempeln aufnimmt
  • kein Codepfad nimmt an, dass ein Schritt nur von einem Menschen erledigt wird
  • das Krypto-Modul für das LDAP-Bind-Passwort ist schon der Platz für Connector-Geheimnisse

5a. Was in der Datenbank steht und warum

Die Service-Schicht ist der richtige Ort für Regeln mit verständlichen Meldungen. Sie ist aber nicht der einzige Weg, auf dem Daten entstehen: Migrationen, psql, Skripte und ab Phase 4 die Connectoren schreiben an ihr vorbei. Was stillschweigend falsch werden könnte, steht deshalb zusätzlich in der Datenbank:

Regel Form
Höchstens eine eigene Organisation partieller Eindeutigkeitsindex
Höchstens ein Entwurf je Vorlage partieller Eindeutigkeitsindex
Kundenkürzel, tagCode-Form, verschlüsseltes Bind-Passwort CHECK auf die Form
Registriertes Gerät braucht Hostname oder Bezeichnung CHECK, greift erst ab registriertAm
Mitarbeiter aus dem Verzeichnis oder Freitextname CHECK
Status und Zeitstempel laufen nicht auseinander vier CHECKs
NICHT_ZUTREFFEND und FEHLGESCHLAGEN brauchen eine Notiz CHECK
Einstellung ist eine einzelne Zeile CHECK auf die feste Kennung
Mandantengrenze vier zusammengesetzte Fremdschlüssel

Die Mandantengrenze verdient die Erklärung: Lauf verweist mit ("geraetId", "kundeId") auf Geraet("id", "kundeId"), analog für Person und Abteilung, und Geraet ebenso auf den Besitzer. Damit ist ein Lauf, der ein Gerät eines fremden Kunden zieht, nicht mehr bloß ein Fehler im Service, sondern strukturell unmöglich. MATCH SIMPLE sorgt dafür, dass ein Lauf ohne Gerät weiterhin erlaubt ist.

Zwei Dinge sind bewusst nicht kaskadierend: ein Lauf nimmt seine Schrittergebnisse und Kommentare nicht mit, und ein Protokoll-Eintrag verliert seinen Urheber nicht. Beides stünde gegen den Zweck eines Archivs. Der tagCode ist zusätzlich in TagCodeVergabe festgehalten, aus dem nie gelöscht wird — sonst würde ein Code nach dem Löschen eines Geräts wieder frei und ein alter Aufkleber zeigte auf ein fremdes Objekt.

5b. Warum ein Screenshot nichts über Bedienbarkeit sagt

In dieser Umgebung hydriert next dev nicht: die Seiten werden serverseitig gerendert und sehen vollständig richtig aus, aber React hängt sich nie an — kein Knopf, kein Formular, kein Sortieren tut etwas. Nachgewiesen in #010, und zwar auch ohne src/proxy.ts und ohne output: "standalone"; der HMR-WebSocket scheitert mit ERR_INVALID_HTTP_RESPONSE. Es liegt am Werkzeug, nicht an diesem Code — im gebauten Stand tragen 1281 von 1296 Elementen React-Knoten, im Entwicklungsmodus zwei.

Zwei Folgen, beide verbindlich:

  1. Oberflächen werden gegen pnpm build && pnpm start abgenommen, nicht gegen pnpm dev — ebenso die Screenshots. Steht in CLAUDE.md.
  2. Was nur mit angehängtem React gelingt, gehört in einen Playwright-Test. pnpm test:e2e klickt den Editor durch: anlegen, tippen, sortieren mit dem Finger bei 390 px, speichern, neu laden und nachsehen, ob es wirklich in der Datenbank steht.

Die Content-Security-Policy in src/proxy.ts ist deshalb zweigeteilt: im Entwicklungsmodus mit unsafe-eval und WebSocket, im ausgelieferten Stand ohne beides. Die Entscheidung fällt an process.env.NODE_ENV, und tests/sicherheitsrichtlinie.test.ts prüft sie am Proxy selbst — eine Prüfung der Funktion mit selbst gesetztem Argument hätte genau den Fehler durchgelassen, vor dem der Kommentar darüber warnt.

5c. Warum die Maskierung dort sitzt, wo sie sitzt

Aus einer Vorlage entsteht ein PowerShell-Befehl, den ein Techniker kopiert und auf einem Domänencontroller ausführt. Drei Entscheidungen tragen das (#012):

  1. Maskiert wird der eingesetzte Wert, nicht der fertige Befehl. Sonst maskierte man die Anführungszeichen des Befehls gleich mit. platzhalterErsetzen bekommt die Maskierung deshalb als Funktion und wendet sie auf jeden Wert einzeln an.
  2. Die Maskierung setzt keine Anführungszeichen dazu — die stehen in der Vorlage. Das ist eine Annahme, und sie wird geprüft: steht ein {{platzhalter}} in einem BEFEHL-Schritt nicht zwischen den erwarteten Anführungszeichen, wird der Schritt abgewiesen statt gefüllt. Ein halb maskierter Befehl zum Kopieren wäre die gefährlichste aller Antworten.
  3. Was sich nicht sicher maskieren lässt, wird abgelehnt. Für Cmd gibt es keine Regel, die ein " in jedem Fall richtig behandelt — ein solcher Wert bekommt eine Fehlermeldung, keinen Befehl. PowerShell liest auch “, ” und „ als Begrenzer; die werden auf ihre ASCII-Form gebracht und dann maskiert, weil sie sich als Text ohnehin nicht durchreichen lassen.

Geprüft wird das ausgeführt, nicht gelesen: tests/shell.test.ts schickt bösartige Werte durch ein echtes bash -c und durch ein echtes PowerShell — und wenn auf der Maschine kein pwsh liegt, nimmt der Test das Container-Abbild. In CI bricht er ab, statt sich zu überspringen; ein stilles Überspringen sieht genauso grün aus wie ein bestandener Lauf.

Das generierte Passwort entsteht erst beim Ersetzen und wird nirgends zurückgegeben — es gibt keinen Weg, es außerhalb des fertigen Texts zu bekommen. Gäbe es ein Feld dafür, wäre die Versuchung groß, es „nur fürs Protokoll“ mitzuschreiben.

5d. Warum die Aktualisierung keine Befehle mitliefert

Die Abarbeitungsansicht fragt alle zehn Sekunden GET /api/laeufe/[id]/zustand — zwei Techniker teilen sich ein Onboarding und sollen die Arbeit des anderen sehen, ohne die Seite neu zu laden. Diese Antwort trägt nur Status und Schrittzustände, ausdrücklich keine fertigen Befehle.

Der Grund ist {{generiertes_passwort}}: es entsteht bei jedem Auflösen neu. Lieferte das Polling Befehle mit, stünde alle zehn Sekunden ein anderes Passwort auf dem Bildschirm als das, das der Techniker gerade in die Konsole geklebt hat. Die Befehle entstehen deshalb genau einmal je Seitenaufbau, und der Client lädt die Seite erst neu, wenn sich am Zustand wirklich etwas geändert hat. Bei verstecktem Tab pausiert die Abfrage.

Der Route Handler prüft sein Recht selbst und gibt einen fremden Lauf als „nicht gefunden“ zurück. Die Hülle unter src/app/(app)/layout.tsx deckt src/app/api/ nicht ab.

5e. Der Aufkleber ist die Schnittstelle

Jedes Objekt traegt einen QR-Aufkleber mit einem tagCode, der nie geaendert und nie wiederverwendet wird — auch nicht, nachdem das Geraet geloescht wurde (TagCodeVergabe, #006). Der Aufkleber ist damit die einzige Angabe am Geraet, die Jahre haelt: Hostnamen aendern sich, Besitzer wechseln, Seriennummern werden abgeschrieben.

Im QR steht ausschliesslich {APP_URL}/t/{tagCode}. Kein Name, keine Seriennummer, kein Besitzer. Ein Aufkleber haengt sichtbar am Geraet und wird von jedem Telefon gelesen, auch von einem fremden; was darauf steht, ist veroeffentlicht. Die Adresse selbst verraet nichts — dahinter verlangt /t/[tagCode] eine Anmeldung und zeigt einem fremden Kunden dieselbe Antwort wie bei einem Code, den es nicht gibt.

Drei Dinge daran sind nicht mehr zu korrigieren, sobald gedruckt ist, und stehen deshalb fest:

  1. Die Basisadresse kommt aus APP_URL, mit ihrem Pfad. Liegt die Anwendung unter https://firma.de/laufzettel, muss genau das im QR stehen; basisAdresse() in src/lib/adressen.ts haelt den Pfad fest, tagAdresse() haengt relativ an. Ohne gesetzte APP_URL warnt die Druckseite, statt still localhost zu drucken.
  2. Der QR entsteht lokal (qrcode, Fehlerkorrektur M, Ruhezone 4). Eine externe API bekaeme mit jedem Aufruf den Bestand an Tag-Codes geliefert.
  3. Die Masse sind geprueft, nicht behauptet. tests/e2e/etiketten.spec.ts misst die Seitengroesse an einem echten PDF (62 × 29 mm bzw. A4) und liest ein bei 300 dpi gerastertes Etikett mit demselben Decoder zurueck, den auch der Scanner benutzt.

Der Scanner laedt barcode-detector/polyfill: wo der Browser eine BarcodeDetector-API mitbringt, laeuft sie, sonst springt WebAssembly ein. Dessen .wasm kommt aus dem eigenen Haus (scripts/wasm-bereitstellen.mjs legt es unter public/zxing/), weil die Content-Security-Policy nur connect-src 'self' erlaubt und die Anwendung ohne Internet laufen soll; dafuer traegt script-src ein 'wasm-unsafe-eval' — die schmale Erlaubnis, WebAssembly zu uebersetzen, und nicht unsafe-eval. Laeuft die Kamera nicht oder faellt der Decoder aus, steht an derselben Stelle ein Feld fuer den abgetippten Code: der steht lesbar unter jedem QR, und ein Scanner, der nicht startet, darf keine Sackgasse sein.

5f. Archiv und Ausdruck: das Gedaechtnis

Die Archivsuche geht ueber drei Tabellen — Lauf.titel, Schrittergebnis.notiz, Schrittergebnis.wert und Kommentar.rumpf — und steht deshalb als eine SQL-Anweisung in src/server/queries/archiv.ts statt als vier Prisma-Abfragen. Zwei Gruende, beide handfest:

  1. Schrittergebnis.wert ist ein Json. Nur ("wert")::text trifft den pg_trgm-GIN-Index aus #006; eine ganze Json-Spalte als Text zu durchsuchen kann Prisma nicht.
  2. Die Fundstelle gehoert zum Treffer. Wer im Archiv sucht, will nicht wissen dass etwas passt, sondern wo — Titel, Notiz, Wert oder Kommentar, mit dem Ausschnitt drumherum. Vier getrennte Abfragen muessten das hinterher wieder zusammenlegen.

Jeder Wert geht als Parameter in die Anweisung (Prisma.sql), und %, _ und \ werden fuer ILIKE maskiert: die Suche nach „50 %“ trifft sonst „5099“. tsvector bleibt die spaetere Optimierung, so wie in §5a festgehalten.

Abgelegt heisst COALESCE(archiviertAm, abgeschlossenAm, erstelltAm) — derselbe Ausdruck fuer die Sortierung und den Zeitraumfilter. Zwei verschiedene Ausdruecke hiessen: ein Lauf steht ausserhalb des Zeitraums, den die Liste an seiner Position anzeigt.

Die Druckansicht (/drucken/lauf/<id>) ist ein eigenes Lesemodell und kein Schalter an laufZumAbarbeiten. Dort entsteht beim Fuellen der Befehle ein {{generiertes_passwort}}; auf einem Blatt, das jemand abheftet, darf keines stehen — dort erscheint [Passwort – nicht gespeichert], und erzeugt wird keines. Der Beweis dafuer ist ein Vergleich: zwei Ausdrucke desselben Laufs sind Zeichen fuer Zeichen gleich, ein erzeugtes Passwort waere bei jedem Aufbau ein anderes.

Vom Mitarbeiter holt dieses Lesemodell nur Name, UPN und Abteilung — nicht alles und dann gefiltert. Ein Ausdruck liegt herum, wird kopiert und weitergegeben; was darauf steht, ist aus der Hand gegeben.

6. Betrieb: zwei Wege, eine Regel

Die Datenbank ist auf beiden Wegen von außen nicht erreichbar:

Weg Wie
Docker Compose postgres ohne ports:, nur im Netz intern mit internal: true (kein Gateway)
Nativ im LXC PostgreSQL mit listen_addresses = '' — nur Unix-Socket

Festgehalten in tests/betriebsstand.test.ts, damit ein ports:-Mapping nicht versehentlich zurückkommt.

7. Werkzeug-Obergrenzen

Zwei Abhängigkeiten dürfen nicht angehoben werden, beides empirisch festgestellt:

  • eslint bleibt auf 9.x. eslint-config-next bringt eslint-plugin-react@7.37.5 mit, das eslint nur bis ^9.7 unterstützt. Mit eslint 10 bricht das Regelwerk beim Laden ab (contextOrFilename.getFilename is not a function). Eine neuere Fassung des Plugins gibt es nicht — die letzte stammt von April 2025.
  • typescript bleibt auf ~6.0.3. typescript-eslint@8 erlaubt nur >=4.8.4 <6.1.0. TypeScript 7.0.2 ist zwar latest, aber noch nicht unterstützt.

Dazu ein Pinning: prisma und @prisma/client exakt auf 7.10.0. Der latest-Tag von prisma zeigt auf einen 8.0-RC, der von @prisma/client nicht — ein unbedachtes pnpm add prisma würde beide auseinanderlaufen lassen.