4.1 KiB
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.