Go-Live Blocker Remediation — Draft Diffs

Status: PARTIALLY APPLIED — see the ledger below
Date: 2026-08-06

Application ledger

Item	State
F1 — duplicate public MCP domain	Applied. Top-level route removed from services/mcp-connector/wrangler.toml; [env.prod] is now sole claimant.
F2 — manifest tool count	Applied. Description now reads "19-tool"; tools array was already correct at 19.
F3 — manifest routing leak	Applied. ownership.routing removed. Nothing in the product path reads it.
F4 — mcp-pool profiles	Applied structurally. [env.prod] removed (no external surface), dangling SPINE binding corrected, workers_dev = false added, [env.test] added but marked BLOCKED — see §5.
F5 — retired manifest	Not applied. marketplace/apps/iw-continuity-bridge.json still present; needs git rm (no shell available this session).
Canonical D1 split	Not applied. Requires two real D1 databases. Writing a placeholder ID would itself be stop-ship #2 — the exact defect that caused S0. Commands in §4.
Validator assertions	Applied. Route uniqueness, test/prod binding disjointness, placeholder-ID detection, and manifest contract added to scripts/release/validate-platform-deployment.sh.
mcp-pool → CORE_SERVICES	Not applied. Correctly blocked until its customer-zero targets exist.

Expect release:check to fail after these changes. The new binding-disjointness
assertion catches the shared canonical Spine D1, and the new placeholder assertion catches
services/task-management/wrangler.toml:10 (database_id = ""). Both are real defects that
were previously invisible. The gate going red is the change working, not a regression.
Verified against: working tree at time of writing
Reconciled against: OneAuth Ecosystem — Final Implementation and Go-Live Specification v1.0
(6 Aug 2026), which declares itself the release authority and supersedes conflicting older notes.
Scope: Tier 0b publication blockers (F1–F5), the canonical Spine D1 isolation leak, and the
release validator that failed to catch any of them.

Reconciliation note — two reversals in the v1.0 spec

The v1.0 spec reverses two positions that INTEGRATEWISE_ARCHITECTURE.md v2.1 still states.
Both change what "aligned" means:

Subject	v2.1 (31 Jul)	OneAuth spec v1.0 (6 Aug)	Effect here
Canonical store	Canonical Spine is Neon Postgres (Fortress); D1 is operational + cache (§8.1–8.2)	D1 is the V1 canonical product-plane database. PostgreSQL excluded from the V1 product plane (§2.2, §11, §25.7); §15.1(5) requires quarantining Neon product-plane migrations	§4 below changes from stopgap to permanent target. The Neon migration is cancelled, not deferred.
Identity	Clerk is canonical primary (ARCHITECTURE_LOCK §VII)	Descope is the direct-host IdP; §15.1(7) requires retiring Clerk runtime paths	Out of scope here, but services/spine/wrangler.toml:7 still references FORTRESS_DATABASE_URL as canonical — now legacy.

Neither reversal is reflected in INTEGRATEWISE_ARCHITECTURE.md yet. Under that document's own
rule — "When this document is wrong, change it here" — v2.1 §8.1, §8.2 and the S0 resolution
text need amending, or the next person to read it will re-plan the Neon migration.

Delete this file once the changes are applied and release:check passes. It is a work order,
not a standing document.

---

0. Why these got through

scripts/release/validate-platform-deployment.sh validates four things: config exists, main
exists, the env-specific Worker name exists with the right suffix, and mcp-connector is named
-test/-prod. It does not check route uniqueness, binding-target uniqueness, or the
marketplace manifest at all.

There is also a structural gap. CORE_SERVICES (line 64) deliberately excludes any Worker
"without those surfaces" — so mcp-pool, which has no [env.test], is exempt from validation
because it is misconfigured. The component with the most privilege is the one the gate does
not look at.

Fixing F1–F5 without §5 below means this recurs. It already has: S0's silent-write defect was
fixed on ~2026-07-31 and reappeared six days later as a shared-database leak.

---

1. F1 — two Workers claim the public MCP domain

Evidence: services/mcp-connector/wrangler.toml binds mcp.integratewise.ai at both the
top level (:6) and in [env.prod] (:228). Last deploy wins, so a routine default-env deploy
silently repoints the public MCP endpoint.

--- a/services/mcp-connector/wrangler.toml
+++ b/services/mcp-connector/wrangler.toml
@@ -3,7 +3,9 @@
 main = "src/index.ts"
 compatibility_date = "2024-12-01"
 compatibility_flags = ["nodejs_compat"]
