ci: consolidate platform pipelines and test prerequisites on macOS support

README.md

@@ -7,7 +7,7 @@ Meeting Assistant is Manuel's local .NET meeting capture and knowledge service.
 This repository owns the application source, tests, OpenSpec requirements, checked-in configuration, and CI validation. It does not own workstation startup automation, a homelab deployment stack, Traefik routing, Docker Compose, or a deployed image tag.
 
 - Windows builds provide the tray icon, global hotkeys, NAudio capture, Outlook Classic COM enrichment, active-window screenshots, and notifications.
-- Portable builds on macOS provide a native menu-bar icon and global hotkeys, and capture the default microphone through AVFoundation plus computer output through ScreenCaptureKit.
+- Portable builds on macOS provide a native menu-bar icon, global hotkeys and actionable notifications with pending-menu fallback, and capture the default microphone through AVFoundation plus computer output through ScreenCaptureKit.
 - Portable builds on other hosts keep the server/testable service surface but do not provide meeting audio capture.
 - The normal runtime endpoint is local HTTP on port `5090`, with `/health` and `/recording/status` as the safe first checks.
 Accepted requirements live under `openspec/specs`. Relevant active changes under `openspec/changes` can describe implemented behavior that has not yet been folded into the accepted specs.
@@ -17,9 +17,9 @@ Accepted requirements live under `openspec/specs`. Relevant active changes under
 The project requires the .NET 10 SDK. Build and test it with:
 
 ```powershell
-dotnet restore MeetingAssistant.slnx
-dotnet build MeetingAssistant.slnx
-dotnet test MeetingAssistant.slnx
+dotnet restore MeetingAssistant.slnx -p:TargetFramework=net10.0 -p:EnableWindowsTargeting=true
+dotnet build MeetingAssistant.slnx -f net10.0 -p:EnableWindowsTargeting=true
+dotnet test MeetingAssistant.slnx -f net10.0 -p:EnableWindowsTargeting=true
 ```
 
 Do not start a second copy over the live workstation instance. Check the local control surface first:
