{"slug":"business/SHARED_FRONTEND_SHELL_AND_DOMAIN_OWNERSHIP","title":"Shared Frontend Shell and Domain Ownership","section":"business","sectionLabel":"Business","status":"unclassified","type":"document","path":"business/SHARED_FRONTEND_SHELL_AND_DOMAIN_OWNERSHIP.mdx","bytes":6991,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\n**Status:** Normative  \n**Date:** 2026-08-11  \n**Parent:** [`INTEGRATEWISE_ARCHITECTURE_v2.2.md`](INTEGRATEWISE_ARCHITECTURE_v2.2.md)\n\n## 1. Core rule\n\nEvery IntegrateWise frontend shares the same four platform capabilities:\n\n```text\nAuth + Connectors + MCP + Platform\n```\n\nEverything else may remain owned by the individual frontend/product surface.\n\nThis 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.\n\n## 2. Frontend composition\n\n```text\nFrontend\n├── Shared Auth\n├── Shared Connectors\n├── Shared MCP\n├── Shared Platform access\n└── Frontend-owned domain/product experience\n```\n\nExamples:\n\n```text\nUser Workbench\n= shared shell + role/subdomain Workbench projections\n\nCustomer Zero Workbench\n= shared shell + Customer Zero-specific operational views\n\nMarketplace frontend\n= shared shell + marketplace/catalog/install experience\n\nPartner/developer frontend\n= shared shell + package/developer/partner workflows\n\nDomain frontend\n= shared shell + its own lifecycle projections and domain workflows\n```\n\n## 3. Shared capability ownership\n\n| Shared concern | Canonical owner                                          | Frontend responsibility                                                                  |\n| -------------- | -------------------------------------------------------- | ---------------------------------------------------------------------------------------- |\n| Auth           | One Auth / shared auth runtime                           | consume session, tenant, membership and permission context                               |\n| Connectors     | connector projection / integration runtime               | render connector state and invoke shared connector lifecycle actions                     |\n| MCP            | MCP Pool / MCP Connector / capability registry           | discover and invoke effective MCP-backed Tool Capabilities                               |\n| Platform       | Platform Backend + Platform Management Console contracts | consume permitted platform capabilities/settings without duplicating control-plane truth |\n\nA frontend may render a custom presentation of these capabilities, but it must not create an independent source of truth or independent runtime for them.\n\n## 4. Frontend-owned responsibilities\n\nEach frontend may own:\n\n- route structure\n- visual design and interaction patterns\n- domain-specific navigation\n- lifecycle/phase-specific views\n- local presentation state\n- domain filters and saved view preferences\n- domain-specific composition of backend projections\n- contextual Tool Capability placement\n- page-specific workflows\n- domain-specific empty/loading/error states\n\nEach frontend does **not** own:\n\n- a separate identity system\n- duplicated provider credentials\n- independent connector registry\n- independent MCP registry\n- independent Tool Capability definitions\n- independent Governance policy truth\n- canonical business truth\n- duplicated Platform Backend configuration\n\n## 5. Shared shell contract\n\nEvery frontend should receive a common runtime context equivalent to:\n\n```ts\ntype SharedFrontendContext = {\n  auth: {\n    userId: string;\n    tenantId: string;\n    workspaceId?: string;\n    roles: string[];\n    permissions: string[];\n    sessionState: \"active\" | \"expired\" | \"restricted\";\n  };\n  connectors: {\n    projections: unknown[];\n    health: unknown[];\n    effectiveGrants: unknown[];\n  };\n  mcp: {\n    availableServers: unknown[];\n    effectiveCapabilities: unknown[];\n    health: unknown[];\n  };\n  platform: {\n    tenantConfig: unknown;\n    featureAvailability: unknown;\n    governancePosture: unknown;\n    observabilitySummary?: unknown;\n  };\n};\n```\n\nThe exact TypeScript type may differ, but these four namespaces are the shared contract.\n\n## 6. Domain extension contract\n\nA frontend adds its own domain projection on top of the shared context:\n\n```ts\ntype FrontendRuntime<TDomainProjection> = {\n  shared: SharedFrontendContext;\n  domain: TDomainProjection;\n};\n```\n\nThe domain projection must follow the lifecycle/table mapping contract in [`LIFECYCLE_CONTINUITY_AND_PROJECTION_MAP.md`](LIFECYCLE_CONTINUITY_AND_PROJECTION_MAP.md).\n\n## 7. Auth rule\n\nAll 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.\n\n## 8. Connector rule\n\nAll frontends consume the same tenant connector projection registry.\n\nA 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.\n\n```text\nhost/tenant connector\n→ shared connector projection\n→ capability resolution\n→ many frontend projections\n```\n\n## 9. MCP rule\n\nAll frontends consume one shared MCP/capability fabric.\n\nA 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.\n\n## 10. Platform rule\n\nPlatform Backend capabilities are common infrastructure.\n\nEach frontend may expose selected platform functions contextually, such as:\n\n- connector health\n- activation state\n- approvals\n- capability availability\n- pipeline status\n- memory/continuity state\n\nDeep operator configuration remains owned by the Platform Management Console unless a role-scoped projection is explicitly supported.\n\n## 11. Shared versus owned navigation\n\nThe architecture does not require every frontend to render identical navigation.\n\nThe rule is capability sharing, not navigation duplication.\n\nFor 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.\n\n## 12. Reuse hierarchy\n\nPreferred reuse order:\n\n```text\nshared runtime contract\n→ shared SDK/hooks/services\n→ shared composable UI primitives\n→ frontend-specific composition\n```\n\nDo not force every frontend into a single monolithic UI package. Reuse the common platform capabilities and contracts; let domain UX diverge where appropriate.\n\n## 13. Isolation rule\n\nFrontend-owned code may fail independently without corrupting common platform truth.\n\nThe shared Auth, Connector, MCP and Platform runtimes remain authoritative even if a particular frontend has stale local state or rendering errors.\n\n## 14. Invariant\n\nThe test for any frontend is:\n\n> Can this frontend be replaced without migrating identity, reconnecting providers, redefining MCP capabilities, or moving Platform Backend truth?\n\nIf yes, the boundary is correct.\n\nIf replacing the frontend requires any of those migrations, the frontend owns too much.\n"}