Unclassified

IntegrateWise / Spine Workspace — Deployment Prerequisites

Status: Release prerequisite — subordinate to canonical architecture
Date: 2026-08-20
Purpose: Define the mandatory infrastructure, contract, and proof gates that must exist before any deployment event

The deployment prerequisites are now clear from the repository audits and attached release material. The mistake to avoid is treating deployment as "deploy Workers + deploy frontend." Before that, the shared platform contract, credentials, routing, storage, connector, MCP, projection, and governance paths must all exist and be isolated by environment.

0. Environment model must be frozen first

There are three distinct infrastructure classes:

A. Product Engineering
   development
   CI
   staging
   test tenants

B. Customer Zero
   IntegrateWise operational tenant
   production-grade but isolated

C. Customer Production
   external tenant runtimes
   isolated from A and B

Development infrastructure may use fixed engineering choices. Customer-facing projections must not force customers to choose or understand underlying infrastructure providers. The Platform resolves those behind the connector/capability abstraction.

Prerequisite: no D1, KV, R2, queue, vector, credential, tenant, or service binding may accidentally be shared across these partitions.

1. Shared Cloudflare Platform foundation

Before any frontend testing event, the Platform must be reachable.

Required:

Cloudflare account
Cloudflare Workers environments
Workers for Platforms / tenant routing where applicable
Gateway
Pipeline
Connector runtime
MCP Connector / Spine Network MCP
Knowledge
Continuity
Intelligence
Workflow
Hermes / Execution
Reconciliation

Do not deploy every Worker in the repository simply because it has a wrangler.toml. The repository audit distinguishes the smaller core release profile from many bound, partial, or zero-inbound services.

For every production Worker:

worker name
environment
route/domain
service bindings
D1 bindings
KV bindings
R2 bindings
queue producers/consumers
DO bindings
AI/model bindings
secret inventory
health endpoint
owner
release version
rollback version

must be known before deployment.

2. DNS and ingress

The following ingress surfaces must resolve and terminate correctly before integrated testing:

gateway.integratewise.ai
auth / OneAuth endpoint
mcp.integratewise.ai
Workbench / Spine Workspace domains
platform control surface
marketplace/activation routes as required

The Gateway is the authoritative platform ingress. Frontends must not bypass it via arbitrary direct service rewrites.

Required validation:

DNS resolves
TLS valid
CORS correct
CSP correct
authenticated request succeeds
unauthenticated request fails correctly
tenant is derived server-side
correlation/trace ID generated

The source material specifically identifies unresolved Gateway/Auth DNS and incomplete bindings as release blockers.

3. OneAuth / identity / tenant authority

This is Flow D, and it precedes A/B/C ingestion.

Required live path:

User / Host
   ↓
OneAuth
   ↓
Authentication
   ↓
Organization resolution
   ↓
Tenant resolution
   ↓
Membership / role / permission
   ↓
Consent
   ↓
Workspace binding
   ↓
Runtime activation

Before testing, you need:

production/test auth provider configuration
client IDs
server secrets
redirect URIs
webhook secret
session verification
tenant mapping
role/RBAC mapping
consent persistence
revocation
logout/session expiry
service identity model

The Gateway must re-derive authority. Browser-supplied tenant, role, entitlement, policy, connector scope, or capability grants cannot be authoritative.

The current ecosystem audit identifies default/preview tenant fallback as a key item to eliminate before release proof.

4. Central secret and environment configuration

This needs to exist before anything is deployed.

Do not create one giant .env and copy it everywhere.

You need a controlled inventory:

ENVIRONMENT
SERVICE
SECRET NAME
OWNER
SOURCE
ROTATION POLICY
USED BY
LAST VERIFIED

Typical groups:

Platform

CLOUDFLARE_ACCOUNT_ID
deployment API token
Gateway service credentials
encryption key
admin/service credentials

Identity

auth publishable/client ID
auth server secret
webhook secret
OAuth redirect configuration

Connectors

provider client ID
provider client secret
provider webhook secret
Nango/configured connector runtime secret if used

MCP

MCP OAuth client
MCP client credentials where applicable
resource/audience configuration
service-to-service auth
internal MCP Pool service identity

AI/model providers

AI Gateway configuration
provider API keys
model-routing policy
local-model endpoint if used

Frontend

Only browser-safe values:

NEXT_PUBLIC_IW_API_URL
auth publishable key
public application IDs
feature/version identifiers