@@ -36,7 +36,7 @@ dotnet build MeetingAssistant/MeetingAssistant.csproj -f net10.0
 dotnet run --project MeetingAssistant/MeetingAssistant.csproj -f net10.0
 ```
 
-The macOS build compiles bundled Swift helpers into `Native/macos-meeting-audio-capture`, `Native/macos-desktop-controls`, and `Native/macos-meeting-integrations`. On first use, allow **Microphone**, **Screen & System Audio Recording**, and **Calendar Full Access** under System Settings > Privacy & Security. The menu-bar icon and global hotkeys use the same configured bindings as Windows and call the local service surface.
+The macOS build compiles bundled Swift helpers into `Native/macos-meeting-audio-capture`, `Native/MeetingAssistantDesktopControls.app/Contents/MacOS/macos-desktop-controls`, and `Native/macos-meeting-integrations`. On first use, allow **Microphone**, **Screen & System Audio Recording**, and **Calendar Full Access** under System Settings > Privacy & Security. The menu-bar icon and global hotkeys use the same configured bindings as Windows and call the local service surface. The signed desktop-helper bundle requests notification permission when its first user request arrives. Allow notifications for **Meeting Assistant** in System Settings > Notifications. Pending questions remain actionable in the menu bar when notifications are denied, hidden by Focus or dismissed.
 
 For a foreground Windows development run when port `5090` is free:
 
@@ -74,6 +74,8 @@ The loopback HTTP surface has no application authentication, so port `5090` must
 - `POST /diagnostics/settings-and-logs/show`
 - `POST /diagnostics/workflow/rules-editor/show`
 - `GET /diagnostics/platform-capabilities`
+- macOS: `GET /desktop/requests`, `POST /desktop/requests/{id}/respond` with `{ "action": "yes" }` (use an offered action ID)
+- macOS: `GET /desktop/agent-windows` and session-aware `GET`/`POST /diagnostics/settings-and-logs/chat?session={id}`
 - `POST /meetings/current/summary/run`
 - `POST` or `GET /meetings/summary/retry`
 - `POST` or `GET /meetings/screenshot-ocr/retry`
@@ -94,7 +96,7 @@ Outlook enrichment selects an unambiguous current or imminent appointment. A sch
 
 Meeting Assistant writes meeting notes, transcripts, assistant context, summaries, and project knowledge into the configured Obsidian vault. Assistant context is persistent meeting-specific memory: the summarizer records problems and assumptions, and the interactive agent can read it and append later repairs and conclusions.
 
-Project discovery uses the `name` and short `description` in each project's `PROJECT.md`. The summarizer can request missing associations through a Yes/No notification that waits up to ten minutes; only approval adds the project and enables its file access. Workflow-change requests return immediately and, when approved, open a separate settings-agent conversation with the proposed change.
+Project discovery uses the `name` and short `description` in each project's `PROJECT.md`. The summarizer can request missing associations through a Yes/No notification that waits up to ten minutes; only approval adds the project and enables its file access. On macOS the same decisions are also available from the menu-bar pending list. Workflow-change requests return immediately and, when approved, open a separate settings-agent conversation with the proposed change.
 
 Agents are intentionally stateful. Depending on the invoked tools, they can change workflow rules and appsettings, create or update project and meeting files, change frontmatter, merge or delete speaker identities and samples, run diagnostics, and trigger transcription or summary work. Screenshot OCR can add recognized attendee names to the meeting note after workflow transformation; OCR of images already embedded in the meeting note does not add attendees or modify that note.
 
@@ -159,7 +161,7 @@ Meeting-specific automation lives in a local YAML file, not in committed persona
 
 The Windows tray and macOS menu-bar menus expose `Open agent`, which opens the `Meeting Summary Agent` window. It can edit workflow rules with validation, inspect logs and health/status, manage speaker identities and samples, run ASR diagnostics, and read/write scoped meeting/project artifacts through explicit tools. Windows renders the chat with WPF; macOS renders the same agent pipeline in a native AppKit window backed by WebKit.
 
-At startup, Meeting Assistant detects whether the host is Windows or macOS and includes that immutable runtime context in the interactive settings/logs assistant instructions. On Windows the assistant uses Windows commands and concepts such as PowerShell, Windows paths, services, and Task Manager. On macOS it uses zsh, POSIX paths, launchd/LaunchAgents, and Activity Monitor. This guidance is also appended when a custom interactive-agent prompt is configured. macOS audio capture, menu-bar controls, global hotkeys, EventKit calendar enrichment/prompts, active-window screenshots, screenshot OCR, speaker identification, FunASR, local diarization, and the AppKit/WebKit workflow editor are available in the portable build. Outlook Classic COM and Windows toast notifications remain Windows-specific implementations.
+At startup, Meeting Assistant detects whether the host is Windows or macOS and includes that immutable runtime context in the interactive settings/logs assistant instructions. On Windows the assistant uses Windows commands and concepts such as PowerShell, Windows paths, services, and Task Manager. On macOS it uses zsh, POSIX paths, launchd/LaunchAgents, and Activity Monitor. This guidance is also appended when a custom interactive-agent prompt is configured. macOS audio capture, menu-bar controls, global hotkeys, EventKit calendar enrichment/prompts, active-window screenshots, screenshot OCR, speaker identification, FunASR, local diarization, and the AppKit/WebKit workflow editor are available in the portable build. Outlook Classic COM and Windows toast notifications remain Windows-specific implementations. macOS uses native UserNotifications and retains unanswered approval, inactivity and calendar requests in its menu bar. Approved workflow prompts start once in separate native agent windows, preserving the normal conversation. Requests expire or cancel with their original lifetime; silence grants no approval.
 
 The macOS publish output includes a signed `MeetingAssistant.app` bundle. Install that bundle in `/Applications` and launch the background service through its native executable so macOS microphone, calendar, and Screen/System Audio privacy grants are attributed to the stable Meeting Assistant application identity.
 
@@ -169,11 +171,13 @@ Detailed workflow syntax and extension guidance live in `docs/meeting-workflow-e
 
 Behavior changes are OpenSpec-driven and test-first: update the relevant requirement/scenario, add a failing public behavior test, implement the smallest passing change, run focused tests and then the justified broader suite, and validate the active change with `openspec validate <change-id> --strict`. Documentation-only maintenance does not need a new OpenSpec change.
 
