Superseded

IntegrateWise Consolidated Product–Platform Contract v1.2

Status: SUPERSEDED — absorbed into INTEGRATEWISE_ARCHITECTURE.md v2.1. Historical reference only.

Date: 2026-07-28

Purpose: Reconcile the complete Product, Platform, Spine Network,
marketplace, Workbench, projection, frontend/API, connector, runtime and
environment decisions into one executable contract.

This revision also resolves the final open questions from the conversation:
the three-environment split, platform-repo responsibility, marketplace
publication names, frontend discovery, and the exact “what gets published
where” rule for Vercel and the other channels.

1. Authority and status language

This document does not introduce a second architecture. Authority remains:

AGENTS.md
ARCHITECTURE_LOCK.md
IMPLEMENTATION_CONTRACT_v1.1.md
FOUR_BUTTONS.md and TWIN_BEHAVIOR.md
This consolidated derived implementation standard

Every claim uses one of three states:

State	Meaning
Defined	The required contract is decided.
Implemented	Repository code or migration evidence exists.
Live verified	The intended environment has passed the required runtime and isolation tests.

Code presence is not live proof. Documentation is not migration evidence.

2. Product and naming lock

IntegrateWise                       = company and product brand
IntegrateWise Workbench             = the user’s single operational surface
Workspace                           = the tenant/user operating environment that hosts a Workbench
IW-Spine-Network                    = the public distribution identity
IW-Spine-Network Plugin             = plugin-directory package with MCP app UI and skills
IW-Spine-Network MCP                = MCP-marketplace package and remote server
IW Spine Tools                      = the public OAuth-protected 19-tool MCP interface
Adaptive Spine                      = the canonical operating model and truth substrate
Continuity                          = a Workbench module and product outcome
IW Continuity Bridge                = retired public name; internal compatibility only

Canonical Spine is the governed truth substrate. Ops Spine is the operational
projection of that truth for day-to-day work, docs, canvases, queues, approvals
and organizational memory. IntegrateWise Spine is the full contract that joins
canonical truth, operational projections, projection engine, governance and
continuity.

The positioning sentence is:

IntegrateWise Workbench runs on IW-Spine-Network.

The distribution name is IW-Spine-Network and its technical identifier is
iw-spine-network. Plugin marketplaces publish the IW-Spine-Network
Plugin. MCP marketplaces publish IW-Spine-Network MCP. “IW Spine Tools”
describes the exact 19-tool MCP interface shared by both artifacts.

The Product remains three concepts only: Onboarding, the User Workbench and the
Silent Twin. The Twin is a contextual Workbench capability, not a permanent
panel or sidebar destination. The Four Buttons remain the only OODA control
grammar.

3. Three environments and three delivery directions

Environment	Purpose	Isolation
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.
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.
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.

Promotion is one-way:

Development proof
→ Customer Zero validation
→ Customer Production release

Every connector, capability, MCP surface and UI feature must be completed in
three directions:

Development readiness: build, schema, contracts, test provider and tests.
Platform release readiness: deploy, observe, secure, version and rollback.
Customer activation readiness: discover, consent, bind tenant, map schema,
hydrate, project, govern, monitor and revoke.

Production data, credentials and connector bindings never flow back to
Development. Customer Zero infrastructure remains separate from Customer
Production infrastructure. A marketplace application may be shared, but every
installation resolves to exactly one authorised environment, tenant and
workspace.

Shared stateless Cloudflare Platform Workers are the default compute model.
Workers for Platforms is optional for isolated customer-supplied or
agent-generated code; it is not a requirement for ordinary tenant-isolated
Gateway, Pipeline, Projection, Governance or Hermes services.

4. Deployment and ownership boundary

Multiple Product frontends or full-stack Product apps may run locally or on
Vercel, Netlify or another approved host. They are clients of the matching
Cloudflare Gateway.

The Platform authority remains Cloudflare-hosted:

Gateway · Configuration · Integration · Activation · Pipeline
Adaptive Spine · Projection Engine · Governance · Hermes · Sync
Credential wall · Internal MCP Pool · Evidence and runtime services

Product owns	Platform owns
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.

No Product deployment becomes a second Fortress, connector runtime, credential
store, canonical database, projection authority or provider-execution path.

Repository responsibility

The repository split is intentional and must stay clear:

Repository / surface	Owns	Does not own
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.
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.
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.

The practical rule is simple: the Platform repo owns the contracts and the
authority path; the Product repo renders and requests those contracts; Customer
Zero proves the same contracts in a real but isolated operating environment.