Provider secrets, Nango secrets, MCP service secrets, model keys, encryption keys, admin secrets, and connector credentials must not be in browser-visible environment variables. The attached environment-variable audit already identified the need to converge frontends onto a single public Gateway URL.

5. Storage and migrations

Before integrated testing, all required stores must exist in the correct environment.

At minimum:

canonical / promoted Spine store
tenant operational D1
KV
R2
Vector/Search
Durable Objects
Queues

And for every store:

environment-specific resource
migration version
backup policy
restore procedure
retention
encryption
tenant boundary
service owner

There is still an architectural storage-authority discrepancy across historical material, so deployment must follow the current repository authority, not old resource names. A D1 database named something like canonical-spine is not automatically canonical authority.

Most importantly:

Do not begin Customer Zero or external testing while canonical promotion is placeholder/skipped.

That is explicitly called out as stop-ship drift in the ecosystem audit.

6. Connector Marketplace control plane

This is mandatory.

A connector cannot be "some source code plus a few env vars."

Each connector needs a machine-readable definition covering:

connector identity
provider
auth method
credential policy
scopes
OAuth URLs
callback URL
webhooks
supported objects
sync strategy
entity mappings
capabilities
MCP exposure if any
ADK capability mapping
governance class
runtime adapter
health check
version
lifecycle

The connector control plane should include:

Connector Catalog
Auth Profiles
Credential Policies
Webhook Registry
Sync Definitions
Entity Mapping Registry
Capability Registry
Deployment Manifest
Health / Lifecycle State

This is explicitly supported in the connector architecture material.

7. ConnectionBinding / "connect once" registry

This is one of the most important prerequisites.

A connected provider must be reusable by all authorized surfaces without each surface creating another OAuth relationship.

Required durable record:

ConnectionBinding
├── tenant
├── workspace
├── principal
├── provider
├── provider workspace/account
├── source kind
│   ├── host-declared
│   └── IW-managed
├── opaque credential/delegation ref
├── confirmed scopes
├── consent
├── policy grants
├── capability grants
├── primary route
├── health
├── freshness
├── provenance
├── sync state
├── reconciliation state
├── authorized consumers
├── audit
└── revocation

The current audit says this is not yet sufficiently proven as a shared durable registry; in-memory fallback exists. That must be resolved before public testing.

8. Host connection discovery

This is separate from connector ownership.

For ChatGPT, Claude, Vercel, GitHub, etc.:

Host
  ↓
OneAuth / MCP Auth
  ↓
Discovery
  ↓
Host-declared capabilities / eligible connections
  ↓
Consent + policy
  ↓
ConnectionBinding
  ↓
Spine Network

IntegrateWise should not copy host tokens just because the host already has a connection.

Host connections are discovered and projected only where the host exposes an authorized delegation/capability route.

Fallback:

No usable host route
    ↓
Connector Marketplace
    ↓
IW-managed OAuth

This distinction is already captured in the ecosystem companion.

9. MCP authentication and public MCP boundary

Before any AI-host testing, mcp.integratewise.ai needs to be production-ready.

Required:

OAuth / MCP Auth
client identity
tenant binding
user/principal binding
scopes
resource metadata
tool visibility policy
read/write classification
approval requirements
connector dependencies
audit
revocation
rate limiting

An MCP client does not inherit full Workbench or tenant administration access simply because it authenticated.

Public MCP must expose semantic business capabilities, not internal engine operations.

Good:

prepare_account_brief
retrieve_verified_context
resolve_customer_risk
create_governed_followup

Bad:

raw_d1_query
pipeline_write
governance_set_approved
memory_insert
loader_execute_internal

Also: treat the current "19 tools" as a release contract, not a permanent architecture invariant.

10. Internal MCP Pool / ADK

Separate from public MCP.

Required for Customer Zero/internal orchestration:

MCP server registry
tool registry
agent registry
model registry
capability manifests
allowed tenant filters
allowed user filters
service identity
health
audit
routing

The current repo audit indicates MCP Pool reachability/registry state is not yet production-proven and includes process-local/configuration drift. This must be corrected before treating it as a shared runtime.

11. Discovery Engine

Before onboarding can feel automatic, Discovery must exist.

It needs to discover:

host capabilities
existing ConnectionBindings
available connectors
schemas
provider objects
unmapped events
capabilities
dependencies
health state

But Discovery is proposal-only:

Discover
→ classify
→ suggest
→ request consent / mapping

