- eine Kachel ohne Bauteil (entfernter Typ oder gesperrtes Modul) zeigt
statt des rohen Typnamens den Satz `widgets.unavailable`, zentriert und
grau; Schluessel in de.json und en.json
- Entwicklerdoku: neuer Abschnitt "Eine Kachel zum Modul" im
Modul-Walkthrough — die drei verbliebenen Stellen und was eine Kachel
mit moduleSlug automatisch tut
- Changelog unter "Unveroeffentlicht - Geaendert"
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Ein neuer Widget-Typ war an sieben Stellen einzutragen; vergass man eine,
fehlte die Kachel im Katalog oder die API lehnte sie mit 400 ab.
- WIDGET_TYPES/WidgetType/WIDGET_MODULE_SLUGS stehen jetzt einmal in
packages/shared; Registry, Katalog und die @IsIn-Whitelist der API
leiten davon ab
- neun wireXWidget()-Funktionen durch ein generisches registerWidget()
ersetzt (idempotent, unbekannter Typ wirft in der Entwicklung)
- der Katalog fuehrt keine zweite Typliste mehr, sondern leitet sie aus
der Registry ab und filtert nach Modulzugriff (fail-closed, wenn die
Modulliste unbekannt ist); der Abruf von /modules/active liegt auf der
Dashboard-Seite, nicht im Dialog
- widget-module-map.ts liest die geteilte Tabelle statt einer Kopie, die
oeffentliche Funktion bleibt unveraendert
Der Katalogfilter ist Komfort (T-M1H-01) — verbindlich bleibt der
serverseitige Filter in DashboardService.getWidgets.
Abweichung vom Plan: apps/web hing entgegen der Planannahme noch nicht
von @tessera/shared ab; die Abhaengigkeit wurde ergaenzt (Lockfile). Die
Dockerfiles kopieren packages/shared bereits, der Produktionsbau von
Next.js und der nest build laufen unveraendert.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Beim Rundgang aufgefallen: nach dem Umzug zeigt eine Zeile auf eine Datei,
die es auf diesem Server nicht gibt — lokal, weil der Umzug am Host lief und
der Container ein eigenes Volume hat. Derselbe Zustand entsteht im Betrieb,
wenn jemand einen `pg_dump` von vor dem Umzug zurueckspielt: die Bytes
stecken noch in der Spalte `data`, das getrennt gesicherte Volume
`user-files` ist aber leer.
`getBytes` schreibt die Datei in diesem Fall aus `data` neu und liefert sie
aus, statt 404 zu melden. Fehlt beides, bleibt es bei 404. Nach dem
Entfernen der Spalte (eigenes Todo) faellt der Zweig ersatzlos weg.
api-Tests 1186 -> 1188, type-check und lint unveraendert gruen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- Changelog unter Unveroeffentlicht -> Geaendert: Bilder liegen im
Dateibereich, vorhandene ziehen beim ersten Start automatisch um
- Betriebsanleitung Kap. 6: user-files nennt die Bilderrahmen-Bilder und
haelt fest, dass pg_dump allein sie nicht mehr enthaelt
- Todo fuer Stufe 2 (DROP data, storagePath NOT NULL) mit Vorbedingung,
Migrationsname und den Nacharbeiten an Spec und Klassifikation
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- Bytes liegen unter user-files/dashboard-images/<userId>/<id>.<ext>, die
Zeile haelt nur noch storagePath (Muster User.avatarPath)
- Dateiname immer servergeneriert: UUID der Zeile + Endung aus dem
ERKANNTEN Mime-Typ, originalName kommt in keinem Pfad vor (T-HK4-01)
- Migration 20260922120000: storagePath dazu, data wird NULLbar, kein DROP
(zweistufig, T-HK4-03); system_read_policy fuer den Umzug
- onApplicationBootstrap zieht Altbestand automatisch um: systemgebunden
lesen, je Zeile mandantengebunden schreiben (Muster DKV-Planer)
- Upload nimmt die Zeile bei fehlgeschlagenem Schreiben zurueck, Loeschen
entfernt die Datei mit, fehlende Datei -> 404 (T-HK4-04)
- 11 neue Dienst-Tests gegen ein echtes Temp-Verzeichnis (kein fs-Mock)
- Zugriffsklassifikation: Stand system-gebunden, Zahlen nachgemessen
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Befund aus dem Browser-Rundgang: example.com setzt `margin: 15vh` — mit
3000 px Vorschauhoehe lag die Ueberschrift bei y 450, in der Kachel mit
720 px Rahmenhoehe bei y 108. Der in der Vorschau gewaehlte Ausschnitt
zeigte in der Kachel also etwas anderes. Die Kachel nutzt jetzt dieselbe
Layouthoehe wie die Vorschau (3000), damit vh-relative Seiten identisch
umbrechen; der Rest wird ohnehin weggeschnitten.
Vorschau: `overflow-x-hidden`, die Eckgriffe am rechten Rand erzeugten
einen 4-px-Querbalken.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- Changelog: Stichpunkt direkt nach dem XFrame-Stichpunkt unter Unveroeffentlicht -> Neu
- Anwenderhandbuch: je ein Satz in der Widget-Tabellenzeile und im Absatz "Dashboard > Widgets"
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- Resolver: crop (x/y/w/h, geklemmt auf 1280er-Seite, x verschoben statt abgewiesen), zoom (50..150, groesste Stufe <= n), readOnly (nur echtes true)
- xframe-crop.ts: reine Geometrie - computeCropLayout (contain + zentriert, scale 0 bis gemessen), applyCropDrag (Verschieben, vier Ecken, Gegenecke bleibt)
- Kachel: Clip + verschobener, skalierter <iframe> bei fester Layoutbreite 1280, ResizeObserver am Koerper; Zoom-Zweig mit Prozentmassen; 100 % wie bisher; readOnly-Flaeche nur im Ansichtsmodus
- Formular: Checkbox Ausschnitt (ein Aufruf mit crop + readOnly), Vorschau 1280 px breit mit derselben Sandbox und pointer-events none, Rahmen mit vier Griffen (Pointer-Events, Capture-Waechter fuer jsdom), Zahlenfelder, Zoom-Auswahl nur ohne Ausschnitt, Nur anzeigen, dauerhafter Hinweis
- Rahmen als <fieldset> statt div role=group (Biome useSemanticElements, kein biome-ignore)
- Test-Helfer stubResizeObserver, 13 neue Schluessel de/en, Ausschnitt auf der Umlaut-Allowlist; Web-Tests 604 -> 640
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Befund des Nutzers (22.09.2026): "Herunterladen" unter Einstellungen ->
Desktop-App tut in der App nichts, unter Windows wie Linux. Die Webansicht
hatte keinen Download-Handler; webkit2gtk verwirft Downloads dann still,
WebView2 zeigte ebenfalls nichts.
Das Hauptfenster entsteht jetzt im Code (app.windows in tauri.conf.json
leer), weil nur der Builder `on_download` annimmt. Der Handler bricht den
Download in der App ab und oeffnet die Adresse ueber den Opener im
System-Browser -- mit Fortschritt, Speicherort und Passwortfenster fuer
einen vorgeschalteten Proxy. Masse, Zentrierung, Titel wie bisher; die
Capability "main" gilt unveraendert.
cargo fmt/clippy/test/check gruen (44 Tests).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Plan mit Messungen (API am Proxy vorbei 200, Proxy 401 Basic von zwei
Netzen), Zusammenfassung des Executors, Zeile in der Quick-Tabelle und
Stopp-Punkt: die Behebung des Passwortschutzes liegt beim Nutzer.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Befund 22.09.2026: alpha bietet 1.2.0-beta.gc001a08 an, der Client auf
a6d1a64 zeigt aber nur den grauen Eintrag "Update installieren". Der
Nginx Proxy Manager vor alpha beantwortet die Update-Anfrage mit 401
(Basic-Auth); die Webansicht kann das Passwortfenster beantworten, der
Updater (eigener reqwest-Client) nicht. tauri-plugin-updater verschluckt
einen Nicht-2xx-Status (updater.rs Z. 529-559: nur Log, last_error
leer, Ergebnis Err(ReleaseNotFound)), und spawn_version_check fing das
mit Err(_) => {} stumm ab. Ein fehlgeschlagener Check war damit vom
Zustand "kein Update" nicht unterscheidbar, und ohne Neustart gab es
keinen Weg, erneut zu pruefen.
- Drei Endzustaende, alle anklickbar: "Auf Version/Beta-Stand ...
aktualisieren", "Kein Update verfuegbar - erneut pruefen",
"Update-Pruefung fehlgeschlagen (HTTP n | keine Verbindung) - erneut
pruefen"; waehrend der Pruefung "Suche nach Updates..." (gesperrt),
http-Server unveraendert gesperrt
- Bei ReleaseNotFound stellt der Client dieselbe Anfrage einmal selbst
(Platzhalter ersetzt, Timeout 8 s) und liest nur den Statuscode;
401/403 erklaeren den Proxy-Passwortschutz, Zugangsdaten werden
bewusst NICHT in den Client eingebaut
- Benachrichtigung je unterschiedlichem Fehlertext einmal
(LastCheckNotice), Erfolg leert die Entprellung
- Wiederhol-Thread alle 4 h (std::thread, kein neues Crate), liest die
Adresse frisch, ueberspringt bei bereits abgelegtem Update
- Klick ohne abgelegtes Update prueft erneut; der Browser-Weg bleibt nur
Rueckfall einer fehlgeschlagenen Installation
- 7 neue Tests (Labels, Diagnose-URL, Konstanten), zuvor rot (E0425)
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Zwei Kosmetik-Punkte nach dem Browser-Rundgang vom 21.09.2026:
- Das laengste Wechselintervall (3600 s) hiess "60 Minuten", beim XFrame
heisst dieselbe Stufe "Jede Stunde". Neuer Schluessel
`pictureFrame.intervalHours` (ICU-Plural, de + en).
- Unter Einstellungen -> Dashboard zeigte "XFrame #1 - Board" seinen Titel,
"Bilderrahmen #1" nichts. Die Kopfzeile nennt jetzt "- 1 Bild" bzw.
"- N Bilder" (Schluessel `imageCountOne`/`imageCountMany`, zwei Schluessel
statt ICU, weil die Panel-Tests eine einfache Uebersetzungs-Attrappe nutzen).
Web-Tests 603 -> 604, type-check und lint unveraendert gruen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Plan, Zusammenfassung mit abgehakter Pruefliste und die Zeile in der
Quick-Tabelle von STATE.md; Stopp-Punkt: beide bestellten Widgets fertig,
nichts offen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Plan, Zusammenfassung (mit Rot-Nachweis, curl-Rundgang, abgehakter
Pruefliste und den drei im Rundgang gefundenen Befunden) sowie die Zeile in
der Quick-Tabelle von STATE.md.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- CHANGELOG: Stichpunkt als erster unter "Unveroeffentlicht -> Neu"
- Anwenderhandbuch: Zeile in der Widget-Tabelle, erweiterter Satz zu den
Widget-Einstellungen, Absatz-Zusatz unter "Dashboard > Widgets"
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- xframe-config.ts: Resolver (https-Pruefung via isHttpsUrl des Bilderrahmens,
Titel bis 100 Zeichen, Neuladen 0/60/300/600/1800/3600 s geklemmt),
XFRAME_SANDBOX ohne allow-top-navigation und allow-modals; 12 Tests zuerst rot
- xframe-widget.tsx: genau ein <iframe> (sandbox, allow="", no-referrer, lazy),
Kopfleiste mit Titel oder Ecksymbol "In neuem Tab oeffnen", Neuladen ueber
key-Wechsel mit Timer-Raeumung, transparente Flaeche im Bearbeitungsmodus
damit die Kachel Ziehgriff bleibt; 12 Tests zuerst rot
- xframe-config-form.tsx: Adresse/Titel mit Uebernahme bei Blur/Enter, http wird
mit Meldung abgewiesen und nicht gespeichert, Intervall-Auswahl, dauerhafter
Hinweis auf verweigertes Einbetten; 8 Tests
- Panel-Zweig samt "— Titel" in der Kopfzeile, Registry (12x12, Fenster-Symbol),
Katalog, Seite, DTO @IsIn, de/en widgets.xframe (15 Schluessel), Umlaut-Allowlist
"neuem"; der Server ruft die Adresse nie ab
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Befunde aus dem Browser-Rundgang am 21.09.2026:
- Die Grossansicht lag in einem `react-grid-item` mit CSS-`transform`; ein
transformierter Vorfahr wird fuer `position: fixed` zum Bezugsrahmen, der
Dialog war deshalb auf die Kachelflaeche (531x216) beschraenkt statt den
Viewport zu fuellen. Jetzt per `createPortal` in `document.body`, wie der
Kalender-Tooltip.
- Wechselintervall "1 Minuten" -> ICU-Plural (`one {# Minute}`), de + en; der
Formular-Test nutzt dafuer den echten `createTranslator` von next-intl auf
der echten de.json statt eines `{n}`-Ersatzes.
- Standardgroesse 8x8 (216 px hoch) war zu flach fuer ein Foto -> 8x12 wie die
Kalender-Vorgabe.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- CHANGELOG.md: erster Stichpunkt unter Unveroeffentlicht -> Neu
- docs/anleitung-anwender.md: Zeile in der Widget-Tabelle, Absatz zur
Bildverwaltung unter Dashboard > Widgets
- umlaut-dictionary.ts: „Webadresse“ und „Bildausschnitt“ als korrektes
Deutsch auf die Erlaubnisliste des Umlaut-Waechters (der volle Web-Testlauf
hatte die beiden neuen ss-Woerter aus de.json gemeldet)
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- picture-frame-config.ts: Eintragstyp als Vereinigung (upload | url) in EINER
geordneten Liste, resolvePictureFrameConfig laesst alles ausser https weg
(T-PI9-07), Intervall 0 oder 5..3600 s, pickNextIndex (Zufall nie dasselbe)
- dashboard-images-api.ts: Upload als FormData-Feld image ohne eigenen
Content-Type, 413 -> deutsche Meldung, Proxy-Pfad fuer <img src>
- PictureFrameWidget: Leerzustand, <img referrerPolicy=no-referrer> (Browser
laedt Fremdbilder, Server nie), object-contain/cover, Unterschrift-Streifen,
Wechsel per Timer mit Raeumung, kaputte Bilder verlassen den Umlauf,
Grossansicht nur ausserhalb des Bearbeitungsmodus mit Fokus-Rueckgabe und
Pause des Wechsels; im Bearbeitungsmodus kein Knopf (Karte bleibt Griff)
- PictureFrameConfigForm im WidgetSettingsPanel: Ausschnitt, Intervall,
Reihenfolge, Liste mit Vorschau/Unterschrift/Pfeilen/Entfernen (Upload wird
auch serverseitig geloescht), Datei hochladen, https-Adresse hinzufuegen
- Registry (4x4 min, 8x8 Vorgabe), Katalog, Seite, Uebersetzungen de/en
(widgets.pictureFrame, 28 Schluessel), bestehende Tests auf acht Typen
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- Prisma-Modell DashboardImage (bytea) mit Migration 20260921120000: Tabelle,
Indizes, RLS ENABLE/FORCE und tenant_isolation_policy mit Benutzerdimension
- dashboard-image-rules.ts: detectImageMime ueber Magic Bytes (PNG/JPEG/GIF/
WebP), Grenzen 5 MiB je Datei und 30 je Benutzer
- DashboardImagesService: list/upload/getBytes/remove, je Methode
forTenant(prisma, tenantId, userId); Besitz = Mandant UND Benutzer, sonst 404
- DashboardImagesController unter dashboard/images: GET, POST (FileInterceptor
image, 5 MiB, eine Datei), GET :id mit Content-Type aus dem erkannten Typ,
Cache-Control private, nosniff, Content-Disposition inline ohne Dateinamen,
CSP sandbox; DELETE :id
- CreateWidgetDto kennt 'picture-frame'
- Klassifikationsdokument: neues Paar dashboard-images.service.ts/
dashboardImage; Bereichs- und Summenzeilen nachgemessen (dashboard 12->18,
settings 3->4 und bug-reports waren in der Summe nie mitgezaehlt)
- Befund: Prisma-Bytes verlangt Uint8Array<ArrayBuffer>, multers Buffer wird
ohne Zusicherung abgelehnt - Kopie per new Uint8Array(buffer) statt Cast
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Elf Quick-Vorgaenge am 2026-09-21. Diagnosen 2923 -> 123, Tests
447 -> 1679, keine auf Fehlerstufe. Aus der Fehlerarbeit ist nichts
mehr offen.
Naechster Auftrag laut Nutzer: zwei neue Dashboard-Widgets. Die
Produktfragen zum ersten (Bilderrahmen) sind geklaert und in
stopped_at festgehalten; das zweite hat der Nutzer noch nicht benannt.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TPPB4ApQxzSU1rwV2Ffj9J
B-06: requireTLS durch doSTARTTLS ersetzt. requireTLS kennt imapflow 1.4.3
nicht und verwirft es still; ein als STARTTLS eingerichtetes Postfach konnte
deshalb unbemerkt im Klartext verbinden. Gewollte Folge: so ein Postfach
scheitert jetzt, wenn der Server kein STARTTLS anbietet. Bei ssl-tls ergibt
der Ausdruck false, was die Unvertraeglichkeit secure=true + doSTARTTLS=true
gar nicht erst entstehen laesst.
B-05: Dateiname aus Content-Disposition kommt jetzt aus dem Feld, in dem
imapflow ihn ablegt (dispositionParameters), statt aus .parameters einer
Zeichenkette. Der alte Ausdruck war zur Laufzeit immer undefined, wodurch
Anhaenge als application/octet-stream (typisch Outlook) nicht erkannt wurden.
Die Zusicherung am Ende von buildClient() entfaellt ersatzlos; sie bestand
nur wegen der unbekannten Option. noExplicitAny in apps/api/src faellt damit
von 15 auf 13.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TPPB4ApQxzSU1rwV2Ffj9J
- B-06: prueft die an ImapFlow uebergebenen Optionen fuer starttls und ssl-tls
- B-05: prueft, dass ein octet-stream-Anhang am Dateinamen aus
Content-Disposition erkannt wird
- Einhaengen des Testdoppels in einen Helfer gezogen; die Umdeutung des
Konstruktors steht damit nur noch an einer Stelle statt an zwoelf
Gegen den heutigen Stand rot: 3 von 12 Faellen scheitern
(doSTARTTLS undefined, Feld requireTLS vorhanden, Anhang nicht eingesammelt).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TPPB4ApQxzSU1rwV2Ffj9J
Zusammenfassung mit Urteilsregister und STATE.md zum Quick-Vorgang
260921-m34.
Der groesste Posten war ein einziges Missverstaendnis: 105 Stellen
trugen eine Zusicherung an der Mandantenbindung, die nie noetig war -
prisma.$extends() liefert laengst einen getypten Klienten.
Die tenantId-Frage wurde hergeleitet statt nach Bequemlichkeit
entschieden: string ohne Fragezeichen, belegt aus Pflichtspalte im
Schema, Bestandstyp und dem Super-Admin-Zweig der Mandantenpruefung -
der diesen Typ gar nicht liest und deshalb nicht zu totem Code werden
kann. Der Waechter blieb ueber den ganzen Lauf unveraendert.
Vier Befunde gemeldet statt still repariert. Zwei brauchen eine
Entscheidung, beide wuerden Verhalten aendern - darunter ein
sicherheitsrelevanter: die IMAP-Einstellung STARTTLS erzwingt nichts,
weil die gesetzte Option in imapflow 1.4.3 nicht existiert.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TPPB4ApQxzSU1rwV2Ffj9J
httpntlm (exchange.provider, exchange-inbox.provider): NtlmOptions und
NtlmResponse beschreiben genau das, was uebergeben und gelesen wird. Die
ueberfluessige Zusicherung (httpntlm as any) faellt weg.
Graph-Rueckrufe (exchange.provider :157/:313): AuthProviderCallback aus dem
SDK selbst statt Handannotation - als import type, also ohne den dynamischen
Import zur Laufzeit zurueckzunehmen.
imapflow: streamToBuffer() nimmt Readable statt NodeJS.ReadableStream (alle
drei Aufrufer reichen client.download().content herein, imapflow deklariert
das als Readable) - damit traegt der Typ destroy() und die Zusicherung
faellt. node.parameters?.name war ebenfalls schon getypt.
nodemailer: ResolvedTransport.options wird SMTPTransport.Options; beide
Zweige bauen reine SMTP-Optionen, createTransport() nimmt sie ohne
Zusicherung.
node-forge: die vier let p7: any werden Captured<PkcsEnvelopedData |
PkcsSignedData> - der MITGELIEFERTE Typ. Die Lesestellen grenzen mit
'certificates' in p7 ein statt zuzusichern; verhaltensgleich, weil der
enveloped-Form das Feld fehlt und beide Schreibweisen dann die leere Liste
liefern. cert.siginfo war bereits getypt.
apps/web/src/test/setup.ts: expect.extend(matchers) traegt ohne Zusicherung
- geprueft im echten Typlauf (setup.ts liegt im include von
apps/web/tsconfig.json, mit einem absichtlichen Fehler nachgewiesen).
BEFUND 4 (D-03, gemeldet, NICHT repariert) imap.provider.ts:78 - der
Ausdruck (node as any).disposition?.parameters?.filename liest .parameters
von einer ZEICHENKETTE: imapflow deklariert disposition als string
(imap-flow.d.ts:448), die Parameter liegen in dispositionParameters (:450).
dispositionFilename ist damit zur Laufzeit immer ''. Folge: Outlook-Anhaenge,
die als application/octet-stream kommen, werden ueber den Dateinamen aus
Content-Disposition NICHT erkannt - nur ueber den aus Content-Type. Umbiegen
waere eine Verhaltensaenderung; die Zusicherung bleibt sichtbar stehen.
BEFUND 5 (D-03, gemeldet, NICHT repariert) imap.provider.ts:402 -
requireTLS kommt in imapflow 1.4.3 NIRGENDS vor, weder in ImapFlowOptions
noch im Laufzeitcode (beides durchsucht). Die Option wird still verworfen;
STARTTLS wird durch sie nicht erzwungen. Genau das } as any hat es
verdeckt. Bleibt stehen, damit der Befund in der Zaehlung sichtbar ist.
BEFUND 6 (D-03, gemeldet, Verhalten unveraendert) httpntlm liefert den
Rumpf als Zeichenkette, nicht als Buffer: httpreq setzt ihn nur bei
gesetzter Option binary auf Buffer (httpreq@1.1.1/lib/httpreq.js:391),
keiner der beiden Aufrufer setzt sie. Der Bestand rief unbesehen
.toString('utf-8') auf - das ging nur gut, weil String.toString() sein
Argument ignoriert. Die Testdoppel reichen dagegen wirklich Buffer herein.
NtlmResponse.body nennt jetzt beide Formen, die Fallunterscheidung liefert
fuer jede exakt dasselbe Ergebnis wie zuvor.
Urteil BLEIBT mit Begruendung im Code an allen 15 verbleibenden Stellen:
3x addCronJob (require-Umweg aus 07-04), 5x node-forge (EC-Zweig und
extensions: any[] sind in @types/node-forge nicht beschrieben, 2x null as
any wo die Typen die Bibliothek nachweislich falsch beschreiben), 2x
imap-Befunde oben, 2x tx: any plus 2x Gefolge (Aufgabe 1), 1x
disposition-Befund.
noExplicitAny in apps/api/src: 31 -> 15 (Ausgang 288, Schranke 45), apps/web
1 -> 0. type-check 4/4, lint 5/5 (0 error), apps/api 72/1143, apps/web
73/531, rls-access-inventory 30/30. noNonNullAssertion 56, as unknown as 33,
ts-expect-error/ts-ignore 0/0, Unterdrueckungsmarker 1. biome.json, alle
package.json und pnpm-lock.yaml unveraendert.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TPPB4ApQxzSU1rwV2Ffj9J
- auth.service.ts:393: (response as any).cookie war schlicht ueberfluessig.
response ist in derselben Signatur bereits Response aus express, die
Schwesterstelle :190 kommt ohne Zusicherung aus. Ersatzlos entfernt.
- calendar.service.ts: das lokal gebaute data-Objekt traegt jetzt
Prisma.CalendarSourceUncheckedCreateInput bzw. ...UncheckedUpdateInput
statt Record<string, unknown> plus Zusicherung. Damit fallen beide
`data as any` weg, ohne dass ein Feld behauptet wird.
- user.service.ts: `let created: any` -> User (die Zuweisung steht im try,
der catch endet ausnahmslos mit throw). `const updateData: any` wird aus
der Signatur hergeleitet - Omit<UpdateUserInput, 'password'> plus dem
daraus berechneten passwordHash; die Parameterform ist dafuer als
UpdateUserInput benannt und nicht neu erfunden. `const results: any[]`
wird Pick<User, keyof typeof PLATFORM_USER_SELECT>[], die Spaltenauswahl
steht als Konstante daneben.
- tenant.controller.ts:69: Elementtyp aus dem hergeleitet, was die Schleife
hineinlegt (fuenf Tenant-Spalten plus userCount).
BEFUND 3 (D-03, gemeldet, kein Verhalten betroffen) Die naheliegende
Prisma-Schreibweise Prisma.UserGetPayload<{ select: typeof X }> laesst
rls-access-inventory.spec.ts rot werden: der Erkenner zaehlt JEDE
select:-Angabe ausserhalb eines erkannten Modellaufrufs als Verstoss und
unterscheidet Typposition nicht von Aufrufposition. Gemessen beim ersten
Versuch. Der Erkenner ist die Mandantenkontrolle (T-M34-03) und wurde
NICHT aufgeweicht - stattdessen leitet der Zeilentyp ueber Pick<User, ...>
her, was ohne das Wort select auskommt. Begruendung steht am Typ.
noExplicitAny in apps/api/src: 38 -> 31. type-check 4/4, lint 5/5 (0
error), apps/api 72/1143, apps/web 73/531, rls-access-inventory 30/30.
noNonNullAssertion 56, as unknown as 33, Unterdrueckungsmarker 1.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TPPB4ApQxzSU1rwV2Ffj9J
catch (e: any) in groups, module-grants, ldap, user, admin-seed, calendar
und vier tenders-Diensten auf catch (e: unknown) umgestellt. Die
Eingrenzung passiert an der Verwendungsstelle, nicht per Zusicherung.
Neu: apps/api/src/prisma/prisma-error.ts mit prismaErrorCode() und
prismaErrorTarget(). Bewusst Form-Pruefungen statt instanceof
Prisma.PrismaClientKnownRequestError - gemessen: samtliche Testdoppel in
apps/api werfen new Error(...) mit angehaengtem .code (groups, user, ldap,
tenders, module-grants, admin-seed) und dashboard.service.spec.ts:451 ein
reines { code: 'P2002' }. Ein instanceof-Test haette all diese Werte in den
anderen Zweig geschickt - Verhaltensaenderung, verboten nach D-03/T-M34-06.
Die Helfer bilden err?.code und err?.meta?.target eins zu eins ab.
ldap.service.ts liest zusaetzlich meta.target; prismaErrorTarget() gibt
unknown zurueck, weil der Bestand dort Array UND Zeichenkette getrennt
behandelt - ein engerer Typ waere eine Behauptung.
calendar.service.ts:341 nutzt instanceof Error statt e?.message: gemessen
wirft validateUrlNotPrivate() ausschliesslich ForbiddenException (der
eigene catch dort setzt jeden Fremdfehler in eine um), also trifft
instanceof dieselben Faelle. Ersatzzweig 'URL not allowed' unveraendert.
noExplicitAny in apps/api/src: 56 -> 38. type-check 4/4, lint 5/5 (0
error), apps/api 72/1143, apps/web 73/531, rls-access-inventory 30/30.
noNonNullAssertion 56, as unknown as 33, Unterdrueckungsmarker 1.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TPPB4ApQxzSU1rwV2Ffj9J
@UploadedFile()/@UploadedFiles() in cert-manager.controller auf
UploadedFileLike. Der Dienst nimmt CertFileLike = Pick<UploadedFileLike,
'buffer' | 'originalname'> - genau die zwei Felder, die er liest; mimetype
und size bleiben draussen, weil kein Zweig sie anfasst.
Belegt statt behauptet: keiner der sechs FileInterceptor/FilesInterceptor-
Aufrufe in apps/api/src setzt eine storage-Option, also gilt multers
memoryStorage, also ist buffer ein Buffer. @types/multer bleibt
uninstalliert (D-04).
Damit fallen 25 Zusicherungen der Form file.buffer as Buffer und
file.originalname as string ersatzlos weg - sie standen nur da, weil file
ein any war. as unknown as bleibt bei 33, noNonNullAssertion bei 56.
noExplicitAny in apps/api/src: 66 -> 56 (Ausgang der Aufgabe: 149,
Schranke des Plans: 75). type-check 4/4, lint 5/5, apps/api 72/1143,
apps/web 73/531.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TPPB4ApQxzSU1rwV2Ffj9J
(req as any) und @Req() req: any durch AuthenticatedRequest ersetzt in
dashboard, favorites, calendar, groups, module-grants, module-registry,
tenders, dkv, ldap, settings; @CurrentUser() in user.controller auf AuthUser.
Die abwehrenden Pruefungen ("No tenant context", "No user context") bleiben
lebendig, weil user auf dem Anfragetyp wahlfrei ist - genau das beschreibt
den Zustand auf oeffentlichen Wegen.
Nebengewinn ohne neue Zusicherungen: req.tenantId as string | undefined
(dkv, settings), file.buffer as Buffer und file.mimetype as string
(dkv, user) sind weggefallen, weil der Typ sie jetzt traegt.
BEFUND 1 (D-03, gemeldet) dashboard.controller.ts:74 alt: der Handler las
req.user?.role NACH extractContext und gab sie an getWidgets(role: Role)
weiter, das eine Rolle zwingend verlangt. Die Annahme "hier gibt es immer
einen Aufrufer" stimmt - die Pruefung "No user context" erzwingt sie -, aber
sie stand in einer anderen Methode, wo der Compiler sie nicht sehen konnte.
extractContext gibt die Rolle jetzt mit zurueck: keine neue Pruefung, kein
erfundener Wert, gleiche Reihenfolge, gleiche Meldungen.
BEFUND 2 (D-03, gemeldet) tenders.controller.ts:142: resolveRequestingTenantId
erklaerte string | undefined, liest aber req.tenantId, das TenantGuard fuer
einen SUPER_ADMIN ohne Mandanten auf null setzt. Die Erklaerung war also nie
vollstaendig. Erweitert auf string | null | undefined, und buildTenderWhere
nimmt string | null - beides nur Erklaerung, kein Verhalten: die Funktion
entscheidet seit jeher ueber Wahrheitswert und faellt bei beiden zu
(nur global sichtbare Ausschreibungen).
Fixtures in user.controller.spec.ts ergaenzt (username, mustChangePassword,
originalname, size). Testzahlen unveraendert.
noExplicitAny in apps/api/src: 137 -> 66. type-check 4/4, lint 5/5,
apps/api 72/1143, apps/web 73/531, tenant.guard.ts unveraendert.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TPPB4ApQxzSU1rwV2Ffj9J
apps/api/src/auth/types/auth-user.ts angelegt: AuthUser, AuthenticatedRequest,
LocalAuthenticatedRequest, LoginUser, JwtPayload, UploadedFileLike. Jedes Feld
traegt seine Herkunft als Kommentar.
tenantId ist string, hergeleitet und nicht gewaehlt: die Spalte User.tenantId
ist in schema.prisma Pflicht, beide Signierstellen schreiben genau sie, und
der Bestand beschreibt dasselbe Objekt in SessionUser schon so. Der
SUPER_ADMIN-Zweig in TenantGuard spricht nicht dagegen - der Waechter liest
AuthUser gar nicht, und dass es den Zweig gibt, steht als null in
AuthenticatedRequest.tenantId weiter im Typsystem. tenant.guard.ts bleibt
unberuehrt.
role ist die Aufzaehlung Role: schema.prisma deklariert die Spalte so, die
SQL-Funktion auth_lookup_user_by_username gibt sie als "Role" zurueck. Die
Handannotation role: string in AuthLookupUserByUsernameRow war eine zweite
Fassung desselben Wertes und faellt damit weg.
SessionUser und UploadedPng in bug-reports.service.ts sind jetzt Pick<> der
neuen Typen statt eigener Beschreibungen.
Fixtures in auth.controller.spec.ts ergaenzt: sie uebergaben einen Aufrufer
ohne username und ohne mustChangePassword - eine Form, die JwtStrategy nie
erzeugt. Testzahlen unveraendert.
noExplicitAny in apps/api/src: 149 -> 137. type-check 4/4, lint 5/5,
apps/api 72/1143, apps/web 73/531.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TPPB4ApQxzSU1rwV2Ffj9J
- prisma-tenant.extension.ts: (prisma as any) und die Handannotation an
$allOperations in forTenant()/forSystem() entfernt; Kopfkommentar
unveraendert. .then((results: any[]) => ...) auf unknown[] umgestellt.
- 105 Aufrufstellen `const X = forTenant(...) as any` / `forSystem(...) as
any` von der Zusicherung befreit, Zuweisungsform woertlich erhalten
(rls-access-inventory.spec.ts bleibt scharf, 30/30 gruen einzeln
geprueft).
- withTenantTransaction(): Prisma.TransactionClient fuer tx probiert,
gemessen verworfen - bricht das Testdoppel in
prisma-tenant.extension.spec.ts (TS2322 auf einem absichtlich
unvollstaendigen Fake-Objekt). tx bleibt any, mit Begruendung am Typ.
- Gefolge des jetzt getypten Klienten entfernt: any[]-Annotationen und
.map((x: any) => ...) in groups.service.ts, module-grants.service.ts,
dkv.service.ts, ldap-config.service.ts, tenders.controller.ts:270.
- Befund (D-03): tender-matching.service.ts:159 trug eine Handannotation
(match: { tender: unknown }), die den Wert nur deshalb auf unknown
verengte, um TS7006 unter dem alten any-Klienten zu vermeiden - mit dem
getypten Klienten war das falsch. Annotation geloescht, kein Ersatz
durch Zusicherung.
- Zwei any bleiben gezielt in groups.service.ts (u/a in
ensureDefaultGroup(), gefolge von tx: any) - Begruendung am Code.
noExplicitAny apps/api/src: 288 -> 149 (Schranke 155). type-check 4/4,
lint 5/5 (0 error). apps/api 72/1143 gruen, apps/web 73/531 gruen,
rls-access-inventory.spec.ts 30/30 gruen.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TPPB4ApQxzSU1rwV2Ffj9J
Drei Aufgaben statt einer Sammelaktion, geschnitten nach Form und Risiko.
Die Formen wurden nicht geschaetzt, sondern durch Probeumbauten am echten
Baum gemessen (jeder danach zurueckgenommen):
- 105 mal forTenant(...) as any: die Zusicherung war nie noetig, tsc meldet
ohne sie genau einen Folgefehler.
- 13 der 15 Stellen in prisma-tenant.extension.ts fallen ebenso.
- Sechs Controller auf einen getypten Request: genau ein Fehler, und der
ist ein echter Befund im Bestandscode.
- Die drei addCronJob-Stellen sind gemessen nicht aufloesbar und bekommen
das Urteil bleibt.
Erwartetes Ergebnis 20 bis 40 verbleibende Befunde, nicht null: wer die
letzten Stellen erzwingt, tauscht eine ehrliche Warnung gegen eine
unehrliche Behauptung.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TPPB4ApQxzSU1rwV2Ffj9J
Der rote CI-Lauf 395 war kein Zufall und kein Testproblem: der
Fehler-melden-Dialog stand bei jedem Oeffnen kurz mit ausgeschaltetem
Haekchen da, weil er dauerhaft eingehaengt war und sein Anfangswert nur
einmal lief. Deterministisch belegt ueber jeden DOM-Commit, im
Produktcode behoben.
Die 20 gruenen Stabilitaetslaeufe gelten ausdruecklich nicht als Beweis
- bei Ausgangsrate 1:17 waeren sie auch ohne Reparatur zu rund 30
Prozent zu erwarten.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TPPB4ApQxzSU1rwV2Ffj9J
Zusammenfassung, Debug-Akte und Knowledge-Base-Eintrag zum Quick-Vorgang
260921-ldf.
Die zentrale Frage war, ob hinter dem Wackeltest aus CI-Lauf 395 ein
echter Nutzerfehler steckt. Sie ist gemessen beantwortet, nicht
geschaetzt: ein MutationObserver ueber jeden DOM-Commit zeigt den
Zustand "Vorschaubild sichtbar, Haekchen aus" bei JEDEM Oeffnen als
echten, festgeschriebenen DOM-Zustand, der ohne act() zwei volle
Makrotask-Runden haelt. Zwischen zwei Makrotasks darf der Browser
zeichnen - der Nutzer kann das also sehen. Was nicht erreichbar ist:
jemand schickt ab und das Bild fehlt, denn die Korrektur kommt binnen
Millisekunden.
Stabilitaet: 20 von 20 vollen Laeufen gruen, je 531 Tests. Die
Zusammenfassung ordnet das ehrlich ein - bei einer Ausgangsrate von
1:17 waeren 20 gruene Laeufe auch ohne Fix zu rund 30 Prozent zu
erwarten. Der tragende Beleg ist der deterministische: den falschen
Zwischenzustand gibt es nicht mehr, und Test 14/15 sind gegen den Stand
davor in fuenf von fuenf Laeufen rot.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TPPB4ApQxzSU1rwV2Ffj9J
Der alte Test 1 fand den Fehler nur durch Zufall: er las den DOM einmal,
nachdem findByRole den Dialog gemeldet hatte, und traf damit mal den
falschen ersten, meist den richtigen zweiten Commit. Ein Fehlschlag auf
rund siebzehn volle Laeufe.
Die beiden neuen Tests beobachten stattdessen per MutationObserver JEDEN
Commit waehrend des Oeffnens und dulden keinen einzigen, in dem das
Vorschaubild sichtbar ist und das Haekchen aus. Test 14 deckt das erste
Oeffnen ab, Test 15 das erneute Oeffnen nach einem Versand mit
abgewaehltem Haekchen und getipptem Text - dort darf weder der alte
Dankestext noch der alte Text noch ein ausgeschaltetes Haekchen in
irgendeinem Commit auftauchen.
Beide sind gegen den Stand vor dem Fix in fuenf von fuenf Laeufen rot,
danach gruen. Kein retry, kein hoeheres Zeitlimit: die Ursache war nie
blosse Zeit, sondern ein falscher Zustand, den es jetzt nicht mehr gibt.
Test 1 bleibt unveraendert in der Sache und prueft weiterhin dieselbe
Zusicherung.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TPPB4ApQxzSU1rwV2Ffj9J
Gemessene Ursache des Wackeltests aus CI-Lauf 395, und es ist ein
Produktfehler, kein Testfehler. Ein MutationObserver ueber jeden
DOM-Commit beim Oeffnen protokollierte:
COMMIT dialog=true img=ja box=AUS <- falsch, aber festgeschrieben
COMMIT dialog=true img=ja box=AN
Der erste Zustand entstand bei JEDEM Oeffnen, nicht nur unter Last, und
hielt ohne act() zwei volle Makrotask-Runden - der Browser hat in dieser
Zeit mindestens zwei Gelegenheiten, ihn zu zeichnen. Ein Nutzer sieht
also sein Vorschaubild kurz mit ausgeschaltetem Haekchen. Der Test fiel
nur dann durch, wenn er zufaellig den ersten statt den zweiten Commit
sah; die Last im vollen Lauf war der Ausloeser, nicht die Ursache.
Zwei Bedingungen mussten zusammentreffen. Erstens war der Dialog
dauerhaft eingehaengt und gab bei geschlossenem Zustand nur null zurueck
- useState(screenshot !== null) lief damit ein einziges Mal, beim
allerersten Mount des Knopfs, als noch gar kein Bild da war. Das
Haekchen startete also immer aus. Zweitens zog ein useEffect den
Zustand nach, und passive Effekte laufen erst NACH dem Commit.
Beides ist jetzt weg. Der Dialog wird nur noch eingehaengt, solange er
offen ist, also ist jedes Oeffnen ein frischer Mount mit frischem
Zustand. Und das Haekchen wird beim Rendern aus screenshot abgeleitet
statt per Effekt nachgezogen; attachChoice haelt allein die bewusste
Abwahl des Nutzers. Der Effekt, der Status, Text und Haekchen beim
Oeffnen zuruecksetzte, entfaellt ersatzlos.
Damit verschwindet dieselbe Klasse an einer zweiten Stelle: beim
erneuten Oeffnen nach einem Versand stand bisher zwei Runden lang der
alte Danke-Bildschirm im DOM, bevor das frische Formular erschien.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TPPB4ApQxzSU1rwV2Ffj9J
Beide Befunde sind nicht die Ursache des Wackeltests aus CI-Lauf 395,
aber beide haetten die Fehlersuche in die Irre fuehren koennen.
Erstens stand ein expect INNERHALB der toPng-Attrappe. Wirft es, landet
der Fehler mitten im await von captureScreenshot, und dessen catch
liefert still null zurueck. Der Test waere dann nicht an der Stelle
durchgefallen, die er prueft, sondern viel spaeter mit der Meldung, es
gebe kein Vorschaubild. Die Attrappe haelt die Beobachtung jetzt nur
noch fest, geprueft wird sie im Testkoerper. Bewiesen wird dasselbe:
zum Zeitpunkt der Aufnahme steht kein role="dialog" im DOM.
Zweitens wurden scrollWidth und scrollHeight von document.body per
Object.defineProperty ueberschrieben und nie zurueckgesetzt. Die eigene
Eigenschaft verdeckt den Getter von Element.prototype, und document.body
ueberlebt cleanup() - alle zwoelf folgenden Tests der Datei sahen
weiterhin 3200x1000. stubBodyGroesse merkt sich das jetzt, afterEach
nimmt es per Reflect.deleteProperty wieder zurueck.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TPPB4ApQxzSU1rwV2Ffj9J
Zusammenfassung und STATE.md zum Quick-Vorgang 260921-jt4.
Der Planer hat zwei Vorgaben des Orchestrators widerlegt: der
vorgesehene Rueckfallweg mit role und Tastaturhandler tauscht gemessen
drei Befunde gegen einen neuen, und vier der elf vermeintlichen
Klick-Befunde sind onError-Handler an Bildern, also gar keine
Bedienung. Alle fuenf ARIA-Befunde waren Beschriftungen auf rollenlosen
Elementen, die Vorleseprogramme still verwerfen.
Laufzeitnachweis vom Orchestrator: drei Monatswechsel holen die
Quellenliste nur noch einmal statt viermal, der Termin-Abruf mit
identischem Zeitraum ist weg. Der 5-Minuten-Auffrischer ist per
gestellter Uhr als intakt belegt, nicht per Warten im Browser - zwei
solche Messversuche waren ungueltig, weil das Werkzeug die Seite
zwischendurch neu laedt.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TPPB4ApQxzSU1rwV2Ffj9J
Restposten 3a (doppeltes Ladefenster): lastFetchWindowRef merkt sich das
zuletzt TATSAECHLICH geholte from/to-Paar; ein Monatswechsel, dessen
berechnetes Fenster damit uebereinstimmt, ueberspringt fetchEvents. Der
5-Minuten-Auffrischer (force=true) umgeht den Sperrgriff immer, sonst
friert die Anzeige ein. computeFetchWindow und die Tagesgrenzen-Rundung
bleiben unangetastet.
Restposten 3b (Quellenliste je Monatswechsel): hasSourcesRef merkt sich
das Ergebnis; fetchSources laeuft nur beim Aufbau (Merkung leer) oder
erzwungen (Auffrischer) — eine neu eingerichtete Quelle wird weiterhin
binnen fuenf Minuten bemerkt.
Restposten 4 (t-Identitaet): neue translations-identity.test.tsx rendert
eine Testkomponente unter dem ECHTEN NextIntlClientProvider und beweist
per Referenzgleichheit, dass t bei einem lokalen Zustandswechsel
dasselbe Funktionsobjekt bleibt — bestaetigt durch den use-intl-4.13.0-
Quelltext (translate entsteht in einem useMemo, dessen Abhaengigkeiten
ausschliesslich aus dem root-staendigen Intl-Kontext stammen). Die
Faustregel aus 260921-gof ("t gehoert in keine Abhaengigkeitsliste")
bleibt als Konvention in Ordnung; die zugrunde liegende Annahme ("t ist
bei jedem Render frisch") ist damit ausdruecklich WIDERLEGT statt ein
drittes Mal weitergetragen. Die vier verbliebenen Stellen
(marketplace/page.tsx, admin/users/page.tsx,
calendar-settings-panel.tsx, calendar-source-form.tsx) bleiben deshalb
unveraendert.
Vier neue zaehlende Testfaelle in calendar-widget.test.tsx (Aufbau je 1,
abweichendes Fenster +1/+0, identisches Fenster +0/+0, erzwungener Lauf
+1/+1) plus ein Test, dass ein uebersprungener Lauf den Ladezustand
sauber beendet und geladene Termine nicht leert.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TPPB4ApQxzSU1rwV2Ffj9J
downloadAllAsZip liegt ausserhalb der Komponente und kann den
Uebersetzungs-Hook nicht aufrufen; der Name kommt jetzt als Parameter
herein, Aufrufstelle uebergibt t('actions.zipFilename'). Neuer
Schluessel unter certManager.actions: deutsch "Zertifikate.zip",
englisch "certificates.zip".
Der 260921-bi2-Einwand (ein uebersetzter Name koenne Umlaute auf eine
Windows-Freigabe tragen) trifft fuer diesen konkreten Text nicht zu —
das deutsche Wort enthaelt keinen Umlaut. Die Sicherheit haengt darauf
aber NICHT: neue Datei zip-filename.ts mit einer fuer sich pruefbaren
Schutzfunktion, die Windows-verbotene Zeichen, Steuerzeichen und
Nicht-ASCII ersetzt, abschliessende Punkte/Leerzeichen entfernt,
reservierte Geraetenamen abfaengt, bei leerem Ergebnis auf
certificates.zip zurueckfaellt und die .zip-Endung sicherstellt.
SplitTab.tsx schickt den uebersetzten Namen durch diese Funktion, bevor
er am Download landet. Die Dateinamen IM Archiv bleiben unangetastet.
zip-filename.test.ts deckt beide Katalogwerte (unveraendert), Umlaut,
verbotenes Zeichen, Steuerzeichen, abschliessende Punkte/Leerzeichen,
fehlende/vorhandene Endung, leeres Ergebnis und reservierte
Geraetenamen ab.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TPPB4ApQxzSU1rwV2Ffj9J
schalli