Product shells are entity-first, not domain-first. The Product repo renders
tables and canvases from RBAC-scoped projection contracts. It may stage draft
operational-memory and agent-memory records locally, but it does not own the
canonical persistence path. Promotion into Fortress happens through Triage and
human approval, then the backend writes the governed result.

5. Final canonical runtime model

The source-pack reconciliation freezes the following responsibility chain:

External Ecosystem
→ One Auth-to-Ecosystem
→ Integration Manager
→ Gateway
→ Loader Runtime
→ Flow A / Flow B / Flow C / Flow D routing
→ Deterministic Normalizer / Governed Triage / Binding validation
→ Governed Spine Writers
→ Stable Core Spine
→ Projection Engine
→ Adaptive User Workbench
→ Contextual Silent Twin
→ Capability Fabric
→ Governance
→ Hermes
→ Execution Provider
→ Provider outcome
→ Re-ingestion, verification and reconciliation
→ Core Spine
→ Projection rehydration
→ Adaptive User Workbench

Four input/control flows

Flow	Owns	Canonical boundary
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.
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.
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.
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.

Flow D is distinct from the governed execution loop. An approved effect follows
Capability → Governance → Hermes → provider → outcome → re-ingestion → reconciliation; it does not turn external execution into Platform-binding
data.

Normalizer, Triage and write authority

The Normalizer and Triage are separate:

Normalizer is deterministic: validate, parse, type, map, deduplicate,
resolve identity/relationships, construct provenance and prepare a write
candidate.
Triage is adaptive: classify cognitive/unstructured material, bind
evidence, estimate materiality/confidence, select a candidate memory or
knowledge scope, and route it for review/promotion or rejection.
Loader Runtime is the sole outer ingress/write controller.
Governed Spine Writers/Pipeline promotion are the only internal modules
that commit persistent canonical truth.

Confidence describes evidence quality. It never creates authority. Twin,
Normalizer and Triage cannot self-approve or bypass Governance.

Click, context and Twin behavior

Every material navigation, view or record interaction may refresh:

selected entity and permitted relationship slice;
visible fields, current filters and objective;
linked records, documents, messages, events, signals and commitments;
freshness, evidence and connector availability;
allowed capabilities and governance posture;
current OODA observation state.

This is Active Context hydration, not automatic visible Twin activation.
The Twin remains silent and lightweight by default. A normal click does not
open a permanent panel, run expensive reasoning or convert navigation into an
OODA Act. Visible Twin output occurs only when:

the user invokes Ask Your Twin, Assign Your Twin or proposal review;
a material proactive signal passes the Silence Law; or
an existing approved assignment/execution requires monitoring.

The Four Buttons remain the explicit OODA control grammar. Ordinary Workbench
navigation and deterministic CRUD controls remain ordinary product
interactions.

Auto-tuning boundary

Auto-tuning is a bounded internal mechanism assembled from Configuration,
Projection, Governance, telemetry and runtime policy. It may propose or
reversibly apply low-risk personal view order, density, prefetch, cache,
notification ranking or capability placement changes. It may not silently:

mutate the Core Spine schema or canonical truth;
change permissions, authority or governance thresholds;
promote institutional memory;
enable a provider or connector scope;
modify shared structures without the required approval;
remove the stable Workbench taxonomy.

Auto-tuning documents define a target. They are not repository or deployment
proof.

6. Pure entity-based Spine schema

Schemas are entity-based. A persisted record represents a business or Platform
entity, relationship, event, evidence artifact, policy, capability, execution,
versioned definition or operational runtime record. A table is never created
only because a sidebar label exists.

There is no canonical home, inbox, finance-manager, view-1 or
view-n truth table. Those are projections over entities.

Identity and person distinction

spine_users represents authenticated Product users.
Membership resolves a user to organisation, workspace, tenant and role.
A business person/contact/stakeholder is a canonical Spine entity with a
governed person/contact subtype.
Provider identities map to canonical entities through connection-scoped
external identities.
Tenant scope is mandatory in canonical rows, relationships, events, caches,
evidence and runtime operations.

Storage ownership

Store	Ownership
Neon Fortress	Canonical entities, relationships, lineage, connector metadata, schema mappings, work, governance, audit and promoted outcomes.
R2	Files, images, audio/video, attachments, raw payloads, exports and immutable evidence bytes.
Vectorize / AI Search	Derived embeddings and retrieval indexes; never truth.
D1	Bounded active context, idempotency, runtime indexes and projection snapshots; reconstructable.
KV	Short-lived sessions, hot projections, connector state and invalidation; never truth.
Credential wall / Nango	Tenant-owned OAuth/API credentials; the Spine stores opaque references only.

