docs(quick-260914-m97): Fehler-melden-Knopf abgeschlossen, verifiziert 9/9 und im Browser bewiesen — Zusammenfassung, Verifikation, Aktenstand, Ledger #38 fixed

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018N9CD3ebPKm1b32bPpBknY

.planning/WINDOWS.md

@@ -2,9 +2,9 @@
 schema_version: 1
 open_count: 15
 waived_count: 1
-fixed_count: 21
-total_count: 37
-last_updated: 2026-09-14T09:51:24.295Z
+fixed_count: 22
+total_count: 38
+last_updated: 2026-09-14T15:17:38.808Z
 ---
 
 # Broken Windows Ledger
@@ -52,6 +52,7 @@ last_updated: 2026-09-14T09:51:24.295Z
 | 35 | quick-260914-ebg | deviation | biome.json |  | Biome ist im Bestand nicht lauffaehig: biome.json traegt den in Biome 2.5.0 unbekannten Schluessel organizeImports (gehoert unter assist), Biome bricht bei jedem Aufruf mit Konfigurationsfehler ab; zusaetzlich fehlt javascript.parser.unsafeParameterDecoratorsEnabled, ohne den jeder NestJS-Parameter-Dekorator ein Parse-Fehler ist (17 allein in user.controller.ts). Der CI-Schritt Lint ruft pnpm lint = turbo lint, keine App hat ein lint-Skript - der Schritt ist ein Leerlauf, der gruen meldet. CLAUDE.md und docs/anleitung-entwicklung.md beschreiben Biome als aktives Werkzeug. Gemessen 260914-ebg; das dortige Gate lief mit einer Ersatzkonfiguration im Scratchpad, relativ zur Baseline (0 Fehler, Warnungen je Datei 22/25/20, alle noExplicitAny-Familie; biome format ebenfalls unsauber, Anfuehrungszeichen-Stil). Zu entscheiden: biome.json reparieren (organizeImports nach assist, Parser-Schalter, quoteStyle single) und ein lint-Skript je App anlegen, dann die Warnungen in einem eigenen Durchlauf abbauen oder als Regelabschaltung begruenden. | open |  | 2026-09-14T08:38:04.079Z |  |
 | 36 | quick-260914-ebg | deviation | apps/web/src/app/(portal)/admin/users/page.tsx |  | handleSubmit und handleDelete pruefen nur res.ok ohne else-Zweig und fangen mit leerem catch - ein 403 der API fuehrt zu keiner sichtbaren Reaktion (Formular bleibt offen, Loeschdialog bleibt stehen, keine Meldung). Bestehendes Verhalten fuer alle 403-Wege (fremder Mandant, Selbstloeschung); seit 260914-ebg (WINDOWS #29) ist der Fall fuer einen ADMIN im Alltag erreichbar, weil die SUPER_ADMIN-Zeile in der eigenen Benutzerliste steht und Aendern/Loeschen darauf jetzt 403 liefert. Familie der still verschluckten Antworten (#28, #32). Frontend von 260914-ebg NICHT geaendert (ausserhalb der Erlaubnisliste). Zu schliessen: Fehlermeldung aus dem Antwortrumpf anzeigen und die Aktionsknoepfe fuer SUPER_ADMIN-Zeilen einem ADMIN gar nicht erst anbieten. | open |  | 2026-09-14T08:38:12.619Z |  |
 | 37 | quick-260914-eym | deviation | apps/api/src/dkv/dkv.service.ts |  | Der Single-Flight-Riegel processing in DkvService.processInbox ist EIN prozessweites Boolean, nicht je Mandant. Seit 260914-eym laeuft je aktivem Mandanten ein eigener Cron-Auftrag (dkv-inbox-poll:<tenantId>); ueberschneiden sich zwei Ticks verschiedener Mandanten, bricht der zweite still ab (Warnzeile 'already processing') und der Mandant wartet bis zum naechsten Intervall - kein Datenverlust, Verzoegerung; mit EINEM Mandanten unveraendert. Der Tick blieb in 3c laut Auftrag unangetastet (T-EYM-09, accept mit Aufzeichnung). Zu schliessen: Riegel je Mandant (Set<tenantId>) mit Test 'zwei Mandanten gleichzeitig, beide werden bedient'. | open |  | 2026-09-14T09:51:24.295Z |  |
+| 38 | quick-260914-m97 | deviation | apps/api/src/bug-reports/dto/bug-report.dto.ts | 71 | Rule 1: @Expose() auf errors ergaenzt, damit die @Transform-Normalisierung auch bei ganz fehlendem Multipart-Feld greift (class-transformer transformiert nur vorhandene Schluessel) | fixed |  | 2026-09-14T15:04:31.846Z | 2026-09-14T15:17:38.808Z |
 
 ````json
 [
@@ -501,6 +502,19 @@ last_updated: 2026-09-14T09:51:24.295Z
     "recorded_at": "2026-09-14T09:51:24.295Z",
     "resolved_at": null,
     "milestone": "v1.2"
+  },
+  {
+    "id": 38,
+    "kind": "deviation",
+    "phase": "quick-260914-m97",
+    "file": "apps/api/src/bug-reports/dto/bug-report.dto.ts",
+    "line": 71,
+    "description": "Rule 1: @Expose() auf errors ergaenzt, damit die @Transform-Normalisierung auch bei ganz fehlendem Multipart-Feld greift (class-transformer transformiert nur vorhandene Schluessel)",
+    "status": "fixed",
+    "reason": "",
+    "recorded_at": "2026-09-14T15:04:31.846Z",
+    "resolved_at": "2026-09-14T15:17:38.808Z",
+    "milestone": "v1.2"
   }
 ]
 ````