Shared Frontend Shell and Domain Ownership
Status: Normative
Date: 2026-08-11
Parent: INTEGRATEWISE_ARCHITECTURE_v2.2.md
1. Core rule
Every IntegrateWise frontend shares the same four platform capabilities:
Auth + Connectors + MCP + Platform
Everything else may remain owned by the individual frontend/product surface.
This prevents each frontend from rebuilding identity, connector lifecycle, MCP discovery/execution and platform controls while still allowing each product/domain to own its own UX, routes, workflows and projections.
2. Frontend composition
Frontend
├── Shared Auth
├── Shared Connectors
├── Shared MCP
├── Shared Platform access
└── Frontend-owned domain/product experience
Examples:
User Workbench
= shared shell + role/subdomain Workbench projections
Customer Zero Workbench
= shared shell + Customer Zero-specific operational views
Marketplace frontend
= shared shell + marketplace/catalog/install experience
Partner/developer frontend
= shared shell + package/developer/partner workflows
Domain frontend
= shared shell + its own lifecycle projections and domain workflows
3. Shared capability ownership
| Shared concern | Canonical owner | Frontend responsibility |
|---|---|---|
| Auth | One Auth / shared auth runtime | consume session, tenant, membership and permission context |
| Connectors | connector projection / integration runtime | render connector state and invoke shared connector lifecycle actions |
| MCP | MCP Pool / MCP Connector / capability registry | discover and invoke effective MCP-backed Tool Capabilities |
| Platform | Platform Backend + Platform Management Console contracts | consume permitted platform capabilities/settings without duplicating control-plane truth |
A frontend may render a custom presentation of these capabilities, but it must not create an independent source of truth or independent runtime for them.
4. Frontend-owned responsibilities
Each frontend may own:
- route structure
- visual design and interaction patterns
- domain-specific navigation
- lifecycle/phase-specific views
- local presentation state
- domain filters and saved view preferences
- domain-specific composition of backend projections
- contextual Tool Capability placement
- page-specific workflows
- domain-specific empty/loading/error states
Each frontend does not own:
- a separate identity system
- duplicated provider credentials
- independent connector registry
- independent MCP registry
- independent Tool Capability definitions
- independent Governance policy truth
- canonical business truth
- duplicated Platform Backend configuration
5. Shared shell contract
Every frontend should receive a common runtime context equivalent to:
type SharedFrontendContext = {
auth: {
userId: string;
tenantId: string;
workspaceId?: string;
roles: string[];
permissions: string[];
sessionState: "active" | "expired" | "restricted";
};
connectors: {
projections: unknown[];
health: unknown[];
effectiveGrants: unknown[];
};
mcp: {
availableServers: unknown[];
effectiveCapabilities: unknown[];
health: unknown[];
};
platform: {
tenantConfig: unknown;
featureAvailability: unknown;
governancePosture: unknown;
observabilitySummary?: unknown;
};
};
The exact TypeScript type may differ, but these four namespaces are the shared contract.
6. Domain extension contract
A frontend adds its own domain projection on top of the shared context:
type FrontendRuntime<TDomainProjection> = {
shared: SharedFrontendContext;
domain: TDomainProjection;
};
The domain projection must follow the lifecycle/table mapping contract in LIFECYCLE_CONTINUITY_AND_PROJECTION_MAP.md.
7. Auth rule
All frontends enter through the same One Auth/session authority. A frontend may have a different login presentation or route shell, but it may not maintain an unrelated identity/session authority for the same ecosystem tenant.
8. Connector rule
All frontends consume the same tenant connector projection registry.
A frontend can choose which connectors to show based on domain, role and lifecycle phase, but it may not create a second provider connection merely because it is a different frontend.
host/tenant connector
→ shared connector projection
→ capability resolution
→ many frontend projections
9. MCP rule
All frontends consume one shared MCP/capability fabric.
A frontend may expose only a subset of MCP servers/Tool Capabilities relevant to its context, but discovery, versioning, health, policy and execution identity come from the shared MCP/Capability runtime.
10. Platform rule
Platform Backend capabilities are common infrastructure.
Each frontend may expose selected platform functions contextually, such as:
- connector health
- activation state
- approvals
- capability availability
- pipeline status
- memory/continuity state
Deep operator configuration remains owned by the Platform Management Console unless a role-scoped projection is explicitly supported.
11. Shared versus owned navigation
The architecture does not require every frontend to render identical navigation.
The rule is capability sharing, not navigation duplication.
For example, one frontend may expose Connectors as a tray, another as an embedded settings panel, and another only as contextual connection status. All three must use the same connector backend/runtime.
12. Reuse hierarchy
Preferred reuse order:
shared runtime contract
→ shared SDK/hooks/services
→ shared composable UI primitives
→ frontend-specific composition
Do not force every frontend into a single monolithic UI package. Reuse the common platform capabilities and contracts; let domain UX diverge where appropriate.
13. Isolation rule
Frontend-owned code may fail independently without corrupting common platform truth.
The shared Auth, Connector, MCP and Platform runtimes remain authoritative even if a particular frontend has stale local state or rendering errors.
14. Invariant
The test for any frontend is:
Can this frontend be replaced without migrating identity, reconnecting providers, redefining MCP capabilities, or moving Platform Backend truth?
If yes, the boundary is correct.
If replacing the frontend requires any of those migrations, the frontend owns too much.