## Why

Der macOS-Port soll die vorhandenen Windows-Funktionen mit denselben beobachtbaren Verhaltensgarantien bieten. Die portable Testsuite weist Windows-spezifische Fälle und native Bedienwege bisher nicht vollständig nach; zwölf Restpunkte und offene operative Abnahmen benötigen klare Anforderungen.

## What Changes

- Bestehende Aufnahmeanforderungen erhalten macOS-Szenarien für Mikrofonwiederherstellung, Geräteauswahl, Angebote neuer Mikrofone, Pause/Fortsetzen und sicheres Beenden.
- Die Desktop-Anforderungen werden um aktive Profilwechsel, vollständige konfigurierbare Shortcuts, Sprecherproben-Wiedergabe und eine frische unabhängige Agent-Unterhaltung ergänzt.
- Agent-Markdown, Links, Bilder, sichtbare Aktivität und Scrollverhalten werden als einzeln überprüfbare Ergebnisse spezifiziert.
- Kalender-Absagepräfixe und isolierte plattformkompatible Resemblyzer-Provisionierung erhalten gemeinsame Verhaltensverträge.
- Eine Plattformmatrix unterscheidet portable Tests, echte Windows-Testtargets und native Nachweise. Die bisherigen offenen Kommunikations-Abnahmen bleiben ihrem ursprünglichen Change zugeordnet.
- Dieser Schritt veröffentlicht Anforderungen und zukünftige Aufgaben. Er startet keine Implementierung oder Anwendungsauslieferung.

## Capabilities

### New Capabilities

- `platform-parity-verification`: echte Testtargets, ehrliche Nichtausführung, native Bildverträge und operative Abnahme der Plattformparität.

### Modified Capabilities

Keine zusätzliche fachliche Delta-Spec in diesem koordinierenden Change. Ergänzungen von `meeting-recording`, `meeting-session` und `meeting-transcription` liegen bei den bestehenden Eigentümern `recover-microphone-disconnect`, `prompt-for-new-microphone`, `add-transcription-pause-controls`, `add-macos-desktop-controls`, `add-macos-meeting-integrations` und `add-resemblyzer-speaker-recognition`.

## Impact

Betroffen sind die Anforderungen an Aufnahme-/Mikrofonadapter, Desktop-Aktionswege, Kalenderfilter, Agent-Präsentation, Playback, Shortcutregistrierung, Resemblyzer und die Test-/Buildmatrix. Die Umsetzung bleibt im gemeinsamen .NET-Fachkern mit vorhandenen nativen Adaptergrenzen. Quellcode, Tests und CI werden in diesem Planungsschritt nicht geändert.