Pipeline promotion through governed writers is the sole canonical commit path.
Browser, Twin, connector, public MCP, Normalizer, Triage and Projection Engine
never write Neon directly.

7. Connector-to-Spine Network contract

The connector catalog is provider-neutral and globally discoverable. Customers
choose tools from the connector tray; IntegrateWise does not force Neon,
Supabase, a storage provider, model provider or mail agent.

Publish connector definition
→ discover/install
→ resolve identity and tenant
→ reuse eligible existing connection or request consent
→ store opaque credential reference
→ create tenant/workspace connection binding
→ discover provider objects, fields, events and operations
→ approve schema/entity/capability mappings
→ activate initial hydration and delta sync
→ Pipeline promotes entities, relationships, provenance and evidence
→ Projection Engine invalidates and recompiles permitted views
→ monitor, repair, revoke and reconcile

The operational binding must deterministically resolve:

(user_id, tenant_account_id, tenant_id, spine_network_id, provider_key,
 provider_workspace_id, connector_binding_id, spine_connection_id,
 schema_binding_set)

Stale, ambiguous, revoked or expired bindings fail closed and are removed from
sync, projections, Twin context, capabilities and execution.

8. RBAC projection and Workbench contract

The schema is entity-based; the experience is projection-based.

Authenticated identity
+ tenant membership
+ role and permissions
+ department and industry
+ tenant policy and entitlement
+ connector/schema/capability availability
+ freshness and user preference
→ Projection Engine
→ SharedWorkbench

Gateway derives authority from Clerk. Browser-provided tenant, user, role or
permission values are non-authoritative. Projection Engine is the sole composer
of SharedWorkbench.

Storage rule:

use one shared public schema;
keep tenant-owned truth in tenant-scoped rows, not tenant-specific schemas;
keep each canonical entity type in its own table;
keep each table's own opaque primary key;
use tenant_id, tenant_account_id, spine_network_id, user_id,
connector_binding_id, and spine_connection_id as stable grouping and
lookup keys where connector-bound data is involved;
classify every entity through an app-category source, RBAC business domain
and lifecycle routing stage; these classifications never create a department
storage partition;
treat role, department and industry as projection dimensions, not storage
partition boundaries;
treat spine_network_id as the tenant's network root and
spine_connection_id as the lineage of one provider connection inside that
network. The first is required for tenant-level cross-connector grouping; the
second is required for connector-specific provenance. They are not
interchangeable.

The detailed Fortress, operational-cache and Flow A-D implementation is
defined in TENANT_SPINE_FORTRESS_OPERATIONAL_FLOW_MODEL.md.

A frontend surface has one owning projection contract, not one physical table.
It may compose multiple entity sources. A view definition stores filters,
grouping, columns, layout and capability placement; it does not own the data it
renders.

User-facing SSOT

The product's center of gravity is work, not ontology browsing.

Users do not arrive to manage raw table families such as teams, projects,
assets, or signals as separate destinations by default. They arrive to run
their work and business.

The rule is:

Identity SSOT
  = spine_users + spine_memberships

Operational user SSOT
  = spine_work_items + approvals + decisions + notifications + dependencies

Business/context SSOT
  = typed entity tables + relationships + knowledge + promoted memory + evidence

Workbench
  = one RBAC projection over those truths

So the Workbench should first answer:

what needs my attention;
what is blocked;
what is waiting for approval;
what changed;
what can my Twin help with next; and
which records, conversations, documents, and entities explain that work.

Entity families remain essential, but they are supporting truth behind the
user's operational experience rather than the primary product noun.

Shared sidebar taxonomy

The taxonomy is common. RBAC projection determines which items are present and
whether they are read, operate or administer. The Work branch is adaptive.

IW
├── Home
├── My Work
│   ├── Inbox · Tasks · My Queue · Approvals
│   └── Notifications · Recent Work · Favorites
├── Communications
│   └── Activity Feed · Email · Calendar · Meetings · Chat · Calls
├── Documents Shared
├── Personal
│   └── Notes · Knowledge Base · Brainstorming Sessions
├── Activity
├── Finance Manager
├── Work
│   └── role × department × industry projected views (View 1 … View N)
├── Platform
│   ├── Integration Manager · Connector Marketplace · Activation Hub
│   ├── Capability Manager · AI Models · Knowledge
│   ├── Memory & Continuity · Automation · Pipelines
│   └── Governance · Observability
└── Administration
    └── Organizations · Users · Roles · Permissions · Audit · Billing
        · Deployments · API Keys · Security

