forked from Manuel/meeting-assistant
64 lines
8.3 KiB
Markdown
64 lines
8.3 KiB
Markdown
# 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**:
|
|
|
|
```zsh
|
|
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:
|
|
|
|
```zsh
|
|
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:
|
|
|
|
```zsh
|
|
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.
|