-routes = [{ pattern = "mcp.integratewise.ai", custom_domain = true }]
+# The public custom domain is claimed by [env.prod] only. A top-level route here
+# would let a default-env deploy silently repoint the published MCP endpoint.
+# Test binds mcp.test.integratewise.ai in [env.test].

Risk: low. The default-env Worker loses a domain it should never have claimed. env.prod
retains it at :228.

Check before applying: confirm nothing currently depends on the unsuffixed
mcp-connector Worker serving production traffic — if it does, that is F1 actively firing and
the cutover needs a deploy of mcp-connector-prod first.

---

2. F2 / F3 — marketplace manifest

Evidence: marketplace/apps/iw-spine-network.json:7 advertises a "23-tool continuity
network"; the tools array (:16–36) correctly holds exactly 19, matching §16.1 in order.
:42 publishes "routing": "mcp-pool", naming the internal control plane in a public artifact.

--- a/marketplace/apps/iw-spine-network.json
+++ b/marketplace/apps/iw-spine-network.json
@@ -4,7 +4,7 @@
   "kind": "plugin",
   "version": "1.0.0",
   "publisher": "IntegrateWise",
-  "description": "The IntegrateWise activation plugin. Installs the full 23-tool continuity network — 20 operational connectors and 3 cognitive providers — and onboards your team into a governed workspace with Digital Memory.",
+  "description": "The IntegrateWise activation plugin. Installs the 19-tool continuity network and onboards your team into a governed workspace with Digital Memory.",
   "icon": "spine",
@@ -39,6 +39,6 @@
   "ownership": {
     "credentials": "provider",
-    "metadata": "integratewise",
-    "routing": "mcp-pool"
+    "metadata": "integratewise"
   }
 }

On dropping routing entirely rather than correcting it. Nothing in the product path reads
ownership.routing — the only references are this file, iw-continuity-bridge.json, and prose
in CODEBASE_EXCAVATION.md / MCP_AND_PLUGIN_PUBLISHING_SPEC.md. Any value here either states
internal topology or restates the public endpoint already carried by the MCP registration.
Removing it satisfies F3 without inventing a new public contract.

Your call: if a marketplace reviewer expects the field, substitute
"routing": "mcp.integratewise.ai" — the public endpoint, not the internal service name.

The "20 operational connectors and 3 cognitive providers" figure is real and worth keeping —
but as a connector count, not a tool count. It belongs in listing copy, not in the tool contract.

---

3. F5 — retired public name in the publishable directory

Evidence: marketplace/apps/iw-continuity-bridge.json — retired name D9 — sits alongside
the live manifest in a directory whose contents are publishable.

Proposed: git rm marketplace/apps/iw-continuity-bridge.json

History preserves it. If it must be retained for reference, move it to
docs/architecture/retired/ where nothing publishes from.

---

4. Canonical Spine D1 — test and prod share one database

Evidence: services/pipeline/wrangler.toml binds CANONICAL_SPINE_DB to database id
1dfe12bc-27be-4c5c-976e-8da691f5dde4 at :126 (top level), :269 (env.test) and :392
(env.prod). This is the anti-pattern named verbatim in CLAUDE.md: "Do not make a warning
disappear by copying a production binding into env.test."

This is the most consequential item in this document. While it stands, §17.2 gate 4 — prove
complete Customer Zero isolation — is not merely unmet but unprovable: there is no
isolation to produce evidence of.

--- a/services/pipeline/wrangler.toml
+++ b/services/pipeline/wrangler.toml
@@ -265,7 +265,7 @@
 # --- Canonical Spine D1 (test) ---
 [[env.test.d1_databases]]
 binding = "CANONICAL_SPINE_DB"
-database_name = "integratewise-canonical-spine"
-database_id = "1dfe12bc-27be-4c5c-976e-8da691f5dde4"
+database_name = "integratewise-canonical-spine-test"
+database_id = "<CREATE VIA: wrangler d1 create integratewise-canonical-spine-test>"

@@ -390,7 +390,7 @@
 # --- Canonical Spine D1 (prod) ---
 [[env.prod.d1_databases]]
 binding = "CANONICAL_SPINE_DB"
-database_name = "integratewise-canonical-spine"
-database_id = "1dfe12bc-27be-4c5c-976e-8da691f5dde4"
+database_name = "integratewise-canonical-spine-prod"
+database_id = "<CREATE VIA: wrangler d1 create integratewise-canonical-spine-prod>"

Required before this can be applied:

1. wrangler d1 create integratewise-canonical-spine-test
2. wrangler d1 create integratewise-canonical-spine-prod
3. Apply the canonical-spine migrations to both
4. Determine what 1dfe12bc currently holds. If it carries real Customer Zero canonical state,
   it becomes the prod database and only test needs creating — but that must be established by
   inspection, not assumption.