not:

Discover
→ automatically steal token
→ automatically ingest all data

12. Loader / Normalizer / Triage paths

These must be separated.

Flow A — structured operational

CRM / ERP / system record
→ Loader
→ Normalizer
→ identity resolution
→ mapping
→ promotion
→ Spine

Flow B — unstructured work context

Email / document / message / project artifact
→ Loader
→ Normalizer
→ chunk/reference/evidence
→ mapping
→ promotion
→ Spine

Flow C — AI/Brainstorming continuity

The latest tested vertical proof explicitly established:

authorized AI/chat reference
→ Brainstorming
→ Triage
→ compare / dedupe / consolidate
→ novel candidate
→ pending governance
→ bounded context

Flow C does not go through Loader/Normalizer in the tested design.

That local integration proof passed, but it is not yet a live-provider deployment proof.

13. Canonical promotion path

This is a hard release prerequisite.

Need a complete verified chain:

Source
→ ingestion
→ normalize/triage
→ provenance
→ promotion decision
→ canonical writer
→ canonical commit
→ outbox
→ projection invalidation

Atomic mutation should pair durable truth with its event/outbox record.

No:

write data
then maybe publish event

because that can split state from downstream projections.

14. Projection Engine and frontend/backend contract map

Before testing, every important frontend surface needs a contract map.

Not:

UI table ↔ database table

Instead:

Workbench route
   ↓
Projection ID / version
   ↓
Gateway endpoint
   ↓
Projection Service / Engine
   ↓
canonical entity family + operational read model
   ↓
RBAC / tenant / freshness policy

For actions:

UI interaction
→ capability ID
→ schema
→ governance class
→ execution owner
→ reconciliation

This is the Projection Binding Registry that the current canonical ecosystem work says is still required.

15. SharedWorkbench / projection contract

The frontends should all consume the same composition authority.

Required:

Projection Engine
→ versioned SharedWorkbench / projection DTO
→ Gateway
→ web / mobile / desktop / host UI / Twin context

The frontend needs explicit states:

loading
ready
partial
empty
stale
degraded
unauthorized
forbidden
unavailable
offline
not configured

A failed live projection must never silently become demo or seed data.

16. Twin readiness

Twin needs to be live only after grounded context exists.

Prerequisites:

context assembly
bounded retrieval
citations
memory scopes
provenance
signal access
capability access
policy context
approval awareness

Twin may:

observe
orient
summarize
draft
plan
recommend
propose

Twin may not:

approve itself
write canonical truth directly
claim provider completion
bypass governance

17. Model and agent deployment

Required registries:

Model Registry
Agent Registry
Capability Registry
Tool Registry
Policy Registry

Model routing requires:

provider
model ID
environment
allowed purposes
tenant policy
fallback order
cost controls
rate limits
observability
health

The recent vertical proof discovered an important naming distinction:

omni-router currently routes connector/tool execution.
model-gateway is the model/provider routing boundary.

Do not merge those responsibilities accidentally.

18. Capability Fabric

Before governed actions can be tested:

capability registry
capability version
input/output schema
required connection
required scope
risk class
required approval
execution adapter
reconciliation contract

Resolver output should be something like:

requested intent
→ capability
→ eligible route
→ policy
→ execution plan

not hardcoded provider logic in the UI.

19. Governance

Before any write capability is enabled:

proposal
policy evaluation
authority evaluation
human approval where required
immutable approved plan
signed/attributable approval
audit

A user click, Twin response, workflow, MCP call, or agent does not execute directly.

20. Hermes / execution

Hermes must be actually reachable, not merely present as a Worker.

Required path:

Approved execution plan
→ Hermes
→ capability route
→ provider
→ provider receipt

The current architecture audit explicitly identifies Hermes as architecture-critical but orphaned/not adequately reachable in the core release profile.

That is a stop-ship issue for consequential actions.

21. Sync + reconciliation

Provider acceptance is not completion.

Need:

provider receipt
→ observe provider state
→ compare expected vs actual
→ reconciliation status
→ evidence
→ promotion
→ projection refresh

The complete loop is still one of the principal runtime proof gaps identified in the current ecosystem audit.

22. Audit + evidence + observability

Before Customer Zero testing:

logs
distributed traces
correlation IDs
audit events
provider receipts
evidence references
queue failures
DLQ
retry counts
connector health
projection freshness
MCP calls
AI/model usage
approval history
reconciliation history

