{"slug":"architecture/CONSOLIDATED_PRODUCT_PLATFORM_CONTRACT_v1.2","title":"IntegrateWise Consolidated Product–Platform Contract v1.2","section":"architecture","sectionLabel":"Architecture","status":"superseded","type":"document","path":"architecture/CONSOLIDATED_PRODUCT_PLATFORM_CONTRACT_v1.2.mdx","bytes":48146,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\n**Status:** SUPERSEDED — absorbed into INTEGRATEWISE_ARCHITECTURE.md v2.1. Historical reference only.\n\n**Date:** 2026-07-28\n\n**Purpose:** Reconcile the complete Product, Platform, Spine Network,\nmarketplace, Workbench, projection, frontend/API, connector, runtime and\nenvironment decisions into one executable contract.\n\nThis revision also resolves the final open questions from the conversation:\nthe three-environment split, platform-repo responsibility, marketplace\npublication names, frontend discovery, and the exact “what gets published\nwhere” rule for Vercel and the other channels.\n\n## 1. Authority and status language\n\nThis document does not introduce a second architecture. Authority remains:\n\n1. `AGENTS.md`\n2. `ARCHITECTURE_LOCK.md`\n3. `IMPLEMENTATION_CONTRACT_v1.1.md`\n4. `FOUR_BUTTONS.md` and `TWIN_BEHAVIOR.md`\n5. This consolidated derived implementation standard\n\nEvery claim uses one of three states:\n\n| State             | Meaning                                                                       |\n| ----------------- | ----------------------------------------------------------------------------- |\n| **Defined**       | The required contract is decided.                                             |\n| **Implemented**   | Repository code or migration evidence exists.                                 |\n| **Live verified** | The intended environment has passed the required runtime and isolation tests. |\n\nCode presence is not live proof. Documentation is not migration evidence.\n\n## 2. Product and naming lock\n\n```text\nIntegrateWise                       = company and product brand\nIntegrateWise Workbench             = the user’s single operational surface\nWorkspace                           = the tenant/user operating environment that hosts a Workbench\nIW-Spine-Network                    = the public distribution identity\nIW-Spine-Network Plugin             = plugin-directory package with MCP app UI and skills\nIW-Spine-Network MCP                = MCP-marketplace package and remote server\nIW Spine Tools                      = the public OAuth-protected 19-tool MCP interface\nAdaptive Spine                      = the canonical operating model and truth substrate\nContinuity                          = a Workbench module and product outcome\nIW Continuity Bridge                = retired public name; internal compatibility only\n```\n\nCanonical Spine is the governed truth substrate. Ops Spine is the operational\nprojection of that truth for day-to-day work, docs, canvases, queues, approvals\nand organizational memory. IntegrateWise Spine is the full contract that joins\ncanonical truth, operational projections, projection engine, governance and\ncontinuity.\n\nThe positioning sentence is:\n\n> **IntegrateWise Workbench runs on IW-Spine-Network.**\n\nThe distribution name is **IW-Spine-Network** and its technical identifier is\n`iw-spine-network`. Plugin marketplaces publish the **IW-Spine-Network\nPlugin**. MCP marketplaces publish **IW-Spine-Network MCP**. “IW Spine Tools”\ndescribes the exact 19-tool MCP interface shared by both artifacts.\n\nThe Product remains three concepts only: Onboarding, the User Workbench and the\nSilent Twin. The Twin is a contextual Workbench capability, not a permanent\npanel or sidebar destination. The Four Buttons remain the only OODA control\ngrammar.\n\n## 3. Three environments and three delivery directions\n\n| Environment             | Purpose                                                                       | Isolation                                                                                                                                        |\n| ----------------------- | ----------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ |\n| **Development**         | Product engineering, local/preview apps, CI and disposable integration tests. | Synthetic data, development Clerk/OAuth apps, development Gateway, Neon, D1/KV/R2/queues and secrets only.                                       |\n| **Customer Zero**       | IntegrateWise operating IntegrateWise as its first real customer.             | Production-grade but isolated tenant, credentials, MCP Pool, queues, evidence, audit and database/runtime bindings. Never a general test tenant. |\n| **Customer Production** | External customers operating their own Workbenches.                           | Tenant-scoped identity, connections, Spine entities, evidence, projections and actions; no access to Development or Customer Zero.               |\n\nPromotion is one-way:\n\n```text\nDevelopment proof\n→ Customer Zero validation\n→ Customer Production release\n```\n\nEvery connector, capability, MCP surface and UI feature must be completed in\nthree directions:\n\n1. **Development readiness:** build, schema, contracts, test provider and tests.\n2. **Platform release readiness:** deploy, observe, secure, version and rollback.\n3. **Customer activation readiness:** discover, consent, bind tenant, map schema,\n   hydrate, project, govern, monitor and revoke.\n\nProduction data, credentials and connector bindings never flow back to\nDevelopment. Customer Zero infrastructure remains separate from Customer\nProduction infrastructure. A marketplace application may be shared, but every\ninstallation resolves to exactly one authorised environment, tenant and\nworkspace.\n\nShared stateless Cloudflare Platform Workers are the default compute model.\nWorkers for Platforms is optional for isolated customer-supplied or\nagent-generated code; it is not a requirement for ordinary tenant-isolated\nGateway, Pipeline, Projection, Governance or Hermes services.\n\n## 4. Deployment and ownership boundary\n\nMultiple Product frontends or full-stack Product apps may run locally or on\nVercel, Netlify or another approved host. They are clients of the matching\nCloudflare Gateway.\n\nThe Platform authority remains Cloudflare-hosted:\n\n```text\nGateway · Configuration · Integration · Activation · Pipeline\nAdaptive Spine · Projection Engine · Governance · Hermes · Sync\nCredential wall · Internal MCP Pool · Evidence and runtime services\n```\n\n| Product owns                                                                                                                             | Platform owns                                                                                                                                                                                  |\n| ---------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Workbench rendering, canvas composition, interaction state, contextual Twin UI, approval UI, onboarding and administration presentation. | Identity resolution, tenant authority, connector catalog and credentials, canonical truth, projections, capability resolution, governance, execution, reconciliation, audit and semantic APIs. |\n\nNo Product deployment becomes a second Fortress, connector runtime, credential\nstore, canonical database, projection authority or provider-execution path.\n\n### Repository responsibility\n\nThe repository split is intentional and must stay clear:\n\n| Repository / surface | Owns                                                                                                                                                                                                                                                                                                             | Does not own                                                                                                                                 |\n| -------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- |\n| **Platform repo**    | Gateway, Configuration Manager, Integration Manager, Activation Hub, Projection Engine, Capability Fabric, Governance, Hermes, Sync, discovery, runtime contracts, connector catalog, credential wall, marketplace publication server, canonical schema, migrations, audit, observability and internal MCP Pool. | Presentation-only UI state, arbitrary browser-side data authority, raw provider credentials in the frontend, or a competing canonical store. |\n| **Product repo**     | Workbench shell, navigation, entity-shaped table/page/canvas rendering from projection contracts, projection consumers, typed Gateway client, onboarding flows, local interaction state, draft operational-memory / agent-memory staging and the user-facing Twin experience.                                    | Canonical truth, secrets, provider transport, connector ownership, or authority to choose tenant/environment/model policy.                   |\n| **Customer Zero**    | A real operating tenant and production-shaped validation environment for IntegrateWise itself.                                                                                                                                                                                                                   | A separate product, a shared test tenant, or a place to hide platform responsibilities.                                                      |\n\nThe practical rule is simple: the Platform repo owns the contracts and the\nauthority path; the Product repo renders and requests those contracts; Customer\nZero proves the same contracts in a real but isolated operating environment.\n\nProduct shells are entity-first, not domain-first. The Product repo renders\ntables and canvases from RBAC-scoped projection contracts. It may stage draft\noperational-memory and agent-memory records locally, but it does not own the\ncanonical persistence path. Promotion into Fortress happens through Triage and\nhuman approval, then the backend writes the governed result.\n\n## 5. Final canonical runtime model\n\nThe source-pack reconciliation freezes the following responsibility chain:\n\n```text\nExternal Ecosystem\n→ One Auth-to-Ecosystem\n→ Integration Manager\n→ Gateway\n→ Loader Runtime\n→ Flow A / Flow B / Flow C / Flow D routing\n→ Deterministic Normalizer / Governed Triage / Binding validation\n→ Governed Spine Writers\n→ Stable Core Spine\n→ Projection Engine\n→ Adaptive User Workbench\n→ Contextual Silent Twin\n→ Capability Fabric\n→ Governance\n→ Hermes\n→ Execution Provider\n→ Provider outcome\n→ Re-ingestion, verification and reconciliation\n→ Core Spine\n→ Projection rehydration\n→ Adaptive User Workbench\n```\n\n### Four input/control flows\n\n| Flow                                      | Owns                                                                                                                                                                                            | Canonical boundary                                                                                   |\n| ----------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- |\n| **Flow A — Structured operational data**  | Entities, typed fields/tuples, relationships, metrics, events, status, ownership and lifecycle state.                                                                                           | Deterministic normalization produces write candidates; governed writers commit them.                 |\n| **Flow B — Documents and communications** | Threads, messages, meetings, calls, documents, attachments, transcripts, chunks, semantic references and evidence links.                                                                        | Raw artifacts remain preserved; extracted meaning retains source lineage.                            |\n| **Flow C — AI and cognitive context**     | Twin/external-AI sessions, model outputs, plans, proposals, tool calls, generated artifacts and candidate memory/knowledge/decisions.                                                           | Triage classifies and proposes promotion. Flow C never directly mutates operational truth.           |\n| **Flow D — Platform binding and control** | Identity, tenant, workspace, membership, role, department, industry, permissions, configuration, connections, credential references, capabilities, policies, entitlements and runtime bindings. | Flow D binds A/B/C to the correct authority context; it is not an arbitrary business-data partition. |\n\nFlow D is distinct from the governed execution loop. An approved effect follows\n`Capability → Governance → Hermes → provider → outcome → re-ingestion →\nreconciliation`; it does not turn external execution into Platform-binding\ndata.\n\n### Normalizer, Triage and write authority\n\nThe Normalizer and Triage are separate:\n\n- **Normalizer** is deterministic: validate, parse, type, map, deduplicate,\n  resolve identity/relationships, construct provenance and prepare a write\n  candidate.\n- **Triage** is adaptive: classify cognitive/unstructured material, bind\n  evidence, estimate materiality/confidence, select a candidate memory or\n  knowledge scope, and route it for review/promotion or rejection.\n- **Loader Runtime** is the sole outer ingress/write controller.\n- **Governed Spine Writers/Pipeline promotion** are the only internal modules\n  that commit persistent canonical truth.\n\nConfidence describes evidence quality. It never creates authority. Twin,\nNormalizer and Triage cannot self-approve or bypass Governance.\n\n### Click, context and Twin behavior\n\nEvery material navigation, view or record interaction may refresh:\n\n- selected entity and permitted relationship slice;\n- visible fields, current filters and objective;\n- linked records, documents, messages, events, signals and commitments;\n- freshness, evidence and connector availability;\n- allowed capabilities and governance posture;\n- current OODA observation state.\n\nThis is **Active Context hydration**, not automatic visible Twin activation.\nThe Twin remains silent and lightweight by default. A normal click does not\nopen a permanent panel, run expensive reasoning or convert navigation into an\nOODA Act. Visible Twin output occurs only when:\n\n1. the user invokes **Ask Your Twin**, **Assign Your Twin** or proposal review;\n2. a material proactive signal passes the Silence Law; or\n3. an existing approved assignment/execution requires monitoring.\n\nThe Four Buttons remain the explicit OODA control grammar. Ordinary Workbench\nnavigation and deterministic CRUD controls remain ordinary product\ninteractions.\n\n### Auto-tuning boundary\n\nAuto-tuning is a bounded internal mechanism assembled from Configuration,\nProjection, Governance, telemetry and runtime policy. It may propose or\nreversibly apply low-risk personal view order, density, prefetch, cache,\nnotification ranking or capability placement changes. It may not silently:\n\n- mutate the Core Spine schema or canonical truth;\n- change permissions, authority or governance thresholds;\n- promote institutional memory;\n- enable a provider or connector scope;\n- modify shared structures without the required approval;\n- remove the stable Workbench taxonomy.\n\nAuto-tuning documents define a target. They are not repository or deployment\nproof.\n\n## 6. Pure entity-based Spine schema\n\nSchemas are entity-based. A persisted record represents a business or Platform\nentity, relationship, event, evidence artifact, policy, capability, execution,\nversioned definition or operational runtime record. A table is never created\nonly because a sidebar label exists.\n\nThere is no canonical `home`, `inbox`, `finance-manager`, `view-1` or\n`view-n` truth table. Those are projections over entities.\n\n### Identity and person distinction\n\n- `spine_users` represents authenticated Product users.\n- Membership resolves a user to organisation, workspace, tenant and role.\n- A business person/contact/stakeholder is a canonical Spine entity with a\n  governed person/contact subtype.\n- Provider identities map to canonical entities through connection-scoped\n  external identities.\n- Tenant scope is mandatory in canonical rows, relationships, events, caches,\n  evidence and runtime operations.\n\n### Storage ownership\n\n| Store                       | Ownership                                                                                                                       |\n| --------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |\n| **Neon Fortress**           | Canonical entities, relationships, lineage, connector metadata, schema mappings, work, governance, audit and promoted outcomes. |\n| **R2**                      | Files, images, audio/video, attachments, raw payloads, exports and immutable evidence bytes.                                    |\n| **Vectorize / AI Search**   | Derived embeddings and retrieval indexes; never truth.                                                                          |\n| **D1**                      | Bounded active context, idempotency, runtime indexes and projection snapshots; reconstructable.                                 |\n| **KV**                      | Short-lived sessions, hot projections, connector state and invalidation; never truth.                                           |\n| **Credential wall / Nango** | Tenant-owned OAuth/API credentials; the Spine stores opaque references only.                                                    |\n\nPipeline promotion through governed writers is the sole canonical commit path.\nBrowser, Twin, connector, public MCP, Normalizer, Triage and Projection Engine\nnever write Neon directly.\n\n## 7. Connector-to-Spine Network contract\n\nThe connector catalog is provider-neutral and globally discoverable. Customers\nchoose tools from the connector tray; IntegrateWise does not force Neon,\nSupabase, a storage provider, model provider or mail agent.\n\n```text\nPublish connector definition\n→ discover/install\n→ resolve identity and tenant\n→ reuse eligible existing connection or request consent\n→ store opaque credential reference\n→ create tenant/workspace connection binding\n→ discover provider objects, fields, events and operations\n→ approve schema/entity/capability mappings\n→ activate initial hydration and delta sync\n→ Pipeline promotes entities, relationships, provenance and evidence\n→ Projection Engine invalidates and recompiles permitted views\n→ monitor, repair, revoke and reconcile\n```\n\nThe operational binding must deterministically resolve:\n\n```text\n(user_id, tenant_account_id, tenant_id, spine_network_id, provider_key,\n provider_workspace_id, connector_binding_id, spine_connection_id,\n schema_binding_set)\n```\n\nStale, ambiguous, revoked or expired bindings fail closed and are removed from\nsync, projections, Twin context, capabilities and execution.\n\n## 8. RBAC projection and Workbench contract\n\nThe schema is entity-based; the experience is projection-based.\n\n```text\nAuthenticated identity\n+ tenant membership\n+ role and permissions\n+ department and industry\n+ tenant policy and entitlement\n+ connector/schema/capability availability\n+ freshness and user preference\n→ Projection Engine\n→ SharedWorkbench\n```\n\nGateway derives authority from Clerk. Browser-provided tenant, user, role or\npermission values are non-authoritative. Projection Engine is the sole composer\nof `SharedWorkbench`.\n\nStorage rule:\n\n- use one shared public schema;\n- keep tenant-owned truth in tenant-scoped rows, not tenant-specific schemas;\n- keep each canonical entity type in its own table;\n- keep each table's own opaque primary key;\n- use `tenant_id`, `tenant_account_id`, `spine_network_id`, `user_id`,\n  `connector_binding_id`, and `spine_connection_id` as stable grouping and\n  lookup keys where connector-bound data is involved;\n- classify every entity through an app-category source, RBAC business domain\n  and lifecycle routing stage; these classifications never create a department\n  storage partition;\n- treat role, department and industry as projection dimensions, not storage\n  partition boundaries;\n- treat `spine_network_id` as the tenant's network root and\n  `spine_connection_id` as the lineage of one provider connection inside that\n  network. The first is required for tenant-level cross-connector grouping; the\n  second is required for connector-specific provenance. They are not\n  interchangeable.\n\nThe detailed Fortress, operational-cache and Flow A-D implementation is\ndefined in `TENANT_SPINE_FORTRESS_OPERATIONAL_FLOW_MODEL.md`.\n\nA frontend surface has one owning projection contract, not one physical table.\nIt may compose multiple entity sources. A view definition stores filters,\ngrouping, columns, layout and capability placement; it does not own the data it\nrenders.\n\n### User-facing SSOT\n\nThe product's center of gravity is **work**, not ontology browsing.\n\nUsers do not arrive to manage raw table families such as `teams`, `projects`,\n`assets`, or `signals` as separate destinations by default. They arrive to run\ntheir work and business.\n\nThe rule is:\n\n```text\nIdentity SSOT\n  = spine_users + spine_memberships\n\nOperational user SSOT\n  = spine_work_items + approvals + decisions + notifications + dependencies\n\nBusiness/context SSOT\n  = typed entity tables + relationships + knowledge + promoted memory + evidence\n\nWorkbench\n  = one RBAC projection over those truths\n```\n\nSo the Workbench should first answer:\n\n- what needs my attention;\n- what is blocked;\n- what is waiting for approval;\n- what changed;\n- what can my Twin help with next; and\n- which records, conversations, documents, and entities explain that work.\n\nEntity families remain essential, but they are supporting truth behind the\nuser's operational experience rather than the primary product noun.\n\n### Shared sidebar taxonomy\n\nThe taxonomy is common. RBAC projection determines which items are present and\nwhether they are read, operate or administer. The Work branch is adaptive.\n\n```text\nIW\n├── Home\n├── My Work\n│   ├── Inbox · Tasks · My Queue · Approvals\n│   └── Notifications · Recent Work · Favorites\n├── Communications\n│   └── Activity Feed · Email · Calendar · Meetings · Chat · Calls\n├── Documents Shared\n├── Personal\n│   └── Notes · Knowledge Base · Brainstorming Sessions\n├── Activity\n├── Finance Manager\n├── Work\n│   └── role × department × industry projected views (View 1 … View N)\n├── Platform\n│   ├── Integration Manager · Connector Marketplace · Activation Hub\n│   ├── Capability Manager · AI Models · Knowledge\n│   ├── Memory & Continuity · Automation · Pipelines\n│   └── Governance · Observability\n└── Administration\n    └── Organizations · Users · Roles · Permissions · Audit · Billing\n        · Deployments · API Keys · Security\n```\n\nThe internal MCP Pool is visible only to authorised Customer Zero/Platform\noperators. External customer and marketplace users receive the public Spine\nNetwork/Spine Tools contract and permitted ADK capabilities, not Pool internals.\n\nChat is a communications or contextual-intake surface. It does not turn Twin\ninto a sidebar destination. Canvas may render safe projection shapes as tables,\ncards, timelines, graphs, images, documents or JSON; it never exposes raw table\nor object-store access.\n\n### Canvases and organizational memory\n\nCanvases are first-class projection surfaces, not decorative wrappers around a\ntable browser. A canvas may compose document-like blocks, linked entity cards,\nembedded tables, decision logs, timelines, policies, KPI strips, source\nreferences and promoted work artifacts, all filtered by RBAC and the active\nprojection contract.\n\nOrganizational memory is a first-class projection family inside the Ops Spine.\nIt behaves like the company wiki / operating handbook surface: the front door\nfor promoted knowledge, operating notes, rituals, decisions, linked subpages\nand canonical references. It is backed by memory, knowledge, documents,\nbrainstorming sessions, events and approved outcomes, but it is still rendered\nas a projection. It does not own a separate truth store.\n\nThe backend mapping rule for canvases and organizational memory is:\n\n```text\ncanonical entities + evidence + promoted memory + linked documents + timeline\n→ Projection Engine\n→ RBAC-scoped canvas / organizational-memory projection\n→ Product renders document-like pages, embedded views and editable blocks\n```\n\n## 9. Frontend-to-Platform communication and discovery\n\nThe browser calls one typed Gateway client using one production variable:\n`NEXT_PUBLIC_IW_API_URL`.\n\n### First canonical read\n\nThe target first read after sign-in or workspace switch is:\n\n```http\nGET /api/v1/workspace/discovery\n```\n\nIt returns a versioned, tenant/RBAC-scoped manifest containing:\n\n- identity, workspace and allowed scope;\n- projected navigation and Work routes;\n- projection IDs and contract versions;\n- connector, schema and sync availability;\n- capability and approval availability;\n- activation/readiness blockers;\n- freshness, partial/degraded state and remediation.\n\nThe route is implemented at Gateway and delegates to the Spine discovery\nhandler. A real-SQL integration test covers response mapping and tenant-scoped\nqueries. Production deployment, negative tenant/RBAC tests and frontend\nacceptance remain required before it is **Live verified**.\n\n### Required response law\n\nEvery semantic response carries contract version, request/trace identifier,\ntenant and permission scope, generated/freshness time, provenance/evidence and\none state: `ready`, `partial`, `degraded` or `pending`. Live failure never\nsilently becomes seed/demo data.\n\n### Endpoint ownership\n\n| Intent                                          | Target Gateway family               | Owner                                             |\n| ----------------------------------------------- | ----------------------------------- | ------------------------------------------------- |\n| Discover Product                                | `/api/v1/workspace/discovery`       | Gateway + Configuration + Activation + Projection |\n| Onboard/configure/activate                      | `/api/v1/workspace/*`               | Configuration + Activation                        |\n| Browse/connect/sync/revoke connectors           | `/api/v1/connectors/*`              | Integration Manager                               |\n| Compose Workbench, Inbox, Entity 360 and canvas | `/api/v1/projections/*`             | Projection Engine                                 |\n| Read knowledge/evidence                         | `/api/v1/knowledge/*`               | Knowledge and evidence services                   |\n| Ask/assign Twin                                 | semantic Twin routes / public tools | Twin runtime; drafts only                         |\n| Approve/reject/execute                          | governance command routes           | Governance → Hermes                               |\n| Platform/Administration views                   | versioned module routes             | Owning Platform service                           |\n\nNo browser call goes directly to Neon, D1, KV, R2, Nango, a provider, Hermes or\nthe internal MCP Pool.\n\n## 10. Runtime substrate and reliability\n\nAll ingress—webhook, polling, streaming, API, MCP, user or agent—normalises to a\ntenant-scoped event envelope with event/version, trace, correlation, causation,\nidempotency, subject, source and provenance.\n\n```text\nValidate → archive raw evidence → publish immutable event\n→ queue/stream → process → resolve capability → govern → Hermes\n→ provider outcome → re-ingest → verify → reconcile\n→ Pipeline promotion → projection invalidation\n```\n\nMandatory base guarantees are Event Bus/PubSub, queues, streams when required,\nidempotency/deduplication, discovery, capability matrix, webhook and polling\nsecurity, retry/replay, sync/reconciliation, structured logging, end-to-end\ntraceability, observability/SLOs, bounded cache and R2 evidence storage.\n\n“Until successful” is policy-bounded retry. Ambiguous remote outcomes must be\nqueried and reconciled before repeating a mutation. Exhausted work goes to dead\nletter and governed reprocessing; it is never blindly replayed.\n\nOperational aging is independent from canonical promotion. D1/KV expiry removes\nor rebuilds bounded state; it does not grant truth authority. Neon retention,\nR2 lifecycle/storage-class transition, evidence locks, deletion, export,\nresidency and legal hold are tenant/record-class policies. The detailed rule is\nin `TENANT_SPINE_FORTRESS_OPERATIONAL_FLOW_MODEL.md`.\n\n## 11. Public Spine Network and marketplace publication\n\nThe public distribution identity is **IW-Spine-Network**, published through two\ndistinct lanes:\n\n| Channel                                                                   | Published item                                                                                                                             | Purpose                                                                                                                     |\n| ------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------- |\n| Plugin marketplaces/directories, including ChatGPT/Codex-compatible hosts | **IW-Spine-Network Plugin**: MCP-backed app, focused interactive UI resources, workflow skills and optional templates                      | Installs an embedded IW control surface inside the AI host. The host controls conversation and declared tool orchestration. |\n| MCP marketplaces/registries/directories                                   | **IW-Spine-Network MCP**: remote server, exact 19-tool IW Spine Tools manifest, optional MCP App UI resources and browser Workbench launch | Connects any compatible MCP client and provides the standalone browser-based Workbench.                                     |\n| Vercel and tool/developer marketplaces                                    | Channel-native IW package plus inbound provider connector when required                                                                    | Connects host resources/events into the same governed tenant Spine Network.                                                 |\n| GitHub / Notion / Coda and provider marketplaces                          | Provider-native app only when provider OAuth, installation, webhook or sync semantics require it                                           | Adds that provider as an explicit tenant connection; never creates another Platform.                                        |\n\nThe public MCP exposes exactly the frozen 19 semantic tools. Provider tools,\nraw tables, credentials, transport operations, agent handoff and MCP Pool\ninternals remain private.\n\nUI resources are additive to the 19 tools. Hosts without MCP App UI support\nreceive meaningful text/JSON results and may launch the browser Workbench.\n\nInstalling the Plugin or MCP does not clone Customer Zero. Activation creates or\nresolves an isolated customer tenant and applies the Customer Zero-proven\nreference configuration/runtime profile. Customer Zero data, credentials,\nmemory, cache, queues and audit never cross that boundary.\n\nAn AI host may compose IW-Spine-Network with other apps it has explicitly\nenabled, but IW does not inherit their credentials or automatically enumerate\nthem. A host app becomes part of persistent Spine Network discovery only through\nexplicit host delegation or a direct IW connector binding.\n\nFor Vercel, the package requires the listing, native MCP-enabled integration,\nCloudflare-hosted integration server, sign-in/tenant selection and consent,\ninstallation/configuration routes, verified lifecycle webhooks, and the inbound\nVercel connector. Other connectors remain in the IntegrateWise tray; they are\nnot individually republished inside Vercel.\n\nThe exact public MCP transport URL must be verified from the deployed protected\nresource before submission. Current service code supports the root protected\nresource, while older documents still cite `/v1/mcp`; no marketplace manifest\nmay be submitted using an unverified historical path.\n\n### Publication matrix by channel\n\nWhen the conversation says “publish it in Vercel,” “publish it in ChatGPT,” or\n“publish it in GitHub/Notion/Coda,” the thing being published is not a different\nbackend. It is a channel-specific package that binds to the same public Spine\nNetwork contract.\n\n| Channel family                                | Publish                                                                                                                                | Notes                                                                                                   |\n| --------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- |\n| **Plugin Directory / AI plugin marketplaces** | `IW-Spine-Network Plugin` with MCP-backed app UI, skills and optional templates                                                        | Embedded host experience; Customer Zero reference profile instantiated for an isolated customer tenant. |\n| **MCP Marketplace / registries**              | `IW-Spine-Network MCP` with exact 19-tool `IW Spine Tools`, optional focused widgets and browser Workbench launch                      | Standalone remote MCP and browser software; not dependent on ChatGPT.                                   |\n| **Vercel**                                    | `IW-Spine-Network` marketplace listing, native MCP product, Vercel connector, installation/configuration routes and lifecycle webhooks | Vercel agents use governed IW capabilities; Vercel data enters through the inbound connector.           |\n| **GitHub / Notion / Coda**                    | Channel-specific app/integration/connector package                                                                                     | Host-native entry point backed by the same Gateway and Spine Network.                                   |\n| **Internal Customer Zero / Platform ops**     | Internal MCP Pool and Platform control plane                                                                                           | Never publish the Pool as a public customer product.                                                    |\n\nPublication rules:\n\n- Publish **IW-Spine-Network Plugin** in plugin marketplaces/directories.\n- Publish **IW-Spine-Network MCP** in MCP marketplaces/registries.\n- Use **IW Spine Tools** for the exact 19-tool semantic MCP interface behind\n  both artifacts.\n- The embedded app is a sandboxed host UI, not a DOM patch and not a second\n  Platform.\n- The MCP marketplace path provides the full browser Workbench as the\n  standalone control surface.\n- Treat **IW Continuity Bridge** as historical/superseded wording only.\n- Reuse existing tenant connections where policy allows; do not create hidden duplicate connections just because the marketplace channel changed.\n- Publish the channel package, not the raw credentials, raw tables, or internal Platform topology.\n\nThe detailed installation, discovery, duplicate-binding and surface\nresponsibility contract is\n`IW_SPINE_NETWORK_PLUGIN_AND_MCP_MARKETPLACE_CONTRACT.md`.\n\n## 12. Platform coding agent and v0 template\n\nA coding agent may run as an internal governed capability using the Cloudflare\nagent runtime. It may read an approved repository/context, work in an isolated\ndevelopment sandbox, and prepare patches, tests and evidence.\n\nIt may not access production credentials, write canonical Spine truth, bypass\nGovernance, deploy directly or mutate a provider without an approved capability\nplan. Promotion is review → approval → governed GitHub/Hermes action.\n\nA v0-style template may accelerate Workbench presentation and canvas\ncomposition. It does not define Platform schema, connectors, identity,\ngovernance, runtime or storage.\n\nIn plain terms: the coding agent can help build the Product and the Platform,\nbut it remains a governed internal worker. It is never the source of truth, and\nthe v0 template is only a presentation accelerator for the Workbench surface.\n\n## 13. Repository status after full review\n\n| Contract                                               | Repository status                                                                                                                                                                                          | Classification                                                                  |\n| ------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- |\n| Frozen architecture, Four Buttons and product boundary | Present                                                                                                                                                                                                    | **Defined**                                                                     |\n| Projection Engine and projected navigation code        | Present, including role configs and navigation composition                                                                                                                                                 | **Implemented; live acceptance pending**                                        |\n| First-read `/workspace/discovery` endpoint             | Gateway delegates to the Spine discovery handler; real-SQL integration coverage exists                                                                                                                     | **Implemented; deployment, negative isolation and frontend acceptance pending** |\n| One frontend API base URL                              | `NEXT_PUBLIC_IW_API_URL` helper exists, but many paths still use `NEXT_PUBLIC_API_BASE_URL` and localhost fallbacks                                                                                        | **Partially implemented; stop-ship**                                            |\n| Server-authoritative tenant/RBAC projection            | Gateway authenticates Clerk/approved session paths, resolves the profile and injects trusted tenant/user/role headers before projection dispatch; the internal projection module consumes those assertions | **Implemented at Gateway; live RBAC and negative-test evidence pending**        |\n| Canonical Fortress migration                           | Migration 035 declares 114 tables                                                                                                                                                                          | **Implemented as file; not live verified**                                      |\n| Migration 035 execution validity                       | Creates `governance_policies` but seeds `spine_governance_policies`                                                                                                                                        | **Broken until corrected and smoke-tested**                                     |\n| Strict connector and schema binding tuple              | Contract references exist; no runtime migration for `connector_bindings` / `connector_schema_bindings`                                                                                                     | **Defined; missing**                                                            |\n| Vercel catalog connector                               | Present in `catalog.yaml`                                                                                                                                                                                  | **Implemented as catalog definition**                                           |\n| Vercel webhook ingress                                 | `/webhooks/vercel` exists in webhook-ingress                                                                                                                                                               | **Implemented; environment verification pending**                               |\n| Marketplace installation/application API routes        | Gateway delegates marketplace apps/installations to Spine; Product server accessors exist                                                                                                                  | **Implemented contract path; deployed lifecycle verification pending**          |\n| Vercel callback/settings/native marketplace package    | No complete channel-native package and submission evidence found                                                                                                                                           | **Missing**                                                                     |\n| Public 19-tool Spine Tools contract                    | Fixed definitions and OAuth-scope tests exist                                                                                                                                                              | **Implemented; deployment/list verification pending**                           |\n| IW-Spine-Network Plugin app/UI/skills package          | No complete host-submission artifact, embedded widget suite or clean-install evidence established                                                                                                          | **Missing**                                                                     |\n| IW-Spine-Network MCP browser/fallback package          | Public tool contract exists; complete MCP listing, optional UI resources, text/JSON fallback and Open Workbench acceptance are not established                                                             | **Partial**                                                                     |\n| MCP Pool tenant/user filters                           | Registry enforcement and tests exist                                                                                                                                                                       | **Implemented; Customer Zero runtime verification pending**                     |\n| Cloudflare/Neon/R2/D1/KV environment isolation         | Configuration/documentation evidence exists                                                                                                                                                                | **Live verification required**                                                  |\n| Marketplace submissions and production DNS/endpoints   | Not established by repository review                                                                                                                                                                       | **Unverified**                                                                  |\n\nLegacy documentation and code still contain superseded product names, old auth\nclaims, old endpoint paths, user-facing layer language, development fallbacks\nand default-tenant paths outside the fully proven Gateway boundary. They remain\nevidence/history until migrated; they do not override this contract or the\nfrozen authority.\n\n## 14. Required implementation sequence\n\n1. Correct and smoke-test migration 035; decide and implement the strict\n   connector-binding model; apply with a migration ledger.\n2. Make Gateway derive user/tenant/RBAC from Clerk and reject authoritative\n   browser overrides across projection and connector routes.\n3. Complete live deployment, negative tenant/RBAC and frontend acceptance for\n   `/api/v1/workspace/discovery`.\n4. Consolidate frontend calls on `NEXT_PUBLIC_IW_API_URL` and one typed Gateway\n   client; remove production localhost and direct-service fallbacks.\n5. Align projected navigation with the shared taxonomy and RBAC; never expose\n   internal MCP Pool or Twin as general-user destinations.\n6. Complete one connector through consent, strict binding, discovery, schema\n   mapping, hydration, delta sync, revoke and projection invalidation.\n7. Prove event/idempotency/retry/dead-letter/reprocessing/reconciliation and\n   observability guarantees end-to-end.\n8. Validate the full Four-Button governed action loop through Hermes and\n   re-ingested outcome.\n9. Complete the Vercel native integration package and verify the deployed OAuth\n   MCP endpoint before marketplace submission.\n10. Build and verify IW-Spine-Network Plugin embedded UI, host composition,\n    explicit delegation and clean tenant activation.\n11. Build and verify IW-Spine-Network MCP listing, fallback behavior and\n    standalone browser Workbench launch.\n12. Validate Development → Customer Zero → Customer Production promotion with\n    isolated credentials, data, bindings, queues, caches, evidence and audit.\n\n## 15. Testing-environment event gate\n\nDo not begin the integrated testing event until the following evidence exists:\n\n- environment/DNS/identity/Gateway/Neon/R2/D1/KV/queue/secret health;\n- migration ledger and schema verification;\n- cross-tenant and cross-environment negative tests;\n- first-read discovery and every visible sidebar projection contract;\n- one real connector with connection reuse, consent, discovery, mapping, sync,\n  health, revoke and reconciliation;\n- public MCP OAuth and exact 19-tool listing;\n- Plugin embedded UI sandbox/fallback behavior and MCP browser Workbench launch;\n- no automatic inheritance of unrelated host-app credentials;\n- no direct frontend database/provider/internal-MCP traffic;\n- explicit partial/degraded states with no live-to-demo fallback;\n- one proposal → approval token → Hermes action → provider outcome → re-ingest\n  → reconciliation → projection refresh trace;\n- bounded retry, ambiguous-outcome protection, dead letter and governed replay;\n- observability, audit, rollback and revocation evidence.\n\nAny missing item is a testing-event blocker, not a post-launch cleanup task.\n\n## 16. Supporting detailed specifications\n\n- `PRODUCT_PLATFORM_BOUNDARY_AND_GO_LIVE_STANDARD.md`\n- `PLATFORM_PRODUCT_DATA_AND_PROJECTION_REFERENCE.md`\n- `RUNTIME_SUBSTRATE_AND_SURFACE_CONTRACT.md`\n- `TENANT_SPINE_FORTRESS_OPERATIONAL_FLOW_MODEL.md`\n- `FRONTEND_PLATFORM_API_AND_DISCOVERY_SPEC.md`\n- `WORKBENCH_ROLE_CAPABILITY_MAP.md`\n- `SOURCE_PACK_RECONCILIATION_2026-07-28.md`\n- `docs/wiki/07-projection-engine-and-shared-workbench.md`\n- `docs/wiki/12-connectors-integration-manager-and-spine-network.md`\n- `docs/wiki/20-release-readiness-and-verification-evidence.md`\n"}