meeting-assistant/docs/platform-test-verification.md

# Platform test verification

The test and application projects expose `net10.0` (portable) and `net10.0-windows10.0.19041.0` (Windows). Always select a TFM. A RID selects runtime assets; it cannot enable Windows conditional compilation. `TestTargetCompositionTests.TestAndApplicationTargetsUseMatchingComposition` checks both assembly targets and the actual HTTP/service composition without starting application background services. Its TRX output records the target and runtime host.

## Portable path

From the repository root on a supported .NET 10 host:

```sh
mkdir -p artifacts/tests/portable
dotnet --info > artifacts/tests/portable/sdk.txt
dotnet restore MeetingAssistant.Tests/MeetingAssistant.Tests.csproj -p:TargetFramework=net10.0 -p:EnableWindowsTargeting=true
dotnet build MeetingAssistant.Tests/MeetingAssistant.Tests.csproj -f net10.0 -c Release --no-restore -p:EnableWindowsTargeting=true
dotnet test MeetingAssistant.Tests/MeetingAssistant.Tests.csproj -f net10.0 -c Release --no-build --list-tests > artifacts/tests/portable/discovery.txt
dotnet test MeetingAssistant.Tests/MeetingAssistant.Tests.csproj -f net10.0 -c Release --no-build --logger 'trx;LogFileName=portable.trx' --results-directory artifacts/tests/portable
dotnet run tools/VerifyPlatformTests.cs -- portable artifacts/tests/portable/discovery.txt artifacts/tests/portable/portable.trx
```

On macOS the application build compiles/signs the existing Swift helpers and runs their self-tests. `MacOsFact` tests exercise packaging and native helper/pixel behavior on the portable target only. Other hosts report reasoned skips. `ResolveKeyFallsBackToUserEnvironment` and `TaskbarIconGlyphsAreVisuallyCentered` report reasoned Windows skips on incompatible hosts; on Windows, even the portable target runs their assertions. The five Outlook cases are excluded from portable compilation and must not appear in portable discovery or results.

## Windows path

From the repository root in PowerShell on Windows with the .NET 10 SDK and Windows Desktop runtime:

```powershell
New-Item -ItemType Directory -Force artifacts/tests/windows | Out-Null
dotnet --info > artifacts/tests/windows/sdk.txt
dotnet restore MeetingAssistant.Tests/MeetingAssistant.Tests.csproj -p:TargetFramework=net10.0-windows10.0.19041.0 -p:EnableWindowsTargeting=true -r win-x64
dotnet build MeetingAssistant/MeetingAssistant.csproj -f net10.0-windows10.0.19041.0 -c Release -r win-x64 -p:EnableWindowsTargeting=true
dotnet build MeetingAssistant.Tests/MeetingAssistant.Tests.csproj -f net10.0-windows10.0.19041.0 -c Release -r win-x64 --no-restore -p:EnableWindowsTargeting=true
dotnet test MeetingAssistant.Tests/MeetingAssistant.Tests.csproj -f net10.0-windows10.0.19041.0 -c Release -r win-x64 --no-build --list-tests > artifacts/tests/windows/discovery.txt
dotnet test MeetingAssistant.Tests/MeetingAssistant.Tests.csproj -f net10.0-windows10.0.19041.0 -c Release -r win-x64 --no-build --logger 'trx;LogFileName=windows.trx' --results-directory artifacts/tests/windows
dotnet run tools/VerifyPlatformTests.cs -- windows artifacts/tests/windows/discovery.txt artifacts/tests/windows/windows.trx
```

Check each command's exit code before proceeding. CI uses `pipefail` when retaining logs. A Windows-compatible Wine environment must run the Windows SDK for both builds and tests; the verifier can run through the Linux SDK against the resulting artifacts. The existing Wine job retains the full application/resource build log separately. It does not disable PRI/resource generation or downgrade build failures to successful compiler evidence. Wine's support for the currently required Windows resource tooling and native runtime must be demonstrated by that run.

Windows discovery and successful result records must name all five existing cases:

- `ExtractAgendaStopsBeforeTeamsJoinInformation`
- `NormalizeAttendeesDeduplicatesOrganizerAndRecipientEmail`
- `SubjectIndicatesCancellationRecognizesOutlookCanceledPrefixes(subject: "Canceled: Project sync")`
- `SubjectIndicatesCancellationRecognizesOutlookCanceledPrefixes(subject: "Cancelled: Project sync")`
- `SubjectIndicatesCancellationRecognizesOutlookCanceledPrefixes(subject: "Abgesagt: Project sync")`

The two Windows-only checks must pass their assertions on this runtime. Merely listing tests, returning before assertions, compiling with resource generation disabled, or running portable tests under Wine cannot satisfy Windows acceptance.

Ticket 02 additionally requires all three `WindowsScreenshotImageCropperTests` cases to be discovered and passed: `WindowsCropUsesOcrPixelCoordinates`, `WindowsCropPreservesExpectedPixelsAtNonzeroOrigin`, and `WindowsCropRejectsInvalidBounds`. The checker rejects omitted or skipped crop results and excludes the crop class from portable evidence, even on a Windows host. These tests use the registered production cropper and deterministic pixel data. See [Windows platform acceptance](windows-platform-acceptance.md) for the crop contract and separate external CI observation.

## Artifact checker and evidence boundaries

Entry point: `tools/VerifyPlatformTests.cs`, a .NET 10 file-based C# app using the standard library. Invocation: `dotnet run tools/VerifyPlatformTests.cs -- <portable|windows> <discovery.txt> <results.trx>`. It reads only the supplied files, prints named outcomes/skip reasons and totals derived from result records, and returns a nonzero exit code for invalid or incomplete evidence. It makes no network calls or application/runtime changes. Its fixture tests use synthetic records; those fixtures are not Windows execution evidence.

Gitea retains `portable-target-evidence` and `windows-target-evidence` separately, including available logs after a failed step. Artifact uploads use the Gitea-compatible action recommended by the [Gitea release documentation](https://blog.gitea.com/release-of-1.22.0/). Artifact publication and Wine execution still require validation on the configured runner.

Report current totals from each TRX, with host, SDK/runtime, TFM, discovery and content identity. Preserve the dated **2026-10-03 historical 602-pass portable baseline** in `openspec/changes/add-macos-user-communication/implementation-evidence.md`; do not reuse that number as a current total. Adapter summary counters for skipped tests can differ from `NotExecuted` records, so the checker counts actual result records.

A portable pass does not prove a full Windows resource build, native Windows operation, notification/menu acceptance, screenshot focus, or an activated ASR backend. Those results belong to their own acceptance evidence. Ticket 01's current evidence is in `openspec/changes/complete-macos-feature-parity/windows-test-assurance-evidence.md`. The old communication Task 4.2 stays open until a compatible runtime supplies the missing full Windows build; Task 4.4 and other tickets remain separate.