tessera-ctl/.planning/quick/260918-gza-fehlermeldung-herkunft-ausweisen-browser/260918-gza-PLAN.md

---
phase: quick-260918-gza
plan: 01
type: execute
wave: 1
depends_on: []
autonomous: true
requirements: [QUICK-260918-GZA]

files_modified:
  - apps/api/src/bug-reports/origin.ts
  - apps/api/src/bug-reports/origin.spec.ts
  - apps/api/src/bug-reports/dto/bug-report.dto.ts
  - apps/api/src/bug-reports/bug-reports.service.ts
  - apps/api/src/bug-reports/bug-reports.service.spec.ts
  - apps/api/src/bug-reports/bug-reports.controller.spec.ts
  - apps/desktop/src-tauri/src/lib.rs
  - apps/web/src/middleware.ts
  - apps/web/src/middleware.test.ts
  - apps/web/src/lib/desktop-client.ts
  - apps/web/src/lib/desktop-client.test.ts
  - apps/web/src/lib/bug-report-api.ts
  - apps/web/src/lib/bug-report-api.test.ts
  - apps/web/src/components/bug-report/bug-report-dialog.tsx
  - apps/web/src/components/bug-report/bug-report-button.test.tsx
  - CHANGELOG.md
  - docs/anleitung-administration.md
  - docs/anleitung-betrieb.md

estimate:
  tokens: 95000
  raw_tokens: 95000
  tasks: 3
  confidence: low

must_haves:
  truths:
    - "Der Betreff jeder Fehlermeldungs-E-Mail traegt direkt nach `[Tessera Fehlermeldung]` ein Herkunfts-Kuerzel: `[Browser]`, `[Desktop/Windows]`, `[Desktop/Linux]` (oder `[Desktop]`, wenn ein alter Client kein Betriebssystem meldet) — so lassen sich Meldungen im Postfach sortieren und filtern."
    - "Der Mailtext enthaelt eine Zeile `Herkunft: …`: im Browser `Herkunft: Browser — <Browser> <Hauptversion> auf <Betriebssystem>` (aus dem User-Agent abgeleitet, unbekannte Teile als `unbekannt`), in der Desktop-App `Herkunft: Desktop-App (<Windows|Linux>), Tessera-App <Version> · Stand <Commit>` (ohne `· Stand …`, wenn der Commit leer ist — dieselbe Regel wie `client_info_label`)."
    - "Die bestehenden Zeilen `Browser: <User-Agent>` und `Fenster: <BxH>` bleiben unveraendert erhalten; der rohe User-Agent bleibt in der Mail."
    - "Ein alter Desktop-Client (nur `desktop=1`, ohne Zusatzparameter) und ein alter Web-Bau (ohne die vier neuen Felder) erzeugen weiterhin eine gueltige Meldung: fehlende Felder fallen serverseitig auf `[Browser]` bzw. auf `Desktop-App (unbekannt)` zurueck, kein 400."
    - "Der Desktop-Client meldet Version, Commit und Betriebssystem bei jeder seiner drei Navigationen zur Server-Adresse mit (`dv`, `dc`, `dos` neben dem unveraenderten `desktop=1`); nach einem In-App-Update steht der neue Stand damit automatisch in der naechsten Meldung."
    - "Nichts davon wird in der Datenbank gespeichert; `main.ts` und die Body-Limits bleiben unangetastet (T-M97-03); die Werte dienen ausschliesslich der Anzeige in der Mail und dem Kuerzel in der einen bestehenden Protokollzeile (T-GZA-01)."
  artifacts:
    - "apps/api/src/bug-reports/origin.ts — NEU: reine Helfer `parseUserAgent(ua)` -> `{ browser, os }` und `describeOrigin(input)` -> `{ tag, line }` (nur Regex, keine Abhaengigkeit)"
    - "apps/api/src/bug-reports/origin.spec.ts — NEU: mindestens 8 Faelle (Edge/Windows, Chrome/Windows, Firefox/Linux, Safari/macOS, Android, iPad, WebKitGTK-UA mit clientKind desktop -> `[Desktop/Linux]`, Desktop ohne Commit, Desktop ohne Details, fehlende Felder -> Browser-Rueckfall)"
    - "apps/api/src/bug-reports/dto/bug-report.dto.ts — vier optionale Felder `clientKind`, `clientOs`, `clientVersion`, `clientCommit`"
    - "apps/api/src/bug-reports/bug-reports.service.ts — Betreff mit Kuerzel, Zeile `Herkunft:` vor `Browser:`, Kuerzel in der Protokollzeile"
    - "apps/desktop/src-tauri/src/lib.rs — `with_client_marker(url, version, commit, os)` (rein, getestet) + `with_desktop_marker(url)` als Huelle mit `env!`-Werten; drei Aufrufstellen unveraendert"
    - "apps/web/src/middleware.ts — `withDesktopCookie` setzt zusaetzlich Cookie `tessera_desktop_client` = `<dv>|<dc>|<dos>` (bereinigt, nur wenn alle drei Parameter vorhanden und gueltig)"
    - "apps/web/src/lib/desktop-client.ts — `DESKTOP_CLIENT_COOKIE_NAME`, `parseDesktopClientCookie(cookieString)` (rein) und `getDesktopClientInfo()` -> `{ version, commit, os } | null`"
    - "apps/web/src/lib/bug-report-api.ts — `BugReportPayload` um `clientKind`, `clientOs`, `clientVersion`, `clientCommit` erweitert, vier FormData-Felder"
    - "apps/web/src/lib/bug-report-api.test.ts — NEU: FormData-Felder fuer Desktop- und Browser-Nutzlast, Netzwerkfehler -> `{ ok: false, status: 0 }`"
    - "apps/web/src/components/bug-report/bug-report-dialog.tsx — `handleSend` fuellt die vier Felder aus `isDesktopClient()`/`getDesktopClientInfo()`"
    - "CHANGELOG.md, docs/anleitung-administration.md, docs/anleitung-betrieb.md — Herkunft und Betreff-Kuerzel beschrieben"
  key_links:
    - "Rust `with_desktop_marker` (drei Aufrufstellen: setup ~536, `save_server_url` ~476, `open_server` ~500) -> Query `desktop=1&dv=…&dc=…&dos=…` -> Next.js-Middleware `withDesktopCookie` -> Cookies `tessera_desktop=1` (wie bisher) und `tessera_desktop_client` (neu)"
    - "Cookie `tessera_desktop_client` -> `getDesktopClientInfo()` in desktop-client.ts -> `handleSend` in bug-report-dialog.tsx -> FormData-Felder in `sendBugReport` -> `BugReportDto` (whitelist verlangt die Deklaration!) -> `describeOrigin()` in origin.ts -> Betreff-Kuerzel + Zeile `Herkunft:` in bug-reports.service.ts"
    - "Rueckwaertskompatibilitaet: `@IsOptional()` an allen vier DTO-Feldern + Rueckfall `browser` im Dienst; globale Pipe hat KEIN `forbidNonWhitelisted` (gemessen in apps/api/src/main.ts Z. 17-20) -> neue Web-Felder gegen eine alte API werden still verworfen, alte Web-Baue gegen die neue API liefern `undefined`"
---