You need dashboards and alerts for the core operational loop, not just Worker uptime.

23. Frontend prerequisites

Each frontend can deploy independently, but all must use the same Platform contract.

Required:

apps/web
apps/platform / canonical operator surface
mobile/desktop if included in test
Customer Zero profile

Every frontend must use:

authenticated Gateway
versioned projection contracts
versioned capability contracts

and not:

direct D1
direct Neon
direct provider API
direct internal MCP
frontend-managed OAuth secrets

24. Platform Console prerequisites

Before testing the ecosystem operationally, the Platform surface needs enough real functionality to observe and control:

tenant
connections
connector health
activation
capabilities
MCP
models
agents
projection manifests
queues
governance
execution
reconciliation
audit
deployment

The current audit states that Platform Console has the right shape but still contains mock/static fallback and incomplete control endpoints.

So it cannot yet be treated as authoritative operations control until those paths are wired.

25. Marketplace assets

Before marketplace submissions, publishable assets must exist:

IW Spine Network MCP metadata
Plugin manifest
OAuth configuration
privacy policy
terms
support URL
documentation
security description
reviewer instructions
demo/test tenant
capability/tool descriptions
screenshots
icons
version
changelog

Connector Marketplace remains the internal activation surface.

Plugin/MCP/provider marketplaces are distribution channels.

The canonical preparation sequence explicitly places marketplace submissions after private certification and clean-tenant proof.

26. Deployment artifact freeze

Before testing, every deployed component needs one matching release version.

Git SHA
frontend version
Gateway version
Worker versions
MCP version
projection contract version
capability contract version
schema version
migration ledger
connector manifest version
model/agent config version

Do not test a frontend from commit X against Gateway Y and migrations from Z and then call the result a release candidate.

27. Rollback and revocation

Must exist before Customer Zero.

You need to prove:

frontend rollback
Worker rollback
schema/migration rollback strategy
connection revoke
OAuth revoke
MCP client revoke
agent disable
model disable
capability disable
tenant suspend
queue pause
bad projection rollback
bad deployment rollback

28. Required pre-test vertical proof

Before the broader testing event, one closed journey must work:

Flow D
identity + tenant + consent


        ↓


Connection / authorized source


        ↓


A or B ingestion
Loader → Normalizer


and/or


C ingestion
Brainstorming → Triage


        ↓


Spine materialization / promotion


        ↓


Projection Engine


        ↓


Workbench


        ↓


Twin context


        ↓


Capability


        ↓


Governance


        ↓


Hermes


        ↓


Provider action


        ↓


Re-ingest


        ↓


Reconciliation


        ↓


Verified promotion


        ↓


Workbench refresh

You already have a deterministic local proof for the A/B/C → bounded MCP context part, including tenant isolation, consent, provenance, Flow C deduplication, and bounded context.

What remains is the live-environment continuation:

real identity
real connection
real canonical promotion
real projection
real approval
real Hermes action
real provider reconciliation
real browser readback

Deployment readiness order

The sequence to follow:

1. Environment isolation
2. Secret/config source of truth
3. DNS + Cloudflare account/runtime
4. Identity / OneAuth / tenant authority
5. Storage + migrations
6. Gateway
7. Connector catalog + credential wall
8. Durable ConnectionBinding registry
9. Discovery
10. Loader / Normalizer / Triage
11. Canonical writer + outbox
12. Projection Binding Registry
13. Projection Engine + frontend read path
14. Public MCP Auth + Spine Network MCP
15. Internal MCP Pool + ADK registries
16. Models + agents
17. Capability Fabric
18. Governance
19. Hermes
20. Sync / reconciliation
21. Evidence / audit / observability
22. Platform Console operational controls
23. Frontend deployments
24. Customer Zero vertical test
25. Customer Zero daily-use proof
26. External clean-tenant test
27. Marketplace certification
28. Public release

The immediate blockers

Based on the repository audits, the highest-priority prerequisites are not more UI or more connectors. They are:

Authoritative identity/tenant path
Environment isolation and secret/config management
Durable connect-once ConnectionBinding registry
Real canonical promotion path
Projection Binding Registry + Gateway-only reads
Production-ready public MCP Auth
Reachable MCP Pool / capability registries
Reachable Hermes
End-to-end action → reconciliation → refresh proof
Customer Zero isolated deployment

Until those are true, deploying more surfaces only increases the amount of unverified infrastructure.