david.delagneau/fidelity-ai-workspace
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: enhance AI Workspace Menu Bar App with packaging scripts, login management, and service status improvements

Browse Source
This commit is contained in:
David Delagneau
2026-05-20 16:11:45 -06:00
parent ab36e4b465
commit 4000747641
8 changed files with 349 additions and 66 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
core/services/menu-bar-app-design.md
View File

@@ -12,6 +12,7 @@ The app should not reimplement service logic. It should call the service manager
- Local-only, no cloud dependency.
- Start at login optional through `LaunchAgent` later.
- Read-only status by default; explicit user actions for start/stop/restart.
- The UI should not own MCP profile selection. AI clients pass profiles to MCP tools/resources; the menu bar app is only a local operations surface.
## Initial UI
@@ -32,6 +33,7 @@ AI Workspace ▾
Open Mattermost
Open Photo Inbox Folder
Copy Photo Inbox Upload URL
Copy Recent Logs
Open Project Knowledge
Open Logs
@@ -75,3 +77,5 @@ Use `status --json` for frequent UI refreshes and `doctor --json` for explicit d
2. Add profile selector and service action buttons.
3. Add LaunchAgent support for start at login.
4. Replace shell parsing with a daemon API if daily use proves stable.
See `multi-profile-runtime-model.md` for how this should evolve when multiple profiles run in parallel.

49
core/services/multi-profile-runtime-model.md Normal file
View File

@@ -0,0 +1,49 @@
# Multi-Profile Runtime Model
## Principle
Profiles are selected by clients and services, not by the menu bar UI.
The menu bar app is a local operations surface for the current operator machine. It can monitor the local services that are enabled now, but it should not become the source of truth for which project an AI client is allowed to query.
## Desired Model
- MCP clients choose the profile at call time, for example `{"profile":"fidelity"}`.
- Multiple profiles may run in parallel when their service ports and inbox paths do not conflict.
- Capture services can be profile-specific or shared:
- shared service: one Mattermost mirror with profile-scoped query filters;
- profile-specific service: separate mirror/output path/port per profile.
- The MCP query layer should remain profile-aware and read from profile manifests/config.
- The menu bar app should show local runtime health, not force a single global profile selection.
## Current Fidelity Setup
The first menu bar version targets the Fidelity service set because that is the active local workflow. This does not prevent MCP clients from querying other profiles when those profiles have canonical memory or context-source config.
## Parallel Profile Requirements
Before running another profile in parallel, define unique values for any conflicting service:
- MCP HTTP port if using separate MCP instances.
- Mattermost proxy listen port if using separate proxy instances.
- Photo Inbox port if using separate upload receivers.
- Mirror/inbox output directory.
- Profile-specific context channels.
Example future split:
```text
fidelity:
aiw-context-mcp: 127.0.0.1:8765
mattermost-proxy: 127.0.0.1:8080
photo-inbox: 0.0.0.0:8787
it-support:
aiw-context-mcp: same shared MCP, profile argument selects context
mattermost-proxy: 127.0.0.1:8081 if a separate capture session is needed
photo-inbox: 0.0.0.0:8788 if a separate receiver is needed
```
## Menu Bar Direction
The menu bar app should evolve toward showing service groups or all running profiles, but not a manual profile selector for MCP query behavior. Profile selection belongs in the MCP tool/resource arguments and client prompts.