<objective>
Fehlermeldungen des Fehler-melden-Knopfs (quick-260914-m97) weisen ihre Herkunft aus: Browser oder Desktop-App, Betriebssystem, bei der Desktop-App zusaetzlich Version und Commit-Stand. Der Betreff bekommt direkt nach `[Tessera Fehlermeldung]` ein kurzes Kuerzel (`[Browser]`, `[Desktop/Windows]`, `[Desktop/Linux]`), der Text eine Zeile `Herkunft: …`. Heute sieht eine Meldung aus WebView2 (Windows) wie Edge und aus WebKitGTK (Linux) wie Safari aus — im Postfach ist nicht erkennbar, ob ein Client oder ein Browser gemeldet hat.

Technischer Ansatz (nach Empfehlung des Orchestrators, keine Abweichung): Der bestehende Marker-/Cookie-Mechanismus aus quick-260917-h2s wird erweitert statt den WebView-User-Agent zu ueberschreiben. Der Rust-Client haengt neben `desktop=1` die Parameter `dv` (CARGO_PKG_VERSION), `dc` (APP_COMMIT, darf leer sein) und `dos` (`std::env::consts::OS`) an; die Middleware legt daraus ein zweites, bereinigtes Cookie `tessera_desktop_client` an; der Web-Client liest es und schickt vier neue Multipart-Felder; die API leitet Kuerzel und Herkunftszeile in einem reinen, eigens getesteten Helfer ab. Alles rein informativ, nichts wird gespeichert.

Purpose: Der Betreiber erkennt am Betreff sofort, ob eine Meldung aus einem Client (und welchem Betriebssystem, welcher App-Version) oder aus einem Browser kommt — und kann das Postfach danach sortieren.
Output: Neue Datei `origin.ts` + Spec in der API; erweiterte DTO/Service/Specs; Rust-Marker mit Zusatzparametern; Middleware-Cookie; Web-Helfer + Nutzlastfelder; CHANGELOG und Handbuecher.
</objective>

<execution_context>
@~/.claude/gsd-core/workflows/execute-plan.md
@~/.claude/gsd-core/templates/summary.md
</execution_context>

<context>
@.planning/STATE.md
@.planning/quick/260914-m97-fehler-melden-knopf-bildschirmfoto-der-a/260914-m97-SUMMARY.md

Quelldateien (alle zur Planungszeit vollstaendig gelesen; Aenderungsumfang ist auf diese Pfade begrenzt):
@apps/api/src/bug-reports/dto/bug-report.dto.ts
@apps/api/src/bug-reports/bug-reports.service.ts
@apps/api/src/bug-reports/bug-reports.service.spec.ts
@apps/api/src/bug-reports/bug-reports.controller.spec.ts
@apps/desktop/src-tauri/src/lib.rs
@apps/web/src/middleware.ts
@apps/web/src/middleware.test.ts
@apps/web/src/lib/desktop-client.ts
@apps/web/src/lib/desktop-client.test.ts
@apps/web/src/lib/bug-report-api.ts
@apps/web/src/components/bug-report/bug-report-dialog.tsx
@apps/web/src/components/bug-report/bug-report-button.test.tsx

<planning_measurements>
Zur Planungszeit gemessen — der Executor braucht das nicht neu herzuleiten:

- **Cookie-Kodierung:** Next.js 15.5 (`next/dist/compiled/@edge-runtime/cookies`) serialisiert Cookie-Werte mit `encodeURIComponent`. `res.cookies.set('tessera_desktop_client', '1.2.0|a6d1a64|windows', …)` erzeugt den Header `tessera_desktop_client=1.2.0%7Ca6d1a64%7Cwindows; Path=/; …`. Im Browser steht deshalb in `document.cookie` die KODIERTE Form. Der Parser in `desktop-client.ts` muss `decodeURIComponent` (in try/catch) anwenden, bevor er an `|` trennt. `res.cookies.get(name)?.value` in Middleware-Tests liefert bereits den dekodierten Wert.
- **Globale ValidationPipe** (`apps/api/src/main.ts` Z. 17-20): `whitelist: true, transform: true`, KEIN `forbidNonWhitelisted`. Folge: Ein neuer Web-Bau gegen eine alte API verliert die vier Felder still (kein 400); ein alter Web-Bau gegen die neue API liefert `undefined` — beide Deploy-Reihenfolgen sind sicher, solange alle vier DTO-Felder `@IsOptional()` tragen.
- **Baseline-Tests:** `pnpm --filter @tessera/api exec vitest run src/bug-reports` -> 11/11 gruen (8 Service + 3 Controller). `pnpm --filter @tessera/web exec vitest run src/lib/desktop-client.test.ts src/middleware.test.ts` -> 11/11 gruen (6 + 5). `bug-report-button.test.tsx` hat 11 Tests. Rust: 33 Tests laut STATE (kgc), `cargo test --lib` im Verzeichnis `apps/desktop/src-tauri` (target/ existiert, inkrementell).
- **Biome:** installiert (2.5.0), aber laut Ledger #35 (STATE.md, 260914-ebg) im Bestand nicht lauffaehig — KEIN Biome-Gate in diesem Plan. Formatierung von Hand am Bestand orientieren (2 Leerzeichen, einfache Anfuehrungszeichen, Zeilen bis 100).
- **Skripte:** `type-check` = `tsc --noEmit` in beiden Apps (`pnpm --filter @tessera/api type-check`, `pnpm --filter @tessera/web type-check`). Paketnamen `@tessera/api`, `@tessera/web`. Kein Paketmanager-Install noetig (keine neue Abhaengigkeit; `class-validator` 0.15 liefert `IsIn`).
- **Docs-Stellen:** `docs/anleitung-administration.md` Z. 208 beschreibt den Mailinhalt und den Betreff `[Tessera Fehlermeldung]` (dort gehoert die Herkunft hin). `docs/anleitung-betrieb.md` hat KEINEN eigenen Fehlermeldungs-/SMTP-Abschnitt und erwaehnt `desktop=1` nirgends; die Anknuepfpunkte sind die Fehlersuche-Tabelle in Kapitel 7 (Zeile „Fehlermeldungen der Anwender kommen nicht an“, Z. 341) und die Tabelle „Fehlerbilder“ in Kapitel 10 (ab Z. 699). `docs/mandantentrennung-zugriffsklassifikation.md` listet keine Rumpffelder -> bleibt unveraendert. Kein UI-Text aendert sich -> `de.json`/`en.json` bleiben unveraendert.
</planning_measurements>
</context>

<tasks>

