29 lines
1.4 KiB
Markdown
29 lines
1.4 KiB
Markdown
# AI Workspace Service Manager
|
|
|
|
## Principle
|
|
|
|
The AI Workspace should unify local service lifecycle without collapsing service responsibilities.
|
|
|
|
- Service manager: starts, stops, checks, and logs local services.
|
|
- Context MCP: exposes bounded read-only context to AI clients.
|
|
- Capture services: produce local evidence such as Mattermost mirror records or photo inbox files.
|
|
- Canonical memory remains under `workspaces/<profile>/project-knowledge/` and is updated by the agent using memory rules.
|
|
|
|
## Service Types
|
|
|
|
- `process`: long-running local command with PID, logs, and optional health check.
|
|
- `app-launcher`: one-shot command that opens an application or helper.
|
|
- `mcp`: a process service that exposes an MCP-compatible context interface.
|
|
|
|
## Profile Manifests
|
|
|
|
Project-specific services should be declared under `profiles/<profile>/services.json`.
|
|
|
|
Manifests should avoid project facts in reusable code. Profile-specific channel names, paths, ports, and enabled services belong in the profile manifest or local `.env` files.
|
|
|
|
## Responsibility Boundaries
|
|
|
|
Do not put capture lifecycle inside the context MCP. The MCP should query local evidence produced by capture services. The service manager may start both the MCP and capture services as one profile-level operation.
|
|
|
|
This keeps the same core usable for Fidelity, IT support, or another project with different communication sources.
|