meeting-assistant/openspec/changes/add-macos-user-communication/implementation-evidence.md

Implementation evidence

Implementation completed on 2026-10-03; no production replacement, push, commit or archive was performed by this task. Full Windows resource-build verification and native interaction acceptance remain open below.

Branch: codex/macos-support. Starting baseline: bd35ebc. Verification HEAD: 1164c26846686c1912fd1816cd06de80352e9504; the branch was fast-forwarded during this work to its existing macOS CI/shutdown change. The final portable suite ran after that commit. The 20 changed/new production and test files are hashed in /private/tmp/mac-user-channel-evidence/code-identity.txt; that manifest has SHA-256 6cf3f10a72315c782cf17467be2dd7aa56fa279f191359780628ae818237d575.

The approved implementation provides one managed pending-request lifecycle, macOS approval/inactivity/calendar adapters, native notifications and pending-menu actions, and independent approved workflow conversations. Managed logic uses C#/.NET. The existing Swift AppKit/UserNotifications host and embedded WebKit JavaScript retain their platform bindings. Windows notification registrations remain selected for the Windows target.

Behavioral implementation and regression evidence

• Managed lifecycle: listing, one-time valid decisions, invalid-action preservation, deadlines, originating cancellation, withdrawal, shutdown and callback failure. Compiled/discovered red and green slices are retained, including 01-store-red.log, 03-invalid-action-red.log, 05-cancellation-red.log, 07-expiry-red.log, 09-withdraw-shutdown-red-and-sessions.log, 11-failed-callback-red-and-sessions.log and 19-expired-list-red.log.
• Prompt adapters: explicit Yes/No approval with decline on timeout/cancellation; nonblocking inactivity Stop/Continue/Pause; nonblocking calendar Record/Skip/AttachMetadata using the original appointment and callback. Adapter reds include 13-approval-red.log, 15-inactivity-red-and-workflow.log and 17-calendar-red.log.
• HTTP composition: list/respond and session-aware snapshot/send endpoints, invalid actions 400, consumed/stale requests 410, unknown sessions 404, and actual macOS service registrations. Executed reds are root-http-list-red.log, root-http-response-red.log and root-composition-red.log. Final focused managed/channel verification: 27 passed, zero failed/skipped, root-managed-final-green.log.
• Workflow sessions: full prompt starts once, histories remain independent, snapshots/reloads do not replay work, response disconnection does not cancel accepted work, shutdown does cancel it. sessions-01-red.log records the original missing behavior. The first complete suite exposed an eager dependency-resolution cycle (14 failing startup tests), retained in full-portable-suite-before-di-fix.log; a deferred session factory fixed it. The startup/channel subset then passed 17/17, startup-and-channel-green.log.
• Native host: compiled red/green checks cover numeric recording status, .NET timestamps, request reconciliation/menu fallback, allowed once-only actions, stale polling after acknowledgement, native actionable content and independent window IDs. All seven native groups pass, including during the integrated Release build and publish.

Temporary logs are under /private/tmp/mac-user-channel-evidence. They may be removed by normal temporary-directory cleanup.

Complete builds and tests

The final portable suite passed 602/602 tests, zero failed/skipped:

dotnet test MeetingAssistant.slnx -f net10.0 -c Release -p:EnableWindowsTargeting=true --logger 'trx;LogFileName=macos-user-channel-full.trx'

Evidence: full-portable-suite.log and generated MeetingAssistant.Tests/TestResults/macos-user-channel-full.trx.

Strict OpenSpec validation passed for both add-macos-user-communication and the adjusted add-macos-desktop-controls change (openspec-user-communication.log, openspec-desktop-controls.log). git diff --check was clean. All 20 source-file hashes still matched the recorded manifest after documentation updates.

The standard Windows build reached C# compilation but failed at resource expansion because MakePri.exe cannot execute on macOS (Exec format error, windows-build.log). Windows C# compilation succeeded with only that resource-generation step disabled:

dotnet build MeetingAssistant/MeetingAssistant.csproj -f net10.0-windows10.0.19041.0 -c Release -p:EnableWindowsTargeting=true -p:AppxGeneratePriEnabled=false

Evidence: windows-cross-compile.log. This checks compilation/isolation, not complete Windows resource/package generation or Windows runtime behavior. A Windows or configured Wine CI environment must complete task 4.2; no Wine runtime is installed on this Mac.

The macOS publish succeeded, compiling the native helpers and executing their self-tests:

dotnet publish MeetingAssistant/MeetingAssistant.csproj -f net10.0 -c Release --self-contained false -p:EnableWindowsTargeting=true -o /private/tmp/mac-user-channel-evidence/publish

Evidence: macos-publish.log. The outer MeetingAssistant.app and nested Native/MeetingAssistantDesktopControls.app passed codesign --verify --deep --strict; the nested plist passed plutil -lint. The published desktop helper passed all seven self-test groups. Its stable identifier is cloud.schweigert.meeting-assistant.desktop-controls; no-argument cold activation exited without recreating a request.

Isolated operational verification

The C# verification host (/private/tmp/mac-user-channel-fixture/Program.cs, Fixture.csproj, README) ran the production request store, endpoint module and workflow sessions at 127.0.0.1:5198. Only the external agent pipeline was replaced with a harmless no-tool response. Its native manifest had no recording profiles or global hotkeys. It registered no live vault, calendar, audio, recording or LLM services.

• The actual signed desktop host reported notification authorization and scheduling. A workflow session opened a native AppKit/WebKit window; its accessibility tree and screenshot displayed the full verification prompt once and the expected harmless reply.
• A live request rejected an unoffered action with 400 and stayed pending; No returned 200; duplicate No and an expired request returned 410. In-memory callbacks recorded exactly one No per answered request.
• A temporary read-only Swift probe used the same stable app identifier and Apple's UNUserNotificationCenter API. It requested no permissions and scheduled/removed nothing. For request 09ba4dc708784aaf98b1ecd85f44aa8a, notification-delivery.json reports complete=true, delivered=true, pending=false, registered category actions yes/no, authorized notification access and enabled alert/Notification Center/sound settings. This proves Notification Center delivery, not visible banner presentation or a physical button click.
• After that request received No (HTTP 200), notification-after-response.json reports delivered=false and pending=false. operational-decisions.json contains exactly the two independently answered No decisions, proving cleanup after the response and no duplicate callback.
• The isolated native host and verification web host were stopped after verification. The installed live Meeting Assistant was neither stopped nor replaced.

Probe entry: /private/tmp/mac-user-channel-evidence/NotificationReadOnlyProbe.app/Contents/MacOS/macos-desktop-controls <request-id>. Dependencies: the existing signed macOS app identity and UserNotifications framework. Effects: read-only API calls and one bounded JSON result, with no unrelated notification content printed.

Remaining acceptance checks and limits

The native/browser UI bridge repeatedly timed out while selecting windowless menu/notification surfaces and interacting with the isolated browser page. No claim is made for actual notification/menu clicks, real notification dismissal retaining its menu item, permission-denied/Focus-hidden fallback, or the visible default draft alongside two simultaneous workflow windows. The implementation and native state tests cover those paths; manual/native interaction acceptance remains in task 4.4.

No live recording/hotkey regression exercise was performed in this isolated fixture. Existing numeric-status regression and the full portable suite passed. Full Windows resource/package generation remains the other verification limit. OpenSpec stays active pending acceptance and those checks; production delivery is separate.