<task type="tracer" tdd="true">
  <name>Task 1: API — Herkunft ableiten (origin.ts), DTO-Felder, Betreff-Kuerzel und Zeile `Herkunft:` (Browser-Pfad damit bereits Ende-zu-Ende fertig)</name>
  <files>apps/api/src/bug-reports/origin.ts, apps/api/src/bug-reports/origin.spec.ts, apps/api/src/bug-reports/dto/bug-report.dto.ts, apps/api/src/bug-reports/bug-reports.service.ts, apps/api/src/bug-reports/bug-reports.service.spec.ts, apps/api/src/bug-reports/bug-reports.controller.spec.ts</files>
  <read_first>apps/api/src/bug-reports/bug-reports.service.ts (Zeilen 122-149 Betreff/Text, 166-169 Protokollzeile), apps/api/src/bug-reports/dto/bug-report.dto.ts, beide bestehenden Specs (Muster fuer Kopfkommentar, `makeService`, `baseDto`)</read_first>
  <behavior>
    origin.spec.ts (NEU, Vitest, reine Funktionen, mindestens 8 Tests; `describe('origin (quick-260918-gza)')`):
    - Test 1 Edge auf Windows: UA `Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/129.0.0.0 Safari/537.36 Edg/129.0.2792.52` -> `parseUserAgent` = `{ browser: 'Edge 129', os: 'Windows' }`; `describeOrigin({ clientKind: 'browser', userAgent })` = `{ tag: '[Browser]', line: 'Browser — Edge 129 auf Windows' }` (Edge MUSS vor Chrome gewonnen werden).
    - Test 2 Chrome auf Windows (gleicher UA ohne `Edg/`): `{ browser: 'Chrome 129', os: 'Windows' }`.
    - Test 3 Firefox auf Linux: UA `Mozilla/5.0 (X11; Linux x86_64; rv:130.0) Gecko/20100101 Firefox/130.0` -> `{ browser: 'Firefox 130', os: 'Linux' }`; Zeile `Browser — Firefox 130 auf Linux`.
    - Test 4 Safari auf macOS: UA `Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.5 Safari/605.1.15` -> `{ browser: 'Safari 17', os: 'macOS' }` (Safari nur OHNE `Chrome/`, Version aus `Version/`).
    - Test 5 Mobil: Android-Chrome-UA `Mozilla/5.0 (Linux; Android 14; Pixel 8) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/129.0.0.0 Mobile Safari/537.36` -> os `Android` (NICHT Linux); iPad-UA `Mozilla/5.0 (iPad; CPU OS 17_5 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.5 Mobile/15E148 Safari/604.1` -> os `iOS` (NICHT macOS), browser `Safari 17`; Opera-UA mit `OPR/114.0.0.0` -> `Opera 114`.
    - Test 6 WebKitGTK-Client als Desktop: UA `Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.0 Safari/605.1.15` mit `clientKind: 'desktop', clientOs: 'linux', clientVersion: '1.2.0', clientCommit: 'a6d1a64'` -> `{ tag: '[Desktop/Linux]', line: 'Desktop-App (Linux), Tessera-App 1.2.0 · Stand a6d1a64' }` (der User-Agent spielt fuer Desktop KEINE Rolle).
    - Test 7 Desktop ohne Commit: `clientKind: 'desktop', clientOs: 'windows', clientVersion: '1.2.0', clientCommit: ''` -> `{ tag: '[Desktop/Windows]', line: 'Desktop-App (Windows), Tessera-App 1.2.0' }` (kein `· Stand`); auch `clientCommit: '  '` -> ohne Stand (trim, wie `client_info_label`).
    - Test 8 Desktop ohne Details (alter Client, Cookie fehlt): `clientKind: 'desktop', clientOs: '', clientVersion: '', clientCommit: ''` -> `{ tag: '[Desktop]', line: 'Desktop-App (unbekannt)' }`; `clientOs: 'freebsd'` -> ebenfalls `unbekannt`/`[Desktop]` (nur windows/linux/macos werden auf Windows/Linux/macOS abgebildet).
    - Test 9 Rueckfall: `describeOrigin({ userAgent: 'UA' })` (alle vier Felder `undefined`, alter Web-Bau) -> `{ tag: '[Browser]', line: 'Browser — unbekannt auf unbekannt' }`; `clientKind: 'browser'` mit leerem UA -> dasselbe.
    - Test 10 Bereinigung: `clientVersion: '1.2.0\nBenutzer: admin'`, `clientCommit: 'a6d1a64<b>'` -> Zeile enthaelt kein Zeilenumbruchzeichen und keine spitzen Klammern; nur `[A-Za-z0-9.+_-]` bleibt, hoechstens 40 Zeichen je Wert (T-GZA-01).
    bug-reports.service.spec.ts (bestehend, anpassen + 2 neue Tests):
    - Test 1 (bestehend): erwarteter Betreff wird `'[Tessera Fehlermeldung] [Browser] v1.2.3 beta - /admin/users?tab=x'`; Needle-Liste um `'Herkunft: Browser — unbekannt auf unbekannt'` ergaenzen (baseDto hat `userAgent: 'UA'` und keine Client-Felder -> Browser-Rueckfall). `'UA'` und `'1920x1080'` bleiben in der Liste (Zeilen `Browser:`/`Fenster:` bleiben).
    - Test 9 (NEU) Desktop/Windows: DTO `{ ...baseDto, clientKind: 'desktop', clientOs: 'windows', clientVersion: '1.2.0', clientCommit: 'a6d1a64', userAgent: '<Edge-UA aus origin Test 1>' }` -> `report.subject` beginnt mit `'[Tessera Fehlermeldung] [Desktop/Windows] v1.2.3 beta - '`; `report.text` enthaelt `'Herkunft: Desktop-App (Windows), Tessera-App 1.2.0 · Stand a6d1a64'`, enthaelt weiterhin `'Browser: Mozilla/5.0 (Windows NT 10.0'` und `'Fenster: 1920x1080'`; die Zeile `Herkunft:` steht im Text VOR der Zeile `Browser:` (Index-Vergleich); der `logger.log`-Spy wurde genau einmal mit einem String gerufen, der `'[Desktop/Windows]'` enthaelt.
    - Test 10 (NEU) Browser mit echtem UA: `{ ...baseDto, clientKind: 'browser', userAgent: '<Chrome-UA aus origin Test 2>' }` -> Betreff enthaelt `'[Browser]'`, Text enthaelt `'Herkunft: Browser — Chrome 129 auf Windows'`.
    bug-reports.controller.spec.ts (bestehend, 1 neuer Test):
    - Test 4 (NEU): Pipe mit `{ ...baseBody, clientKind: 'desktop', clientOs: 'windows', clientVersion: '1.2.0', clientCommit: '' }` -> alle vier Felder bleiben erhalten (Leerstring bleibt Leerstring); `{ ...baseBody }` -> `clientKind` ist `undefined` (kein Default im DTO); `clientKind: 'tablet'` -> `BadRequestException`; `clientOs` mit 21 Zeichen -> `BadRequestException`; `clientVersion`/`clientCommit` mit 41 Zeichen -> `BadRequestException`.
  </behavior>
  <action>
    Reihenfolge RED -> GREEN: zuerst `origin.spec.ts` und die Spec-Aenderungen schreiben, Lauf muss rot sein (origin.ts fehlt, Betreff ohne Kuerzel), dann implementieren.

    1. `apps/api/src/bug-reports/origin.ts` (NEU, keine Abhaengigkeit ausser TypeScript): Kopfkommentar deutsch (ASCII-Umlaute wie im Bestand): Zweck (quick-260918-gza — Herkunft einer Fehlermeldung ausweisen, weil WebView2 wie Edge und WebKitGTK wie Safari aussehen), Trust-Modell (alle Eingaben stammen vom Client, rein informativ, laengenbegrenzt, nie fuer Routing/Berechtigung, T-GZA-01), warum Regex statt Bibliothek (kein neues Paket, fuenf Browser und fuenf Systeme reichen fuer ein Postfach). Exporte: Typ `ClientKind = 'desktop' | 'browser'`; Interface `OriginInput { clientKind?: string; clientOs?: string; clientVersion?: string; clientCommit?: string; userAgent?: string }`; Interface `Origin { tag: string; line: string }` — `tag` ist das Betreff-Kuerzel in eckigen Klammern, `line` der Text NACH dem Label `Herkunft: ` (der Dienst setzt das Label davor); Interface `ParsedUserAgent { browser: string; os: string }`; Konstante `UNKNOWN = 'unbekannt'`.
       `parseUserAgent(ua: string): ParsedUserAgent` — Browser in dieser Reihenfolge pruefen (die erste Uebereinstimmung gewinnt): `Edg/(\d+)` -> `Edge N`; `OPR/(\d+)` -> `Opera N`; `Firefox/(\d+)` -> `Firefox N`; `(?:Chrome|CriOS)/(\d+)` -> `Chrome N`; `Safari/` OHNE `Chrome/` -> `Safari N` mit N aus `Version/(\d+)`, ohne `Version/` nur `Safari`; sonst `UNKNOWN`. Betriebssystem in dieser Reihenfolge: `Windows NT` -> `Windows`; `Android` -> `Android`; `iPhone|iPad|iPod` -> `iOS`; `Mac OS X|Macintosh` -> `macOS`; `Linux|X11` -> `Linux`; sonst `UNKNOWN`. Kommentar an der Reihenfolge: Android-UAs enthalten `Linux`, iPad-UAs enthalten `like Mac OS X`, Edge/Opera-UAs enthalten `Chrome/` und `Safari/` — deshalb die Reihenfolge.
       `describeOrigin(input: OriginInput): Origin` — Hilfsfunktion `clean(value, max = 40)`: `String(value ?? '')`, alles ausser `[A-Za-z0-9.+_-]` entfernen, `slice(0, max)` (T-GZA-01: kein Zeilenumbruch, kein Markup in der Mail). Wenn `input.clientKind === 'desktop'`: `osLabel` aus `clean(clientOs).toLowerCase()` ueber die Abbildung `windows -> Windows`, `linux -> Linux`, `macos -> macOS`, sonst `UNKNOWN`; `version = clean(clientVersion)`, `commit = clean(clientCommit)`; `appLabel` = `Tessera-App ${version} · Stand ${commit}` wenn beide nicht leer, `Tessera-App ${version}` wenn nur Version, sonst leer (gleiche Regel wie `client_info_label` in lib.rs); `line = Desktop-App (${osLabel})` plus `, ${appLabel}` falls appLabel nicht leer; `tag` = `[Desktop/${osLabel}]` wenn osLabel nicht UNKNOWN, sonst `[Desktop]`. Sonst (alles andere, auch `undefined`): `{ browser, os } = parseUserAgent(input.userAgent ?? '')`, `line = Browser — ${browser} auf ${os}` (Gedankenstrich U+2014 wie im Auftrag), `tag = '[Browser]'`.

    2. `apps/api/src/bug-reports/dto/bug-report.dto.ts`: `IsIn` aus `class-validator` importieren. Vier neue optionale Felder ans Ende der Klasse, jeweils mit Doc-Kommentar: `clientKind?: 'desktop' | 'browser'` mit `@IsOptional() @IsIn(['desktop', 'browser'])`; `clientOs?: string` mit `@IsOptional() @IsString() @MaxLength(20)`; `clientVersion?: string` mit `@IsOptional() @IsString() @MaxLength(40)`; `clientCommit?: string` mit `@IsOptional() @IsString() @MaxLength(40)`. Kopfkommentar der Klasse um einen Absatz ergaenzen: die vier Felder kommen seit quick-260918-gza vom Web-Client (Browser: `clientKind=browser`, uebrige leer; Desktop-App: aus dem Cookie `tessera_desktop_client`); sie sind optional, damit aeltere Web-Baue weiter gueltig senden (Rueckfall `browser` im Dienst); `whitelist: true` verlangt die Deklaration hier, sonst wuerde die Pipe sie entfernen; rein informativ, laengenbegrenzt (T-GZA-01).

    3. `apps/api/src/bug-reports/bug-reports.service.ts`: `describeOrigin` aus `./origin` importieren. Vor Schritt (5) `const origin = describeOrigin(dto);`. Betreff wird `[Tessera Fehlermeldung] ${origin.tag} ${dto.webVersion} ${dto.webChannel} - ${pageShort}`. Im Text-Array direkt VOR der Zeile `Browser: ${dto.userAgent}` die neue Zeile `Herkunft: ${origin.line}` einfuegen; `Browser:` und `Fenster:` bleiben unveraendert. Protokollzeile (9) wird `Bug report ${origin.tag} from ${user.username} …` (Rest unveraendert; das Kuerzel ist ein aufgezaehlter Wert aus origin.ts, nie ein roher Client-String — deshalb protokollierbar). Kopfkommentar der Datei um einen Absatz „Herkunft (quick-260918-gza)“ ergaenzen: warum Kuerzel im Betreff (Sortieren im Postfach), warum der rohe User-Agent bleibt, Verweis auf origin.ts und T-GZA-01.

    4. Specs gemaess `<behavior>` anpassen bzw. anlegen; Kopfkommentar von `origin.spec.ts` im Stil der bestehenden Specs (deutsch, Zweck, Liste der Faelle). In `bug-reports.service.spec.ts` und `bug-reports.controller.spec.ts` den Kopfkommentar um einen Satz zu den neuen Tests ergaenzen (Anzahl korrigieren).

    Commit nach gruenem Lauf: `feat(bug-reports): Herkunft der Fehlermeldung im Betreff-Kuerzel und als Zeile Herkunft ausweisen`.
  </action>
  <verify>
    <automated>cd /home/vicolab/projects/tessera-ctl && pnpm --filter @tessera/api exec vitest run src/bug-reports && pnpm --filter @tessera/api type-check</automated>
  </verify>
  <done>`origin.spec.ts` mit mindestens 8 Tests, `bug-reports.service.spec.ts` mit 10 Tests, `bug-reports.controller.spec.ts` mit 4 Tests — alle gruen (mindestens 22 statt 11 in `src/bug-reports`); `tsc --noEmit` der API ohne Fehler. Betreff traegt das Kuerzel direkt nach `[Tessera Fehlermeldung]`, der Text die Zeile `Herkunft:` vor `Browser:`; ein DTO ohne die vier Felder ergibt `[Browser]` (Rueckfall), `clientKind: 'tablet'` ergibt 400. Der Browser-Pfad ist damit Ende-zu-Ende fertig: der bestehende Web-Client schickt bereits `userAgent`, die Mail zeigt ab jetzt `[Browser]` und `Herkunft: Browser — <Name> <Version> auf <System>`.</done>
