forked from Manuel/meeting-assistant
dh
9542c05ea4
- Introduced MacOsDesktopControlManifest to manage desktop control configurations. - Implemented MacOsDesktopControlService to handle the lifecycle of the macOS helper process. - Created MacOsWorkflowRulesEditorWindowService for managing workflow rules through a native window. - Developed a Swift helper for macOS that integrates with AppKit and Carbon for menu-bar controls and global hotkeys. - Added support for recording lifecycle actions via HTTP endpoints, maintaining consistency with existing Windows functionality. - Enhanced user experience by allowing macOS users to start/stop recordings and access settings through a menu-bar interface. - Documented design decisions, implementation evidence, and verification tasks for the new macOS features.
56 lines
4.1 KiB
Markdown
56 lines
4.1 KiB
Markdown
## Context
|
|
|
|
Meeting Assistant already separates many Windows-only implementations at compile time, while its portable service surface can run on macOS. The interactive settings/logs assistant is different: its model instructions are currently platform-neutral and do not tell the model which local operating system it is helping to operate. As a result, responses can mix PowerShell, Windows path and service concepts with macOS shells, POSIX paths, and launchd concepts.
|
|
|
|
The host platform is stable for the lifetime of one application process, so it should be detected once during startup and passed to consumers as runtime context.
|
|
|
|
## Goals / Non-Goals
|
|
|
|
**Goals:**
|
|
|
|
- Detect Windows and macOS explicitly when the process starts.
|
|
- Give the interactive settings/logs assistant unambiguous host-platform context.
|
|
- Require Windows-native operational guidance on Windows and macOS-native guidance on macOS.
|
|
- Prevent the assistant from presenting unavailable platform features as if they existed.
|
|
- Retain safe, neutral behavior on other hosts used for build or test execution.
|
|
|
|
**Non-Goals:**
|
|
|
|
- Implement macOS audio capture, global hotkeys, tray UI, Outlook integration, active-window screenshots, or notifications.
|
|
- Change automatic meeting-summary instructions, which do not operate the local application environment.
|
|
- Add a user-configurable OS override.
|
|
- Translate every internal process invocation into a shell script; existing argument-based process execution remains portable where it already is.
|
|
|
|
## Decisions
|
|
|
|
### Detect once and inject immutable runtime context
|
|
|
|
Startup will create one immutable host-operating-system value using .NET runtime checks and register it as a singleton. The interactive instruction builder will consume that value instead of invoking static OS checks itself.
|
|
|
|
This makes startup responsible for environment detection, keeps model instruction generation deterministic, and lets behavior tests supply explicit Windows and macOS values without depending on the test runner's host.
|
|
|
|
Alternative considered: call `OperatingSystem.IsWindows()` or `OperatingSystem.IsMacOS()` directly inside the instruction builder. That would couple instruction tests to their host and repeat environment detection at the usage site.
|
|
|
|
### Append platform guidance even when a custom prompt is configured
|
|
|
|
The detected platform and platform constraints will be part of the always-appended runtime context, alongside configured paths and tool descriptions. A custom initial prompt may change the assistant persona, but it must not erase the factual host environment.
|
|
|
|
Alternative considered: include platform text only in the built-in prompt. That would recreate the current ambiguity whenever `WorkflowRulesEditor:InitialPrompt` is configured.
|
|
|
|
### Use explicit platform concepts and exclusions
|
|
|
|
Windows guidance will name PowerShell, Windows paths, environment variables, processes, services, and Task Manager concepts while excluding macOS-only instructions. macOS guidance will name zsh/POSIX paths, launchd/LaunchAgents, Activity Monitor, and macOS environment conventions while excluding Windows-only instructions.
|
|
|
|
Both branches will remind the assistant that it must respect the application's actual feature availability. Platform detection informs operational language; it does not create platform integrations.
|
|
|
|
### Preserve a neutral unsupported-host fallback
|
|
|
|
Linux and other hosts may be used for CI or the portable service surface. Those hosts will be identified as unsupported for platform-specific guidance and will receive portable .NET/tool guidance without being mislabeled as Windows or macOS.
|
|
|
|
## Risks / Trade-offs
|
|
|
|
- [Prompt guidance cannot guarantee every model response uses the correct command syntax] → Make the platform explicit, name positive concepts, and explicitly forbid cross-platform substitutions.
|
|
- [Platform examples can become too prescriptive] → Keep the guidance at the command/concept family level and prefer the assistant's built-in tools when available.
|
|
- [Users may interpret macOS detection as full macOS feature support] → State in both the prompt and documentation that feature availability remains separate from OS detection.
|
|
|