The internal MCP Pool is visible only to authorised Customer Zero/Platform
operators. External customer and marketplace users receive the public Spine
Network/Spine Tools contract and permitted ADK capabilities, not Pool internals.

Chat is a communications or contextual-intake surface. It does not turn Twin
into a sidebar destination. Canvas may render safe projection shapes as tables,
cards, timelines, graphs, images, documents or JSON; it never exposes raw table
or object-store access.

Canvases and organizational memory

Canvases are first-class projection surfaces, not decorative wrappers around a
table browser. A canvas may compose document-like blocks, linked entity cards,
embedded tables, decision logs, timelines, policies, KPI strips, source
references and promoted work artifacts, all filtered by RBAC and the active
projection contract.

Organizational memory is a first-class projection family inside the Ops Spine.
It behaves like the company wiki / operating handbook surface: the front door
for promoted knowledge, operating notes, rituals, decisions, linked subpages
and canonical references. It is backed by memory, knowledge, documents,
brainstorming sessions, events and approved outcomes, but it is still rendered
as a projection. It does not own a separate truth store.

The backend mapping rule for canvases and organizational memory is:

canonical entities + evidence + promoted memory + linked documents + timeline
→ Projection Engine
→ RBAC-scoped canvas / organizational-memory projection
→ Product renders document-like pages, embedded views and editable blocks

9. Frontend-to-Platform communication and discovery

The browser calls one typed Gateway client using one production variable:
NEXT_PUBLIC_IW_API_URL.

First canonical read

The target first read after sign-in or workspace switch is:

GET /api/v1/workspace/discovery

It returns a versioned, tenant/RBAC-scoped manifest containing:

identity, workspace and allowed scope;
projected navigation and Work routes;
projection IDs and contract versions;
connector, schema and sync availability;
capability and approval availability;
activation/readiness blockers;
freshness, partial/degraded state and remediation.

The route is implemented at Gateway and delegates to the Spine discovery
handler. A real-SQL integration test covers response mapping and tenant-scoped
queries. Production deployment, negative tenant/RBAC tests and frontend
acceptance remain required before it is Live verified.

Required response law

Every semantic response carries contract version, request/trace identifier,
tenant and permission scope, generated/freshness time, provenance/evidence and
one state: ready, partial, degraded or pending. Live failure never
silently becomes seed/demo data.

Endpoint ownership

Intent	Target Gateway family	Owner
Discover Product	`/api/v1/workspace/discovery`	Gateway + Configuration + Activation + Projection
Onboard/configure/activate	`/api/v1/workspace/*`	Configuration + Activation
Browse/connect/sync/revoke connectors	`/api/v1/connectors/*`	Integration Manager
Compose Workbench, Inbox, Entity 360 and canvas	`/api/v1/projections/*`	Projection Engine
Read knowledge/evidence	`/api/v1/knowledge/*`	Knowledge and evidence services
Ask/assign Twin	semantic Twin routes / public tools	Twin runtime; drafts only
Approve/reject/execute	governance command routes	Governance → Hermes
Platform/Administration views	versioned module routes	Owning Platform service

No browser call goes directly to Neon, D1, KV, R2, Nango, a provider, Hermes or
the internal MCP Pool.

10. Runtime substrate and reliability

All ingress—webhook, polling, streaming, API, MCP, user or agent—normalises to a
tenant-scoped event envelope with event/version, trace, correlation, causation,
idempotency, subject, source and provenance.

Validate → archive raw evidence → publish immutable event
→ queue/stream → process → resolve capability → govern → Hermes
→ provider outcome → re-ingest → verify → reconcile
→ Pipeline promotion → projection invalidation

Mandatory base guarantees are Event Bus/PubSub, queues, streams when required,
idempotency/deduplication, discovery, capability matrix, webhook and polling
security, retry/replay, sync/reconciliation, structured logging, end-to-end
traceability, observability/SLOs, bounded cache and R2 evidence storage.

“Until successful” is policy-bounded retry. Ambiguous remote outcomes must be
queried and reconciled before repeating a mutation. Exhausted work goes to dead
letter and governed reprocessing; it is never blindly replayed.