</task>

<task type="auto" tdd="true">
  <name>Task 2: Desktop-Client meldet Version/Commit/OS im Marker, Middleware setzt Cookie `tessera_desktop_client`, Web-Client schickt die vier Felder</name>
  <files>apps/desktop/src-tauri/src/lib.rs, apps/web/src/middleware.ts, apps/web/src/middleware.test.ts, apps/web/src/lib/desktop-client.ts, apps/web/src/lib/desktop-client.test.ts, apps/web/src/lib/bug-report-api.ts, apps/web/src/lib/bug-report-api.test.ts, apps/web/src/components/bug-report/bug-report-dialog.tsx, apps/web/src/components/bug-report/bug-report-button.test.tsx</files>
  <read_first>apps/desktop/src-tauri/src/lib.rs Zeilen 49-62 (`with_desktop_marker` + Doc), 170-178 (`client_info_label`), 464-503 (`save_server_url`, `open_server`), 530-537 (setup-Navigation), 698-745 (bestehende Marker-Tests); apps/web/src/middleware.ts Zeilen 15-38; apps/web/src/lib/desktop-client.ts; apps/web/src/lib/bug-report-api.ts Zeilen 71-97; apps/web/src/components/bug-report/bug-report-dialog.tsx Zeilen 55-75; apps/web/src/components/bug-report/bug-report-button.test.tsx Zeilen 60-93 (Mocks, beforeEach/afterEach) und 118-156 (Test 2)</read_first>
  <behavior>
    Rust (`mod tests` in lib.rs; die drei bestehenden Marker-Tests werden auf die reine Funktion umgestellt, plus zwei neue):
    - `with_client_marker(&Url::parse("https://tessera.example.com").unwrap(), "1.2.0", "a6d1a64", "windows").as_str()` == `https://tessera.example.com/?desktop=1&dv=1.2.0&dc=a6d1a64&dos=windows`.
    - Mit vorhandenem Query `https://host/app?x=1` -> `https://host/app?x=1&desktop=1&dv=1.2.0&dc=a6d1a64&dos=windows`.
    - Original bleibt unveraendert (`url.query() == None` nach dem Aufruf).
    - Leerer bzw. nur aus Leerzeichen bestehender Commit -> `dc=` (leer, Paar bleibt vorhanden, damit die Middleware „alle drei Parameter vorhanden“ erkennt): `…?desktop=1&dv=1.2.0&dc=&dos=linux`.
    - Huelle `with_desktop_marker(&url)`: `query_pairs()` enthaelt die Paare `("desktop","1")`, `("dv", env!("CARGO_PKG_VERSION"))`, `("dos", std::env::consts::OS)` und ein Paar mit Schluessel `dc`.
    middleware.test.ts (bestehender describe-Block, 4 neue Tests):
    - Test 6: `/login?desktop=1&dv=1.2.0&dc=a6d1a64&dos=windows` -> `res.cookies.get('tessera_desktop')?.value === '1'` UND `res.cookies.get('tessera_desktop_client')?.value === '1.2.0|a6d1a64|windows'`; der rohe `set-cookie`-Header enthaelt `tessera_desktop_client=1.2.0%7Ca6d1a64%7Cwindows` (Next kodiert, gemessen), `Max-Age=31536000`, `Path=/` und fuer dieses Cookie kein `HttpOnly`.
    - Test 7 (alter Client): `/login?desktop=1` -> `tessera_desktop=1` gesetzt, `res.cookies.get('tessera_desktop_client')` ist `undefined` (kein Ueberschreiben eines evtl. vorhandenen Werts).
    - Test 8 (Bereinigung): `dv=1.2.0%3Cscript%3E` (spitze Klammern) -> kein `tessera_desktop_client`; `dos=win%20dows` -> keins; `dv` fehlt, `dc`/`dos` vorhanden -> keins; `dc=` leer mit gueltigem `dv`/`dos` -> Wert `1.2.0||linux`.
    - Test 9 (Redirect-Pfad): `/dashboard?desktop=1&dv=1.2.0&dc=a6d1a64&dos=linux` ohne Session -> Status 307, `location` enthaelt `/login`, beide Cookies gesetzt (Wert `1.2.0|a6d1a64|linux`).
    desktop-client.test.ts (neuer describe-Block `getDesktopClientInfo / parseDesktopClientCookie`; `clearCookie()` loescht zusaetzlich `tessera_desktop_client`):
    - `parseDesktopClientCookie('tessera_desktop=1; tessera_desktop_client=1.2.0%7Ca6d1a64%7Cwindows')` -> `{ version: '1.2.0', commit: 'a6d1a64', os: 'windows' }` (kodierte Form, wie der Browser sie haelt).
    - Rohe Form `tessera_desktop_client=1.2.0|a6d1a64|windows` -> gleiches Ergebnis.
    - Leerer Commit `1.2.0%7C%7Clinux` -> `{ version: '1.2.0', commit: '', os: 'linux' }`.
    - Ohne Cookie -> `null`; Wert `abc` (ein Teil) oder `1.2.0|x` (zwei Teile) oder `|a6d1a64|linux` (Version leer) oder `1.2.0|a6d1a64|` (OS leer) -> `null`.
    - `getDesktopClientInfo()` liest `document.cookie` (Cookie per `document.cookie = …` gesetzt -> Objekt; ohne Cookie -> `null`); mit `vi.stubGlobal('document', undefined)` -> `null`.
    bug-report-api.test.ts (NEU, 3 Tests, `vi.stubGlobal('fetch', mockFetch)` wie in bug-report-button.test.tsx, `mockFetch.mockResolvedValue(new Response('{}', { status: 200 }))`):
    - Test 1 Desktop-Nutzlast: `sendBugReport({ description: 'x', page: '/a', webVersion: 'v1', webChannel: 'beta', webCommit: 'c', userAgent: 'UA', viewport: '1x1', clientTime: 't', errors: ['e1', 'e2'], screenshot: null, clientKind: 'desktop', clientOs: 'windows', clientVersion: '1.2.0', clientCommit: 'a6d1a64' })` -> `{ ok: true }`; `init.body` ist `FormData` mit `get('clientKind') === 'desktop'`, `get('clientOs') === 'windows'`, `get('clientVersion') === '1.2.0'`, `get('clientCommit') === 'a6d1a64'`, `getAll('errors')` = `['e1','e2']`, `has('screenshot') === false`, `init.credentials === 'include'`, URL endet auf `/bug-reports`.
    - Test 2 Browser-Nutzlast: `clientKind: 'browser'`, uebrige drei `''` -> `get('clientKind') === 'browser'`, `get('clientOs') === ''`, `get('clientVersion') === ''`, `get('clientCommit') === ''` (Felder VORHANDEN, Leerstring — nicht weggelassen).
    - Test 3: `mockFetch.mockRejectedValue(new Error('offline'))` -> `{ ok: false, status: 0 }`; `mockFetch.mockResolvedValue(new Response('', { status: 429 }))` -> `{ ok: false, status: 429 }`.
    bug-report-button.test.tsx:
    - Test 2 (bestehend) ergaenzen: `body.get('clientKind') === 'browser'`, `body.get('clientOs') === ''`, `body.get('clientVersion') === ''`, `body.get('clientCommit') === ''` (jsdom ohne Cookies).
    - Test 12 (NEU): vor dem Rendern `document.cookie = 'tessera_desktop=1; path=/'` und `document.cookie = 'tessera_desktop_client=1.2.0%7Ca6d1a64%7Cwindows; path=/'`; Senden -> `body.get('clientKind') === 'desktop'`, `clientOs === 'windows'`, `clientVersion === '1.2.0'`, `clientCommit === 'a6d1a64'`. `afterEach` loescht beide Cookies (Ablaufdatum 1970, `path=/`), damit die uebrigen Tests Browser bleiben.
    - Test 13 (NEU, alter Client): nur `tessera_desktop=1` ohne `tessera_desktop_client` -> `clientKind === 'desktop'`, die drei anderen `''`.
  </behavior>
  <action>
    Reihenfolge: Rust zuerst (RED: Tests auf `with_client_marker` umstellen, `cargo test --lib` rot; GREEN: implementieren), dann Middleware, dann Web-Helfer, dann Nutzlast und Dialog — jeweils Test vor Implementierung.

    1. `apps/desktop/src-tauri/src/lib.rs`: Neue reine Funktion `fn with_client_marker(url: &tauri::Url, version: &str, commit: &str, os: &str) -> tauri::Url` — klont die URL, haengt per `query_pairs_mut().append_pair` nacheinander `("desktop", "1")`, `("dv", version)`, `("dc", commit.trim())`, `("dos", os)` an (Reihenfolge fest, `dc` auch leer anhaengen). Die bestehende `fn with_desktop_marker(url: &tauri::Url) -> tauri::Url` wird zur Huelle: `with_client_marker(url, env!("CARGO_PKG_VERSION"), env!("APP_COMMIT"), std::env::consts::OS)` — so bleiben die drei Aufrufstellen (`save_server_url`, `open_server`, `setup`) UNVERAENDERT und die Tests bleiben rein (kein `env!` in der Erwartung). Doc-Kommentar von `with_desktop_marker` erweitern: seit quick-260918-gza wandern Version, Commit-Stempel und Betriebssystem (`dv`, `dc`, `dos`) mit, die Middleware legt daraus das Cookie `tessera_desktop_client` an, aus dem der Fehler-melden-Knopf die Herkunft der Meldung fuellt; `desktop=1` bleibt unveraendert, damit ein neuer Client gegen eine aeltere Middleware weiter erkannt wird; die Werte gehen NUR in die Navigation, nie in den Store (wie bisher); der Browser-Rueckfall `open_download_page` bekommt weiterhin keinen Marker. `mod tests`: die drei bestehenden `with_desktop_marker_*`-Tests auf `with_client_marker(&url, "1.2.0", "a6d1a64", "windows")` umstellen (Erwartungen laut `<behavior>`), Test fuer leeren Commit (`""` und `"  "` -> `dc=`) und einen Test fuer die Huelle ueber `query_pairs()` ergaenzen. `cargo fmt` anwenden (2-Zeilen-Doc-Umbrueche wie im Bestand).

    2. `apps/web/src/middleware.ts`: Konstante `DESKTOP_CLIENT_COOKIE = 'tessera_desktop_client'` und drei Muster als Modulkonstanten: `DESKTOP_VERSION_RE = /^[A-Za-z0-9][A-Za-z0-9.+_-]{0,39}$/`, `DESKTOP_COMMIT_RE = /^[A-Za-z0-9]{0,40}$/` (leer erlaubt), `DESKTOP_OS_RE = /^[a-z]{1,20}$/`. Neue reine Hilfsfunktion `buildDesktopClientCookieValue(params: URLSearchParams): string | null` — liest `dv`, `dc`, `dos`; wenn eines `null` (fehlt) ist oder sein Muster nicht passt -> `null`; sonst `${dv}|${dc}|${dos}` (hoechstens 82 Zeichen durch die Muster). In `withDesktopCookie` innerhalb des bestehenden `if (desktop === '1')`-Zweigs: `tessera_desktop=1` wie bisher setzen; zusaetzlich `const info = buildDesktopClientCookieValue(req.nextUrl.searchParams); if (info !== null) res.cookies.set(DESKTOP_CLIENT_COOKIE, info, { …dieselben Optionen wie fuer tessera_desktop… })`. Ohne gueltige Parameter wird das Info-Cookie NICHT gesetzt und NICHT geloescht (alter Client -> die Mail sagt `Desktop-App (unbekannt)`). Doc-Kommentar von `withDesktopCookie` ergaenzen: zweites Cookie, Herkunft (quick-260918-gza), Bereinigung per Muster und Laenge, warum `httpOnly: false` (wird von `getDesktopClientInfo()` gelesen; Version/OS sind kein Geheimnis, dieselbe Vertrauensstufe wie der User-Agent), Hinweis dass Next den Wert mit `encodeURIComponent` serialisiert (T-GZA-03). Tests laut `<behavior>` in `middleware.test.ts` ergaenzen; Kopfkommentar um einen Satz erweitern.

    3. `apps/web/src/lib/desktop-client.ts`: `export const DESKTOP_CLIENT_COOKIE_NAME = 'tessera_desktop_client'`; `export interface DesktopClientInfo { version: string; commit: string; os: string }`; `export function parseDesktopClientCookie(cookieString: string): DesktopClientInfo | null` — trennt an `;`, trimmt, sucht den Eintrag mit Praefix `${DESKTOP_CLIENT_COOKIE_NAME}=`, nimmt den Rest, dekodiert per `decodeURIComponent` in try/catch (bei Fehler den Rohwert nehmen), trennt an `|`; genau drei Teile, Teil 1 (version) und Teil 3 (os) nicht leer, sonst `null`; Rueckgabe `{ version, commit, os }`. `export function getDesktopClientInfo(): DesktopClientInfo | null` — `typeof document === 'undefined'` -> `null`, sonst `parseDesktopClientCookie(document.cookie)`. Kopfkommentar ergaenzen (Gegenstueck zu `buildDesktopClientCookieValue`, warum dekodieren — Next kodiert `|` als `%7C`, gemessen). Tests laut `<behavior>`; `clearCookie()` im Test loescht beide Cookies.

    4. `apps/web/src/lib/bug-report-api.ts`: `BugReportPayload` um `clientKind: 'desktop' | 'browser'`, `clientOs: string`, `clientVersion: string`, `clientCommit: string` erweitern; in `sendBugReport` nach `clientTime` vier `body.append(...)`-Zeilen fuer genau diese Feldnamen (Leerstrings mitschicken — das DTO ist optional, aber die Felder sollen fuer den Browser-Fall sichtbar leer sein, nicht fehlen). Kopfkommentar um einen Satz ergaenzen (Herkunft, quick-260918-gza; Desktop-Werte kommen aus `getDesktopClientInfo()`). NEU `apps/web/src/lib/bug-report-api.test.ts` laut `<behavior>` (Kopfkommentar: warum diese Datei erst jetzt entsteht — bisher pruefte nur der Komponententest die FormData; die reinen Nutzlastfelder gehoeren an die Funktion selbst).

    5. `apps/web/src/components/bug-report/bug-report-dialog.tsx`: `getDesktopClientInfo` und `isDesktopClient` aus `@/lib/desktop-client` importieren. In `handleSend` vor dem `sendBugReport`-Aufruf: `const desktop = isDesktopClient(); const info = desktop ? getDesktopClientInfo() : null;` und im Aufruf `clientKind: desktop ? 'desktop' : 'browser', clientOs: info?.os ?? '', clientVersion: info?.version ?? '', clientCommit: info?.commit ?? ''`. Kein UI-Text, keine Uebersetzung aendert sich. Kurzer Kommentar an der Stelle: Herkunft (quick-260918-gza) — `tessera_desktop` entscheidet Desktop/Browser, `tessera_desktop_client` liefert die Details; fehlt es (alter Client), bleibt es bei Desktop ohne Details. `bug-report-button.test.tsx` laut `<behavior>` erweitern (Test 2 ergaenzen, Tests 12 und 13 neu, Cookie-Aufraeumen im `afterEach`, Kopfkommentar „Elf Tests“ -> „Dreizehn Tests“).

    Zwei Commits nach gruenem Lauf: `feat(desktop): Version, Stand und Betriebssystem im Desktop-Marker mitgeben (dv, dc, dos)` fuer lib.rs; `feat(web): Herkunft der Fehlermeldung — Cookie tessera_desktop_client und Client-Felder in der Nutzlast` fuer die Web-Dateien.
  </action>
  <verify>
    <automated>cd /home/vicolab/projects/tessera-ctl/apps/desktop/src-tauri && cargo fmt --check && cargo test --lib && cd /home/vicolab/projects/tessera-ctl && pnpm --filter @tessera/web exec vitest run src/lib src/middleware.test.ts src/components/bug-report && pnpm --filter @tessera/web type-check</automated>
  </verify>
  <done>Rust: `cargo fmt --check` sauber, alle Tests gruen (mindestens 35, davon 5 Marker-Tests: drei umgestellte, leerer Commit, Huelle). Web: `middleware.test.ts` 9 Tests, `desktop-client.test.ts` mindestens 11, `bug-report-api.test.ts` 3, `bug-report-button.test.tsx` 13 — alle gruen, `tsc --noEmit` ohne Fehler. Kette nachgewiesen: Anfrage mit `desktop=1&dv&dc&dos` -> beide Cookies (auch auf dem 307 nach /login) -> `getDesktopClientInfo()` liefert das Tripel aus der kodierten Cookie-Form -> FormData traegt `clientKind=desktop`, `clientOs`, `clientVersion`, `clientCommit`; ohne Info-Cookie `desktop` mit leeren Details; ohne Desktop-Cookie `browser`.</done>