-The Gitea workflow runs for pull requests, pushes, and manual dispatch on the existing `ubuntu-latest` runners. One job explicitly builds the Windows desktop target, installs Wine plus a matching Windows .NET SDK, and runs the portable test project through the Windows host under Wine. Another job builds and tests `net10.0` on Ubuntu, including the managed macOS audio, calendar, screenshot, registration, and desktop-control behavior tests. Its `TZ=Europe/Berlin` setting also exercises the calendar daylight-saving regression. No additional runner labels or host devices are required.
+The test project targets both `net10.0` and `net10.0-windows10.0.19041.0`, with the same application target selected explicitly. Choose `-f net10.0` for portable tests; use the Windows TFM on a compatible Windows runtime. A `win-x64` RID or Windows test host alone does not compile Windows tests. See `docs/platform-test-verification.md` for separate build, discovery, execution and artifact-verification commands.
+
+The Gitea workflow runs for pull requests, pushes, and manual dispatch on the existing `ubuntu-latest` runners. Its Windows job installs pinned Wine 11 plus a matching Windows .NET SDK, imports the SDK's public NuGet trust roots into a disposable Wine prefix, performs the full Windows application build without disabling resource generation, and builds/discovers/executes the real Windows test TFM. The portable job builds and tests `net10.0` on Ubuntu, including the managed macOS adapters; `TZ=Europe/Berlin` also exercises the calendar daylight-saving regression. Each job retains its own logs, discovery, TRX and verification report. The C# verifier requires the five named Outlook cases to pass in the Windows target and checks genuine platform skips. Wine compatibility is an execution prerequisite: a failed resource or runtime step remains a failed Windows check, with its evidence retained. Windows acceptance requires a successful run for the tested revision. See [Windows builds under Wine](docs/wine-windows-build.md) and [SDK certificate trust](docs/wine-sdk-trust.md) for the existing dependency correction, preparation and evidence boundaries.
 
 Ubuntu does not compile the Swift helpers or execute Apple frameworks. Tests requiring the native macOS environment report an explicit skip through `MacOsFact`; they must also be run on a supported Mac with `dotnet test MeetingAssistant.Tests/MeetingAssistant.Tests.csproj -f net10.0 -c Release -p:EnableWindowsTargeting=true`. That build compiles and signs the helpers, and the suite checks packaging, helper self-tests, and native image cropping. Real microphone/system-audio capture and privacy permissions still require the operational checks described above.
 
-[Docker-OSX](https://github.com/sickcodes/Docker-OSX) runs a macOS VM rather than providing a Wine-style compatibility layer. Its launcher supports software emulation with `KVM=accel=tcg`, so KVM is not an absolute requirement. A supported .NET 10 guest needs macOS 14 or later plus the Swift build tools. The documented `auto` build downloads a preinstalled guest disk through `IMAGE_URL`; its documented ready-made tags and disk downloads were unavailable when checked on 2026-10-03. No verified native guest bootstrap is owned by this repository. CI validates source; it does not publish or deploy the workstation application.
+The required `macos-native-full` job follows both jobs on the same existing Ubuntu infrastructure. It boots a disposable macOS 13/x86_64 guest with the existing Docker daemon and `/dev/kvm`, explicitly uses the RAW Recovery backend, installs the toolchain and builds/tests the exact checked-out revision. The current test inventory is verified against fresh discovery and TRX; all native macOS assertions must pass, while only the named Windows-only cases may skip. See [native macOS CI](docs/macos-native-diagnostic.md) for dependencies, limits, retained receipts and owned-resource cleanup. macOS 13 is outside Microsoft's current .NET 10 OS support; this configuration still needs a complete remote build/test qualification. CI validates source; it does not publish or deploy the workstation application.
 
 ## Operations And Limitations