Operational aging is independent from canonical promotion. D1/KV expiry removes
or rebuilds bounded state; it does not grant truth authority. Neon retention,
R2 lifecycle/storage-class transition, evidence locks, deletion, export,
residency and legal hold are tenant/record-class policies. The detailed rule is
in TENANT_SPINE_FORTRESS_OPERATIONAL_FLOW_MODEL.md.

11. Public Spine Network and marketplace publication

The public distribution identity is IW-Spine-Network, published through two
distinct lanes:

Channel	Published item	Purpose
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.
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.
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.
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.

The public MCP exposes exactly the frozen 19 semantic tools. Provider tools,
raw tables, credentials, transport operations, agent handoff and MCP Pool
internals remain private.

UI resources are additive to the 19 tools. Hosts without MCP App UI support
receive meaningful text/JSON results and may launch the browser Workbench.

Installing the Plugin or MCP does not clone Customer Zero. Activation creates or
resolves an isolated customer tenant and applies the Customer Zero-proven
reference configuration/runtime profile. Customer Zero data, credentials,
memory, cache, queues and audit never cross that boundary.

An AI host may compose IW-Spine-Network with other apps it has explicitly
enabled, but IW does not inherit their credentials or automatically enumerate
them. A host app becomes part of persistent Spine Network discovery only through
explicit host delegation or a direct IW connector binding.

For Vercel, the package requires the listing, native MCP-enabled integration,
Cloudflare-hosted integration server, sign-in/tenant selection and consent,
installation/configuration routes, verified lifecycle webhooks, and the inbound
Vercel connector. Other connectors remain in the IntegrateWise tray; they are
not individually republished inside Vercel.

The exact public MCP transport URL must be verified from the deployed protected
resource before submission. Current service code supports the root protected
resource, while older documents still cite /v1/mcp; no marketplace manifest
may be submitted using an unverified historical path.

Publication matrix by channel

When the conversation says “publish it in Vercel,” “publish it in ChatGPT,” or
“publish it in GitHub/Notion/Coda,” the thing being published is not a different
backend. It is a channel-specific package that binds to the same public Spine
Network contract.

Channel family	Publish	Notes
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.
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.
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.
GitHub / Notion / Coda	Channel-specific app/integration/connector package	Host-native entry point backed by the same Gateway and Spine Network.
Internal Customer Zero / Platform ops	Internal MCP Pool and Platform control plane	Never publish the Pool as a public customer product.

Publication rules:

Publish IW-Spine-Network Plugin in plugin marketplaces/directories.
Publish IW-Spine-Network MCP in MCP marketplaces/registries.
Use IW Spine Tools for the exact 19-tool semantic MCP interface behind
both artifacts.
The embedded app is a sandboxed host UI, not a DOM patch and not a second
Platform.
The MCP marketplace path provides the full browser Workbench as the
standalone control surface.
Treat IW Continuity Bridge as historical/superseded wording only.
Reuse existing tenant connections where policy allows; do not create hidden duplicate connections just because the marketplace channel changed.
Publish the channel package, not the raw credentials, raw tables, or internal Platform topology.

The detailed installation, discovery, duplicate-binding and surface
responsibility contract is
IW_SPINE_NETWORK_PLUGIN_AND_MCP_MARKETPLACE_CONTRACT.md.

12. Platform coding agent and v0 template

A coding agent may run as an internal governed capability using the Cloudflare
agent runtime. It may read an approved repository/context, work in an isolated
development sandbox, and prepare patches, tests and evidence.

It may not access production credentials, write canonical Spine truth, bypass
Governance, deploy directly or mutate a provider without an approved capability
plan. Promotion is review → approval → governed GitHub/Hermes action.

A v0-style template may accelerate Workbench presentation and canvas
composition. It does not define Platform schema, connectors, identity,
governance, runtime or storage.

In plain terms: the coding agent can help build the Product and the Platform,
but it remains a governed internal worker. It is never the source of truth, and
the v0 template is only a presentation accelerator for the Workbench surface.

13. Repository status after full review