</task>

<task type="auto">
  <name>Task 3: CHANGELOG und Handbuecher — Herkunft und Betreff-Kuerzel beschreiben</name>
  <files>CHANGELOG.md, docs/anleitung-administration.md, docs/anleitung-betrieb.md</files>
  <read_first>CHANGELOG.md Zeilen 1-25 (Abschnitt „Unveröffentlicht“ mit „Neu“/„Geändert“/„Behoben“); docs/anleitung-administration.md Zeile 208 (Absatz „Fehlermeldungen an“); docs/anleitung-betrieb.md Zeile 341 (Tabellenzeile „Fehlermeldungen der Anwender kommen nicht an“) und Zeilen 699-709 (Tabelle „Fehlerbilder“ in Kapitel 10)</read_first>
  <action>
    Alle Texte deutsch, Alltagssprache, Anwender/Betreiber werden gesiezt (App-Texte), echte Umlaute wie in den Handbuechern.

    1. `CHANGELOG.md`, Abschnitt `## Unveröffentlicht` -> `### Geändert`, neue Zeile am Ende der Liste: `- Fehler melden: Fehlermeldungen nennen jetzt die Herkunft – Browser oder Desktop-App, Betriebssystem, bei der Desktop-App auch Version und Stand; der Betreff trägt dafür ein Kürzel wie „[Browser]“, „[Desktop/Windows]“ oder „[Desktop/Linux]“, nach dem sich das Postfach sortieren lässt`.

    2. `docs/anleitung-administration.md`, Absatz **Fehlermeldungen an** (Z. 208): den Teilsatz „— der Betreff beginnt mit „[Tessera Fehlermeldung]“, das Bild hängt als PNG an.“ ersetzen durch einen Teilsatz, der sagt: der Betreff beginnt mit „[Tessera Fehlermeldung]“ und einem Kürzel für die Herkunft („[Browser]“, „[Desktop/Windows]“ oder „[Desktop/Linux]“), nach dem Sie das Postfach sortieren oder filtern können; im Text nennt die Zeile „Herkunft“ bei Browsern Browser und Betriebssystem (Beispiel „Browser — Chrome 129 auf Windows“), bei der Desktop-App Betriebssystem, Version und Stand (Beispiel „Desktop-App (Windows), Tessera-App 1.2.0 · Stand a6d1a64“); das Bild hängt als PNG an. Der uebrige Absatz bleibt.

    3. `docs/anleitung-betrieb.md`:
       a) Kapitel 7, Tabellenzeile „Fehlermeldungen der Anwender kommen nicht an“ (Z. 341), Spalte „Prüfen / Beheben“: die Klammer „(eine Zeile je gesendeter Meldung, `Bug report mail failed` bei Versandfehler)“ erweitern zu „(eine Zeile je gesendeter Meldung mit dem Herkunfts-Kürzel `[Browser]`, `[Desktop/Windows]` oder `[Desktop/Linux]`, `Bug report mail failed` bei Versandfehler)“.
       b) Kapitel 10, Tabelle „Fehlerbilder“ (ab Z. 699), neue letzte Zeile: Symptom „Eine Fehlermeldung aus der Desktop-App nennt als Herkunft „Desktop-App (unbekannt)“ ohne Version, Betreff-Kürzel `[Desktop]`“ — Ursache „Der Client ist älter als diese Fassung: er meldet dem Server beim Start nur `desktop=1`, nicht Version, Stand und Betriebssystem (Parameter `dv`, `dc`, `dos`, aus denen `web` das Cookie `tessera_desktop_client` bildet)“ — Prüfen/Beheben „Kein Fehler, die Meldung ist trotzdem als Desktop-App erkennbar. Client über „Auf Version … aktualisieren“ im Infobereich oder den Browser-Installer aktualisieren; danach stehen Betriebssystem, Version und Stand in der Meldung.“

    Nicht anfassen: `docs/mandantentrennung-zugriffsklassifikation.md` (listet keine Rumpffelder), `docs/anleitung-anwender.md` (Anwender sehen keine Aenderung), `de.json`/`en.json` (kein UI-Text).

    Commit: `docs: Fehlermeldungen — Herkunft (Browser/Desktop-App, Betriebssystem, Version) und Betreff-Kürzel (Handbücher, CHANGELOG)`.
  </action>
  <verify>
    <automated>cd /home/vicolab/projects/tessera-ctl && grep -q "Desktop/Windows" CHANGELOG.md && grep -q "Desktop/Windows" docs/anleitung-administration.md && grep -q "Desktop/Windows" docs/anleitung-betrieb.md && grep -q "Desktop-App (unbekannt)" docs/anleitung-betrieb.md && grep -q "tessera_desktop_client" docs/anleitung-betrieb.md && echo DOCS-OK</automated>
  </verify>
  <done>Alle drei Dateien nennen das Kuerzel `[Desktop/Windows]`; das Betriebshandbuch erklaert in Kapitel 10 den Fall „Desktop-App (unbekannt)“ als alten Client mit Verweis auf `dv`/`dc`/`dos` und das Cookie `tessera_desktop_client`; der Changelog-Eintrag steht unter „Unveröffentlicht → Geändert“; der Verify-Befehl gibt `DOCS-OK` aus; genau ein Commit `docs: …` mit den drei Dateien (Nachweis: `git show --stat --format= <sha>` des Doku-Commits listet genau CHANGELOG.md, docs/anleitung-administration.md, docs/anleitung-betrieb.md).</done>
