Problem Statement

Mission Control currently supports only a single tenant. All data—tasks, agents, comments, activities, notifications—exists in a flat namespace with no isolation between different teams or organizations. This prevents:

• Running multiple teams or departments on a single Mission Control instance
• Separating production from development environments
• Offering Mission Control as a SaaS product to external customers

If you try to add workspace_id to tasks or agents, the schema doesn't support it. There's no workspaces table and no way to filter data by organization.

Proposed Solution

Add native multi-workspace (multi-tenant) support to Mission Control:

1. Database Schema

   • Create a workspaces table with id, name, slug, created_at
   • Add workspace_id foreign key to: tasks, agents, comments, activities, notifications, quality_reviews, users

2. API Layer

   • All queries must filter by workspace_id (derived from authenticated session)
   • Add workspace management endpoints: create, list, update, delete workspaces

3. Authentication & Authorization

   • Bind user sessions to workspaces
   • Add workspace-scoped RBAC (workspace admin vs viewer vs operator)

4. Frontend

   • Workspace switcher dropdown in header
   • Workspace settings/admin page
   • All views filter data by current workspace

Alternatives Considered

• Separate SQLite files per workspace: Simpler to implement but doesn't scale well and makes cross-workspace queries impossible
• Prefix all table names with workspace slug: Extremely hacky, breaks foreign keys and indexes
• External PostgreSQL with row-level security: Not applicable—Mission Control uses SQLite

Additional Context

This is a schema-breaking change. The current Phase 2 schema has no workspace concept at all. Implementing this would require:

• Database migration to add workspace_id columns
• Migration of existing data to a default workspace
• Update to all 30+ API endpoints to validate workspace context
• UI updates across all 26 panels