Superseded guidance — read this before acting on the drift register. The register resolves
S0 with "The Canonical Spine is Neon; delete CANONICAL_SPINE_DB." The OneAuth spec v1.0
reverses that: D1 is the V1 canonical product-plane store (§25.7), and §15.1(5) requires
Neon product-plane migrations to be quarantined out of the release lane.

Under the current authority, the diffs above are therefore the permanent fix, not a stopgap.
CANONICAL_SPINE_DB stays. What remains open from S0 is different work: making Pipeline the
only canonical writer (spec §25.8, §15.1(4)), retiring the Supabase legacy writer, and
consolidating the duplicated 16-concept ontology out of pipeline/src/canonical/entity-type-map.ts.

This also satisfies spec stop-ship condition #1 and §16.2 (G1 — physical resource isolation),
which is a hard gate before any external activation.

---

5. F4 — mcp-pool has no environment isolation, and a dangling binding

This is the one with a dependency that would have broken a deploy.

Evidence: services/mcp-pool/wrangler.toml has no [env.test]. All three service bindings
are identical across the top level (:16–26), [env.dev] (:31–41) and [env.prod]
(:46–56) — not just INTEGRATION_MANAGEMENT as F4 records, but TASK_MANAGEMENT and SPINE
too. The development control plane talks to production on every binding.

Additionally — SPINE is dangling. It targets integratewise-spine. No Worker by that name
exists: services/spine/wrangler.toml:1 names the Worker integratewise-live, with
integratewise-live-test and integratewise-live-prod per environment. This is drift register
S2 ("the core nine were renamed; consumers were never updated"). The file's own header comment
warns that a binding to an undeployed Worker fails the deploy.

Blocking dependency — do not add [env.test] to mcp-pool first. Its natural targets do not
exist:

Binding	Needs	Present?
INTEGRATION_MANAGEMENT	integratewise-integration-management-mcp-test	No — that service defines only [env.dev] and [env.prod]
TASK_MANAGEMENT	integratewise-task-management-test	No — same gap
SPINE	integratewise-live-test	Yes

Required order:

1. Add [env.test] to services/integration-management-mcp/wrangler.toml
2. Add [env.test] to services/task-management/wrangler.toml
3. Deploy both to test
4. Only then apply the mcp-pool diff below
5. Add mcp-pool to CORE_SERVICES in the validator so it stops being exempt

--- a/services/mcp-pool/wrangler.toml
+++ b/services/mcp-pool/wrangler.toml
@@ -28,15 +28,31 @@
 [env.dev]
 vars = { ENVIRONMENT = "development" }

 [[env.dev.services]]
 binding = "TASK_MANAGEMENT"
 service = "integratewise-task-management"

 [[env.dev.services]]
 binding = "INTEGRATION_MANAGEMENT"
-service = "integratewise-integration-management-mcp-prod"
+service = "integratewise-integration-management-mcp"

 [[env.dev.services]]
 binding = "SPINE"
-service = "integratewise-spine"
+service = "integratewise-live"
+
+[env.test]
+name = "integratewise-mcp-pool-test"
+vars = { ENVIRONMENT = "test" }
+
+[[env.test.services]]
+binding = "TASK_MANAGEMENT"
+service = "integratewise-task-management-test"
+
+[[env.test.services]]
+binding = "INTEGRATION_MANAGEMENT"
+service = "integratewise-integration-management-mcp-test"
+
+[[env.test.services]]
+binding = "SPINE"
+service = "integratewise-live-test"

 [env.prod]
+name = "integratewise-mcp-pool-prod"
 vars = { ENVIRONMENT = "production" }
@@ -46,11 +62,11 @@
 [[env.prod.services]]
 binding = "TASK_MANAGEMENT"
-service = "integratewise-task-management"
+service = "integratewise-task-management-prod"

 [[env.prod.services]]
 binding = "INTEGRATION_MANAGEMENT"
 service = "integratewise-integration-management-mcp-prod"

 [[env.prod.services]]
 binding = "SPINE"
-service = "integratewise-live"
+service = "integratewise-live-prod"

The top-level bindings (:16–26) should also be corrected for the dangling SPINE name, or the
top-level section removed entirely if mcp-pool is never deployed without an environment flag.

Note: integratewise-task-management-prod assumes [env.prod] in that service derives its
name from the base. Confirm the deployed name before applying — the same derivation question
applies to integratewise-integration-management-mcp-prod, which does resolve today.