</task>

</tasks>

<threat_model>
## Trust Boundaries

| Boundary | Description |
|----------|-------------|
| Desktop-Client -> Web (Query `desktop=1&dv&dc&dos`) | Ungepruefte Query-Parameter einer Navigation; jeder Browser kann sie ebenso setzen |
| Web-Middleware -> Browser (Cookie `tessera_desktop_client`) | Nicht-httpOnly-Cookie, fuer Seiten-JavaScript lesbar und vom Anwender aenderbar |
| Browser -> API (`POST /bug-reports`, vier neue Multipart-Felder) | Vom Client gelieferte Strings, unbeglaubigt wie der User-Agent |
| API -> Postfach des Betreibers (Betreff, Textzeile, Protokollzeile) | Client-Text landet in einer E-Mail und teilweise im Log |

## STRIDE Threat Register (ASVS Level 1)

| Threat ID | Category | Component | Severity | Disposition | Mitigation Plan |
|-----------|----------|-----------|----------|-------------|-----------------|
| T-GZA-01 | Spoofing / Tampering | `clientKind`, `clientOs`, `clientVersion`, `clientCommit` im DTO; `describeOrigin` | low | mitigate | Rein informativ: nie fuer Routing, Berechtigung oder Speicherung genutzt; `@IsIn(['desktop','browser'])`, `@MaxLength` 20/40/40; `clean()` in origin.ts laesst nur `[A-Za-z0-9.+_-]` und 40 Zeichen zu (kein Zeilenumbruch, kein Markup in der Mail); OS wird auf drei feste Labels abgebildet; ins Log geht NUR das aufgezaehlte Kuerzel, nie ein Rohwert (Test 9 im Service-Spec, Test 10 in origin.spec) |
| T-GZA-02 | Tampering | Betreff-Zeile (Header-Injection) | low | mitigate | In den Betreff geht ausschliesslich `origin.tag` — ein Wert aus einer festen Menge (`[Browser]`, `[Desktop]`, `[Desktop/Windows|Linux|macOS]`); Version/Commit stehen nur im Text, nie im Header |
| T-GZA-03 | Tampering | `withDesktopCookie` — Query -> Cookie `tessera_desktop_client` | low | mitigate | Drei feste Muster (`DESKTOP_VERSION_RE`, `DESKTOP_COMMIT_RE`, `DESKTOP_OS_RE`), Gesamtlaenge ≤ 82; nur gesetzt, wenn `desktop=1` UND alle drei Parameter vorhanden und gueltig; Middleware trifft keine Entscheidung auf Grund des Werts; `sameSite: 'lax'`, `secure` bei https wie das bestehende Cookie (Tests 6-9 in middleware.test.ts) |
| T-GZA-04 | Information Disclosure | Cookie `tessera_desktop_client` (App-Version und OS fuer Seiten-JS lesbar) | low | accept | Dieselbe Vertrauensstufe und Sichtbarkeit wie der User-Agent, den jede Seite ohnehin liest; kein Geheimnis, kein Token; nur die eigene Web-App laeuft im WebView |
| T-M97-03 | Denial of Service | `main.ts`, Body-Limits | medium | mitigate (unveraendert) | Kein globales Limit angefasst; vier kurze Textfelder innerhalb des bestehenden Multipart-Rumpfs, DTO-Grenzen wie oben |
| T-M97-09 | Spoofing | Irrefuehrende Herkunftsangaben durch einen Anwender | low | accept | Wie bisher fuer Beschreibung/Fehlerliste: reiner Text an den Administrator des eigenen Mandanten; Benutzer/Mandant/API-Version kommen weiterhin aus Sitzung und Umgebung, nicht aus dem Rumpf |
| T-GZA-SC | Tampering | Paketinstallationen | — | n/a | Keine neue npm-/cargo-Abhaengigkeit (Regex und Standardbibliothek); kein Install-Schritt in diesem Plan |
</threat_model>

