{"slug":"operations/GO_LIVE_BLOCKER_REMEDIATION_DRAFT","title":"Go-Live Blocker Remediation — Draft Diffs","section":"operations","sectionLabel":"Operations","status":"unclassified","type":"document","path":"operations/GO_LIVE_BLOCKER_REMEDIATION_DRAFT.mdx","bytes":26308,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\n**Status:** PARTIALLY APPLIED — see the ledger below\n**Date:** 2026-08-06\n\n## Application ledger\n\n| Item | State |\n| -------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| F1 — duplicate public MCP domain | **Applied.** Top-level route removed from `services/mcp-connector/wrangler.toml`; `[env.prod]` is now sole claimant. |\n| F2 — manifest tool count | **Applied.** Description now reads \"19-tool\"; `tools` array was already correct at 19. |\n| F3 — manifest routing leak | **Applied.** `ownership.routing` removed. Nothing in the product path reads it. |\n| 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. |\n| F5 — retired manifest | **Not applied.** `marketplace/apps/iw-continuity-bridge.json` still present; needs `git rm` (no shell available this session). |\n| 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. |\n| Validator assertions | **Applied.** Route uniqueness, test/prod binding disjointness, placeholder-ID detection, and manifest contract added to `scripts/release/validate-platform-deployment.sh`. |\n| `mcp-pool` → `CORE_SERVICES` | **Not applied.** Correctly blocked until its customer-zero targets exist. |\n\n**Expect `release:check` to fail after these changes.** The new binding-disjointness\nassertion catches the shared canonical Spine D1, and the new placeholder assertion catches\n`services/task-management/wrangler.toml:10` (`database_id = \"\"`). Both are real defects that\nwere previously invisible. The gate going red is the change working, not a regression.\n**Verified against:** working tree at time of writing\n**Reconciled against:** _OneAuth Ecosystem — Final Implementation and Go-Live Specification v1.0_\n(6 Aug 2026), which declares itself the release authority and supersedes conflicting older notes.\n**Scope:** Tier 0b publication blockers (F1–F5), the canonical Spine D1 isolation leak, and the\nrelease validator that failed to catch any of them.\n\n## Reconciliation note — two reversals in the v1.0 spec\n\nThe v1.0 spec reverses two positions that `INTEGRATEWISE_ARCHITECTURE.md` v2.1 still states.\nBoth change what \"aligned\" means:\n\n| Subject | v2.1 (31 Jul) | OneAuth spec v1.0 (6 Aug) | Effect here |\n| --------------- | ------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- |\n| 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. |\n| 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. |\n\nNeither reversal is reflected in `INTEGRATEWISE_ARCHITECTURE.md` yet. Under that document's own\nrule — _\"When this document is wrong, change it here\"_ — v2.1 §8.1, §8.2 and the S0 resolution\ntext need amending, or the next person to read it will re-plan the Neon migration.\n\nDelete this file once the changes are applied and `release:check` passes. It is a work order,\nnot a standing document.\n\n---\n\n## 0. Why these got through\n\n`scripts/release/validate-platform-deployment.sh` validates four things: config exists, `main`\nexists, the env-specific Worker name exists with the right suffix, and `mcp-connector` is named\n`-test`/`-prod`. It does not check route uniqueness, binding-target uniqueness, or the\nmarketplace manifest at all.\n\nThere is also a structural gap. `CORE_SERVICES` (line 64) deliberately excludes any Worker\n\"without those surfaces\" — so `mcp-pool`, which has no `[env.test]`, is exempt from validation\n_because_ it is misconfigured. The component with the most privilege is the one the gate does\nnot look at.\n\nFixing F1–F5 without §5 below means this recurs. It already has: S0's silent-write defect was\nfixed on ~2026-07-31 and reappeared six days later as a shared-database leak.\n\n---\n\n## 1. F1 — two Workers claim the public MCP domain\n\n**Evidence:** `services/mcp-connector/wrangler.toml` binds `mcp.integratewise.ai` at both the\ntop level (`:6`) and in `[env.prod]` (`:228`). Last deploy wins, so a routine default-env deploy\nsilently repoints the public MCP endpoint.\n\n```diff\n--- a/services/mcp-connector/wrangler.toml\n+++ b/services/mcp-connector/wrangler.toml\n@@ -3,7 +3,9 @@\n main = \"src/index.ts\"\n compatibility_date = \"2024-12-01\"\n compatibility_flags = [\"nodejs_compat\"]\n-routes = [{ pattern = \"mcp.integratewise.ai\", custom_domain = true }]\n+# The public custom domain is claimed by [env.prod] only. A top-level route here\n+# would let a default-env deploy silently repoint the published MCP endpoint.\n+# Test binds mcp.test.integratewise.ai in [env.test].\n```\n\n**Risk:** low. The default-env Worker loses a domain it should never have claimed. `env.prod`\nretains it at `:228`.\n\n**Check before applying:** confirm nothing currently depends on the unsuffixed\n`mcp-connector` Worker serving production traffic — if it does, that is F1 actively firing and\nthe cutover needs a deploy of `mcp-connector-prod` first.\n\n---\n\n## 2. F2 / F3 — marketplace manifest\n\n**Evidence:** `marketplace/apps/iw-spine-network.json:7` advertises a \"23-tool continuity\nnetwork\"; the `tools` array (`:16–36`) correctly holds exactly 19, matching §16.1 in order.\n`:42` publishes `\"routing\": \"mcp-pool\"`, naming the internal control plane in a public artifact.\n\n```diff\n--- a/marketplace/apps/iw-spine-network.json\n+++ b/marketplace/apps/iw-spine-network.json\n@@ -4,7 +4,7 @@\n \"kind\": \"plugin\",\n \"version\": \"1.0.0\",\n \"publisher\": \"IntegrateWise\",\n- \"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.\",\n+ \"description\": \"The IntegrateWise activation plugin. Installs the 19-tool continuity network and onboards your team into a governed workspace with Digital Memory.\",\n \"icon\": \"spine\",\n@@ -39,6 +39,6 @@\n \"ownership\": {\n \"credentials\": \"provider\",\n- \"metadata\": \"integratewise\",\n- \"routing\": \"mcp-pool\"\n+ \"metadata\": \"integratewise\"\n }\n }\n```\n\n**On dropping `routing` entirely rather than correcting it.** Nothing in the product path reads\n`ownership.routing` — the only references are this file, `iw-continuity-bridge.json`, and prose\nin `CODEBASE_EXCAVATION.md` / `MCP_AND_PLUGIN_PUBLISHING_SPEC.md`. Any value here either states\ninternal topology or restates the public endpoint already carried by the MCP registration.\nRemoving it satisfies F3 without inventing a new public contract.\n\n**Your call:** if a marketplace reviewer expects the field, substitute\n`\"routing\": \"mcp.integratewise.ai\"` — the public endpoint, not the internal service name.\n\nThe \"20 operational connectors and 3 cognitive providers\" figure is real and worth keeping —\nbut as a connector count, not a tool count. It belongs in listing copy, not in the tool contract.\n\n---\n\n## 3. F5 — retired public name in the publishable directory\n\n**Evidence:** `marketplace/apps/iw-continuity-bridge.json` — retired name D9 — sits alongside\nthe live manifest in a directory whose contents are publishable.\n\n**Proposed:** `git rm marketplace/apps/iw-continuity-bridge.json`\n\nHistory preserves it. If it must be retained for reference, move it to\n`docs/architecture/retired/` where nothing publishes from.\n\n---\n\n## 4. Canonical Spine D1 — test and prod share one database\n\n**Evidence:** `services/pipeline/wrangler.toml` binds `CANONICAL_SPINE_DB` to database id\n`1dfe12bc-27be-4c5c-976e-8da691f5dde4` at `:126` (top level), `:269` (`env.test`) and `:392`\n(`env.prod`). This is the anti-pattern named verbatim in `CLAUDE.md`: _\"Do not make a warning\ndisappear by copying a production binding into env.test.\"_\n\nThis is the most consequential item in this document. While it stands, §17.2 gate 4 — _prove\ncomplete Customer Zero isolation_ — is not merely unmet but **unprovable**: there is no\nisolation to produce evidence of.\n\n```diff\n--- a/services/pipeline/wrangler.toml\n+++ b/services/pipeline/wrangler.toml\n@@ -265,7 +265,7 @@\n # --- Canonical Spine D1 (test) ---\n [[env.test.d1_databases]]\n binding = \"CANONICAL_SPINE_DB\"\n-database_name = \"integratewise-canonical-spine\"\n-database_id = \"1dfe12bc-27be-4c5c-976e-8da691f5dde4\"\n+database_name = \"integratewise-canonical-spine-test\"\n+database_id = \"\"\n```\n\n```diff\n@@ -390,7 +390,7 @@\n # --- Canonical Spine D1 (prod) ---\n [[env.prod.d1_databases]]\n binding = \"CANONICAL_SPINE_DB\"\n-database_name = \"integratewise-canonical-spine\"\n-database_id = \"1dfe12bc-27be-4c5c-976e-8da691f5dde4\"\n+database_name = \"integratewise-canonical-spine-prod\"\n+database_id = \"\"\n```\n\n**Required before this can be applied:**\n\n1. `wrangler d1 create integratewise-canonical-spine-test`\n2. `wrangler d1 create integratewise-canonical-spine-prod`\n3. Apply the canonical-spine migrations to both\n4. Determine what `1dfe12bc` currently holds. If it carries real Customer Zero canonical state,\n it becomes the prod database and only test needs creating — but that must be established by\n inspection, not assumption.\n\n**Superseded guidance — read this before acting on the drift register.** The register resolves\nS0 with _\"The Canonical Spine is Neon; delete `CANONICAL_SPINE_DB`.\"_ The OneAuth spec v1.0\nreverses that: D1 **is** the V1 canonical product-plane store (§25.7), and §15.1(5) requires\nNeon product-plane migrations to be quarantined out of the release lane.\n\nUnder the current authority, the diffs above are therefore the **permanent** fix, not a stopgap.\n`CANONICAL_SPINE_DB` stays. What remains open from S0 is different work: making Pipeline the\n_only_ canonical writer (spec §25.8, §15.1(4)), retiring the Supabase legacy writer, and\nconsolidating the duplicated 16-concept ontology out of `pipeline/src/canonical/entity-type-map.ts`.\n\nThis also satisfies spec stop-ship condition #1 and §16.2 (G1 — physical resource isolation),\nwhich is a hard gate before any external activation.\n\n---\n\n## 5. F4 — mcp-pool has no environment isolation, and a dangling binding\n\nThis is the one with a dependency that would have broken a deploy.\n\n**Evidence:** `services/mcp-pool/wrangler.toml` has no `[env.test]`. All three service bindings\nare identical across the top level (`:16–26`), `[env.dev]` (`:31–41`) and `[env.prod]`\n(`:46–56`) — not just `INTEGRATION_MANAGEMENT` as F4 records, but `TASK_MANAGEMENT` and `SPINE`\ntoo. The development control plane talks to production on every binding.\n\n**Additionally — `SPINE` is dangling.** It targets `integratewise-spine`. No Worker by that name\nexists: `services/spine/wrangler.toml:1` names the Worker `integratewise-live`, with\n`integratewise-live-test` and `integratewise-live-prod` per environment. This is drift register\nS2 (\"the core nine were renamed; consumers were never updated\"). The file's own header comment\nwarns that a binding to an undeployed Worker fails the deploy.\n\n**Blocking dependency — do not add `[env.test]` to mcp-pool first.** Its natural targets do not\nexist:\n\n| Binding | Needs | Present? |\n| ------------------------ | ----------------------------------------------- | ----------------------------------------------------------- |\n| `INTEGRATION_MANAGEMENT` | `integratewise-integration-management-mcp-test` | No — that service defines only `[env.dev]` and `[env.prod]` |\n| `TASK_MANAGEMENT` | `integratewise-task-management-test` | No — same gap |\n| `SPINE` | `integratewise-live-test` | Yes |\n\n**Required order:**\n\n1. Add `[env.test]` to `services/integration-management-mcp/wrangler.toml`\n2. Add `[env.test]` to `services/task-management/wrangler.toml`\n3. Deploy both to test\n4. Only then apply the mcp-pool diff below\n5. Add `mcp-pool` to `CORE_SERVICES` in the validator so it stops being exempt\n\n```diff\n--- a/services/mcp-pool/wrangler.toml\n+++ b/services/mcp-pool/wrangler.toml\n@@ -28,15 +28,31 @@\n [env.dev]\n vars = { ENVIRONMENT = \"development\" }\n\n [[env.dev.services]]\n binding = \"TASK_MANAGEMENT\"\n service = \"integratewise-task-management\"\n\n [[env.dev.services]]\n binding = \"INTEGRATION_MANAGEMENT\"\n-service = \"integratewise-integration-management-mcp-prod\"\n+service = \"integratewise-integration-management-mcp\"\n\n [[env.dev.services]]\n binding = \"SPINE\"\n-service = \"integratewise-spine\"\n+service = \"integratewise-live\"\n+\n+[env.test]\n+name = \"integratewise-mcp-pool-test\"\n+vars = { ENVIRONMENT = \"test\" }\n+\n+[[env.test.services]]\n+binding = \"TASK_MANAGEMENT\"\n+service = \"integratewise-task-management-test\"\n+\n+[[env.test.services]]\n+binding = \"INTEGRATION_MANAGEMENT\"\n+service = \"integratewise-integration-management-mcp-test\"\n+\n+[[env.test.services]]\n+binding = \"SPINE\"\n+service = \"integratewise-live-test\"\n\n [env.prod]\n+name = \"integratewise-mcp-pool-prod\"\n vars = { ENVIRONMENT = \"production\" }\n@@ -46,11 +62,11 @@\n [[env.prod.services]]\n binding = \"TASK_MANAGEMENT\"\n-service = \"integratewise-task-management\"\n+service = \"integratewise-task-management-prod\"\n\n [[env.prod.services]]\n binding = \"INTEGRATION_MANAGEMENT\"\n service = \"integratewise-integration-management-mcp-prod\"\n\n [[env.prod.services]]\n binding = \"SPINE\"\n-service = \"integratewise-live\"\n+service = \"integratewise-live-prod\"\n```\n\nThe top-level bindings (`:16–26`) should also be corrected for the dangling `SPINE` name, or the\ntop-level section removed entirely if mcp-pool is never deployed without an environment flag.\n\n**Note:** `integratewise-task-management-prod` assumes `[env.prod]` in that service derives its\nname from the base. Confirm the deployed name before applying — the same derivation question\napplies to `integratewise-integration-management-mcp-prod`, which does resolve today.\n\n---\n\n## 6. Validator extension\n\n### RESOLVED — environment profiles\n\n**Decision (founder, 2026-08-06):** MCP Pool serves the **dev** and **customer-zero** profiles\nonly. It has no external surface.\n\nThis settles the ambiguity below in favour of Reading A: three physical surfaces, with the\nwrangler environment names as the physical handles and the OneAuth spec names as the logical\nones.\n\n| Logical (OneAuth spec §11.2) | Physical (wrangler / `CLAUDE.md`) |\n| --------------------------------------------- | --------------------------------- |\n| `dev` — engineering and contract testing | `[env.dev]` |\n| `customer-zero` — production reference tenant | `[env.test]` |\n| `external` — external production tenants | `[env.prod]` |\n\nIt also adds a rule the drift register did not capture: **not every Worker exists on every\nsurface.** MCP Pool is Platform/Customer Zero infrastructure per\n`PRODUCT_PLATFORM_BOUNDARY_AND_GO_LIVE_STANDARD.md:65` — external tenants reach capability\nthrough the Gateway and the public 19-tool MCP, never through the Pool. Its `[env.prod]` was\nnot a misconfiguration to repair but a surface that should not exist, and has been removed.\n\nWorth recording this mapping in `CLAUDE.md` so the next reader does not re-derive it.\n\n
\nOriginal ambiguity, retained for lineage\n\nThree documents disagreed:\n\n| Source | Profiles named |\n| ----------------------------------- | ------------------------------------------------------------------------------ |\n| `CLAUDE.md` | _\"Deployment surfaces are fixed: local `dev`, demo `test`, and live `prod`\"_ |\n| Every `wrangler.toml` in the repo | `[env.dev]`, `[env.test]`, `[env.prod]` |\n| `INTEGRATEWISE_ARCHITECTURE.md` §17 | Development · Customer Zero · Customer Production |\n| OneAuth spec §11.2 | _\"Three physical profiles are mandatory\"_ — `dev`, `customer-zero`, `external` |\n| OneAuth spec §1.1(1) and §23(1) | _\"test, Customer Zero, or external\"_ — reads as **four** |\n\nTwo readings, with very different costs:\n\n**Reading A — the names are aliases.** `dev` = Development, `test` = Customer Zero,\n`prod` = external/Customer Production. Three physical surfaces already exist; the spec is using\nlogical names for them. The validator below is correct as written, and the only change needed is\ndocumenting the mapping so this ambiguity does not recur.\n\n**Reading B — four surfaces are required.** `test` and `customer-zero` are distinct, and a new\nphysical profile must be provisioned across every Worker: D1, KV, R2, Queues, Vectorize, Durable\nObjects, secrets, routes. That is substantial work, it changes `CORE_SERVICES` handling, and it\nmust land before G1 can be declared green.\n\nSpec §11.2's \"three profiles\" supports Reading A; §1.1 and §23's three-way enumeration alongside\n`dev` supports Reading B.\n\n
\n\n### The assertions\n\nThree checks, appended before the final `failed` check (after line 179). Configuration-only,\nconsistent with the script's stated contract of never calling the Cloudflare API. Written for\nReading A; under Reading B the environment list needs extending, not rewriting.\n\n```bash\n# --- Custom-domain route uniqueness -----------------------------------------\n# A custom domain claimed in more than one section means the last deploy wins\n# and a default-env deploy can silently repoint a published endpoint. (F1)\nsection_route_patterns() {\n local config=\"$1\" header=\"$2\"\n awk -v header=\"$header\" '\n header == \"\" {\n if ($0 ~ /^\\[/) exit\n if ($0 ~ /custom_domain[[:space:]]*=[[:space:]]*true/) print\n next\n }\n $0 == header { in_section = 1; next }\n in_section && /^\\[/ { exit }\n in_section && /custom_domain[[:space:]]*=[[:space:]]*true/ { print }\n ' \"$config\" | grep -o 'pattern[[:space:]]*=[[:space:]]*\"[^\"]*\"' | sed 's/.*\"\\(.*\\)\"/\\1/'\n}\n\nfor service in \"${TARGET_SERVICES[@]}\"; do\n config=\"services/${service}/wrangler.toml\"\n [[ -f \"$config\" ]] || continue\n\n duplicate_routes=\"$(\n {\n section_route_patterns \"$config\" \"\"\n section_route_patterns \"$config\" \"[env.test]\"\n section_route_patterns \"$config\" \"[env.prod]\"\n } | sort | uniq -d\n )\"\n\n if [[ -n \"$duplicate_routes\" ]]; then\n echo \"FAIL ${service}: custom domain claimed in more than one section:\"\n echo \"$duplicate_routes\" | sed 's/^/ /'\n failed=1\n else\n echo \"OK ${service} route uniqueness\"\n fi\ndone\n\n# --- Test/prod binding-target disjointness ----------------------------------\n# Platform rule: test and prod must never share a D1, KV, R2, Queue or service\n# binding target. Catches the canonical Spine D1 leak and the mcp-pool bindings.\nenv_binding_targets() {\n local config=\"$1\" environment=\"$2\"\n awk -v env_re=\"^\\\\[+env\\\\.${environment}\\\\.\" '\n /^\\[/ { in_section = ($0 ~ env_re) ? 1 : 0; next }\n in_section && ($1 == \"database_id\" || $1 == \"id\" || $1 == \"bucket_name\" || \\\n $1 == \"queue\" || $1 == \"service\") {\n gsub(/\"/, \"\", $3); print $1 \"=\" $3\n }\n ' \"$config\" | sort -u\n}\n\nfor service in \"${TARGET_SERVICES[@]}\"; do\n config=\"services/${service}/wrangler.toml\"\n [[ -f \"$config\" ]] || continue\n\n shared=\"$(comm -12 \\\n <(env_binding_targets \"$config\" test) \\\n <(env_binding_targets \"$config\" prod))\"\n\n if [[ -n \"$shared\" ]]; then\n echo \"FAIL ${service}: test and prod share binding targets:\"\n echo \"$shared\" | sed 's/^/ /'\n failed=1\n else\n echo \"OK ${service} test/prod binding isolation\"\n fi\ndone\n\n# --- Published manifest contract --------------------------------------------\n# Exactly 19 public tools; no internal topology in a public artifact. (F2, F3)\nMANIFEST=\"marketplace/apps/iw-spine-network.json\"\nif [[ -f \"$MANIFEST\" ]]; then\n if node -e '\n const m = require(\"./marketplace/apps/iw-spine-network.json\");\n const errors = [];\n if (!Array.isArray(m.tools) || m.tools.length !== 19) {\n errors.push(`tools array must hold exactly 19 entries (found ${\n Array.isArray(m.tools) ? m.tools.length : \"none\"})`);\n }\n const claimed = /(\\d+)-tool/.exec(m.description || \"\");\n if (claimed && claimed[1] !== \"19\") {\n errors.push(`description advertises ${claimed[1]} tools; the contract is 19`);\n }\n const internal = /mcp-pool|mcp_pool|integratewise-(spine|live|pipeline|gateway)\\b/;\n if (internal.test(JSON.stringify(m.ownership || {}))) {\n errors.push(\"ownership names an internal service; public manifests must not leak topology\");\n }\n if (errors.length) { errors.forEach((e) => console.error(\" \" + e)); process.exit(1); }\n '; then\n echo \"OK published manifest contract\"\n else\n echo \"FAIL ${MANIFEST}: manifest contract violations above\"\n failed=1\n fi\nelse\n echo \"FAIL missing ${MANIFEST}\"\n failed=1\nfi\n```\n\n**Also change — remove the exemption that hid F4:**\n\n```diff\n--- a/scripts/release/validate-platform-deployment.sh\n+++ b/scripts/release/validate-platform-deployment.sh\n@@ -70,6 +70,7 @@ CORE_SERVICES=(\n intelligence\n workflow\n+ mcp-pool\n gateway\n )\n```\n\nApply this **only after** §5 steps 1–4. Adding `mcp-pool` before it has an `[env.test]` will\ncorrectly fail the validator — which is the point, but it will block every release until fixed.\n\n---\n\n## 7. Application order\n\n```\n1. F2/F3 manifest copy — no dependencies, no deploy impact\n2. F5 remove retired manifest — no dependencies\n3. F1 remove top-level route — verify prod Worker serves the domain first\n4. Validator §6 assertions — WITHOUT the mcp-pool CORE_SERVICES line\n └─ expect: canonical D1 leak now FAILS. That is the validator working.\n5. Canonical D1 split (§4) — create databases, migrate, then apply\n6. integration-management-mcp + task-management [env.test]\n7. Deploy both to test\n8. mcp-pool §5 diff\n9. Add mcp-pool to CORE_SERVICES\n10. pnpm release:check -- --environment test\n11. pnpm release:deploy -- --environment test --service core --dry-run\n```\n\nSteps 1–3 are safe to apply and review independently. Step 4 is where the value is: it makes\nstep 5 mandatory rather than remembered.\n\n---\n\n## 8. What this does not unblock\n\nAfter all of the above, these gates remain open. Mapped to the OneAuth spec's G0–G9 where they\ncorrespond:\n\n- **Pipeline is not yet the only canonical writer** (spec §25.8, §15.1(4); register S0 steps 3–4).\n `pipeline/src/spine/` — the self-labelled Supabase \"legacy writer\" — is still in the release\n path, and the 16-concept ontology is copy-pasted into `entity-type-map.ts`. **G4.**\n- **S0b** — `org_memory` is a documented cache with six writers and no defined reconciliation.\n- **S0c** — `agent_memory` exists only inside the retired Supabase writer scheduled for deletion.\n It needs a D1 table **before** that file is removed, or the capability is lost with it.\n- **S1** — `hub-controller-api` remains a second unauthenticated entry point bound in all three\n environments to one D1, carrying billing, auth and capability execution.\n- **S2** — fifteen dangling service bindings; §5 above fixes one of them.\n- **F6** — five release flavours against a two-package doctrine.\n- Every evidence gate in §17.2 that requires a live run: Customer Zero daily use, clean-tenant\n install, negative isolation tests, connector lifecycle, governed execution end-to-end.\n\n**Environment note:** the Linux sandbox could not start (host out of disk space), so nothing here\nwas executed — no `release:check`, no dry-run, no `git status`. Every claim above is read from\nthe working tree. The diffs are drafted, not validated.\n"}