- apps/api/src/dkv/dkv.service.spec.ts (neu): Zwei-Klienten-Nachweis nach
dem Muster aus groups.service.spec.ts/tender-triage.service.spec.ts —
dieser Bereich hatte vorher KEINE Testdatei (Befund J). 7 Testfaelle
decken getConfigForApi, saveConfig (Zugangsdaten-Erhaltung), testConnection,
die Verarbeitungsstrecke und den bewusst ungebundenen Planer-Startpfad ab
- dkv.service.ts: loadConfig(tenantId?) in zwei Methoden geteilt —
loadConfig(tenantId) [Pflicht-Mandant, gebunden] und die neue, eigene
Methode loadAnyActiveConfigForScheduler() [bewusst UNGEBUNDEN, eigener
Kopfkommentar mit beiden Zustaenden]. getConfigForApi/saveConfig/
testConnection/_runPipeline binden je EINEN Klienten pro Methode
vollstaendig ueber forTenant()
- dkv-scheduler.service.ts: Kopfkommentar fortgeschrieben (beide Zustaende,
Praezedenzfall, Unsymmetrie), Aufruf auf loadAnyActiveConfigForScheduler()
umgestellt — an der Ablauflogik des Planers nichts geaendert
- .planning/WINDOWS.md: Eintrag #21 (deviation) fuer die benannte Altlast
des Planer-Startpfads angelegt
- docs/mandantentrennung-zugriffsklassifikation.md: dkvModuleConfig-Zeile
auf den jetzt gemessenen Stand "gemischt" nachgezogen (Rule 3 — noetig,
damit rls-access-inventory.spec.ts nach der Aufteilung von loadConfig()
gruen bleibt; die uebrigen zwei dkv-Zeilen und die Uebersichtstabelle
bleiben Aufgabe 3 vorbehalten)
- Falsifizierungsnachweis erbracht: getConfigForApi's erster gebundener
Client probeweise durch this.prisma ersetzt, genau Test 1 wurde rot
(6 andere blieben gruen), Rueckbau zurueckgenommen, Dateien identisch
zum Ausgangsstand bestaetigt
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AMASaSxv5QMY7RncqZriRR
Values >=60 in the cron minute field silently misbehave (*/60 fires once per
hour, */90 fires once per hour, etc.). Use the hours field for intervals >=60:
<60 min → */N * * * *
>=60 min → 0 */H * * * (H = floor(N/60))
Also adds @Max(1440) to DkvConfigDto to bound the field at 24 h.
- DkvSchedulerService: SchedulerRegistry.addCronJob (dynamic interval, not static @Cron)
- onModuleInit loads first active config (v1 single-tenant, documented in SUMMARY)
- setInterval() replaces existing job and registers new one with */ cron expression
- stopJob() removes job when config.isActive=false
- cron package resolved via require() workaround (pnpm strict isolation: transitive dep)
- DkvController: 12 handlers all carrying @Roles(Role.ADMIN, Role.SUPER_ADMIN)
- Routes: GET/PUT config, POST check-now, POST test-connection, GET history,
GET exports/:filename, GET/POST/PUT/DELETE vehicles, POST vehicles/import
- vehicles/import uses FileInterceptor('file') for CSV multipart upload
- exports/:filename streams file as attachment; traversal guard in DkvService
- Controller coordinates scheduler after PUT /dkv/config (no circular dep)
schalli