{"slug":"strategy/business-strategy/CUSTOMER_ZERO_AND_EXTERNAL_PRODUCT_SPEC","title":"IntegrateWise — Customer Zero and External Product Split Specification","section":"strategy","sectionLabel":"Strategy","status":"current","type":"document","path":"strategy/business-strategy/CUSTOMER_ZERO_AND_EXTERNAL_PRODUCT_SPEC.mdx","bytes":31149,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\n**Status:** Current  \n**Date:** 2026-07-29  \n**Authority:** `HERMES.md`, `ROUND_EXECUTION_SEQUENCE.md`, `IW_SPINE_NETWORK_PLUGIN_AND_MCP_MARKETPLACE_CONTRACT.md`\n\n---\n\n## 1. Purpose\n\nThis document defines the canonical **three runtime profiles** for IntegrateWise:\n\n1. **Dev Internal**\n2. **Customer Zero**\n3. **External Product**\n\nIt specifies:\n\n- The three runtime profiles inside one codebase\n- The two frontend activation modes inside one app\n- The two marketplace lanes: Plugin marketplace vs MCP marketplace\n- How the platform repo maps to all profiles\n\n---\n\n## 2. Canonical Runtime Profiles\n\n| Path                                | Audience                                        | Isolation                                               | Purpose                                                        |\n| ----------------------------------- | ----------------------------------------------- | ------------------------------------------------------- | -------------------------------------------------------------- |\n| **Dev Internal**                    | IW engineers                                    | Local workstation, full DB access, seed data            | Build, debug, prove end-to-end                                 |\n| **Customer Zero**                   | IW’s own production tenant (`iw-customer-zero`) | Isolated tenant, isolated operational partition         | Prove the exact runtime shape external users will receive      |\n| **Product to Users / External GTM** | External customers                              | Tenant-isolated shared Platform or dedicated deployment | Public install/connect via Vercel/Cursor/MCP Directory/ChatGPT |\n\n**Rule:** The platform repo is the single source of truth for all three profiles. The split is runtime-context-driven, not branch-driven. Customer Zero is not a separate product; it is the reference activation profile. External users receive the same software, parameterized by tenant.\n\n---\n\n## 3. Repository Split Strategy\n\nOne repository, `integratewise-live`, serves all three profiles. The split is **tenant/runtime-context-driven**, not branch-driven.\n\n```text\nintegratewise-live/\n├── services/\n│   ├── gateway/\n│   ├── spine/\n│   ├── mcp-connector/\n│   └── ...\n├── apps/web/\n├── packages/\n├── marketplace/\n├── docs/\n└── migrations/\n```\n\n**Rule:** Every commit must be valid for all three profiles unless explicitly gated by tenant/context headers.\n\n### 3.1 Single Codebase, Three Runtime Profiles\n\n| Profile              | How selected                                                                              | Tenant                                          | Data                                                                         | Deployment                                                                                                                                    |\n| -------------------- | ----------------------------------------------------------------------------------------- | ----------------------------------------------- | ---------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |\n| **Dev Internal**     | Local env / seed auth                                                                     | Local dev tenant                                | Local Neon or Docker Postgres; seed data allowed                             | Local Workers / turbo dev                                                                                                                     |\n| **Customer Zero**    | Header `x-tenant-id: iw-customer-zero` or dedicated host `customer-zero.integratewise.ai` | `iw-customer-zero`                              | Real isolated operational partition; real providers, real audit, real queues | Cloudflare Workers + dedicated Neon database                                                                                                  |\n| **External Product** | Header `x-tenant-id: <external-tenant>` or marketplace installation JWT                   | `<tenant-slug>` generated at install/activation | Tenant-isolated data in shared schema; strict row-level isolation            | Cloudflare Workers shared stateless deployment + shared Neon with RLS, or dedicated physical deployment if approved isolation policy requires |\n\n### 3.2 Feature/Config Gating\n\n```text\nIF profile == Dev Internal\n  → allow local seed data, local DB, full diagnostic routes, internal pool access\n  → skip production-only gates\nELSE IF tenant == 'iw-customer-zero'\n  → enable internal telemetry, raw diagnostic routes, debug surfaces, seed tools\n  → allow internal-only connector bindings\nELSE IF profile == External Product\n  → disable diagnostic routes\n  → enforce 19-tool public contract only\n  → enforce scoped OAuth\n  → enforce approval-required governance\n```\n\n**Implementation:** Gate by `tenant_id` + `request.origin` + JWT `aud`. Do not branch code.\n\n---\n\n## 4. Frontend Split Strategy\n\n`apps/web` is a single Next.js application with two runtime contexts.\n\n### 4.1 Single App, Two Activation Modes\n\n| Mode                 | Trigger                                                                 | URL pattern     | Behavior                                                                                                          |\n| -------------------- | ----------------------------------------------------------------------- | --------------- | ----------------------------------------------------------------------------------------------------------------- |\n| **Customer Zero**    | Login with `@integratewise.ai` email or `x-tenant-id: iw-customer-zero` | `/app/platform` | Full admin surfaces, internal connector tray, raw audit, seed data controls, 55-tool internal MCP pool visibility |\n| **External Product** | Marketplace installation JWT or external email domain                   | `/app/platform` | Reduced 19-tool surface, no internal diagnostics, no raw pool visibility, tenant-scoped projections only          |\n\n### 4.2 Frontend Boundary Rules\n\n- **Customer Zero frontend** may call the full Gateway surface, including internal diagnostics, because the operator is IW itself.\n- **External Product frontend** must call only `NEXT_PUBLIC_IW_API_URL` and must never:\n  - call databases directly\n  - call providers directly\n  - call Hermes directly\n  - call the internal MCP Pool directly\n  - infer architecture or reconstruct tenant state from URL/client hints\n- **Both modes** share the same `PlatformShell.tsx`, `PlatformNav.tsx`, and component tree. Differences are rendered by server-resolved identity/roles in `/api/v1/workspace/discovery`.\n\n---\n\n## 5. Marketplace Lane Definitions\n\n### 5.1 Plugin Marketplace Lane\n\n| Attribute                  | Value                                                                                                                |\n| -------------------------- | -------------------------------------------------------------------------------------------------------------------- |\n| **Lane name**              | Plugin marketplace / directory                                                                                       |\n| **Host environment**       | ChatGPT, Codex, compatible AI hosts                                                                                  |\n| **Publication artifact**   | Not a separate package                                                                                               |\n| **User experience**        | User installs IW-Spine-Network from the MCP marketplace; ChatGPT renders a thin IW-created overlay UI inside ChatGPT |\n| **Control model**          | ChatGPT is the operator; IW is the governed interface                                                                |\n| **Capability discovery**   | Host-composed + host-delegated + IW-direct, through supported host contracts                                         |\n| **Credential inheritance** | Never automatic; only explicit host delegation or direct IW connector binding                                        |\n| **UI surface**             | Thin overlay widgets: active work/context, Spine status, approval confirmation, execution progress, Open Workbench   |\n| **Fallback**               | Text/JSON if host does not support MCP App widgets                                                                   |\n\n**Rule:** There is no `IW-Spine-Network Plugin` package published separately. The plugin-lane description in old docs is superseded.\n\n### 5.2 MCP Marketplace Lane\n\n| Attribute                  | Value                                                                                           |\n| -------------------------- | ----------------------------------------------------------------------------------------------- |\n| **Lane name**              | MCP marketplace / registry / directory                                                          |\n| **Host environment**       | Any MCP-compatible client: Cursor, Windsurf, Claude Desktop, Vercel Agent Tools, custom clients |\n| **Publication artifact**   | `IW-Spine-Network MCP`                                                                          |\n| **User experience**        | User connects the remote MCP server; browser Workbench launches for full control                |\n| **Control model**          | User operates through IW Workbench or host MCP client; IW governs all actions                   |\n| **Capability discovery**   | `iw_direct` primary; host composition/delegation if supported                                   |\n| **Credential inheritance** | Never; only explicit IW connector bindings                                                      |\n| **UI surface**             | Full standalone browser Workbench                                                               |\n| **Fallback**               | Text/JSON guaranteed                                                                            |\n\n**Rule:** This is the only published marketplace artifact.\n\n### 5.3 MCP Marketplace → ChatGPT Special Case\n\nWhen the MCP marketplace install flow appears inside ChatGPT:\n\n- ChatGPT remains the conversational controller\n- ChatGPT may render an IW-hosted overlay widget inside its sandbox\n- That widget is thin: evidence display, approval confirmation, progress\n- ChatGPT uses the widget to call IW tools; ChatGPT does not receive IW credentials, internal pools, or provider access\n- The underlying publication is still `IW-Spine-Network MCP`\n\n---\n\n## 6. Customer Zero Implementation\n\n### 6.1 Definition\n\nCustomer Zero is **IntegrateWise’s own production tenant**, identified by `tenant_id = iw-customer-zero`. It is not a test tenant. It is not shared. It is the reference activation profile.\n\n### 6.2 What Runs in Customer Zero\n\n- Full Cloudflare Worker stack: Gateway, Spine, MCP Connector, Intelligence, Knowledge, Hermes, Pipeline, Governance State, MCP Pool\n- Dedicated/isolated Neon operational data\n- Real provider connectors (initial set: GitHub, Notion, Slack, Salesforce, HubSpot, Jira, Confluence, Coda, Google Calendar, Google Drive, Asana, Monday, Zendesk, Intercom, Stripe, Snowflake, BigQuery, Postgres, MySQL, GitLab, OpenAI, Anthropic, Perplexity)\n- Real OAuth + Clerk identity\n- Real queue/DLQ/audit\n- Full 19-tool public MCP surface\n- Internal diagnostic surfaces exposed only to `@integratewise.ai` identities\n\n### 6.3 Customer Zero Platform Repo Mapping\n\n| Component           | Service/Path                                         | Customer Zero Behavior                                                                                                                                        |\n| ------------------- | ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Gateway             | `services/gateway/src/index.ts`                      | Resolves `iw-customer-zero` tenant from Clerk JWT or trusted `x-tenant-id`; rewrites to internal Spine/MCP Connector; allows internal diagnostic routes       |\n| Spine               | `services/spine/src/neon-workbench.ts`               | Queries dedicated Customer Zero Neon database; full workbench/activities/entities/knowledge/memories; no row-level tenant restriction beyond single-tenant DB |\n| MCP Connector       | `services/mcp-connector/src/continuity-bridge.ts`    | Exposes 19 public tools + internal 4 tools; `createContinuityBridgeServer` called with internal scope; diagnostic `/v1/continuity-bridge/*` routes active     |\n| Web App             | `apps/web`                                           | Full admin UI, internal connector tray, raw audit, seed data, 55-tool internal MCP pool visible to IW staff                                                   |\n| Platform Shell      | `apps/web/src/components/platform/PlatformShell.tsx` | Renders all 12 surfaces including Governance with Twin rail, KPI strip, capability actions, full action strips                                                |\n| Marketplace Install | `/api/v1/marketplace/installations/*`                | Customer Zero is pre-installed; installation state shows `active`                                                                                             |\n| Workspace Discovery | `/api/v1/workspace/discovery`                        | Returns Customer Zero workspace: all projections, all capabilities, all connectors, all approvals, all continuity                                             |\n\n### 6.4 Customer Zero Activation Profile\n\nCustomer Zero is activated once, manually, by IW founders:\n\n1. Provision `iw-customer-zero` tenant in tenants service\n2. Create dedicated Neon database or schema with RLS bypass\n3. Bind Clerk org/team to `iw-customer-zero`\n4. Apply migration 035 + all subsequent migrations\n5. Seed initial connectors, connectors catalog, connector installations\n6. Enable internal MCP pool routes\n7. Set `IW_CUSTOMER_ZERO=true` in Worker environment\n8. Verify `/api/v1/workspace/discovery` returns full Customer Zero projection\n\nAfter activation, Customer Zero is treated as a first-class production tenant.\n\n---\n\n## 7. External Product Implementation\n\n### 7.1 Definition\n\nExternal product is the same codebase and same workers, compiled and deployed for external tenants. No code fork. No separate frontend repo.\n\n### 7.2 How It Differs from Customer Zero\n\n| Attribute         | Customer Zero                                                  | External Product                                                                                    |\n| ----------------- | -------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- |\n| **Tenant ID**     | `iw-customer-zero` (hardcoded allowed, but resolved from auth) | Auto-generated at activation (`tenant-<slug>`)                                                      |\n| **Neon access**   | Dedicated DB or schema; no RLS needed                          | Shared DB with strict RLS; row-level tenant isolation enforced on every query                       |\n| **MCP Connector** | 19 public + 4 internal tools; diagnostic routes enabled        | 19 public tools only; internal 4 tools return 403/404; diagnostic routes disabled                   |\n| **Gateway**       | Allows internal routes; rewrites to internal MCP pool          | Rewrites only to public Spine + public MCP pool; rejects internal paths                             |\n| **Web App**       | Full surfaces, internal tray, seed data                        | Reduced surfaces; no internal tray; no seed data; no raw pool                                       |\n| **Marketplace**   | Pre-installed; `active` state                                  | Install flow: OAuth → tenant creation → activation → `active`                                       |\n| **Discovery**     | Returns everything                                             | Returns only permitted projections, capabilities, connectors, approvals, continuity for that tenant |\n| **Approval**      | Optional for internal IW actors                                | Mandatory for all governed actions                                                                  |\n| **OAuth scopes**  | Full internal scopes allowed                                   | Strict scoped OAuth; `mcp:tools` is not a blanket grant                                             |\n| **Telemetry**     | Full raw logs, internal metrics                                | Aggregated anonymized metrics; no internal stack traces                                             |\n\n### 7.3 External Tenant Activation\n\n```text\nExternal user installs IW-Spine-Network MCP from marketplace\n→ OAuth handshake with Clerk\n→ Gateway creates/activates tenant slug\n→ tenants service records tenant, membership, roles\n→ Activation applies Customer Zero-proven reference profile (same code path)\n→ Spine creates tenant-scoped schema/rows in Neon\n→ MCP Connector issues 19-tool scoped catalog\n→ Browser Workbench launches at /app/platform\n→ Host-compatible clients receive widgets through MCP App metadata\n```\n\n**Rule:** The same `activateCustomerZeroProfile` code path runs for external tenants. It is parameterized by `tenant_id`. Customer Zero just passes a fixed `tenant_id`.\n\n---\n\n## 8. Platform Repo Mapping\n\nThe platform repo (`integratewise-live`) owns all services, migrations, packages, marketplace definitions, and docs. It does not fork per lane.\n\n### 8.1 Directory Ownership\n\n| Directory                                | Customer Zero                                                                                              | External Product                                               |\n| ---------------------------------------- | ---------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- |\n| `services/gateway/`                      | Full route table including internal; allows `x-tenant-id: iw-customer-zero` bypass for inter-service calls | Public route table only; rejects internal paths                |\n| `services/spine/`                        | Full Neon queries; can cross tenant context for internal diagnostics                                       | Row-level tenant isolation enforced in every query helper      |\n| `services/mcp-connector/`                | 19 + 4 tools; diagnostic routes; internal scope map                                                        | 19 tools only; no diagnostics; strict public scope map         |\n| `services/tenants/`                      | Pre-seeded `iw-customer-zero`                                                                              | Onboarding API: create/activate/resolve tenant                 |\n| `services/governance-state/`             | Full audit, approval, checkpoint                                                                           | Same, scoped to tenant                                         |\n| `apps/web/`                              | Full 12-surface PlatformShell                                                                              | Reduced 12-surface PlatformShell; internal surfaces return 403 |\n| `marketplace/apps/iw-spine-network.json` | Same manifest; debug metadata included                                                                     | Same manifest; no debug metadata                               |\n| `docs/`                                  | Full internal docs                                                                                         | Public docs subset                                             |\n| `migrations/`                            | Applied once to shared or dedicated DB                                                                     | Applied to shared DB; RLS policies enforced                    |\n\n### 8.2 Runtime Branching\n\nBranching inside the platform repo must be by `tenant_id` or `request.origin`, never by separate code paths.\n\n```typescript\n// Example: gateway route gating\nconst isInternalTenant = tenantId === \"iw-customer-zero\";\nconst isInternalOrigin = request.headers.get(\"x-origin\")?.includes(\"integratewise.ai\");\n\nif (!isInternalTenant && !isInternalOrigin && isInternalRoute(path)) {\n  return new Response(\"Forbidden\", { status: 403 });\n}\n```\n\n```typescript\n// Example: mcp-connector tool gating\nconst publicTools = PUBLIC_CONTINUITY_BRIDGE_TOOL_DEFINITIONS; // 19\nconst internalTools = INTERNAL_CONTINUITY_BRIDGE_TOOL_DEFINITIONS; // 4\n\nif (tenantId === \"iw-customer-zero\") {\n  server.setRequestHandler(ListToolsRequestSchema, () => ({\n    tools: [...publicTools, ...internalTools],\n  }));\n} else {\n  server.setRequestHandler(ListToolsRequestSchema, () => ({\n    tools: publicTools,\n  }));\n}\n```\n\n---\n\n## 9. Frontend Duality\n\n### 9.1 Customer Zero Frontend\n\n- Route: `/app/platform`\n- Auth: Clerk with `@integratewise.ai` approved domain\n- Surfaces: all 12 surfaces active\n- Capability actions: full set including internal connectors, seed data, diagnostic actions\n- Projections: full unfiltered\n- Marketplace: shows installation state; can re-activate/reset external tenants\n- Twin panel: full silent Twin surface with internal proposal types\n- Action strip: reply, reply all, archive, compose, assign Twin, store in Spine, propose action, approve action, run diagnostic\n\n### 9.2 External Product Frontend\n\n- Route: `/app/platform`\n- Auth: Clerk with external email domain or marketplace JWT\n- Surfaces: all 12 surfaces present, but internal surfaces return empty or reduced view\n- Capability actions: only permitted capabilities for that tenant\n- Projections: tenant-scoped, RBAC-filtered\n- Marketplace: installation entry point only; no admin controls\n- Twin panel: Ask Your Twin, Assign Your Twin, Review Twin’s Work only\n- Action strip: reply, reply all, archive, compose, propose action (requires approval), approve action (if authorized), store in Spine\n\n### 9.3 Server-Resolved Identity\n\nThe frontend must not infer lane from URL or client hints. It must call `/api/v1/workspace/discovery` first and let the server return:\n\n```json\n{\n  \"actor\": {\n    \"tenant_id\": \"acme-corp\",\n    \"user_id\": \"user_123\",\n    \"email\": \"user@acme.com\",\n    \"roles\": [\"admin\"],\n    \"lane\": \"external_product\"\n  },\n  \"workspace\": { ... },\n  \"available_surfaces\": [\"dashboard\",\"marketplace\",\"governance\",\"twin\",\"continuity\"],\n  \"available_actions\": [\"reply\",\"reply_all\",\"archive\",\"compose\",\"propose_action\",\"approve_action\",\"store_in_spine\"],\n  \"internal_surfaces\": false,\n  \"internal_actions\": false\n}\n```\n\nFrontend renders conditionally from `available_surfaces`, `available_actions`, `internal_surfaces`, `internal_actions`.\n\n---\n\n## 10. Deployment Model\n\n### 10.1 Customer Zero Deployment\n\n- Workers: dedicated or tagged with `IW_CUSTOMER_ZERO=true`\n- Database: dedicated Neon database or schema\n- Domains:\n  - `gateway.integratewise.ai` → Customer Zero Gateway\n  - `workbench.integratewise.ai` → Customer Zero Workbench\n  - `marketplace.integratewise.ai` → Customer Zero Marketplace\n- Auth: Clerk production org with `@integratewise.ai` domain\n- Secrets: Customer Zero secrets in Secret Store under `CUSTOMER_ZERO_*` namespace\n\n### 10.2 External Product Deployment\n\n- Workers: shared stateless Platform Workers\n- Database: shared Neon with strict RLS\n- Domains:\n  - `gateway.integratewise.ai` → public Gateway (routes to shared workers)\n  - `workbench.integratewise.ai` → public Workbench\n  - `marketplace.integratewise.ai` → public Marketplace\n- Auth: Clerk production org with external domains + marketplace JWT\n- Secrets: per-tenant secrets in Secret Store under `TENANT_<slug>_*`\n\n### 10.3 Deployment Isolation Matrix\n\n| Dimension         | Customer Zero       | External Product               |\n| ----------------- | ------------------- | ------------------------------ |\n| Workers           | Dedicated or tagged | Shared stateless               |\n| Database          | Dedicated           | Shared + RLS                   |\n| Tenant ID         | `iw-customer-zero`  | Auto-generated                 |\n| Auth domain       | `@integratewise.ai` | External domains + marketplace |\n| Internal routes   | Exposed             | Hidden                         |\n| 55-tool pool      | Visible             | Hidden                         |\n| Diagnostic API    | Enabled             | Disabled                       |\n| Seed data         | Enabled             | Disabled                       |\n| Marketplace state | Pre-installed       | Install → activate             |\n\n---\n\n## 11. Tenant Isolation Enforcement\n\n### 11.1 Database Isolation\n\n- **Customer Zero:** direct connection, no RLS needed\n- **External Product:** every query includes `tenant_id = $1` as the first bind parameter; RLS policy `USING (tenant_id = current_setting('app.tenant_id')::text)` enforced at database level\n\n### 11.2 Gateway Isolation\n\n- Gateway overwrites caller-supplied tenant headers with verified JWT tenant\n- Internal `x-tenant-id: iw-customer-zero` is accepted only from trusted origins\n- External requests cannot forge Customer Zero identity\n\n### 11.3 MCP Connector Isolation\n\n- ` ContinuityBridgeActor.tenant_id` derived from Gateway, never from client\n- Tool scope map enforced per tenant\n- Internal tools require `internal` profile or `iw-customer-zero` tenant\n\n### 11.4 Frontend Isolation\n\n- Frontend receives tenant context only from `/api/v1/workspace/discovery`\n- Frontend never stores tenant_id in URL, localStorage, or client state without server round-trip\n- Frontend never infers capabilities from URL or component visibility\n\n---\n\n## 12. Capability and Action Surface\n\n### 12.1 Customer Zero Capabilities\n\n- Read/write/delete on all entities\n- Internal connector management\n- Diagnostic queries\n- Seed data import/export\n- Raw MCP pool invocation\n- All 19 public tools + 4 internal tools\n- Capability actions: reply, reply all, archive, compose, propose, approve, store_in_spine, project_context, relay_state, handoff_agent, delegate_action, run_diagnostic, reset_tenant, seed_data\n\n### 12.2 External Product Capabilities\n\n- Read on permitted entities\n- Write only through governed proposals\n- No raw MCP pool\n- 19 public tools only\n- Capability actions: reply, reply all, archive, compose, propose_action, approve_action, store_in_spine, ask_twin, assign_twin\n\n### 12.3 Governance\n\n- **Customer Zero:** optional human approval for IW founders; internal actors can bypass with `internal` scope\n- **External Product:** human approval mandatory for all governed writes; no autonomous execution\n\n---\n\n## 13. Plugin Marketplace vs MCP Marketplace Summary\n\n| Dimension              | Plugin Marketplace                                | MCP Marketplace                                             |\n| ---------------------- | ------------------------------------------------- | ----------------------------------------------------------- |\n| **Published artifact** | Not published separately                          | `IW-Spine-Network MCP`                                      |\n| **Host**               | ChatGPT, Codex                                    | Any MCP client + browser Workbench                          |\n| **UI**                 | Thin overlay widgets                              | Full standalone browser Workbench                           |\n| **Control**            | ChatGPT operates; IW governs                      | User operates through IW Workbench                          |\n| **Discovery**          | Host composition + host delegation + IW-direct    | IW-direct primary; host composition/delegation if supported |\n| **Credentials**        | Never inherited automatically                     | Never inherited automatically                               |\n| **Tools exposed**      | 9-tool subset (chatgpt/claude/perplexity profile) | 19-tool public contract                                     |\n| **Approval**           | Mandatory                                         | Mandatory                                                   |\n| **Fallback**           | Text/JSON                                         | Text/JSON                                                   |\n\n---\n\n## 14. Implementation Order for Claude Code / Claude Cowork\n\n1. **Round 1** — P0 contract/code alignment (current commit: `495a0295`)\n2. **Round 2** — P0 infrastructure/auth: DNS/Clerk + single auth node + bindings audit\n3. **Round 3** — P1 Plugin + MCP + discovery: build both artifacts, implement discovery origins\n4. **Round 4** — P1 frontend/platform completion: enforce boundary, deploy discovery, remove direct calls\n5. **Round 5** — P1 Customer Zero testing: clean install, clean connect, governed action cycle, Flow A/B/C/D, aging, reconciliation\n6. **Round 6** — P2 publication: submit assets, Vercel native package, monitoring\n\n**Rule:** Do not start Round 3 before Round 2’s auth/config prerequisites are committed. Do not start Round 5 before Round 4 is deployed to Customer Zero.\n\n---\n\n## 15. Acceptance Gates\n\n| Gate                       | Evidence required                                                                                                                   |\n| -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |\n| **P0 contract/code**       | `grep -R \"IW-Continuity-Bridge\"` returns zero hits in code; `typecheck` + `mcp-connector` + `gateway` tests pass                    |\n| **P0 infrastructure/auth** | DNS resolves; Clerk JWT verifies; `tenants` service resolves `iw-customer-zero`; D1/KV/R2/secret bindings listed and present        |\n| **P1 Plugin**              | `npm run build` succeeds; plugin OAuth flow completes in test; widget renders in host sandbox                                       |\n| **P1 MCP**                 | `server.json` validates; 19 tools listed; Open Workbench launch contract succeeds                                                   |\n| **P1 discovery**           | Three origins return distinct discovery payloads; duplicate detection works; credential scraping prevented                          |\n| **P1 frontend**            | `/api/v1/workspace/discovery` deployed; no `localhost` fallback in production build; no direct DB/provider calls in frontend bundle |\n| **P1 Customer Zero**       | Clean install into new tenant succeeds; exactly 19 public tools proven; governed action cycle end-to-end; Flow A/B/C/D proven       |\n| **P2 publication**         | Marketplace listing live; Vercel native package installed; monitoring dashboard green                                               |\n"}