---

6. Validator extension

RESOLVED — environment profiles

Decision (founder, 2026-08-06): MCP Pool serves the dev and customer-zero profiles
only. It has no external surface.

This settles the ambiguity below in favour of Reading A: three physical surfaces, with the
wrangler environment names as the physical handles and the OneAuth spec names as the logical
ones.

Logical (OneAuth spec §11.2)	Physical (wrangler / CLAUDE.md)
dev — engineering and contract testing	[env.dev]
customer-zero — production reference tenant	[env.test]
external — external production tenants	[env.prod]

It also adds a rule the drift register did not capture: not every Worker exists on every
surface. MCP Pool is Platform/Customer Zero infrastructure per
PRODUCT_PLATFORM_BOUNDARY_AND_GO_LIVE_STANDARD.md:65 — external tenants reach capability
through the Gateway and the public 19-tool MCP, never through the Pool. Its [env.prod] was
not a misconfiguration to repair but a surface that should not exist, and has been removed.

Worth recording this mapping in CLAUDE.md so the next reader does not re-derive it.

<details> <summary>Original ambiguity, retained for lineage</summary>

Three documents disagreed:

Source	Profiles named
CLAUDE.md	"Deployment surfaces are fixed: local dev, demo test, and live prod"
Every wrangler.toml in the repo	[env.dev], [env.test], [env.prod]
INTEGRATEWISE_ARCHITECTURE.md §17	Development · Customer Zero · Customer Production
OneAuth spec §11.2	"Three physical profiles are mandatory" — dev, customer-zero, external
OneAuth spec §1.1(1) and §23(1)	"test, Customer Zero, or external" — reads as four

Two readings, with very different costs:

Reading A — the names are aliases. dev = Development, test = Customer Zero,
prod = external/Customer Production. Three physical surfaces already exist; the spec is using
logical names for them. The validator below is correct as written, and the only change needed is
documenting the mapping so this ambiguity does not recur.

Reading B — four surfaces are required. test and customer-zero are distinct, and a new
physical profile must be provisioned across every Worker: D1, KV, R2, Queues, Vectorize, Durable
Objects, secrets, routes. That is substantial work, it changes CORE_SERVICES handling, and it
must land before G1 can be declared green.

Spec §11.2's "three profiles" supports Reading A; §1.1 and §23's three-way enumeration alongside
dev supports Reading B.

</details>

The assertions

Three checks, appended before the final failed check (after line 179). Configuration-only,
consistent with the script's stated contract of never calling the Cloudflare API. Written for
Reading A; under Reading B the environment list needs extending, not rewriting.

# --- Custom-domain route uniqueness -----------------------------------------
# A custom domain claimed in more than one section means the last deploy wins
# and a default-env deploy can silently repoint a published endpoint. (F1)
section_route_patterns() {
  local config="$1" header="$2"
  awk -v header="$header" '
    header == "" {
      if ($0 ~ /^\[/) exit
      if ($0 ~ /custom_domain[[:space:]]*=[[:space:]]*true/) print
      next
    }
    $0 == header { in_section = 1; next }
    in_section && /^\[/ { exit }
    in_section && /custom_domain[[:space:]]*=[[:space:]]*true/ { print }
  ' "$config" | grep -o 'pattern[[:space:]]*=[[:space:]]*"[^"]*"' | sed 's/.*"\(.*\)"/\1/'
}

for service in "${TARGET_SERVICES[@]}"; do
  config="services/${service}/wrangler.toml"
  [[ -f "$config" ]] || continue

  duplicate_routes="$(
    {
      section_route_patterns "$config" ""
      section_route_patterns "$config" "[env.test]"
      section_route_patterns "$config" "[env.prod]"
    } | sort | uniq -d
  )"

  if [[ -n "$duplicate_routes" ]]; then
    echo "FAIL  ${service}: custom domain claimed in more than one section:"
    echo "$duplicate_routes" | sed 's/^/        /'
    failed=1
  else
    echo "OK    ${service} route uniqueness"
  fi
done