Contract	Repository status	Classification
Frozen architecture, Four Buttons and product boundary	Present	Defined
Projection Engine and projected navigation code	Present, including role configs and navigation composition	Implemented; live acceptance pending
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
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
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
Canonical Fortress migration	Migration 035 declares 114 tables	Implemented as file; not live verified
Migration 035 execution validity	Creates `governance_policies` but seeds `spine_governance_policies`	Broken until corrected and smoke-tested
Strict connector and schema binding tuple	Contract references exist; no runtime migration for `connector_bindings` / `connector_schema_bindings`	Defined; missing
Vercel catalog connector	Present in `catalog.yaml`	Implemented as catalog definition
Vercel webhook ingress	`/webhooks/vercel` exists in webhook-ingress	Implemented; environment verification pending
Marketplace installation/application API routes	Gateway delegates marketplace apps/installations to Spine; Product server accessors exist	Implemented contract path; deployed lifecycle verification pending
Vercel callback/settings/native marketplace package	No complete channel-native package and submission evidence found	Missing
Public 19-tool Spine Tools contract	Fixed definitions and OAuth-scope tests exist	Implemented; deployment/list verification pending
IW-Spine-Network Plugin app/UI/skills package	No complete host-submission artifact, embedded widget suite or clean-install evidence established	Missing
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
MCP Pool tenant/user filters	Registry enforcement and tests exist	Implemented; Customer Zero runtime verification pending
Cloudflare/Neon/R2/D1/KV environment isolation	Configuration/documentation evidence exists	Live verification required
Marketplace submissions and production DNS/endpoints	Not established by repository review	Unverified

Legacy documentation and code still contain superseded product names, old auth
claims, old endpoint paths, user-facing layer language, development fallbacks
and default-tenant paths outside the fully proven Gateway boundary. They remain
evidence/history until migrated; they do not override this contract or the
frozen authority.

14. Required implementation sequence

Correct and smoke-test migration 035; decide and implement the strict
connector-binding model; apply with a migration ledger.
Make Gateway derive user/tenant/RBAC from Clerk and reject authoritative
browser overrides across projection and connector routes.
Complete live deployment, negative tenant/RBAC and frontend acceptance for
/api/v1/workspace/discovery.
Consolidate frontend calls on NEXT_PUBLIC_IW_API_URL and one typed Gateway
client; remove production localhost and direct-service fallbacks.
Align projected navigation with the shared taxonomy and RBAC; never expose
internal MCP Pool or Twin as general-user destinations.
Complete one connector through consent, strict binding, discovery, schema
mapping, hydration, delta sync, revoke and projection invalidation.
Prove event/idempotency/retry/dead-letter/reprocessing/reconciliation and
observability guarantees end-to-end.
Validate the full Four-Button governed action loop through Hermes and
re-ingested outcome.
Complete the Vercel native integration package and verify the deployed OAuth
MCP endpoint before marketplace submission.
Build and verify IW-Spine-Network Plugin embedded UI, host composition,
explicit delegation and clean tenant activation.
Build and verify IW-Spine-Network MCP listing, fallback behavior and
standalone browser Workbench launch.
Validate Development → Customer Zero → Customer Production promotion with
isolated credentials, data, bindings, queues, caches, evidence and audit.

15. Testing-environment event gate

Do not begin the integrated testing event until the following evidence exists:

environment/DNS/identity/Gateway/Neon/R2/D1/KV/queue/secret health;
migration ledger and schema verification;
cross-tenant and cross-environment negative tests;
first-read discovery and every visible sidebar projection contract;
one real connector with connection reuse, consent, discovery, mapping, sync,
health, revoke and reconciliation;
public MCP OAuth and exact 19-tool listing;
Plugin embedded UI sandbox/fallback behavior and MCP browser Workbench launch;
no automatic inheritance of unrelated host-app credentials;
no direct frontend database/provider/internal-MCP traffic;
explicit partial/degraded states with no live-to-demo fallback;
one proposal → approval token → Hermes action → provider outcome → re-ingest
→ reconciliation → projection refresh trace;
bounded retry, ambiguous-outcome protection, dead letter and governed replay;
observability, audit, rollback and revocation evidence.

Any missing item is a testing-event blocker, not a post-launch cleanup task.

16. Supporting detailed specifications

PRODUCT_PLATFORM_BOUNDARY_AND_GO_LIVE_STANDARD.md
PLATFORM_PRODUCT_DATA_AND_PROJECTION_REFERENCE.md
RUNTIME_SUBSTRATE_AND_SURFACE_CONTRACT.md
TENANT_SPINE_FORTRESS_OPERATIONAL_FLOW_MODEL.md
FRONTEND_PLATFORM_API_AND_DISCOVERY_SPEC.md
WORKBENCH_ROLE_CAPABILITY_MAP.md
SOURCE_PACK_RECONCILIATION_2026-07-28.md
docs/wiki/07-projection-engine-and-shared-workbench.md
docs/wiki/12-connectors-integration-manager-and-spine-network.md
docs/wiki/20-release-readiness-and-verification-evidence.md