{"slug":"internal/architecture/CANONICAL_ECOSYSTEM_COVERAGE_COMPANION","title":"Canonical Ecosystem Coverage Companion","section":"internal","sectionLabel":"Internal","status":"unclassified","type":"document","path":"internal/architecture/CANONICAL_ECOSYSTEM_COVERAGE_COMPANION.mdx","bytes":100263,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\n**Status:** Grounded implementation companion — subordinate to\n[`INTEGRATEWISE_ARCHITECTURE.md`](INTEGRATEWISE_ARCHITECTURE.md) and\n[`SPEC_AMENDMENTS_v1.md`](SPEC_AMENDMENTS_v1.md) \n**Verified against checkout:** 2026-08-20 \n**Purpose:** Account for every repository component and turn the canonical architecture into\nan explicit connection, ownership, deployment, storage, and remediation program.\n\nThis companion does not create new product concepts or override the architecture. It answers\nthe implementation question that the architecture alone cannot answer: **why does each thing\nin this repository exist, what owns it, what is it connected to, and what must happen to it?**\n\n## Current state summary (2026-08-20)\n\n| Category | Count | Status |\n| -------------------------- | --------------------------------------------- | ---------------------------------------------------------------------------------------------------------- |\n| Apps | 12 directories (11 manifests + mcp-servers) | 9 material surfaces; 3 empty/untracked aliases |\n| Services | 31 directories (~30 Worker manifests) | 9 core release; 12 bound/outside-release; 11 orphaned |\n| Packages | 48 directories (47 manifests + domain-shells) | ~57 logical units when nested counted |\n| Core release Workers | 9 | pipeline, connector, mcp-connector, connector-sync, knowledge, continuity, intelligence, workflow, gateway |\n| Stop-ship gaps | 5 | Identity drift, connect-once drift, canonical writer placeholder, Hermes orphaned, reconciliation unproven |\n| Vertical integration proof | 1 | Three-flow A/B/C deterministic local proof (§16) |\n| Open decisions | 10 | D11 identity, D12 isolation, D13 Twin/ADK, plus 7 more (§14) |\n\n## 1. Evidence and status rules\n\nThe repository currently contains 15 physical `apps/*` directories (11 package manifests), 34\nphysical `services/*` directories (approximately 30 Worker manifests), and 52 physical\n`packages/*` directories. The package tree represents approximately 57 logical package units\nwhen nested packages and non-workspace source packages are counted. Product/browser coverage is\nten material app surfaces; skeletons, Workers under `apps/`, and empty/untracked aliases are\nreported separately. Counts are a checkout snapshot, not an architectural target.\n\n| Label | Meaning |\n| -------------------- | --------------------------------------------------------------------------------------------------------------- |\n| **verified** | Direct code, test, route, or manifest evidence was inspected. |\n| **configured/wired** | A route, binding, rewrite, or deploy manifest exists; this is not proof that the target is deployed or healthy. |\n| **runtime-proven** | External or clean-tenant evidence proves the deployed path. No path receives this label from code alone. |\n| **partial** | Useful implementation exists but a required authority, persistence, caller, or return path is missing. |\n| **orphaned** | Implementation exists without a release path or inbound runtime binding. |\n| **legacy** | Superseded implementation retained in the tree. |\n| **intended** | Canonical target without complete implementation evidence. |\n| **drift** | Current implementation conflicts with the canonical law. |\n| **decision** | Product/engineering ownership must be explicitly decided before implementation. |\n\nEvidence boundaries are strict:\n\n- `package.json`, Vercel configuration, Wrangler manifests, service bindings, rewrites, and code\n prove **presence or configured wiring**, never runtime reachability.\n- Vercel owns browser/product deployments. Cloudflare Wrangler manifests are the deployment\n evidence for shared platform/runtime services. Vercel rewrites may describe ingress but do not\n prove a Worker exists.\n- The nine-Worker array in `scripts/release/deploy-platform.sh` is the intentional core release\n profile: `pipeline`, `connector`, `mcp-connector`, `connector-sync`, `knowledge`, `continuity`,\n `intelligence`, `workflow`, `gateway`.\n- No current repository evidence proves the complete clean-tenant action loop. Customer Zero is\n useful evidence only when its tenant, deployment, provider, and audit boundaries are recorded;\n it is not a substitute for external clean-tenant evidence.\n\n## 2. Product and authority lock\n\n| Question | Canonical answer | Implementation consequence |\n| --------------------- | --------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Company | **IntegrateWise** | Company, legal, marketing, and operator identity. |\n| Product | **Spine Workspace** | Role-aware Workbenches are projections of one product, not separate products. |\n| Protected core | **The Spine** | Tenant-wide organizational context; only governed Pipeline promotion writes canonical truth. |\n| Browser/runtime split | Vercel / Cloudflare Workers | Browser shells do not become service or storage authorities. |\n| Connection law | Discover first; adopt/connect once per tenant | Host-connected connectors are the first source. Authorized products, Workbenches, and agents reuse an eligible governed connection under identity, consent, RBAC, least privilege, approvals, provenance, and audit. |\n| Surface law | Multiple surfaces, one continuity system | Login, connections, data, context, and AI cannot become independent tenant islands. |\n| Workbench law | One role-aware surface | Competing route families must converge behind the Projection Binding Registry. |\n| Twin law | Silent, THINK-only, approval-bound | Twin creates proposals/context; it never directly writes the Spine or providers. |\n\nAuthority order is: canonical architecture → canonical amendment → retained implementation\nspecifications → this coverage companion → evidence/drift reports → lineage. `AGENTS.md` and\narchitecture `README.md` are pointers. `CODEBASE_EXCAVATION.md` is a dated drift baseline, not\ncurrent authority. Commercial/GTM documents cannot override this chain.\n\n### Connector ownership doctrine\n\nSpine Workspace owns connectors at the **ecosystem and governance layer**; it does not claim to\nwholly own or rebuild every provider integration. A connected host is the first source of\nconnection discovery. The shared platform discovers eligible host connections and, only after\nidentity, tenant, consent and policy checks, adopts a durable tenant `ConnectionBinding` that\nauthorized Workbenches, products and agents can reuse.\n\nIntegrateWise owns **OneAuth** and the **Spine Network MCP** as its connector products. External\nprovider integrations remain provider/host capabilities, with host-connected access preferred.\nCataloging, governing or projecting an external connector does not make the underlying provider\nintegration an IntegrateWise-owned connector product.\n\nThe shared platform owns that binding's consent, capability grants, confirmed scopes, sync and\nreconciliation lifecycle, health/freshness, provenance, consumers, revocation and audit. It never\ncopies a host token. Provider or host credentials remain behind their credential wall. Discovery\ndoes not mean IntegrateWise created a second integration, received unrestricted access, or may\ntransfer all host data. Every read and action remains capability-, scope-, tenant-, purpose- and\napproval-bounded. IntegrateWise-managed OAuth is a fallback only when the host cannot delegate the\nrequired capability and the user explicitly consents.\n\nThe **Discovery Agent** is the bounded explorer of the host-connected and already-connected\nenvironment. It may inspect declared app/capability metadata, connection health and consent-visible\nscope; compare those declarations with Workbench needs; and propose mapping, reuse or an explicit\nfallback connection. It never receives unrestricted provider credentials, cannot infer consent\nfrom discovery, cannot read arbitrary provider data, cannot create its own `ConnectionBinding`, and\nhas no canonical Spine write authority. Gateway/OneAuth validates every discovery result before\nProvider Management records or changes a binding.\n\nThe Gateway-owned binding must record tenant, workspace, principal, provider and provider-workspace\nidentity; source kind (`host-declared` or `IW-managed`); opaque credential/delegation reference;\nconfirmed scopes; consent; policy and capability grants; primary route; health and freshness;\nprovenance; sync and reconciliation state; authorized consumers; and audit/revocation state. Every\nsurface resolves and binds through Gateway rather than reading a UI-local registry.\n\n## 3. End-to-end control and data map\n\n```text\nFlow D: host identity → user identity → tenant membership → consent/grant → RBAC/policy\n │\n ▼\nFlow A/B: provider/webhook/file/MCP → Gateway → Loader → Normalizer → operational Spine\n │\n ▼\n promotion record + provenance\n │\n ▼\n governed Pipeline canonical writer\n │\n Neon canonical Spine ─────┤\n ▼\n bounded D1/KV/search projections\n │\n Projection Binding Registry → role-aware Workbench\n │\nFlow C: operational evidence → THINK/Twin → governed intent → APPROVE token\n │\n ▼\n Hermes → capability/MCP/provider adapter\n │\n ▼\n provider result → re-ingestion → reconciliation → projection refresh\n```\n\n**Current result:** individual segments are verified or configured, but the chain is **partial**.\nCanonical promotion, durable shared connection reuse, authoritative shared identity, Hermes\nreachability, and the closed reconciliation/refresh loop are release blockers.\n\n## 4. Application and public/domain surface manifest\n\nEvery browser surface must consume Flow D and Gateway-owned contracts. `None` in the write column\nmeans it must not write canonical or provider state directly.\n\nThe currently declared shared host ownership is `www → marketing`, `auth → auth`, `platform →\nplatform`, and operational role hosts → `web`. `docs`, `activation`, and `connector` have app roots\nbut no reconciled release host owner; they are non-release until assigned or deliberately invoked\ninside an owned shell. Vercel browser ownership and Cloudflare Worker ownership must be recorded in\none deployment registry. A rewrite between them is wiring evidence, not ownership or live proof.\n\n| Root / surface | Reason and owner | Upstream → downstream | Write/storage authority | Boundary / target | Status → disposition | Evidence |\n| ------------------------- | -------------------------------------------------------- | ---------------------------------------------------------------------- | ---------------------------------------------------------- | ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ |\n| `apps/web` | Primary Spine Workspace and role projections; Product UI | Flow D/Gateway → Projection Engine/Workbench APIs | None; governed intents only | authenticated product; Vercel | **partial, drift → KEEP + CONNECT** competing `/workspace`, `/workbench`, `/workbenches`, and domain-host families must converge | `apps/web/app`, `apps/web/middleware.ts`, `apps/web/vercel.json`/root `vercel.json` |\n| `apps/platform` | Platform Console/control board; Platform Engineering | Flow D/Gateway discovery → owning control services | Control intents only; never projection/canonical authority | internal/tenant-admin; Vercel | **partial → KEEP + CONNECT** fail-closed discovery is valid; mock/static fallback and TODO endpoints prevent SoT-console claims | `apps/platform/app/api/v1/workspace/discovery/route.ts`, `apps/platform/lib/services`, `apps/platform/vercel.json` |\n| `apps/auth` | Dedicated login/signup entry | identity provider → tenant/consent handoff | Identity session only | public-to-authenticated; Vercel | **configured/wired → MERGE contractually** into OneAuth Flow D, not an identity island | `apps/auth/package.json`, source routes |\n| `apps/activation` | Onboarding/activation journey | Flow D + connection discovery → hydration/Workbench | Activation commands only | authenticated; Vercel | **partial → CONNECT** to durable tenant/connection and activation state | `apps/activation/package.json` |\n| `apps/connector` | Connection discovery/consent tray host | host discovery + Flow D → Gateway Provider/Integration Management APIs | Delegation/OAuth grants and commands through owner | authenticated; Vercel | **partial → CONNECT** discover host connections first; adopt one governed binding; never copy host tokens or create a second registry | `apps/connector/package.json` |\n| `apps/one-access` | Composite OneAuth shell | auth + activation + connector MFEs → Spine Workspace | None beyond identity/grant commands | public/authenticated; Vercel | **configured → KEEP + MERGE** three journeys behind one tenant trust contract | `apps/one-access/package.json` |\n| `apps/marketing` | Company/product discovery and GTM | public content → signup/marketplace | None | public; Vercel | **verified → KEEP** claims remain gated by release proof | `apps/marketing/app`, `apps/marketing/vercel.json` |\n| `apps/docs` | Published technical/product documentation | canonical docs → evaluators/operators | None | public/controlled; Vercel | **configured → KEEP + ADAPT** publish authority labels prominently | `apps/docs/package.json` |\n| `apps/portfolio` | Corporate/portfolio presentation | public content → company/product | None | public; Vercel | **decision → MERGE or ARCHIVE** avoid a second marketing truth source | `apps/portfolio/package.json`, `apps/portfolio/vercel.json` |\n| `apps/workspace` | Workspace alias/root without tracked implementation | intended Workbench → none | None | intended product | **untracked/empty → DELETE residue or document generator owner** | physical directory; no tracked files |\n| `apps/mcp-servers` | Worker-hosted public MCP entry despite `apps` location | assistant/OAuth → semantic MCP facade | Intent/event only | public machine surface; Cloudflare | **configured/wired → MOVE classification** to runtime inventory; verify exact 19-tool public contract | `apps/mcp-servers/wrangler.toml` |\n| `apps/mobile` | Native mobile skeleton | intended Gateway → mobile projection | None | authenticated native | **partial skeleton → decision: FUND or ARCHIVE** | `apps/mobile/package.json` |\n| `apps/desktop` | Electron desktop skeleton | intended Gateway → desktop projection | None | authenticated desktop | **partial skeleton → decision: FUND or ARCHIVE** | `apps/desktop/package.json`, `apps/desktop/vercel.json` |\n| `apps/one-access-console` | Empty/local alias | none | None | unknown | **untracked/empty → DELETE residue** | physical directory; no tracked files |\n| `apps/platform-console` | Empty/local alias | none | None | unknown | **untracked/empty → DELETE residue**; `apps/platform` is the real console | physical directory; no tracked files |\n\n### Domain and Projection Binding Registry contract\n\nDomain hosts are routing inputs, not separate data authorities. The binding contract is:\n\n```text\nhostname → known/reserved/unknown classification → ProjectionId\n→ authenticated principal + tenant → RoleConfig + grants\n→ Gateway projection endpoint → Projection Engine → bounded SharedWorkbench DTO\n```\n\n| Contract element | Owner | Required behavior | Current evidence/status |\n| -------------------------------- | ------------------------------------------------------------ | ---------------------------------------------------------------------------------- | --------------------------------------------------------------------------- |\n| Host registry | Product routing, `apps/web/lib/projection-registry/hosts.ts` | Known role host resolves; reserved host bypasses; unknown workspace host fails 404 | **verified in current user change; retain** |\n| Middleware binding | Product routing, `apps/web/middleware.ts` | Attach projection headers only for known projections; reject unknown workspaces | **verified in current user change; focused tests pending in §13** |\n| Projection identifiers/contracts | `packages/projection-contracts`, `packages/workbench-config` | Stable role/module vocabulary, no user-facing engineering layers | **configured/wired** |\n| Composition | `packages/projection-engine` | Sole composer of bounded role-aware DTOs | **partial/configured**; deployed reachability and full data path not proven |\n| Backend registry | Gateway projection routes | Resolve frontend binding to tenant-scoped service/data contract | **partial**; direct Vercel rewrites and route-family competition remain |\n| Unknown host | Web edge | Fail closed without leaking tenant/projection data | **implemented by preserved change** |\n\nThe `apps/web` profile → compose → context path through Gateway is the strongest current projection\ndirection, but mock and fallback payloads remain. **Every view**, including restored donor views,\nworkflows, skills, agents, Platform modules, and marketplace/control views, requires an explicit\nfrontend-to-backend projection/capability binding; component presence is not a binding.\n\nPublic solution taxonomy must not expose internal `brandstore` or `book-of-records`/`orgmemory`\nas marketing solutions. Host/domain changes require route, middleware, redirects, sitemap,\nnavigation, host map, and resolver tests to move together.\n\n## 5. Worker service manifest\n\nStorage abbreviations: **N** Neon canonical, **D** D1 operational, **K** KV/cache,\n**DO** Durable Object, **P** provider. “Intent” means no direct canonical/provider authority.\n\n### 5.1 Core release profile (nine Workers)\n\nThe actual release script publishes only the nine rows below. It explicitly does **not** publish\n`spine`, `hermes`, `mcp-pool`, `provider-management-mcp`, `integration-management-mcp`,\n`twin-orchestrator`, `loader`, `store`, `webhook-ingress`, or the hidden Workers under `apps/` and\n`packages/`. Some are referenced through bindings, but a binding to a service excluded from the\nrelease profile is a dependency gap, not deployment proof. Because Spine authority, durable\nbindings, governed execution and reconciliation depend on excluded services, the nine-Worker\nprofile cannot currently prove the canonical release loop.\n\n| Service | Reason / owner | Upstream → downstream | Authority | Boundary/target | Status → disposition |\n| ---------------- | --------------------------------------------------- | -------------------------------------------- | ------------------------------------- | ------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |\n| `pipeline` | LOAD/NORMALIZE/STORE promotion owner; Data Platform | Gateway/loader → operational/canonical Spine | **sole intended N writer**, D staging | internal CF Worker | **drift/stop-ship → KEEP + CONNECT** placeholder/skipped canonical writes and legacy alternatives must be removed only after real writer proof |\n| `connector` | Compatibility router; Integration | Gateway → loader/mcp-connector/store | Intent; P delegated | internal CF Worker | **configured → ADAPT/MERGE** keep temporarily, publish owning boundaries |\n| `mcp-connector` | Public semantic MCP/provider OAuth adapter | Gateway/assistants → provider/capability | grants, governed P calls | public/internal CF Worker | **configured → KEEP + CONNECT** exact public tool and approval boundaries need deployed proof; legacy Firestore path is drift |\n| `connector-sync` | Scheduled/on-demand provider sync | connection registry → providers → pipeline | P read; D job state; no N | internal CF Worker | **configured → KEEP + CONNECT** to durable shared registry and reconciliation |\n| `knowledge` | Chunk/search/synthesis/promotion evidence | operational Spine → search/Twin | derived indexes, candidates only | internal CF Worker | **configured → KEEP** separate nested legacy server |\n| `continuity` | Session/event continuity | Gateway/Workbench → context assembler | D/K bounded context; no N | internal CF Worker | **configured → KEEP + CONNECT** enforce tenant/freshness boundaries |\n| `intelligence` | THINK, proposals, governance compatibility | projections → approval/Hermes | proposal/audit state; no P/N | internal CF Worker | **partial → SPLIT contractually** governance hard gate and execution owner must remain explicit despite co-location |\n| `workflow` | BFF, views, stream, HITL | Gateway → projection/workflow DO | D/DO operational; Intent | internal CF Worker | **configured → KEEP + ADAPT** do not become second Gateway/projection authority |\n| `gateway` | Intended single ingress and TenantGate | browser/MCP/webhooks → owners | none; routing/auth only | edge CF Worker | **drift → KEEP + CONNECT** direct Vercel rewrites and incomplete/commented bindings bypass or weaken single-ingress claim |\n\n### 5.2 Services outside core release\n\n| Service(s) | Reason / owner | Relationship and authority | Status → disposition; evidence |\n| --------------------------------------------------------- | --------------------------------------------------------------- | ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- |\n| `spine` | Legacy/operational Spine service; Data Platform | Gateway → D/cache; must not compete with Pipeline N writer | **bound outside core + drift → ADAPT/MERGE**; `services/spine/wrangler.toml` |\n| `loader`, `store` | ingestion retrieval and compatibility storage; Integration/Data | connector → loader/store → pipeline; provider read/D staging only | **bound indirectly, outside core → CONNECT** and clarify why core connector depends on non-core deploys |\n| `iw-agent-runtime` | agent runtime; AI Platform | Gateway → governed capabilities; no N/P direct | **bound outside core → CONNECT or add explicit profile** |\n| `webhook-ingress` | provider event ingress; Integration | provider → Gateway/Pipeline; append evidence only | **bound outside core → CONNECT** required for reconciliation |\n| `mcp-pool` | internal capability registry/router; Capability Platform | Gateway/management MCPs → internal tools | registry/health only | **bound outside core → CONNECT** not deployable/reachable in core profile |\n| `admin`, `billing`, `tenants` | internal control/account services; Platform Ops | Gateway → control stores | scoped control writes, never N business truth | **bound outside core → KEEP + CONNECT** remove mystery admin: document routes, roles, and audit |\n| `folder-watcher` | file ingress | Gateway (prod/config variance) → loader/pipeline | evidence only | **partially bound → ADAPT** make environment profile explicit |\n| `context-fetch` | tenant context read facade | callers → bounded context | read/cache only | **configured, non-core → CONNECT or ARCHIVE** no unexplained parallel context path |\n| `task-management` | internal tasks MCP | MCP Pool → task state/events | operational task state | **indirect/non-core → CONNECT** |\n| `provider-management-mcp` | connections/apps/OAuth control | Platform/Gateway → provider grants | connection/grant metadata | **orphaned → CONNECT** canonical owner of provider-once registry |\n| `integration-management-mcp` | connectors/sync/webhooks/schema control | Platform/Gateway → integration services | control metadata | **orphaned → CONNECT** |\n| `twin-orchestrator` | Silent Twin orchestration | THINK → governed proposal | candidates only | **orphaned/critical → CONNECT** |\n| `hermes` | approved action dispatch | Governance token → adapter/provider → reconciliation | governed P mutation + audit | **orphaned/architecture-critical → CONNECT, stop-ship**; stale/nonexistent binding references must be corrected |\n| `marketplace-installation` | install/activation lifecycle | marketplace → Flow D/grants/catalog | installation metadata only | **orphaned → CONNECT** to OneAuth and Platform Console |\n| `agent-registry` | governed agent catalog | Platform/MCP → agent runtime | registry only | **orphaned → CONNECT or MERGE** with capability registry |\n| `schema-ai` | schema assistance | connector evidence → candidate mappings | candidates only | **orphaned → CONNECT or ARCHIVE** |\n| `signals` | material event/signal service | Spine → Workbench/Twin | derived events | **orphaned → CONNECT or MERGE** |\n| `telemetry` | operational observability | all services → operator views | telemetry only | **orphaned → CONNECT** required for release evidence |\n| `vercel-mcp` | Vercel integration MCP | internal capability → Vercel | governed external mutation | **orphaned → CONNECT or ARCHIVE** |\n| `billing` | billing control (also above bound group) | Gateway → billing provider/state | billing state only | **configured outside core**; runtime proof absent |\n| `schema-ai`, `signals`, `telemetry` migrations | service-local operational schemas | service → own store | never implicit N authority | **partial**; migration ownership must be registered |\n| `ai-provider-mcp`, `core-engine`, `huggingface-inference` | local/build residue without product source | none | none | **legacy/residue → ARCHIVE/DELETE after tracked-state check** |\n| `knowledge/server` | nested Express/Firestore/GCS knowledge API | no workspace/release caller | legacy external stores | **legacy orphan → ARCHIVE** after data/export decision |\n\nMCP reconciliation backlog: the MCP Pool has a service-binding/source-name mismatch and a\nprocess-local registry; the management MCPs are scoped facades but lack core-profile reachability;\nthe MCP Connector has configured external-boundary code without live external proof; and\n`apps/mcp-servers` contains configuration placeholders. Reconcile names, bindings, durable registry,\npublic/internal inventory, deployment profile, OAuth/tenant scope and health evidence before MCP or\nmarketplace readiness claims. None may become a duplicate connection, policy, or projection\nauthority.\n\nThe Gateway itself has zero inbound service bindings because it is edge ingress; that is not an\norphan signal. All other zero-inbound Workers require an explicit caller and deployment profile.\n\n## 6. Package coverage manifest\n\nPackages define contracts and reusable implementation; they do not become independent product or\ncanonical data authorities. Each item below is accounted for. Package manifests are evidence of\nbuild intent, not consumption or publication.\n\n| Family / packages | Reason and owner | Upstream → downstream; authority | Status → disposition |\n| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ |\n| Kernel/contracts: `kernel`, `types`, `contracts`, `connector-contracts`, `context-contracts`, `projection-contracts` | Frozen vocabulary and boundary types; Architecture/Platform | architecture → all apps/services; no storage | **KEEP + MERGE definitions where duplicated**; `contracts`/some narrow packages have weak consumption evidence |\n| Identity/tenancy: `auth`, `rbac`, `tenancy`, `auth-connectors-mfe`, `auth-onboarding-mfe`, `one-access-ui`, `host-platform-connector` | Flow D, consent, grants, reusable OneAuth UI; Identity | identity provider/host → Gateway/apps; session/grant only | **KEEP + CONNECT**; default tenant/preview fallback is drift and shared authority is unproven |\n| Projection/Workbench: `workbench-config`, `projection-engine`, `platform-mfe`, `domain-shells`, `ui`, `design-system`, `knowledge-bank-ui` | Role configuration, composition, control UI and presentation; Product | Gateway contracts → browser surfaces; no writes | **KEEP core; CONNECT UI; MERGE duplicate libraries; ARCHIVE legacy knowledge UI** |\n| Ingestion: `loader`, `normalizer`, `connectors`, `connector-utils`, `provider-base`, `adapters`, `webhooks` | Provider discovery/read/normalization/adapters; Integration | connection → provider → Pipeline; evidence/operational only | **KEEP + CONNECT**; avoid duplicate implementations inside services without explicit ownership |\n| Spine/data: `spine-entities`, `spine-schema`, `spine-schema-generator`, `db`, `lib`, `spine-network`, `hermes-spine-memory` | entity/schema/data utilities and distribution; Data Platform | Pipeline/Spine → consumers; only Pipeline runtime may receive N write authority | **KEEP canonical contracts; ADAPT/ARCHIVE zero-consumer and dist-only packages** |\n| Capability/agents: `core`, `core/capability-registry`, `adk`, `accelerators`, `orchestrator`, `handoff-adapters`, `integratewise-mcp-tool-connector`, `model-gateway`, `omni-router` | capability catalog, agent kit, model routing and handoff; AI/Capability Platform | Twin/Governance → MCP/Hermes/providers; no direct N/P | **KEEP + CONNECT/MERGE**; reachability and approval enforcement required |\n| APIs/SDK: `api`, `gateway-sdk`, `sdk`, `bootstrap`, `config` | Gateway clients, bootstrap, shared configuration; Platform | apps/services → Gateway; `api` also hides a Worker | **KEEP + SPLIT classification** `packages/api` must be in Worker/deploy inventory; eliminate same-name cross-env binding |\n| Validation: `integration-tests` | cross-service contract/release proof; Quality | release profile → evidence | **KEEP + CONNECT** to clean-tenant gates |\n| Product integrations: `coda-pack`, `analytics` | external packaging/analytics helpers | capability/provider → external | **decision → CONNECT or ARCHIVE**; no unexplained published asset |\n| Residue: `config-backup-1782830543`, `lib-backup-1782830543` | timestamped local backups | none | **untracked/excluded → DELETE residue only with explicit approval** |\n\n### Package-by-package owner/disposition register\n\nThis compact register closes the “approximately 57” logical-unit inventory. The family table above\ndefines upstream/downstream and authority; this register makes every unit discoverable.\n\n| Disposition | Packages |\n| --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| **KEEP** | `accelerators`, `adk`, `auth`, `auth-connectors-mfe`, `auth-onboarding-mfe`, `bootstrap`, `config`, `connector-contracts`, `connector-utils`, `connectors`, `connectors/memory-repo`, `context-contracts`, `db`, `gateway-sdk`, `host-platform-connector`, `integration-tests`, `kernel`, `lib`, `loader`, `model-gateway`, `normalizer`, `omni-router`, `one-access-ui`, `platform-mfe`, `projection-contracts`, `projection-engine`, `provider-base`, `rbac`, `sdk`, `spine-entities`, `spine-schema`, `spine-schema-generator`, `tenancy`, `types`, `webhooks`, `workbench-config` |\n| **CONNECT / prove consumption** | `adapters`, `analytics`, `coda-pack`, `core`, `core/capability-registry`, `handoff-adapters`, `hermes-spine-memory`, `integratewise-mcp-tool-connector`, `orchestrator`, `spine-network` |\n| **MERGE / select one UI authority** | `design-system`, `ui`, `domain-shells` |\n| **SPLIT deployment classification** | `api` (package plus bound Worker) |\n| **ARCHIVE candidate** | `contracts` if its frozen definitions are merged, `knowledge-bank-ui` with `knowledge/server` |\n| **DELETE local residue after approval** | `config-backup-1782830543`, `lib-backup-1782830543` |\n\nNo deletion is authorized by this ledger; it records the required outcome after ownership and data\nretention checks.\n\n### Public package and artifact registry requirement\n\nEvery publishable package, tarball, Plugin/MCP manifest, generated SDK, schema artifact and release\nbundle must have one registry record containing: canonical name, owning team, source path, build\ncommand, version, commit, content digest/signature, public/internal boundary, supported consumers,\ncompatibility contract, publication channel, environment, supersedes/superseded-by links,\nrevocation status and verification evidence. `private: false`, a tarball in `releases/`, or a\nmanifest in the tree is packaging intent—not proof that the artifact is current, published, safe,\nor consumed. Unregistered public artifacts block release.\n\n## 7. Configuration and deployment roots\n\n| Root | Reason/owner | Target / authority | Status → disposition |\n| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------ | -------------------------------------- | --------------------------------------------------------------------------------------------------------- |\n| root `vercel.json`, `configs/root/vercel.json` | browser routing/deploy description; Product Ops | Vercel; no Worker deployment authority | **configured → MERGE** canonical Vercel config and eliminate contradictory direct service rewrites |\n| app `vercel.json` files | app-specific browser builds | Vercel | **configured → KEEP/ADAPT** only for funded product surfaces |\n| root `wrangler.toml`, `wrangler.dev.toml`, `wrangler.customer-zero.toml`, `wrangler.external-users.toml` | environment/profile binding declarations; Platform Ops | Cloudflare Workers | **configured → KEEP + ADAPT** profile matrix must name every included/excluded Worker and tenant boundary |\n| `services/*/wrangler.toml`, `apps/mcp-servers/wrangler.toml`, `packages/api/wrangler.toml`, `packages/integratewise-mcp-tool-connector/wrangler.toml`, `packages/webhooks/wrangler.toml` | deployable Worker manifests | Cloudflare | **deployment evidence only**; register all non-service Workers in release tooling |\n| `configs/templates/{packages,services}` | scaffolding | generated future components | **KEEP** but templates must inherit canonical auth, tenant, telemetry, and deployment contracts |\n| `configs/scripts` | config generation/validation | operator tooling | **KEEP + CONNECT** to drift checks |\n| `infrastructure/config` | runtime/catalog manifests | deployment/catalog inputs | **KEEP + RECONCILE** with Wrangler/release profile; not independent truth |\n| `.github/workflows` and `scripts/release` | CI publication and verification | Vercel/Cloudflare/packages | **KEEP**; core nine is intentional but incomplete for canonical loop |\n\n### Deployment profile matrix\n\n| Profile | Proven by repo | Missing proof |\n| -------------- | ------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ |\n| Core Workers | nine-service release script and matching validation/workflow intent | critical non-core dependencies, Hermes, management MCPs, MCP Pool, telemetry, actual deployment health |\n| Customer Zero | `wrangler.customer-zero.toml`, Customer Zero specs/runbooks | isolated tenant evidence across entire loop; cannot certify external readiness alone |\n| External users | `wrangler.external-users.toml` and release docs | clean tenant, real consent/provider, audit, reconciliation, rollback, multi-surface refresh |\n| Local/dev | dev Wrangler/root scripts | no production inference permitted |\n| Browser apps | Vercel configs/package manifests | current production project/domain mapping and Gateway-only ingress |\n\nMarketing deployment authority is unresolved while root/app Vercel configurations, rewrites,\ndomain references and more than one marketing-capable app can describe overlapping public routes.\nThe required owner is one declared Vercel project and one route/domain manifest for the public\ncompany/product surface. Cloudflare may serve shared runtime APIs, but it must not become a second\nmarketing deployment authority. A DNS target, rewrite or merged PR is not proof of the currently\nserving deployment.\n\n## 8. Storage and migration authority register\n\nMigration duplication is evidence of unresolved storage ownership. The tree contains canonical,\noperational, fixtures, copied public docs, legacy Supabase, and service-local roots. A migration is\nnot canonical merely because it is SQL.\n\n| Root family | Intended owner/target | Status → disposition |\n| -------------------------------------------------------------------------------------- | ------------------------------------------------------ | ------------------------------------------------------------------------------------------------ |\n| `migrations/`, `migrations/v0-core` | canonical Neon schema history, Data Platform | **partial → KEEP + declare one migration runner/order** |\n| `services/pipeline/migrations` | Pipeline canonical/operational writer schema | **critical → MERGE/CONNECT** to the authoritative Neon history; placeholder writes block release |\n| `services/{intelligence,knowledge,mcp-connector,schema-ai,signals,tenants}/migrations` | service-local D1/operational stores | **KEEP where owner is live; ARCHIVE with orphan otherwise** |\n| `services/{connector-sync,workflow}/d1_migrations`, `services/workflow/migrations` | scheduled sync/workflow operational D1/DO state | **KEEP + register ordering/tenant scope** |\n| `services/context-fetch/migrations` | context cache/read model | **decision → CONNECT or ARCHIVE** with service |\n| `packages/api/migrations`, `packages/webhooks/migrations`, `packages/api/schema.sql` | hidden Worker/package state | **SPLIT and register** in deployment/migration tooling |\n| `sql-migrations/*`, `docs/internal/sql-migrations/*` | duplicated operational/reference migrations | **legacy/reference → ARCHIVE**, never run from docs |\n| `apps/web/public/docs/**/sql` and mirrored `docs/domains/**/sql` | published copies/reference artifacts | **documentation only → KEEP labeled; never execute** |\n| `supabase/migrations`, `migrations/supabase-export` | superseded provider/storage path | **legacy → ARCHIVE after data-retention/export decision**; prohibited in product path |\n| `services/*/src/{schema,fixtures}`, `apps/web/scripts` SQL | schemas/fixtures/scripts, not automatically migrations | **ADAPT** label purpose and block production runner discovery |\n\nCanonical N writes belong only to the governed Pipeline writer. D1/KV/DO/search stores are bounded\noperational projections. Memory and model output inform truth but cannot promote themselves.\n\nThe migration registry must record, for every migration root: storage target, logical owner,\nenvironment, runner, ordering/version scheme, tenant scope, checksum, applied-state evidence,\nrollback/forward-fix policy and whether the root is executable, fixture-only, copied documentation\nor legacy export. No release runner may discover SQL transitively from `docs/`, `public/`, fixtures,\nSupabase exports or an orphaned service.\n\n## 9. Connection, identity, and consent lifecycle (Flow D before A/B/C)\n\n| Phase | Required owner and record | Reuse/guard | Current status |\n| ------------------------- | -------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Host connection discovery | OneAuth host adapter; host identity, eligible connections and capabilities | host is first source; metadata is not tenant authority or unrestricted transfer permission | **partial/configured** |\n| Discovery Agent mapping | bounded explorer → Gateway/OneAuth confirmation | declared capabilities only; proposes reuse/mapping; no credentials, consent inference, binding write or canonical authority | **intended/partial; runtime boundedness not proven** |\n| User authentication | shared identity authority | audience-bound session; no preview identity in release | **drift:** platform default-tenant/preview fallbacks do not prove shared identity |\n| Tenant binding | TenantGate + membership authority | fail closed; every durable record has `tenant_id` | **partial** |\n| Consent/grant | Provider Management + identity | provider/scopes/purpose/user/tenant/audit | **partial/orphaned owner** |\n| Adopt/connect once | Gateway-owned durable `ConnectionBinding` | prefer host delegation; never copy host token; IW OAuth fallback only; reusable by authorized consumers | **partial/drift:** Gateway tenant/Nango/`tenant_integrations` lifecycle exists but is not runtime-proven; Platform global-memory registry and OneAccess APIs are scaffold/mock; competing registry tables and D11 identity remain unresolved |\n| Discover capabilities | host/provider discovery → connector projections | projections are not re-connections | **configured; runtime proof absent** |\n| Hydrate | loader/sync → normalizer → operational Spine | provenance, cursor, idempotency | **partial** |\n| Activate Workbench | Projection Binding Registry + RoleConfig | RBAC/policy-bounded DTO | **partial** |\n| Revoke/rotate | Provider Management | fan-out invalidation, credential rotation, audit | **not end-to-end proven** |\n\n## 10. Current wiring versus canonical target\n\n| Capability | Current wiring | Canonical target | Gap/status |\n| ------------------- | ----------------------------------------------------------------------------------- | ------------------------------------------------------------------------- | ------------------------------- |\n| Identity/tenant | app/platform fallbacks and multiple auth surfaces | one authoritative Flow D before data/context | **drift, stop-ship** |\n| Connect once | Gateway lifecycle/Nango/`tenant_integrations` plus competing UI/scaffold registries | one Gateway `ConnectionBinding`, host-declared first, reusable everywhere | **partial/drift, stop-ship** |\n| Ingress | Gateway routes plus direct Vercel rewrites/bindings | Gateway/TenantGate single policy ingress | **partial/drift** |\n| Load/normalize | multiple useful loaders/normalizers | one owned chain into operational Spine | **configured, integration gap** |\n| Canonical promotion | placeholder/skipped writer and legacy paths | Pipeline performs real governed N transaction with provenance/outbox | **stop-ship** |\n| Projection | configs/engine/routes and competing families | registry-bound role projection, one Workbench namespace | **partial/drift** |\n| Twin/agents/MCP | substantial code; core reachability gaps | THINK-only Twin through internal MCP/capability fabric | **partial/orphaned** |\n| Approval/action | governance code co-located; Hermes orphaned | cryptographic approval → Hermes → adapter | **stop-ship** |\n| Reconciliation | sync/webhook pieces exist | outcome re-ingested, reconciled, audited, all surfaces refreshed | **not proven** |\n| Platform Console | fail-closed discovery plus mocks/TODOs | real control plane over owning APIs, never SoT | **partial** |\n| Marketplace | contracts, release bundles, manifests, install service | signed/versioned distribution → Flow D install/consent → activation | **partial/orphaned** |\n| External release | scripts/config/specs | clean-tenant evidence pack for full loop | **not runtime-proven** |\n\nOperational `brandstore` and `book-of-records`/`orgmemory` bindings are internal-only. They may be\nused by authorized operational projections but cannot appear as public marketing solutions,\nmarketplace categories, or unauthenticated navigation.\n\n## 11. Marketplace and distribution assets\n\n| Asset | Reason/owner | Boundary/authority | Status → disposition |\n| ---------------------------------------------------------------------- | ------------------------------------------------ | ------------------------------------------------ | ------------------------------------------------------------------------------- |\n| `marketplace/` | connector/catalog content | public catalog metadata only | **KEEP + reconcile** with canonical connector registry |\n| `releases/iw-spine-network-*` bundles/checksums | ChatGPT/Claude/Notion/MCP distribution snapshots | public signed/versioned artifact; no credentials | **configured artifacts → KEEP as releases**, verify provenance and supersession |\n| `apps/web/app/.well-known/ai-plugin.json` and `public/manifest.json` | discovery manifests | public | **KEEP + validate** against current domains/tool inventory |\n| `infrastructure/config/{spine-network,adk}/manifest.yaml` | runtime/package manifests | internal/config | **KEEP + connect** to build/release source of truth |\n| `packages/contracts/src/marketplace` | marketplace contracts | internal reusable schema | **CONNECT or merge** into consumed contract package |\n| `services/marketplace-installation` | installation lifecycle runtime | authenticated control | **orphaned → CONNECT** |\n| `scripts/seed-marketplace-apps.ts`, marketplace migrations | seed/catalog state | controlled operator path | **ADAPT** idempotency, environment, tenant and ownership guards |\n| `docs/submission/plugin-directory-submission.md` and marketplace specs | submission/runbook evidence | documentation | **KEEP subordinate**; claims gated by deployed proof |\n\nThe public Plugin exposes exactly the canonical 19 semantic IW Spine tools. Internal MCP Pool,\nprovider-management, integration-management, task-management, and raw provider tools are not\npublic marketplace inventory.\n\n## 12. Remediation ledger\n\n| ID | Action | Scope | Acceptance evidence | Order |\n| --- | ----------------------------------------- | --------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----- |\n| R1 | **KEEP + CONNECT** | Flow D shared identity/TenantGate | no default/preview release path; negative tenant tests; shared session accepted by all surfaces | 1 |\n| R2 | **KEEP + CONNECT** | durable Gateway `ConnectionBinding` | eligible host connection discovered first; required binding fields persisted; two products reuse it; revoke/rotate propagates; no host-token copy or unrestricted transfer | 2 |\n| R3 | **MERGE** | Gateway ingress policy | Vercel routes only to Gateway/public allowed endpoints; complete Worker bindings per profile | 3 |\n| R4 | **CONNECT** | loader/normalizer/operational Spine | idempotent A/B ingest with provenance and tenant isolation | 4 |\n| R5 | **ADAPT + DELETE legacy after migration** | canonical Pipeline writer | ✅ Neon primary writer implemented (hard-fail, R8 boundary guard, `DATABASE_URL` bound). Remaining: outbox pattern in Neon, retire `pipeline/src/spine/` legacy writer, delete `CANONICAL_SPINE_DB` D1 binding after edge cache migration | 5 |\n| R6 | **MERGE + CONNECT** | projection route families and registry | one canonical namespace; host/role/RBAC contract tests; unknown host fail closed | 6 |\n| R7 | **CONNECT** | Platform Console control APIs | no mocks in release; every module names service owner, permissions, audit, freshness | 7 |\n| R8 | **CONNECT** | MCP Pool, management MCPs, Twin runtime | explicit release profile, health/routes, public/internal inventory tests | 8 |\n| R9 | **SPLIT contractually + CONNECT** | Governance and Hermes | approval token validation; denied/expired/replayed tokens cannot mutate provider | 9 |\n| R10 | **CONNECT** | provider writeback/re-ingestion/reconciliation | same action observed back, correlated, reconciled, audited, multi-surface refresh | 10 |\n| R11 | **ADAPT** | marketplace/install lifecycle | signed versioned assets, Flow D consent, clean uninstall/revoke, exact 19 public tools | 11 |\n| R12 | **SPLIT** | hidden Workers under `apps/`/`packages/` | deployment and migration registry covers each target/environment | 12 |\n| R13 | **ARCHIVE** | legacy Supabase/Firestore/nested knowledge UI-server/docs | data-retention decision, no imports/bindings/runners, clear lineage label | 13 |\n| R14 | **DELETE** | empty/untracked aliases/backups | explicit approval and tracked/data check; recoverable cleanup | 14 |\n| R15 | **ADAPT** | release evidence | Customer Zero plus external clean tenant full-loop evidence, rollback and observability | 15 |\n\n## 13. Dependency-ordered implementation and release program\n\nThis is an order lock; downstream work does not compensate for a missing upstream authority.\n\n1. **Spine authority:** select the single canonical Spine implementation and real Neon target;\n replace the Pipeline placeholder/cache-success path with truthful transactional writes. Pipeline\n is the sole canonical writer; other Spine implementations become bounded reads or are retired.\n2. **Binding and deployment closure:** reconcile names, environment bindings and release profiles;\n register every Vercel app, Worker, package Worker, dependency and migration root. Remove\n browser-to-internal-service bypasses.\n3. **Flow D and ConnectionBinding:** remove identity/tenant fallbacks; make Gateway/Provider\n Management the durable binding owner; discover host capabilities first; reconcile competing\n tables; never copy host tokens; prove consent, grants, revocation and consumer reuse.\n4. **Flow A/B/C remediation:** route structured provider records (A), evidence/documents (B) and\n cognitive candidates (C) through tenant-bound ingress, loader, normalizer, operational Spine and\n governed promotion. Discovery produces proposals only. Flow C never self-promotes, and no stage\n may report success when canonical persistence was skipped.\n5. **Projection closure:** require a registered Projection Binding for every view; converge route\n families and prove role, tenant, freshness, provenance, empty/error and unknown-host behavior.\n6. **Governance/Hermes loop:** replace the nonexistent/stale workflow binding, make Hermes reachable,\n validate approval tokens, execute through the selected provider route, then re-ingest, reconcile,\n audit and refresh all affected projections.\n7. **Twin ownership:** after the action loop works, bind the Silent Twin to THINK-only evidence and\n proposal ownership through the MCP/capability fabric. Twin never becomes a canonical writer or\n an alternate action path.\n8. **Control and distribution:** replace Platform Console fixtures/TODOs with owner APIs; validate\n public package/artifact manifests, exact public tools, install/upgrade/uninstall/revoke and\n marketplace claims.\n9. **Customer Zero cross-surface proof:** exercise OneAuth, Spine Network MCP, Workbench, Platform,\n Twin and provider reconciliation as a controlled rehearsal, followed by an external clean tenant.\n10. **Consolidation:** only after proof, merge duplicate packages/routes and archive/delete legacy\n components. Do not clean first and discover dependencies later.\n\n## 14. Release proof and unresolved decisions\n\n### Required proof pack\n\n- commit/artifact identifiers and Vercel/Cloudflare deployment identifiers;\n- profile-to-Worker binding inventory and health checks;\n- clean user, tenant, membership, consent and provider connection evidence;\n- A/B ingest provenance, normalization and real canonical promotion record;\n- role-aware projection/host/RBAC and negative isolation tests;\n- Twin proposal and cryptographically bound approval/denial/replay tests;\n- Hermes/provider mutation and correlated re-ingestion/reconciliation audit;\n- multi-surface refresh/freshness evidence;\n- marketplace install, upgrade, revoke and exact public-tool inventory;\n- rollback/recovery and telemetry evidence.\n\n### Release evidence manifest\n\nEach release candidate must produce one immutable manifest that joins otherwise fragmented proof:\n\n| Manifest section | Required fields |\n| ------------------- | ---------------------------------------------------------------------------------------------------------------------------- |\n| Source | repository, commit, dirty-tree declaration, build run, approving change set |\n| Browser deployments | Vercel project, app/root, domains/routes, deployment ID/URL, artifact digest, environment |\n| Worker deployments | canonical service, Wrangler source, Worker name, environment, version/deployment ID, bindings and health |\n| Packages/artifacts | package/bundle name, version, digest/signature, registry/channel, public/internal status, compatibility |\n| Migrations | root, target store, owner/runner, ordered versions/checksums, applied evidence, forward-fix/rollback status |\n| Identity/bindings | user/tenant authority, consent record, `ConnectionBinding` source/scopes/grants, revocation and negative isolation proof |\n| Flows A/B/C | ingress IDs, provenance, normalize result, operational record, promotion record and real canonical transaction ID |\n| Projections | View → Projection Binding → Gateway route → owner mapping, tenant/RBAC/freshness and negative tests |\n| Action loop | proposal, approval token/hash, Hermes dispatch, provider result, re-ingestion, reconciliation, audit and refresh IDs |\n| Distribution | OneAuth/Spine Network MCP versions, exact public tools, install/upgrade/revoke checks, marketplace listing identity |\n| Verification | test suites, Customer Zero run, external clean-tenant run, telemetry window, rollback/recovery exercise and known exceptions |\n\nThe manifest may reference signed evidence artifacts, but every reference must be immutable and\nenvironment-specific. Missing sections are release blockers, not documentation follow-ups.\n\n### Decisions that remain open\n\n1. Which identity provider/record is the final shared authority, and when are all preview/default\n tenant fallbacks prohibited?\n2. Which durable store and service own the provider-once registry, connection leases, rotation and\n revocation?\n3. Are non-core but canonical services added to the core profile, or is there a dependency-ordered\n multi-profile release? “Bound somewhere” is not a release policy.\n4. Which Workbench route family is canonical, and what is the redirect/deprecation window?\n5. Does `packages/api` remain a Worker, move to `services/`, or merge into an existing owner?\n6. Which UI library survives (`ui`, `design-system`, domain-shell components), and who migrates\n consumers?\n7. Are mobile, desktop, portfolio, context-fetch, schema-ai, signals, and vercel-mcp funded now or\n archived?\n8. What is the data-retention/export plan for Supabase, Firestore/GCS knowledge, and other legacy\n provider paths?\n9. Which marketplace bundle is current, who signs it, and what is the revocation/supersession rule?\n10. What objective evidence promotes Customer Zero learning into external GTM readiness?\n\nUntil R1–R10 and the clean-tenant proof pack pass, GTM and release planning may continue as a\n**conditional plan**, but must not be labeled final or generally available.\n\n## 15. Pull-request lineage: protected Workbench capabilities\n\nThis section records read-only GitHub evidence inspected on 2026-08-13. PR state is not checkout\nstate, and a merged label is not architectural approval. No PR was merged, closed, reopened, or\notherwise changed during this review.\n\n**Protected scope:** workflows, skills, agents, capability registry/execution, and their Workbench\nentry points are existing product scope. Donor-view or taxonomy work must preserve these surfaces;\nabsence from a replacement registry is a regression, not permission to retire them.\n\n| PR | Change evidence | Shared-platform assessment | Disposition / sequencing advice |\n| ----------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |\n| [#139 — migrate donor domain views](https://github.com/integratewise/integratewise-live/pull/139) | Merged 2026-08-11; 268 files, approximately 55,579 additions and one deletion. Adds 261 donor domain-view components, a new dynamic domain-view registry, hydration compatibility hooks, and `DomainViewShell` integration. It includes donor workflow/capability views, but its changed-file inventory does not add or prove preservation of the existing first-class skills and agents routes/registries. | **Partial alignment with Projection direction, regression risk elsewhere.** Binding donor views to `AuthorizedProjectionPayload` and `ProjectionRouteRuntime` is directionally correct. The bulk snapshot, compatibility stubs, fixture-heavy components, and incomplete protected-surface coverage do not prove Gateway/Spine/OneAuth authority or full capability preservation. The reported post-merge loss of existing workflow/skill/agent work is treated as material regression evidence. | **Do not re-merge wholesale.** Extract the registry/hydration pattern and individually accepted views only after protected-surface contract tests exist. Require real bounded projection data; stubs/fixtures cannot become release truth. |\n| [#140 — revert #139](https://github.com/integratewise/integratewise-live/pull/140) | Open at inspection time; mechanical inverse of #139: 268 files, approximately 55,579 deletions and one addition. It removes the donor registry, hydration hook, workflow canvas/list views, and donor capability views along with the rest of the import. | **Rollback, not target architecture.** It avoids retaining the risky bulk integration, but also removes useful donor scope and supplies no shared Spine/OneAuth/connector/platform reconnection plan. | Use only as change-isolation evidence. Do not merge merely to “restore” protected capabilities; verify the base actually contains them and recover missing pieces from their authoritative commits/sources. |\n| [#141 — SpineWorkspace/domain refactor](https://github.com/integratewise/integratewise-live/pull/141) | Merged 2026-08-11; 178 files, about 5,317 additions and 6,749 deletions. Changes marketing/domain taxonomy, projection registry and teleport switcher, centralizes marketing content, modifies CI, and deletes `apps/portfolio`. It does not restore #139's donor view registry and its file list does not add workflow/skill/agent preservation coverage. | **Mixed.** “Spine Workspace” branding, industry-as-context, marketing consolidation, and removal of a duplicate portfolio app are directionally aligned. The registry revision includes internal `brandstore`/`orgmemory` identifiers and competing domain names; they may be internal projection identifiers but must not become public marketing solution routes. It does not close shared identity, connection, Gateway, or projection-backend contracts. | Retain only changes already reconciled with current canon. Revalidate route/redirect/sitemap/host-map/tests as one unit. Do not treat #141 as restoration of #139 or of protected capabilities. |\n\n### Required restoration sequence\n\n1. Inventory and pin the existing route, navigation, registry, component, test, workflow service,\n capability service, skill, and agent entry points on the current canonical base.\n2. Add non-regression tests proving each protected surface remains discoverable and consumes a\n tenant/RBAC-bounded Gateway projection or capability contract.\n3. Reconcile projection identifiers with the canonical public/internal taxonomy. Internal\n `brandstore` and `orgmemory` may remain internal bindings; they cannot become public solutions.\n4. Port PR #139's `AuthorizedProjectionPayload` hydration/registry mechanics as a small reviewed\n change, without compatibility identity stubs or fixture truth.\n5. Port domain views by role family in bounded batches. Each batch must prove loading, empty/error/\n stale states, RBAC, accessibility, and no replacement of workflow/skill/agent navigation.\n6. Connect workflow/capability/agent actions through Governance and Hermes; until then, imported\n controls are declarative previews, not executable product proof.\n7. Only after the protected surfaces and closed loop pass may obsolete donor/duplicate code be\n archived. Never use a bulk revert or historical merge label as the source of truth.\n\nThe direct checkout inspected for this companion contains existing capability-engine,\ncapability-registry, agent-registry, agent route, capability route, agent runtime view, and agent\nactivation drawer sources. It contains no populated `apps/web/components/domain-views` tree at\nthe inspected HEAD. This is checkout evidence only; it does not infer the contents of a remote\nmerged commit or deployed Vercel project.\n\n## 16. First Spine Workspace vertical integration proof\n\nThe deterministic proof in\n`services/intelligence/src/chatgpt-brainstorm.vertical.integration.test.ts` binds three explicit,\ntenant-scoped exemplars to one work context without using or requiring provider credentials:\n\n| Flow | Exemplar | Enforced path | Proof boundary |\n| ---- | --------------------------------------------- | ---------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ |\n| A | structured CRM account fixture | explicit item consent → Loader fixture adapter → real Normalizer → Pipeline operational D1 | provenance and tenant isolation; no live CRM or canonical promotion claim |\n| B | authorized document excerpt fixture | explicit item consent → Loader fixture adapter → real Normalizer → Pipeline operational D1/reference | bounded excerpt and provenance; no full document-history ingestion |\n| C | user-authorized ChatGPT chat/window reference | explicit reference handoff → Brainstorming → deterministic Triage comparison → novel-only candidate | no Loader/Normalizer; duplicate content consolidates citations; candidate remains `pending_governance` |\n\nThe public `get_context` IW-Spine-Network MCP dispatcher reads the correlated active work context\nand returns minimum-necessary references and citations for A, B, and C. It does not return the CRM\nrecord, document excerpt, ChatGPT excerpt, provider credential, or arbitrary chat history. A second\ntenant cannot read the first tenant's candidate, operational rows, or active context. The harness is\na **full local integration-path proof**, not proof of live provider authentication, deployed Worker\nbindings, external ChatGPT history access, or a canonical Neon transaction.\n\nFlow C intentionally bypasses Loader and Normalizer. Triage owns novelty, repetition, conflict and\nconsolidation decisions, but it does not own canonical writes. The proof stores only a governed\npromotion candidate in operational D1; promotion remains a later Pipeline/Spine governance step.\n\n### Omni Router / model-routing boundary\n\nThe checkout contains two different routing packages. `packages/omni-router` is currently a\nprovider-agnostic **connector tool executor** with connector credentials; it has no model-selection\nor fallback contract. `packages/model-gateway` is the package that currently defines provider/model\nrouting. Therefore the test uses a bounded `TriageReasoningRouter` contract seam and asserts that\nTriage emits only tenant, principal, purpose, policy and an input hash to the routing boundary. The\nexternal reasoning response is deterministic and local; no secret or raw excerpt is sent.\n\nConnecting that seam to the required private OmniRoute AI gateway, and reconciling the naming and\nownership overlap between `omni-router`, `model-gateway`, and the OmniRoute endpoint, is unresolved\nruntime wiring. This test does not claim the current Codex session, a deployed Triage Worker, or any\nexternal model call traversed that gateway.\n\nRun the proof with:\n\n```sh\nNODE_OPTIONS=--experimental-sqlite pnpm --dir services/intelligence exec vitest run src/chatgpt-brainstorm.vertical.integration.test.ts --reporter=verbose\n```\n\nCustomer Zero may begin only after replacing each fixture with an explicitly authorized real item,\nbinding the Triage reasoning seam to the deployed policy router, proving the Pipeline canonical\nwriter transaction rather than its operational candidate, and repeating the negative isolation and\nbounded MCP assertions against deployed services.\n"}