# --- Test/prod binding-target disjointness ----------------------------------
# Platform rule: test and prod must never share a D1, KV, R2, Queue or service
# binding target. Catches the canonical Spine D1 leak and the mcp-pool bindings.
env_binding_targets() {
  local config="$1" environment="$2"
  awk -v env_re="^\\[+env\\.${environment}\\." '
    /^\[/ { in_section = ($0 ~ env_re) ? 1 : 0; next }
    in_section && ($1 == "database_id" || $1 == "id" || $1 == "bucket_name" || \
                   $1 == "queue" || $1 == "service") {
      gsub(/"/, "", $3); print $1 "=" $3
    }
  ' "$config" | sort -u
}

for service in "${TARGET_SERVICES[@]}"; do
  config="services/${service}/wrangler.toml"
  [[ -f "$config" ]] || continue

  shared="$(comm -12 \
    <(env_binding_targets "$config" test) \
    <(env_binding_targets "$config" prod))"

  if [[ -n "$shared" ]]; then
    echo "FAIL  ${service}: test and prod share binding targets:"
    echo "$shared" | sed 's/^/        /'
    failed=1
  else
    echo "OK    ${service} test/prod binding isolation"
  fi
done

# --- Published manifest contract --------------------------------------------
# Exactly 19 public tools; no internal topology in a public artifact. (F2, F3)
MANIFEST="marketplace/apps/iw-spine-network.json"
if [[ -f "$MANIFEST" ]]; then
  if node -e '
    const m = require("./marketplace/apps/iw-spine-network.json");
    const errors = [];
    if (!Array.isArray(m.tools) || m.tools.length !== 19) {
      errors.push(`tools array must hold exactly 19 entries (found ${
        Array.isArray(m.tools) ? m.tools.length : "none"})`);
    }
    const claimed = /(\d+)-tool/.exec(m.description || "");
    if (claimed && claimed[1] !== "19") {
      errors.push(`description advertises ${claimed[1]} tools; the contract is 19`);
    }
    const internal = /mcp-pool|mcp_pool|integratewise-(spine|live|pipeline|gateway)\b/;
    if (internal.test(JSON.stringify(m.ownership || {}))) {
      errors.push("ownership names an internal service; public manifests must not leak topology");
    }
    if (errors.length) { errors.forEach((e) => console.error("        " + e)); process.exit(1); }
  '; then
    echo "OK    published manifest contract"
  else
    echo "FAIL  ${MANIFEST}: manifest contract violations above"
    failed=1
  fi
else
  echo "FAIL  missing ${MANIFEST}"
  failed=1
fi

Also change — remove the exemption that hid F4:

--- a/scripts/release/validate-platform-deployment.sh
+++ b/scripts/release/validate-platform-deployment.sh
@@ -70,6 +70,7 @@ CORE_SERVICES=(
   intelligence
   workflow
+  mcp-pool
   gateway
 )

Apply this only after §5 steps 1–4. Adding mcp-pool before it has an [env.test] will
correctly fail the validator — which is the point, but it will block every release until fixed.

---

7. Application order

1. F2/F3 manifest copy          — no dependencies, no deploy impact
2. F5 remove retired manifest   — no dependencies
3. F1 remove top-level route    — verify prod Worker serves the domain first
4. Validator §6 assertions      — WITHOUT the mcp-pool CORE_SERVICES line
   └─ expect: canonical D1 leak now FAILS. That is the validator working.
5. Canonical D1 split (§4)      — create databases, migrate, then apply
6. integration-management-mcp + task-management [env.test]
7. Deploy both to test
8. mcp-pool §5 diff
9. Add mcp-pool to CORE_SERVICES
10. pnpm release:check -- --environment test
11. pnpm release:deploy -- --environment test --service core --dry-run

Steps 1–3 are safe to apply and review independently. Step 4 is where the value is: it makes
step 5 mandatory rather than remembered.

---

8. What this does not unblock

After all of the above, these gates remain open. Mapped to the OneAuth spec's G0–G9 where they
correspond:

• Pipeline is not yet the only canonical writer (spec §25.8, §15.1(4); register S0 steps 3–4).
  pipeline/src/spine/ — the self-labelled Supabase "legacy writer" — is still in the release
  path, and the 16-concept ontology is copy-pasted into entity-type-map.ts. G4.
• S0b — org_memory is a documented cache with six writers and no defined reconciliation.
• S0c — agent_memory exists only inside the retired Supabase writer scheduled for deletion.
  It needs a D1 table before that file is removed, or the capability is lost with it.
• S1 — hub-controller-api remains a second unauthenticated entry point bound in all three
  environments to one D1, carrying billing, auth and capability execution.
• S2 — fifteen dangling service bindings; §5 above fixes one of them.
• F6 — five release flavours against a two-package doctrine.
• Every evidence gate in §17.2 that requires a live run: Customer Zero daily use, clean-tenant
  install, negative isolation tests, connector lifecycle, governed execution end-to-end.

Environment note: the Linux sandbox could not start (host out of disk space), so nothing here
was executed — no release:check, no dry-run, no git status. Every claim above is read from
the working tree. The diffs are drafted, not validated.