<verification>
Automatisch (Executor, je Task im `<verify>`):
- API: `pnpm --filter @tessera/api exec vitest run src/bug-reports` (≥ 22 Tests gruen, vorher 11) und `pnpm --filter @tessera/api type-check`.
- Web: `pnpm --filter @tessera/web exec vitest run src/lib src/middleware.test.ts src/components/bug-report` und `pnpm --filter @tessera/web type-check`.
- Rust: `cargo fmt --check && cargo test --lib` in `apps/desktop/src-tauri` (≥ 35 Tests).
- Falsifizierung (RED zuerst): Betreff ohne Kuerzel laesst Service-Test 1 scheitern; fehlendes `origin.ts` laesst origin.spec scheitern; Marker ohne `dv` laesst die Rust-Tests scheitern; Middleware ohne Info-Cookie laesst middleware Test 6 scheitern.
- Abschliessend einmal die vollen Suiten: `pnpm --filter @tessera/api exec vitest run` und `pnpm --filter @tessera/web exec vitest run` (keine Regression ausserhalb der geaenderten Dateien).

Kein Biome-Gate (Ledger #35: Konfiguration im Bestand nicht lauffaehig).

Nachweis durch den Orchestrator NACH der Ausfuehrung (nicht Aufgabe des Executors):
- Browser-Fall lokal mit Playwright MCP und mailhog (`docker compose -f docker-compose.yml -f docker-compose.dev.yml up -d mailhog`, `docker compose up -d --build api web`): Fehler melden -> Mail in `http://localhost:8025` mit Betreff `[Tessera Fehlermeldung] [Browser] dev dev - /…` und Zeile `Herkunft: Browser — Chrome <N> auf Linux`; Zeilen `Browser:`/`Fenster:` weiterhin vorhanden; `docker compose logs api | grep "Bug report"` zeigt das Kuerzel.
- Desktop-Fall nach CI-Bau auf der Windows-Test-VM (Zugang laut Memory `reference_windows_test_vm.md`): Client installieren bzw. per In-App-Update aktualisieren, gegen alpha melden -> Betreff `[Desktop/Windows]`, Zeile `Herkunft: Desktop-App (Windows), Tessera-App <Version> · Stand <sha7>`; Kontrolle des Cookies `tessera_desktop_client` in der Seite ueber Einstellungen -> Desktop-App ist nicht noetig, die Mail genuegt.
- Alter Client (optional): ein bestehender 1.2.0-Client ohne Update erzeugt `[Desktop]` und `Desktop-App (unbekannt)` — das ist das dokumentierte Verhalten (Betriebshandbuch Kap. 10).
</verification>

<success_criteria>
- Jede Fehlermeldungs-Mail traegt im Betreff direkt nach `[Tessera Fehlermeldung]` genau eines der Kuerzel `[Browser]`, `[Desktop/Windows]`, `[Desktop/Linux]` (oder `[Desktop]` bei einem alten Client) und im Text die Zeile `Herkunft: …` in der im Auftrag festgelegten Form; `Browser:` und `Fenster:` bleiben.
- Desktop-Client, Middleware, Web-Helfer, Nutzlast, DTO und Dienst sind durchgaengig verbunden und je Schicht durch Tests belegt (Rust 5 Marker-Tests, Middleware 9, desktop-client ≥ 11, bug-report-api 3, Komponententest 13, origin ≥ 8, Service 10, Controller 4).
- Rueckwaertskompatibel in beide Richtungen (alter Client, alter Web-Bau, alte API) — kein 400, kein Verlust der bisherigen Meldung.
- Keine neue Abhaengigkeit, keine DB-Aenderung, `main.ts` unveraendert, kein UI-Text geaendert.
- CHANGELOG und beide Handbuecher beschreiben Kuerzel und Herkunftszeile; drei bis vier Code-/Doku-Commits mit den vorgegebenen Praefixen; `.planning/`-Artefakte werden vom Executor NICHT committet.
</success_criteria>

<output>
Create `.planning/quick/260918-gza-fehlermeldung-herkunft-ausweisen-browser/260918-gza-SUMMARY.md` when done
</output>