{"slug":"developers/v0-frontend-spec","title":"Historical v0 Frontend Specification — Superseded","section":"developers","sectionLabel":"Developers","status":"unclassified","type":"document","path":"developers/v0-frontend-spec.mdx","bytes":34232,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\n> **Status:** HISTORICAL IMPLEMENTATION HANDOFF\n> **Current frontend authority:** [`docs/frontend-v0/README.md`](frontend-v0/README.md),\n> [`FRONTEND_PLATFORM_API_AND_DISCOVERY_SPEC.md`](architecture/FRONTEND_PLATFORM_API_AND_DISCOVERY_SPEC.md)\n> and [`TWIN_BEHAVIOR.md`](architecture/TWIN_BEHAVIOR.md).\n>\n> Do not implement the permanent Twin sidebar/panel or one-to-one UI/table\n> authority described below.\n\n# Original Snapshot: IntegrateWise v0 Frontend Spec\n\n**Status:** Definitive alignment spec  \n**Date:** July 23, 2026  \n**Scope:** Frontend surfaces, backend service mapping, Twin/agent/memory/triage/continuity/capabilities/Spine network integration, interaction flow, and exhaustive one-to-one and cross-mapping tables for v0\n\n---\n\n## 1. Context\n\nv0 is the first aligned frontend release after the canonical architecture correction. Its purpose is not to add new platform concepts, but to make the existing frozen product doctrine executable through one identity path, one public continuity contract, one truth path, one projection path, and one governed execution path.\n\nThe user must never be asked to explain context already held by the Spine Network. Twin inherits permitted active context, reads governed evidence, prepares work, and stays silent when there is no material contribution. All durable execution, approval, memory promotion, and canonical writes remain in the backend.\n\n---\n\n## 2. Current State of the Codebase\n\n### 2.1 Frontend\n\n- Marketing, auth, onboarding, and authenticated workbench routes exist under `apps/web/src/app`.\n- `AppShell.tsx` manages stage flow: login → signup → provisioning → loading → workspace.\n- Route rendering is centralized in `apps/web/src/app/_components/route-views.tsx`.\n- Department/module routing is derived from `@integratewise/workbench-config` in `apps/web/src/app/_lib/workbench-routes.ts`.\n- Reusable workbench views exist under `packages/ui/src/views/*.tsx`.\n\n### 2.2 Backend Services\n\nCanonical deployable services:\n\n| Service                                                  | Canonical Role                                                    |\n| -------------------------------------------------------- | ----------------------------------------------------------------- |\n| `gateway`                                                | Public entry, JWT/tenant routing, projections, capability routing |\n| `pipeline`                                               | Normalization, triage, promotion, canonical writes                |\n| `spine`                                                  | Canonical read model and internal Spine operations                |\n| `tenants`                                                | Tenant lifecycle, workspace context, plan limits                  |\n| `mcp-connector` / `mcp-pool`                             | Inbound/outbound MCP pool, tenant-scoped tool routing             |\n| `integration-management-mcp` / `provider-management-mcp` | Integration and provider MCP surfaces                             |\n| `connector` / `connector-sync`                           | Provider adapters, OAuth, sync, credential wall                   |\n| `normalizer` / `schema-ai`                               | Schema discovery, normalization, canonical mapping                |\n| `knowledge` / `continuity`                               | Knowledge base, memory lifecycle, continuity substrate            |\n| `intelligence` / `hermes` / `iw-agent-runtime`           | AI routing, orchestration, agent runtime                          |\n| `signals` / `telemetry`                                  | Signal interpretation, observability                              |\n| `govern` / `workflow` / `task-management`                | Approval, workflow, task accountability                           |\n| `store` / `admin` / `folder-watcher` / `webhook-ingress` | Projection persistence, admin, telemetry, webhooks                |\n\nLegacy aliases such as `think`, `act`, `l2`, and historical `twin-orchestrator` references are not canonical runtime entry points and must not be introduced as new frontend dependencies.\n\n---\n\n## 3. Correct Platform Sequence\n\n```text\nUser intent\n  ↓\nTwin\n  ↓\nContext Builder\n  ↓\nUser / Work / Organization Memory\n  ↓\nKnowledge and AI Search\n  ↓\nCapability and Agent Resolver\n  ↓\nGovernance\n  ↓\nAgent or capability execution\n  ↓\nContinuity runtime\n  ↓\nTriage candidates\n  ↓\nApproved Spine writes\n  ↓\nUpdated projections\n  ↓\nTwin reports the result\n```\n\nFrontend ownership rules:\n\n- The user interacts with Twin, not internal orchestrators.\n- The Workbench renders governed projections only.\n- Approval, execution, continuity, and memory promotion happen in the backend.\n- The frontend never writes canonical state directly.\n\n---\n\n## 4. Frontend Surfaces and Functions\n\n| Frontend Surface     | v0 Function                                                                       | Owner             |\n| -------------------- | --------------------------------------------------------------------------------- | ----------------- |\n| Marketing            | Discovery, sign-in/sign-up, onboarding entry                                      | Marketing         |\n| Onboarding           | Intent capture, domain selection, connector setup, activation                     | Platform          |\n| Workbench shell      | Navigation, context propagation, role-aware layout, Twin entry                    | Platform          |\n| Domain views         | Projection-based operational surfaces                                             | Platform          |\n| Twin sidebar/panel   | Ask, analyze, explain, recommend, plan, delegate, act, continue, review, remember | Twin              |\n| Governance surface   | Approval queue, proposal review, evidence, decision capture                       | Governance        |\n| Knowledge surface    | Knowledge search, extraction feedback, document review                            | Knowledge         |\n| Memory surface       | Memory triage, promotion review, contradiction review                             | Memory            |\n| Agents surface       | Agent selection, task monitoring, outcome review                                  | Twin/Agents       |\n| Capabilities surface | Capability discovery, execution, approval-state visibility                        | Capability Fabric |\n| Continuity surface   | Workflow status, retry/escalation state, completion tracking                      | Continuity        |\n| Admin surface        | Users, roles, policies, connections, integrations, models, billing                | Administration    |\n\n---\n\n## 5. Backend Service Mapping\n\n| Frontend Surface     | Primary Backend Services                     | Secondary Backend Services                    |\n| -------------------- | -------------------------------------------- | --------------------------------------------- |\n| Marketing            | `gateway`, `tenants`, `mcp-connector`        | `provider-management-mcp`                     |\n| Onboarding           | `gateway`, `tenants`, `pipeline`, `spine`    | `integration-management-mcp`, `connector`     |\n| Workbench shell      | `gateway`, `spine`, `projection-engine`      | `store`, `signals`, `telemetry`               |\n| Domain views         | `gateway`, `spine`, `pipeline`               | `knowledge`, `signals`                        |\n| Twin sidebar/panel   | `intelligence`, `hermes`, `iw-agent-runtime` | `mcp-connector`, `knowledge`, `continuity`    |\n| Governance surface   | `govern`, `workflow`                         | `gateway`, `task-management`                  |\n| Knowledge surface    | `knowledge`                                  | `pipeline`, `spine`, `mcp-connector`          |\n| Memory surface       | `continuity`, `knowledge`                    | `govern`, `pipeline`, `spine`                 |\n| Agents surface       | `iw-agent-runtime`, `agent-registry`         | `intelligence`, `hermes`, `task-management`   |\n| Capabilities surface | `mcp-pool`, `integration-management-mcp`     | `govern`, `hermes`, `provider-management-mcp` |\n| Continuity surface   | `workflow`, `task-management`, `continuity`  | `hermes`, `signals`, `telemetry`              |\n| Admin surface        | `gateway`, `admin`, `tenants`                | `store`, `billing`, `provider-management-mcp` |\n\n---\n\n## 6. Twin Ownership\n\nTwin is the primary intelligent actor visible to the user.\n\nTwin responsibilities:\n\n- Understands user intent\n- Retrieves governed context\n- Reasons over Knowledge and Memory\n- Recommends actions\n- Activates agents\n- Selects capabilities\n- Delegates work\n- Requests approvals\n- Tracks delegated outcomes\n- Explains evidence and decisions\n- Maintains continuity from the user’s perspective\n\nFrontend implication: Every major surface is Twin-mediated. The Workbench never exposes raw backend control surfaces without Twin framing.\n\n---\n\n## 7. Agent Interaction Model\n\nAgents do not independently control the user experience. Agents are activated and coordinated through Twin.\n\nInteraction rule:\n\n```text\nUser\n  ↓\nTwin\n  ↓\nAgent Registry\n  ↓\nAgent selection\n  ↓\nContext assignment\n  ↓\nCapability assignment\n  ↓\nGoverned execution\n  ↓\nResult returned to Twin\n```\n\nAgent invariants:\n\n- Agents do not read canonical Spine directly.\n- Agents do not write canonical state.\n- Agents do not promote their own memory.\n- Agents do not approve their own actions.\n- Agents may not bypass Twin, Governance, or Triage.\n\nFrontend implication: Agent surfaces must always show Twin as the supervisor. Execution histories and outcomes are surfaced under Twin review, not as standalone agent control panels.\n\n---\n\n## 8. Memory Mapping\n\nTwin reads permission-filtered memory projections.\n\n| Memory Scope          | Frontend Exposure                 | Twin Use                             | Backend Dependency                    |\n| --------------------- | --------------------------------- | ------------------------------------ | ------------------------------------- |\n| Personal Memory       | Memory surface, Twin context      | User preferences and private context | `continuity`                          |\n| User Work Memory      | Role and assignment context       | Work context                         | `continuity`, `knowledge`             |\n| Work Memory           | Account/project/task history      | Operational context                  | `spine`, `continuity`                 |\n| Organization Memory   | Approved institutional knowledge  | Reference context                    | `knowledge`, `pipeline`               |\n| Agent Working Memory  | Active delegated execution state  | Execution context                    | `iw-agent-runtime`, `task-management` |\n| Agent Episodic Memory | Previous run outcomes             | Outcome review                       | `continuity`, `task-management`       |\n| Candidate Memory      | Unapproved material, triage queue | Review and promotion recommendation  | `continuity`, `govern`                |\n\nPromotion path:\n\n```text\nTwin insight\n  ↓\nMemory candidate\n  ↓\nTriage\n  ↓\nGovernance\n  ↓\nApproved memory\n```\n\nFrontend implication:\n\n- Twin surfaces read memory projections.\n- Triage surfaces review candidates.\n- Promotion is always backend-governed.\n\n---\n\n## 9. Triage Mapping\n\n| Frontend Section | Triage Responsibility                             | Backend Dependency                 |\n| ---------------- | ------------------------------------------------- | ---------------------------------- |\n| Memory triage    | Candidate review, contradiction review, promotion | `continuity`, `govern`, `pipeline` |\n| Knowledge triage | Extraction feedback, document review, promotion   | `knowledge`, `pipeline`            |\n| Outcome triage   | Execution outcomes, learning candidates           | `hermes`, `pipeline`, `spine`      |\n\nTriage rule:\n\n- Only triage and governance may promote material into canonical Spine.\n- Twin may recommend promotion only.\n\nFrontend implication: Triage surfaces must be review-only for Twin. Submission paths are governed and approval-gated.\n\n---\n\n## 10. Continuity Mapping\n\nUser-facing continuity language:\n\n- Twin is continuing this work\n- Twin is waiting for approval\n- Twin will resume after dependency completes\n- Twin retried the failed action\n- Twin completed the delegated workflow\n- Twin needs your decision\n\nInternal continuity language:\n\n- Workflow runtime\n- Continuation service\n- Scheduler\n- Queue\n- Durable checkpoint\n- Orchestration engine\n\n| Frontend Section   | Continuity Responsibility                      | Backend Dependency                          |\n| ------------------ | ---------------------------------------------- | ------------------------------------------- |\n| Continuity surface | Workflow status, retry, resume, completion     | `workflow`, `task-management`, `continuity` |\n| Twin continuity    | Twin-reported durable execution state          | `hermes`, `workflow`                        |\n| Agent continuity   | Agent pause/resume, checkpoint, outcome return | `iw-agent-runtime`, `task-management`       |\n\nFrontend implication: Continuity is presented as a Twin state, not as raw infrastructure. The frontend never exposes queue names, durable object identities, or internal scheduler state.\n\n---\n\n## 11. Capabilities Mapping\n\nTwin is the primary capability consumer.\n\n| Frontend Section            | Capability Responsibility                  | Backend Dependency                               |\n| --------------------------- | ------------------------------------------ | ------------------------------------------------ |\n| Capabilities surface        | Discovery, execution, approval visibility  | `mcp-pool`, `integration-management-mcp`         |\n| Twin capability use         | Resolve, invoke, monitor, summarize        | `mcp-pool`, `govern`, `hermes`                   |\n| Agent capability assignment | Scoped capability assignment and execution | `agent-registry`, `iw-agent-runtime`, `mcp-pool` |\n\nCapability Registry exposes:\n\n- Capability identity\n- Purpose\n- Inputs/outputs\n- Required scopes\n- Compatible agents\n- Execution target\n- Risk classification\n- Approval requirements\n- Audit requirements\n\nFrontend implication: Capabilities are surfaced as governed actions. Discovery is permission-scoped. Execution requires approval flow where policy demands.\n\n---\n\n## 12. Spine Network Mapping\n\n| Frontend Section        | Spine Network Responsibility                         | Backend Dependency                    |\n| ----------------------- | ---------------------------------------------------- | ------------------------------------- |\n| Workbench projections   | Governed read models, Entity 360, timeline, search   | `spine`, `projection-engine`, `store` |\n| Twin context            | Permission-filtered memory and knowledge projections | `spine`, `continuity`, `knowledge`    |\n| Governance and approval | Proposal and approval artifacts, evidence            | `govern`, `spine`, `workflow`         |\n| Admin and configuration | Tenant config, schema config, connection config      | `tenants`, `pipeline`, `spine`        |\n\nSpine invariants:\n\n- No browser component, Twin runtime, MCP tool, connector, or projection component writes Neon directly.\n- Pipeline promotion is the sole canonical Spine writer.\n- D1/KV are operational caches only; Neon/R2 are canonical.\n\nFrontend implication: Every read path goes through Gateway and Projection Engine. Direct Spine schema access is forbidden from the browser surface.\n\n---\n\n## 13. MCP Pool and Integration Mapping\n\nPublic MCP is the 19-tool Spine contract only. Broader MCP Pool and capability registries remain internal.\n\n| Frontend Function    | Public/Internal         | Backend Service                                          |\n| -------------------- | ----------------------- | -------------------------------------------------------- |\n| Twin Ask             | Public                  | `mcp-connector`                                          |\n| Twin Act             | Public via Twin surface | `mcp-connector`, `govern`, `hermes`                      |\n| Knowledge retrieval  | Public                  | `mcp-connector`                                          |\n| Memory retrieval     | Public                  | `mcp-connector`                                          |\n| Capability execution | Internal                | `mcp-pool`, `integration-management-mcp`                 |\n| Provider invocation  | Internal                | `provider-management-mcp`, `connector`, `connector-sync` |\n\nFrontend implication:\n\n- The browser never chooses MCP transport.\n- The browser never sees provider credential state.\n- The browser never calls provider APIs directly after approval.\n\n---\n\n## 14. Activation and Connector Mapping\n\n| Frontend Section      | Activation Responsibility                    | Backend Dependency                                                   |\n| --------------------- | -------------------------------------------- | -------------------------------------------------------------------- |\n| Onboarding activation | Intent, domain, identity, initial connection | `gateway`, `tenants`, `pipeline`, `spine`                            |\n| Connector setup       | OAuth, scopes, health, sync schedule         | `connector`, `integration-management-mcp`, `provider-management-mcp` |\n| Marketplaces          | Discovery of available apps/connectors       | `integration-management-mcp`, `mcp-pool`                             |\n\nFrontend implication:\n\n- Onboarding collects intent and domain only.\n- Connector setup results in governed connection state, not raw credentials.\n- Integration management is exposed through approved capability surfaces.\n\n---\n\n## 15. Existing UI Component and Route Mapping\n\n### 15.1 Routes and Shells\n\n| Frontend Path/Surface    | Existing File                                      | v0 Purpose                                  |\n| ------------------------ | -------------------------------------------------- | ------------------------------------------- |\n| `/`                      | `apps/web/src/app/page.tsx`                        | Marketing home                              |\n| `/app`                   | `apps/web/src/app/app/[...segments]/page.tsx`      | Authenticated app shell                     |\n| `/app/admin`             | `apps/web/src/app/admin/page.tsx`                  | Admin surface                               |\n| `/app/administration`    | `apps/web/src/app/administration/page.tsx`         | Administration workbench                    |\n| `/app/governance`        | `apps/web/src/app/governance/page.tsx`             | Governance queue                            |\n| `/app/knowledge`         | `apps/web/src/app/knowledge/page.tsx`              | Knowledge surface                           |\n| `/app/marketplace`       | `apps/web/src/app/marketplace/page.tsx`            | Marketplace entry                           |\n| `/app/onboarding`        | `apps/web/src/app/onboarding/page.tsx`             | Onboarding flow                             |\n| `/app/settings`          | `apps/web/src/app/settings/page.tsx`               | Settings surface                            |\n| `/workbench/:department` | `apps/web/src/app/workbench/[department]/page.tsx` | Role-aware workbench                        |\n| `/workspace/:department` | `apps/web/src/app/workspace/[department]/page.tsx` | Workspace domain view                       |\n| `/domains`               | `apps/web/src/app/domains/page.tsx`                | Domain routing shell                        |\n| Auth entry/callback      | `apps/web/src/components/core/auth/*`              | Clerk/Descope auth entry and callback       |\n| Layout/shell             | `apps/web/src/AppShell.tsx`                        | Authenticated layout, stage flow, providers |\n| Route rendering          | `apps/web/src/app/_components/route-views.tsx`     | Dynamic route mounts                        |\n| Workbench routing config | `apps/web/src/app/_lib/workbench-routes.ts`        | Department/module routing manifest          |\n\n### 15.2 Workbench UI Components\n\n| Existing Component/View                        | v0 Workbench Section    | Mapping                                     |\n| ---------------------------------------------- | ----------------------- | ------------------------------------------- |\n| `packages/ui/src/views/home-view.tsx`          | Workbench Home          | Twin primary surface + workspace projection |\n| `packages/ui/src/views/tasks-view.tsx`         | Tasks                   | Task runtime + continuity state             |\n| `packages/ui/src/views/knowledge-view.tsx`     | Knowledge               | Knowledge service + AI search               |\n| `packages/ui/src/views/clients-view.tsx`       | Accounts                | Entity 360 + spine projection               |\n| `packages/ui/src/views/deals-view.tsx`         | Opportunities           | Entity 360 + spine projection               |\n| `packages/ui/src/views/projects-view.tsx`      | Projects                | Entity 360 + task runtime                   |\n| `packages/ui/src/views/settings-view.tsx`      | Settings                | Admin/tenant configuration                  |\n| `packages/ui/src/views/governance-view.tsx`    | Governance              | Approval queue, policy evidence             |\n| `packages/ui/src/views/integrations-view.tsx`  | Integrations            | Integration Manager + MCP Pool              |\n| `packages/ui/src/views/insights-view.tsx`      | Intelligence            | Signal Engine + projections                 |\n| `packages/ui/src/views/brainstorming-view.tsx` | Twin drafting           | Memory + knowledge + triage candidates      |\n| `packages/ui/src/views/iq-hub-view.tsx`        | Intelligence hub        | AI search + reasoning + recommendations     |\n| `packages/ui/src/views/sessions-view.tsx`      | Twin session/continuity | Continuity + memory + execution history     |\n\n### 15.3 Twin and Cognitive Surfaces\n\nExisting views that map to Twin roles:\n\n- `brainstorming-view.tsx` → Twin draft/review\n- `iq-hub-view.tsx` → Intelligence hub\n- `sessions-view.tsx` → Twin session/continuity\n\nDefinitive v0 addition needed:\n\n- A dedicated Twin sidebar/panel in `AppShell.tsx` that exposes Ask, Analyze, Explain, Recommend, Plan, Delegate, Act, Continue, Review, Remember.\n- The sidebar receives current user, tenant, workspace, selected entity, task, document, conversation, active section, available capabilities, relevant memory, and pending approvals.\n\n---\n\n## 16. One-to-One Mapping: Frontend Function ↔ Backend Service\n\n| #   | Frontend Function    | Backend Service                                         | API/Contract                                   |\n| --- | -------------------- | ------------------------------------------------------- | ---------------------------------------------- |\n| 1   | Marketing pages      | `gateway`, `tenants`                                    | Public routes, onboarding discovery            |\n| 2   | Authentication       | `gateway`, `tenants`                                    | Clerk JWT validation, tenant resolution        |\n| 3   | Onboarding           | `gateway`, `tenants`, `pipeline`                        | `/api/v1/workspace/profile`, activation routes |\n| 4   | Domain routing       | `gateway`, `spine`                                      | Projection Engine responses                    |\n| 5   | Workbench home       | `spine`, `projection-engine`, `store`                   | `SharedWorkbench` contracts                    |\n| 6   | Tasks                | `task-management`, `workflow`, `gateway`                | Task/projection APIs                           |\n| 7   | Knowledge search     | `knowledge`, `mcp-connector`                            | Public Spine MCP `get_relevant_knowledge`      |\n| 8   | Memory triage        | `continuity`, `govern`, `pipeline`                      | Memory candidate → promotion contracts         |\n| 9   | Twin ask             | `intelligence`, `hermes`, `mcp-connector`               | `ask_twin`, context assembly                   |\n| 10  | Twin delegate        | `iw-agent-runtime`, `hermes`, `task-management`         | Agent task creation and monitoring             |\n| 11  | Twin act             | `govern`, `hermes`, `mcp-pool`                          | `prepare_action`, `approve_action`, execution  |\n| 12  | Governance approvals | `govern`, `workflow`, `task-management`                 | Approval/proposal APIs                         |\n| 13  | Capabilities browse  | `mcp-pool`, `integration-management-mcp`                | Capability registry/resolver                   |\n| 14  | Continuity status    | `workflow`, `task-management`, `continuity`             | Workflow/continuity APIs                       |\n| 15  | Admin users/roles    | `admin`, `tenants`, `gateway`                           | Admin API                                      |\n| 16  | Admin integrations   | `provider-management-mcp`, `integration-management-mcp` | Connection/registry APIs                       |\n| 17  | Webhook ingestion    | `webhook-ingress`, `gateway`                            | Webhook routes, signature verification         |\n| 18  | Entity 360           | `spine`, `projection-engine`, `store`                   | Entity projections, memory, tasks              |\n| 19  | Signal/telemetry     | `signals`, `telemetry`                                  | Signal streams, telemetry APIs                 |\n| 20  | MCP discovery        | `mcp-connector`                                         | Public 19-tool Spine MCP                       |\n\n---\n\n## 17. Cross-Mapping: Twin + Memory + Agents + Continuity + Capabilities\n\n| #   | Frontend Event          | Twin Action                  | Agent Action  | Memory Action          | Continuity Action      | Capability Action       | Backend Service Path                            |\n| --- | ----------------------- | ---------------------------- | ------------- | ---------------------- | ---------------------- | ----------------------- | ----------------------------------------------- |\n| 1   | User asks question      | Retrieve context, explain    | None          | Read permitted memory  | None                   | None                    | `mcp-connector` → `intelligence` → `continuity` |\n| 2   | Twin recommends action  | Build proposal               | None          | None                   | None                   | Resolve capability      | `intelligence` → `mcp-pool`                     |\n| 3   | User approves proposal  | Summarize decision           | None          | None                   | Schedule execution     | Invoke capability       | `govern` → `hermes` → `workflow`                |\n| 4   | Twin delegates to agent | Select agent, assign context | Execute task  | Read working memory    | Checkpoint/resume      | Assign capability       | `iw-agent-runtime` → `task-management`          |\n| 5   | Agent returns result    | Summarize outcome            | Return result | Write episodic memory  | Update execution state | None                    | `intelligence` → `continuity` → `spine`         |\n| 6   | Triage review           | Recommend promotion          | None          | Promote candidate      | None                   | None                    | `continuity` → `govern` → `pipeline`            |\n| 7   | Continuity retry        | Notify user                  | None          | None                   | Retry/backoff          | None                    | `workflow` → `continuity` → `hermes`            |\n| 8   | Cancel execution        | Explain cancellation         | Pause/stop    | Archive working memory | Cancel workflow        | Revoke capability token | `task-management` → `workflow` → `govern`       |\n| 9   | Memory contradiction    | Explain conflict             | None          | Surface contradiction  | None                   | None                    | `continuity` → `knowledge` → `spine`            |\n| 10  | Knowledge promotion     | Recommend promotion          | None          | None                   | None                   | None                    | `knowledge` → `pipeline` → `spine`              |\n\n---\n\n## 18. Cross-Mapping: Frontend Section ↔ Backend Service ↔ UI Component\n\n| #   | Frontend Section | UI Components/Routes                                         | Backend Services                                                                         |\n| --- | ---------------- | ------------------------------------------------------------ | ---------------------------------------------------------------------------------------- |\n| 1   | Home/Workbench   | `home-view.tsx`, `tasks-view.tsx`, `AppShell.tsx`            | `spine`, `projection-engine`, `task-management`, `store`, `gateway`                      |\n| 2   | Knowledge        | `knowledge-view.tsx`, `/knowledge` route                     | `knowledge`, `pipeline`, `mcp-connector`                                                 |\n| 3   | Memory           | `brainstorming-view.tsx`, memory triage UI                   | `continuity`, `govern`, `pipeline`                                                       |\n| 4   | Governance       | `governance-view.tsx`, `/governance` route                   | `govern`, `workflow`, `task-management`                                                  |\n| 5   | Integrations     | `integrations-view.tsx`                                      | `integration-management-mcp`, `provider-management-mcp`, `connector`                     |\n| 6   | Agents           | Agent task panel, execution history, `iq-hub-view.tsx`       | `iw-agent-runtime`, `intelligence`, `task-management`                                    |\n| 7   | Capabilities     | Capability browser, action plan, approval flow               | `mcp-pool`, `govern`, `hermes`                                                           |\n| 8   | Continuity       | Workflow status, retry/escalation panel, `sessions-view.tsx` | `workflow`, `continuity`, `hermes`                                                       |\n| 9   | Admin            | `admin/page.tsx`, `/administration`                          | `admin`, `tenants`, `gateway`                                                            |\n| 10  | Marketing        | Marketing shell, platform, pricing, solutions                | `gateway`, `tenants`, `mcp-connector`                                                    |\n| 11  | Twin panel       | Twin sidebar in `AppShell.tsx`                               | `intelligence`, `hermes`, `iw-agent-runtime`, `mcp-connector`, `knowledge`, `continuity` |\n| 12  | Entity 360       | Entity detail views, Entity 360 panels                       | `spine`, `projection-engine`, `store`                                                    |\n\n---\n\n## 19. Interaction Flow by Day\n\n| Day | User Journey                       | Frontend Section       | Backend Services Involved                                                   |\n| --- | ---------------------------------- | ---------------------- | --------------------------------------------------------------------------- |\n| 0   | Discovers platform, signs up       | Marketing / Auth       | `gateway`, `tenants`                                                        |\n| 0   | Onboards domain and connectors     | Onboarding             | `gateway`, `tenants`, `pipeline`, `spine`, `connector`                      |\n| 1   | Enters workbench, sees projections | Workbench shell / Home | `spine`, `projection-engine`, `store`, `gateway`                            |\n| 1   | Asks Twin for context              | Twin sidebar           | `mcp-connector`, `intelligence`, `continuity`, `knowledge`                  |\n| 2   | Reviews memory and knowledge       | Knowledge / Memory     | `knowledge`, `continuity`, `spine`                                          |\n| 2   | Approves proposed actions          | Governance             | `govern`, `workflow`, `task-management`                                     |\n| 3   | Assigns delegated work to agent    | Agents / Twin          | `iw-agent-runtime`, `agent-registry`, `task-management`                     |\n| 3   | Monitors continuity and outcomes   | Continuity / Twin      | `workflow`, `continuity`, `hermes`, `signals`                               |\n| 4   | Reviews triage candidates          | Memory / Governance    | `continuity`, `govern`, `pipeline`                                          |\n| 4   | Uses discovered capabilities       | Capabilities           | `mcp-pool`, `integration-management-mcp`, `govern`                          |\n| 5   | Configures integrations and admin  | Admin / Integrations   | `admin`, `tenants`, `provider-management-mcp`, `integration-management-mcp` |\n\n---\n\n## 20. v0 Build Order\n\n1. Twin sidebar/panel in `AppShell.tsx`\n2. Twin Workbench core routes and projections\n3. Memory triage surface\n4. Governance approval queue surface\n5. Agent task and execution surface\n6. Continuity status surface\n7. Capability discovery and execution surface\n8. Knowledge surface alignment\n9. Admin surface alignment\n10. Marketing-to-onboarding handoff alignment\n\n---\n\n## 21. Stop-Ship Invariants for v0\n\n- Frontend must not invoke provider APIs directly after approval; Hermes coordinates approved external execution.\n- Frontend must not write canonical Spine state directly.\n- D1/KV are operational caches only; they must not be described or used as canonical business truth.\n- Public MCP remains the 19-tool Spine contract only; broader MCP Pool and capability registries remain internal.\n- Twin is the canonical cognitive and interaction layer; continuity runtime is internal durable execution.\n- Agents are delegated specialists only; they may not read canonical Spine, write canonical state, promote memory, or approve their own actions.\n- Failed live projections must not silently become demo seed data.\n- L1/L2/L4/L7 must not appear as user-facing product navigation.\n- Legacy runtime aliases must not be introduced as new canonical frontend dependencies.\n"}