Canonical Ecosystem Coverage Companion
Status: Grounded implementation companion — subordinate to
INTEGRATEWISE_ARCHITECTURE.md and
SPEC_AMENDMENTS_v1.md
Verified against checkout: 2026-08-20
Purpose: Account for every repository component and turn the canonical architecture into
an explicit connection, ownership, deployment, storage, and remediation program.
This companion does not create new product concepts or override the architecture. It answers
the implementation question that the architecture alone cannot answer: why does each thing
in this repository exist, what owns it, what is it connected to, and what must happen to it?
Current state summary (2026-08-20)
| Category | Count | Status |
|---|---|---|
| Apps | 12 directories (11 manifests + mcp-servers) | 9 material surfaces; 3 empty/untracked aliases |
| Services | 31 directories (~30 Worker manifests) | 9 core release; 12 bound/outside-release; 11 orphaned |
| Packages | 48 directories (47 manifests + domain-shells) | ~57 logical units when nested counted |
| Core release Workers | 9 | pipeline, connector, mcp-connector, connector-sync, knowledge, continuity, intelligence, workflow, gateway |
| Stop-ship gaps | 5 | Identity drift, connect-once drift, canonical writer placeholder, Hermes orphaned, reconciliation unproven |
| Vertical integration proof | 1 | Three-flow A/B/C deterministic local proof (§16) |
| Open decisions | 10 | D11 identity, D12 isolation, D13 Twin/ADK, plus 7 more (§14) |
1. Evidence and status rules
The repository currently contains 15 physical apps/* directories (11 package manifests), 34
physical services/* directories (approximately 30 Worker manifests), and 52 physical
packages/* directories. The package tree represents approximately 57 logical package units
when nested packages and non-workspace source packages are counted. Product/browser coverage is
ten material app surfaces; skeletons, Workers under apps/, and empty/untracked aliases are
reported separately. Counts are a checkout snapshot, not an architectural target.
| Label | Meaning |
|---|---|
| verified | Direct code, test, route, or manifest evidence was inspected. |
| configured/wired | A route, binding, rewrite, or deploy manifest exists; this is not proof that the target is deployed or healthy. |
| runtime-proven | External or clean-tenant evidence proves the deployed path. No path receives this label from code alone. |
| partial | Useful implementation exists but a required authority, persistence, caller, or return path is missing. |
| orphaned | Implementation exists without a release path or inbound runtime binding. |
| legacy | Superseded implementation retained in the tree. |
| intended | Canonical target without complete implementation evidence. |
| drift | Current implementation conflicts with the canonical law. |
| decision | Product/engineering ownership must be explicitly decided before implementation. |
Evidence boundaries are strict:
package.json, Vercel configuration, Wrangler manifests, service bindings, rewrites, and code
prove presence or configured wiring, never runtime reachability.- Vercel owns browser/product deployments. Cloudflare Wrangler manifests are the deployment
evidence for shared platform/runtime services. Vercel rewrites may describe ingress but do not
prove a Worker exists. - The nine-Worker array in
scripts/release/deploy-platform.shis the intentional core release
profile:pipeline,connector,mcp-connector,connector-sync,knowledge,continuity,
intelligence,workflow,gateway. - No current repository evidence proves the complete clean-tenant action loop. Customer Zero is
useful evidence only when its tenant, deployment, provider, and audit boundaries are recorded;
it is not a substitute for external clean-tenant evidence.
2. Product and authority lock
| Question | Canonical answer | Implementation consequence |
|---|---|---|
| Company | IntegrateWise | Company, legal, marketing, and operator identity. |
| Product | Spine Workspace | Role-aware Workbenches are projections of one product, not separate products. |
| Protected core | The Spine | Tenant-wide organizational context; only governed Pipeline promotion writes canonical truth. |
| Browser/runtime split | Vercel / Cloudflare Workers | Browser shells do not become service or storage authorities. |
| 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. |
| Surface law | Multiple surfaces, one continuity system | Login, connections, data, context, and AI cannot become independent tenant islands. |
| Workbench law | One role-aware surface | Competing route families must converge behind the Projection Binding Registry. |
| Twin law | Silent, THINK-only, approval-bound | Twin creates proposals/context; it never directly writes the Spine or providers. |
Authority order is: canonical architecture → canonical amendment → retained implementation
specifications → this coverage companion → evidence/drift reports → lineage. AGENTS.md and
architecture README.md are pointers. CODEBASE_EXCAVATION.md is a dated drift baseline, not
current authority. Commercial/GTM documents cannot override this chain.
Connector ownership doctrine
Spine Workspace owns connectors at the ecosystem and governance layer; it does not claim to
wholly own or rebuild every provider integration. A connected host is the first source of
connection discovery. The shared platform discovers eligible host connections and, only after
identity, tenant, consent and policy checks, adopts a durable tenant ConnectionBinding that
authorized Workbenches, products and agents can reuse.
IntegrateWise owns OneAuth and the Spine Network MCP as its connector products. External
provider integrations remain provider/host capabilities, with host-connected access preferred.
Cataloging, governing or projecting an external connector does not make the underlying provider
integration an IntegrateWise-owned connector product.
The shared platform owns that binding's consent, capability grants, confirmed scopes, sync and
reconciliation lifecycle, health/freshness, provenance, consumers, revocation and audit. It never
copies a host token. Provider or host credentials remain behind their credential wall. Discovery
does not mean IntegrateWise created a second integration, received unrestricted access, or may
transfer all host data. Every read and action remains capability-, scope-, tenant-, purpose- and
approval-bounded. IntegrateWise-managed OAuth is a fallback only when the host cannot delegate the
required capability and the user explicitly consents.
The Discovery Agent is the bounded explorer of the host-connected and already-connected
environment. It may inspect declared app/capability metadata, connection health and consent-visible
scope; compare those declarations with Workbench needs; and propose mapping, reuse or an explicit
fallback connection. It never receives unrestricted provider credentials, cannot infer consent
from discovery, cannot read arbitrary provider data, cannot create its own ConnectionBinding, and
has no canonical Spine write authority. Gateway/OneAuth validates every discovery result before
Provider Management records or changes a binding.
The Gateway-owned binding must record tenant, workspace, principal, provider and provider-workspace
identity; source kind (host-declared or IW-managed); opaque credential/delegation reference;
confirmed scopes; consent; policy and capability grants; primary route; health and freshness;
provenance; sync and reconciliation state; authorized consumers; and audit/revocation state. Every
surface resolves and binds through Gateway rather than reading a UI-local registry.
3. End-to-end control and data map
Flow D: host identity → user identity → tenant membership → consent/grant → RBAC/policy
│
▼
Flow A/B: provider/webhook/file/MCP → Gateway → Loader → Normalizer → operational Spine
│
▼
promotion record + provenance
│
▼
governed Pipeline canonical writer
│
Neon canonical Spine ─────┤
▼
bounded D1/KV/search projections
│
Projection Binding Registry → role-aware Workbench
│
Flow C: operational evidence → THINK/Twin → governed intent → APPROVE token
│
▼
Hermes → capability/MCP/provider adapter
│
▼
provider result → re-ingestion → reconciliation → projection refresh
Current result: individual segments are verified or configured, but the chain is partial.
Canonical promotion, durable shared connection reuse, authoritative shared identity, Hermes
reachability, and the closed reconciliation/refresh loop are release blockers.
4. Application and public/domain surface manifest
Every browser surface must consume Flow D and Gateway-owned contracts. None in the write column
means it must not write canonical or provider state directly.
The currently declared shared host ownership is www → marketing, auth → auth, platform → platform, and operational role hosts → web. docs, activation, and connector have app roots
but no reconciled release host owner; they are non-release until assigned or deliberately invoked
inside an owned shell. Vercel browser ownership and Cloudflare Worker ownership must be recorded in
one deployment registry. A rewrite between them is wiring evidence, not ownership or live proof.
| Root / surface | Reason and owner | Upstream → downstream | Write/storage authority | Boundary / target | Status → disposition | Evidence |
|---|---|---|---|---|---|---|
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
apps/mobile | Native mobile skeleton | intended Gateway → mobile projection | None | authenticated native | partial skeleton → decision: FUND or ARCHIVE | apps/mobile/package.json |
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 |
apps/one-access-console | Empty/local alias | none | None | unknown | untracked/empty → DELETE residue | physical directory; no tracked files |
apps/platform-console | Empty/local alias | none | None | unknown | untracked/empty → DELETE residue; apps/platform is the real console | physical directory; no tracked files |
Domain and Projection Binding Registry contract
Domain hosts are routing inputs, not separate data authorities. The binding contract is:
hostname → known/reserved/unknown classification → ProjectionId
→ authenticated principal + tenant → RoleConfig + grants
→ Gateway projection endpoint → Projection Engine → bounded SharedWorkbench DTO
| Contract element | Owner | Required behavior | Current evidence/status |
|---|---|---|---|
| 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 |
| 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 |
| Projection identifiers/contracts | packages/projection-contracts, packages/workbench-config | Stable role/module vocabulary, no user-facing engineering layers | configured/wired |
| Composition | packages/projection-engine | Sole composer of bounded role-aware DTOs | partial/configured; deployed reachability and full data path not proven |
| Backend registry | Gateway projection routes | Resolve frontend binding to tenant-scoped service/data contract | partial; direct Vercel rewrites and route-family competition remain |
| Unknown host | Web edge | Fail closed without leaking tenant/projection data | implemented by preserved change |
The apps/web profile → compose → context path through Gateway is the strongest current projection
direction, but mock and fallback payloads remain. Every view, including restored donor views,
workflows, skills, agents, Platform modules, and marketplace/control views, requires an explicit
frontend-to-backend projection/capability binding; component presence is not a binding.
Public solution taxonomy must not expose internal brandstore or book-of-records/orgmemory
as marketing solutions. Host/domain changes require route, middleware, redirects, sitemap,
navigation, host map, and resolver tests to move together.
5. Worker service manifest
Storage abbreviations: N Neon canonical, D D1 operational, K KV/cache,
DO Durable Object, P provider. “Intent” means no direct canonical/provider authority.
5.1 Core release profile (nine Workers)
The actual release script publishes only the nine rows below. It explicitly does not publish
spine, hermes, mcp-pool, provider-management-mcp, integration-management-mcp,
twin-orchestrator, loader, store, webhook-ingress, or the hidden Workers under apps/ and
packages/. Some are referenced through bindings, but a binding to a service excluded from the
release profile is a dependency gap, not deployment proof. Because Spine authority, durable
bindings, governed execution and reconciliation depend on excluded services, the nine-Worker
profile cannot currently prove the canonical release loop.
| Service | Reason / owner | Upstream → downstream | Authority | Boundary/target | Status → disposition |
|---|---|---|---|---|---|
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 |
connector | Compatibility router; Integration | Gateway → loader/mcp-connector/store | Intent; P delegated | internal CF Worker | configured → ADAPT/MERGE keep temporarily, publish owning boundaries |
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 |
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 |
knowledge | Chunk/search/synthesis/promotion evidence | operational Spine → search/Twin | derived indexes, candidates only | internal CF Worker | configured → KEEP separate nested legacy server |
continuity | Session/event continuity | Gateway/Workbench → context assembler | D/K bounded context; no N | internal CF Worker | configured → KEEP + CONNECT enforce tenant/freshness boundaries |
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 |
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 |
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 |
5.2 Services outside core release
| Service(s) | Reason / owner | Relationship and authority | Status → disposition; evidence |
| --------------------------------------------------------- | --------------------------------------------------------------- | ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- |
| 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 |
| 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 |
| iw-agent-runtime | agent runtime; AI Platform | Gateway → governed capabilities; no N/P direct | bound outside core → CONNECT or add explicit profile |
| webhook-ingress | provider event ingress; Integration | provider → Gateway/Pipeline; append evidence only | bound outside core → CONNECT required for reconciliation |
| 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 |
| 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 |
| folder-watcher | file ingress | Gateway (prod/config variance) → loader/pipeline | evidence only | partially bound → ADAPT make environment profile explicit |
| context-fetch | tenant context read facade | callers → bounded context | read/cache only | configured, non-core → CONNECT or ARCHIVE no unexplained parallel context path |
| task-management | internal tasks MCP | MCP Pool → task state/events | operational task state | indirect/non-core → CONNECT |
| provider-management-mcp | connections/apps/OAuth control | Platform/Gateway → provider grants | connection/grant metadata | orphaned → CONNECT canonical owner of provider-once registry |
| integration-management-mcp | connectors/sync/webhooks/schema control | Platform/Gateway → integration services | control metadata | orphaned → CONNECT |
| twin-orchestrator | Silent Twin orchestration | THINK → governed proposal | candidates only | orphaned/critical → CONNECT |
| 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 |
| marketplace-installation | install/activation lifecycle | marketplace → Flow D/grants/catalog | installation metadata only | orphaned → CONNECT to OneAuth and Platform Console |
| agent-registry | governed agent catalog | Platform/MCP → agent runtime | registry only | orphaned → CONNECT or MERGE with capability registry |
| schema-ai | schema assistance | connector evidence → candidate mappings | candidates only | orphaned → CONNECT or ARCHIVE |
| signals | material event/signal service | Spine → Workbench/Twin | derived events | orphaned → CONNECT or MERGE |
| telemetry | operational observability | all services → operator views | telemetry only | orphaned → CONNECT required for release evidence |
| vercel-mcp | Vercel integration MCP | internal capability → Vercel | governed external mutation | orphaned → CONNECT or ARCHIVE |
| billing | billing control (also above bound group) | Gateway → billing provider/state | billing state only | configured outside core; runtime proof absent |
| schema-ai, signals, telemetry migrations | service-local operational schemas | service → own store | never implicit N authority | partial; migration ownership must be registered |
| ai-provider-mcp, core-engine, huggingface-inference | local/build residue without product source | none | none | legacy/residue → ARCHIVE/DELETE after tracked-state check |
| knowledge/server | nested Express/Firestore/GCS knowledge API | no workspace/release caller | legacy external stores | legacy orphan → ARCHIVE after data/export decision |
MCP reconciliation backlog: the MCP Pool has a service-binding/source-name mismatch and a
process-local registry; the management MCPs are scoped facades but lack core-profile reachability;
the MCP Connector has configured external-boundary code without live external proof; and
apps/mcp-servers contains configuration placeholders. Reconcile names, bindings, durable registry,
public/internal inventory, deployment profile, OAuth/tenant scope and health evidence before MCP or
marketplace readiness claims. None may become a duplicate connection, policy, or projection
authority.
The Gateway itself has zero inbound service bindings because it is edge ingress; that is not an
orphan signal. All other zero-inbound Workers require an explicit caller and deployment profile.
6. Package coverage manifest
Packages define contracts and reusable implementation; they do not become independent product or
canonical data authorities. Each item below is accounted for. Package manifests are evidence of
build intent, not consumption or publication.
| Family / packages | Reason and owner | Upstream → downstream; authority | Status → disposition |
|---|---|---|---|
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 |
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 |
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 |
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 |
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 |
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 |
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 |
Validation: integration-tests | cross-service contract/release proof; Quality | release profile → evidence | KEEP + CONNECT to clean-tenant gates |
Product integrations: coda-pack, analytics | external packaging/analytics helpers | capability/provider → external | decision → CONNECT or ARCHIVE; no unexplained published asset |
Residue: config-backup-1782830543, lib-backup-1782830543 | timestamped local backups | none | untracked/excluded → DELETE residue only with explicit approval |
Package-by-package owner/disposition register
This compact register closes the “approximately 57” logical-unit inventory. The family table above
defines upstream/downstream and authority; this register makes every unit discoverable.
| Disposition | Packages |
|---|---|
| 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 |
| CONNECT / prove consumption | adapters, analytics, coda-pack, core, core/capability-registry, handoff-adapters, hermes-spine-memory, integratewise-mcp-tool-connector, orchestrator, spine-network |
| MERGE / select one UI authority | design-system, ui, domain-shells |
| SPLIT deployment classification | api (package plus bound Worker) |
| ARCHIVE candidate | contracts if its frozen definitions are merged, knowledge-bank-ui with knowledge/server |
| DELETE local residue after approval | config-backup-1782830543, lib-backup-1782830543 |
No deletion is authorized by this ledger; it records the required outcome after ownership and data
retention checks.
Public package and artifact registry requirement
Every publishable package, tarball, Plugin/MCP manifest, generated SDK, schema artifact and release
bundle must have one registry record containing: canonical name, owning team, source path, build
command, version, commit, content digest/signature, public/internal boundary, supported consumers,
compatibility contract, publication channel, environment, supersedes/superseded-by links,
revocation status and verification evidence. private: false, a tarball in releases/, or a
manifest in the tree is packaging intent—not proof that the artifact is current, published, safe,
or consumed. Unregistered public artifacts block release.
7. Configuration and deployment roots
| Root | Reason/owner | Target / authority | Status → disposition |
|---|---|---|---|
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 |
app vercel.json files | app-specific browser builds | Vercel | configured → KEEP/ADAPT only for funded product surfaces |
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 |
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 |
configs/templates/{packages,services} | scaffolding | generated future components | KEEP but templates must inherit canonical auth, tenant, telemetry, and deployment contracts |
configs/scripts | config generation/validation | operator tooling | KEEP + CONNECT to drift checks |
infrastructure/config | runtime/catalog manifests | deployment/catalog inputs | KEEP + RECONCILE with Wrangler/release profile; not independent truth |
.github/workflows and scripts/release | CI publication and verification | Vercel/Cloudflare/packages | KEEP; core nine is intentional but incomplete for canonical loop |
Deployment profile matrix
| Profile | Proven by repo | Missing proof |
|---|---|---|
| Core Workers | nine-service release script and matching validation/workflow intent | critical non-core dependencies, Hermes, management MCPs, MCP Pool, telemetry, actual deployment health |
| Customer Zero | wrangler.customer-zero.toml, Customer Zero specs/runbooks | isolated tenant evidence across entire loop; cannot certify external readiness alone |
| External users | wrangler.external-users.toml and release docs | clean tenant, real consent/provider, audit, reconciliation, rollback, multi-surface refresh |
| Local/dev | dev Wrangler/root scripts | no production inference permitted |
| Browser apps | Vercel configs/package manifests | current production project/domain mapping and Gateway-only ingress |
Marketing deployment authority is unresolved while root/app Vercel configurations, rewrites,
domain references and more than one marketing-capable app can describe overlapping public routes.
The required owner is one declared Vercel project and one route/domain manifest for the public
company/product surface. Cloudflare may serve shared runtime APIs, but it must not become a second
marketing deployment authority. A DNS target, rewrite or merged PR is not proof of the currently
serving deployment.
8. Storage and migration authority register
Migration duplication is evidence of unresolved storage ownership. The tree contains canonical,
operational, fixtures, copied public docs, legacy Supabase, and service-local roots. A migration is
not canonical merely because it is SQL.
| Root family | Intended owner/target | Status → disposition |
|---|---|---|
migrations/, migrations/v0-core | canonical Neon schema history, Data Platform | partial → KEEP + declare one migration runner/order |
services/pipeline/migrations | Pipeline canonical/operational writer schema | critical → MERGE/CONNECT to the authoritative Neon history; placeholder writes block release |
services/{intelligence,knowledge,mcp-connector,schema-ai,signals,tenants}/migrations | service-local D1/operational stores | KEEP where owner is live; ARCHIVE with orphan otherwise |
services/{connector-sync,workflow}/d1_migrations, services/workflow/migrations | scheduled sync/workflow operational D1/DO state | KEEP + register ordering/tenant scope |
services/context-fetch/migrations | context cache/read model | decision → CONNECT or ARCHIVE with service |
packages/api/migrations, packages/webhooks/migrations, packages/api/schema.sql | hidden Worker/package state | SPLIT and register in deployment/migration tooling |
sql-migrations/*, docs/internal/sql-migrations/* | duplicated operational/reference migrations | legacy/reference → ARCHIVE, never run from docs |
apps/web/public/docs/**/sql and mirrored docs/domains/**/sql | published copies/reference artifacts | documentation only → KEEP labeled; never execute |
supabase/migrations, migrations/supabase-export | superseded provider/storage path | legacy → ARCHIVE after data-retention/export decision; prohibited in product path |
services/*/src/{schema,fixtures}, apps/web/scripts SQL | schemas/fixtures/scripts, not automatically migrations | ADAPT label purpose and block production runner discovery |
Canonical N writes belong only to the governed Pipeline writer. D1/KV/DO/search stores are bounded
operational projections. Memory and model output inform truth but cannot promote themselves.
The migration registry must record, for every migration root: storage target, logical owner,
environment, runner, ordering/version scheme, tenant scope, checksum, applied-state evidence,
rollback/forward-fix policy and whether the root is executable, fixture-only, copied documentation
or legacy export. No release runner may discover SQL transitively from docs/, public/, fixtures,
Supabase exports or an orphaned service.
9. Connection, identity, and consent lifecycle (Flow D before A/B/C)
| Phase | Required owner and record | Reuse/guard | Current status |
|---|---|---|---|
| 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 |
| 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 |
| User authentication | shared identity authority | audience-bound session; no preview identity in release | drift: platform default-tenant/preview fallbacks do not prove shared identity |
| Tenant binding | TenantGate + membership authority | fail closed; every durable record has tenant_id | partial |
| Consent/grant | Provider Management + identity | provider/scopes/purpose/user/tenant/audit | partial/orphaned owner |
| 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 |
| Discover capabilities | host/provider discovery → connector projections | projections are not re-connections | configured; runtime proof absent |
| Hydrate | loader/sync → normalizer → operational Spine | provenance, cursor, idempotency | partial |
| Activate Workbench | Projection Binding Registry + RoleConfig | RBAC/policy-bounded DTO | partial |
| Revoke/rotate | Provider Management | fan-out invalidation, credential rotation, audit | not end-to-end proven |
10. Current wiring versus canonical target
| Capability | Current wiring | Canonical target | Gap/status |
|---|---|---|---|
| Identity/tenant | app/platform fallbacks and multiple auth surfaces | one authoritative Flow D before data/context | drift, stop-ship |
| Connect once | Gateway lifecycle/Nango/tenant_integrations plus competing UI/scaffold registries | one Gateway ConnectionBinding, host-declared first, reusable everywhere | partial/drift, stop-ship |
| Ingress | Gateway routes plus direct Vercel rewrites/bindings | Gateway/TenantGate single policy ingress | partial/drift |
| Load/normalize | multiple useful loaders/normalizers | one owned chain into operational Spine | configured, integration gap |
| Canonical promotion | placeholder/skipped writer and legacy paths | Pipeline performs real governed N transaction with provenance/outbox | stop-ship |
| Projection | configs/engine/routes and competing families | registry-bound role projection, one Workbench namespace | partial/drift |
| Twin/agents/MCP | substantial code; core reachability gaps | THINK-only Twin through internal MCP/capability fabric | partial/orphaned |
| Approval/action | governance code co-located; Hermes orphaned | cryptographic approval → Hermes → adapter | stop-ship |
| Reconciliation | sync/webhook pieces exist | outcome re-ingested, reconciled, audited, all surfaces refreshed | not proven |
| Platform Console | fail-closed discovery plus mocks/TODOs | real control plane over owning APIs, never SoT | partial |
| Marketplace | contracts, release bundles, manifests, install service | signed/versioned distribution → Flow D install/consent → activation | partial/orphaned |
| External release | scripts/config/specs | clean-tenant evidence pack for full loop | not runtime-proven |
Operational brandstore and book-of-records/orgmemory bindings are internal-only. They may be
used by authorized operational projections but cannot appear as public marketing solutions,
marketplace categories, or unauthenticated navigation.
11. Marketplace and distribution assets
| Asset | Reason/owner | Boundary/authority | Status → disposition |
|---|---|---|---|
marketplace/ | connector/catalog content | public catalog metadata only | KEEP + reconcile with canonical connector registry |
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 |
apps/web/app/.well-known/ai-plugin.json and public/manifest.json | discovery manifests | public | KEEP + validate against current domains/tool inventory |
infrastructure/config/{spine-network,adk}/manifest.yaml | runtime/package manifests | internal/config | KEEP + connect to build/release source of truth |
packages/contracts/src/marketplace | marketplace contracts | internal reusable schema | CONNECT or merge into consumed contract package |
services/marketplace-installation | installation lifecycle runtime | authenticated control | orphaned → CONNECT |
scripts/seed-marketplace-apps.ts, marketplace migrations | seed/catalog state | controlled operator path | ADAPT idempotency, environment, tenant and ownership guards |
docs/submission/plugin-directory-submission.md and marketplace specs | submission/runbook evidence | documentation | KEEP subordinate; claims gated by deployed proof |
The public Plugin exposes exactly the canonical 19 semantic IW Spine tools. Internal MCP Pool,
provider-management, integration-management, task-management, and raw provider tools are not
public marketplace inventory.
12. Remediation ledger
| ID | Action | Scope | Acceptance evidence | Order |
|---|---|---|---|---|
| R1 | KEEP + CONNECT | Flow D shared identity/TenantGate | no default/preview release path; negative tenant tests; shared session accepted by all surfaces | 1 |
| 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 |
| R3 | MERGE | Gateway ingress policy | Vercel routes only to Gateway/public allowed endpoints; complete Worker bindings per profile | 3 |
| R4 | CONNECT | loader/normalizer/operational Spine | idempotent A/B ingest with provenance and tenant isolation | 4 |
| 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 |
| R6 | MERGE + CONNECT | projection route families and registry | one canonical namespace; host/role/RBAC contract tests; unknown host fail closed | 6 |
| R7 | CONNECT | Platform Console control APIs | no mocks in release; every module names service owner, permissions, audit, freshness | 7 |
| R8 | CONNECT | MCP Pool, management MCPs, Twin runtime | explicit release profile, health/routes, public/internal inventory tests | 8 |
| R9 | SPLIT contractually + CONNECT | Governance and Hermes | approval token validation; denied/expired/replayed tokens cannot mutate provider | 9 |
| R10 | CONNECT | provider writeback/re-ingestion/reconciliation | same action observed back, correlated, reconciled, audited, multi-surface refresh | 10 |
| R11 | ADAPT | marketplace/install lifecycle | signed versioned assets, Flow D consent, clean uninstall/revoke, exact 19 public tools | 11 |
| R12 | SPLIT | hidden Workers under apps//packages/ | deployment and migration registry covers each target/environment | 12 |
| R13 | ARCHIVE | legacy Supabase/Firestore/nested knowledge UI-server/docs | data-retention decision, no imports/bindings/runners, clear lineage label | 13 |
| R14 | DELETE | empty/untracked aliases/backups | explicit approval and tracked/data check; recoverable cleanup | 14 |
| R15 | ADAPT | release evidence | Customer Zero plus external clean tenant full-loop evidence, rollback and observability | 15 |
13. Dependency-ordered implementation and release program
This is an order lock; downstream work does not compensate for a missing upstream authority.
- Spine authority: select the single canonical Spine implementation and real Neon target;
replace the Pipeline placeholder/cache-success path with truthful transactional writes. Pipeline
is the sole canonical writer; other Spine implementations become bounded reads or are retired. - Binding and deployment closure: reconcile names, environment bindings and release profiles;
register every Vercel app, Worker, package Worker, dependency and migration root. Remove
browser-to-internal-service bypasses. - Flow D and ConnectionBinding: remove identity/tenant fallbacks; make Gateway/Provider
Management the durable binding owner; discover host capabilities first; reconcile competing
tables; never copy host tokens; prove consent, grants, revocation and consumer reuse. - Flow A/B/C remediation: route structured provider records (A), evidence/documents (B) and
cognitive candidates (C) through tenant-bound ingress, loader, normalizer, operational Spine and
governed promotion. Discovery produces proposals only. Flow C never self-promotes, and no stage
may report success when canonical persistence was skipped. - Projection closure: require a registered Projection Binding for every view; converge route
families and prove role, tenant, freshness, provenance, empty/error and unknown-host behavior. - Governance/Hermes loop: replace the nonexistent/stale workflow binding, make Hermes reachable,
validate approval tokens, execute through the selected provider route, then re-ingest, reconcile,
audit and refresh all affected projections. - Twin ownership: after the action loop works, bind the Silent Twin to THINK-only evidence and
proposal ownership through the MCP/capability fabric. Twin never becomes a canonical writer or
an alternate action path. - Control and distribution: replace Platform Console fixtures/TODOs with owner APIs; validate
public package/artifact manifests, exact public tools, install/upgrade/uninstall/revoke and
marketplace claims. - Customer Zero cross-surface proof: exercise OneAuth, Spine Network MCP, Workbench, Platform,
Twin and provider reconciliation as a controlled rehearsal, followed by an external clean tenant. - Consolidation: only after proof, merge duplicate packages/routes and archive/delete legacy
components. Do not clean first and discover dependencies later.
14. Release proof and unresolved decisions
Required proof pack
- commit/artifact identifiers and Vercel/Cloudflare deployment identifiers;
- profile-to-Worker binding inventory and health checks;
- clean user, tenant, membership, consent and provider connection evidence;
- A/B ingest provenance, normalization and real canonical promotion record;
- role-aware projection/host/RBAC and negative isolation tests;
- Twin proposal and cryptographically bound approval/denial/replay tests;
- Hermes/provider mutation and correlated re-ingestion/reconciliation audit;
- multi-surface refresh/freshness evidence;
- marketplace install, upgrade, revoke and exact public-tool inventory;
- rollback/recovery and telemetry evidence.
Release evidence manifest
Each release candidate must produce one immutable manifest that joins otherwise fragmented proof:
| Manifest section | Required fields |
|---|---|
| Source | repository, commit, dirty-tree declaration, build run, approving change set |
| Browser deployments | Vercel project, app/root, domains/routes, deployment ID/URL, artifact digest, environment |
| Worker deployments | canonical service, Wrangler source, Worker name, environment, version/deployment ID, bindings and health |
| Packages/artifacts | package/bundle name, version, digest/signature, registry/channel, public/internal status, compatibility |
| Migrations | root, target store, owner/runner, ordered versions/checksums, applied evidence, forward-fix/rollback status |
| Identity/bindings | user/tenant authority, consent record, ConnectionBinding source/scopes/grants, revocation and negative isolation proof |
| Flows A/B/C | ingress IDs, provenance, normalize result, operational record, promotion record and real canonical transaction ID |
| Projections | View → Projection Binding → Gateway route → owner mapping, tenant/RBAC/freshness and negative tests |
| Action loop | proposal, approval token/hash, Hermes dispatch, provider result, re-ingestion, reconciliation, audit and refresh IDs |
| Distribution | OneAuth/Spine Network MCP versions, exact public tools, install/upgrade/revoke checks, marketplace listing identity |
| Verification | test suites, Customer Zero run, external clean-tenant run, telemetry window, rollback/recovery exercise and known exceptions |
The manifest may reference signed evidence artifacts, but every reference must be immutable and
environment-specific. Missing sections are release blockers, not documentation follow-ups.
Decisions that remain open
- Which identity provider/record is the final shared authority, and when are all preview/default
tenant fallbacks prohibited? - Which durable store and service own the provider-once registry, connection leases, rotation and
revocation? - Are non-core but canonical services added to the core profile, or is there a dependency-ordered
multi-profile release? “Bound somewhere” is not a release policy. - Which Workbench route family is canonical, and what is the redirect/deprecation window?
- Does
packages/apiremain a Worker, move toservices/, or merge into an existing owner? - Which UI library survives (
ui,design-system, domain-shell components), and who migrates
consumers? - Are mobile, desktop, portfolio, context-fetch, schema-ai, signals, and vercel-mcp funded now or
archived? - What is the data-retention/export plan for Supabase, Firestore/GCS knowledge, and other legacy
provider paths? - Which marketplace bundle is current, who signs it, and what is the revocation/supersession rule?
- What objective evidence promotes Customer Zero learning into external GTM readiness?
Until R1–R10 and the clean-tenant proof pack pass, GTM and release planning may continue as a
conditional plan, but must not be labeled final or generally available.
15. Pull-request lineage: protected Workbench capabilities
This section records read-only GitHub evidence inspected on 2026-08-13. PR state is not checkout
state, and a merged label is not architectural approval. No PR was merged, closed, reopened, or
otherwise changed during this review.
Protected scope: workflows, skills, agents, capability registry/execution, and their Workbench
entry points are existing product scope. Donor-view or taxonomy work must preserve these surfaces;
absence from a replacement registry is a regression, not permission to retire them.
| PR | Change evidence | Shared-platform assessment | Disposition / sequencing advice |
|---|---|---|---|
| #139 — migrate donor domain views | 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. |
| #140 — revert #139 | 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. |
| #141 — SpineWorkspace/domain refactor | 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. |
Required restoration sequence
- Inventory and pin the existing route, navigation, registry, component, test, workflow service,
capability service, skill, and agent entry points on the current canonical base. - Add non-regression tests proving each protected surface remains discoverable and consumes a
tenant/RBAC-bounded Gateway projection or capability contract. - Reconcile projection identifiers with the canonical public/internal taxonomy. Internal
brandstoreandorgmemorymay remain internal bindings; they cannot become public solutions. - Port PR #139's
AuthorizedProjectionPayloadhydration/registry mechanics as a small reviewed
change, without compatibility identity stubs or fixture truth. - Port domain views by role family in bounded batches. Each batch must prove loading, empty/error/
stale states, RBAC, accessibility, and no replacement of workflow/skill/agent navigation. - Connect workflow/capability/agent actions through Governance and Hermes; until then, imported
controls are declarative previews, not executable product proof. - Only after the protected surfaces and closed loop pass may obsolete donor/duplicate code be
archived. Never use a bulk revert or historical merge label as the source of truth.
The direct checkout inspected for this companion contains existing capability-engine,
capability-registry, agent-registry, agent route, capability route, agent runtime view, and agent
activation drawer sources. It contains no populated apps/web/components/domain-views tree at
the inspected HEAD. This is checkout evidence only; it does not infer the contents of a remote
merged commit or deployed Vercel project.
16. First Spine Workspace vertical integration proof
The deterministic proof in
services/intelligence/src/chatgpt-brainstorm.vertical.integration.test.ts binds three explicit,
tenant-scoped exemplars to one work context without using or requiring provider credentials:
| Flow | Exemplar | Enforced path | Proof boundary |
|---|---|---|---|
| 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 |
| 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 |
| 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 |
The public get_context IW-Spine-Network MCP dispatcher reads the correlated active work context
and returns minimum-necessary references and citations for A, B, and C. It does not return the CRM
record, document excerpt, ChatGPT excerpt, provider credential, or arbitrary chat history. A second
tenant cannot read the first tenant's candidate, operational rows, or active context. The harness is
a full local integration-path proof, not proof of live provider authentication, deployed Worker
bindings, external ChatGPT history access, or a canonical Neon transaction.
Flow C intentionally bypasses Loader and Normalizer. Triage owns novelty, repetition, conflict and
consolidation decisions, but it does not own canonical writes. The proof stores only a governed
promotion candidate in operational D1; promotion remains a later Pipeline/Spine governance step.
Omni Router / model-routing boundary
The checkout contains two different routing packages. packages/omni-router is currently a
provider-agnostic connector tool executor with connector credentials; it has no model-selection
or fallback contract. packages/model-gateway is the package that currently defines provider/model
routing. Therefore the test uses a bounded TriageReasoningRouter contract seam and asserts that
Triage emits only tenant, principal, purpose, policy and an input hash to the routing boundary. The
external reasoning response is deterministic and local; no secret or raw excerpt is sent.
Connecting that seam to the required private OmniRoute AI gateway, and reconciling the naming and
ownership overlap between omni-router, model-gateway, and the OmniRoute endpoint, is unresolved
runtime wiring. This test does not claim the current Codex session, a deployed Triage Worker, or any
external model call traversed that gateway.
Run the proof with:
NODE_OPTIONS=--experimental-sqlite pnpm --dir services/intelligence exec vitest run src/chatgpt-brainstorm.vertical.integration.test.ts --reporter=verbose
Customer Zero may begin only after replacing each fixture with an explicitly authorized real item,
binding the Triage reasoning seam to the deployed policy router, proving the Pipeline canonical
writer transaction rather than its operational candidate, and repeating the negative isolation and
bounded MCP assertions against deployed services.