{"slug":"canonical/17-IMPLEMENTATION-ALIGNMENT-AND-GAP-REGISTER","title":"Implementation Alignment and Gap Register","section":"canonical","sectionLabel":"Canon","status":"canon","type":"document","path":"canonical/17-IMPLEMENTATION-ALIGNMENT-AND-GAP-REGISTER.md","bytes":83213,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\n**Class:** ALIGNMENT — this document **describes** the repository. It never defines architecture.\nWhere it disagrees with\n[`00-SPINEWORKSPACE-INTEGRATEWISE-CANON.md`](00-SPINEWORKSPACE-INTEGRATEWISE-CANON.md), the\ndisagreement is a gap to close in code.\n\nPart I maps the nine planes to real code. Part II is the ranked gap register.\n\nCanon §28 sets the standard this document is held to:\n\n> Readiness must be evidence-based across at least: implemented, wired, deployed and verified\n> end-to-end. **Presence of code or a Wrangler manifest is not proof of production readiness.**\n\nThat is why several entries below downgrade a finding from \"broken\" to \"dead\" or \"unwired\" — and\nwhy one stays **Not verified** rather than being closed on inference.\n\n**Describes commit:** `b60d21ec0effbf9e382c801727ce233703625ede` (main)\n**Surveyed:** 2026-09-04 · re-verification of G-17–G-22 plus a new-structure survey across\n`services/` (39), `packages/` (56) and `sql-migrations/`. Code is byte-identical to the\n2026-09-03 survey base (`22013618`); the commits in between are canonical-documentation only.\n**Method:** every claim below was checked by reading the file it names. Claims that could not be\nclosed by reading code are marked **Not verified** rather than inferred.\n\n---\n\n## Verdicts on the drifts named in the Founder Canon\n\nThe canon's drift list was written against the Aug 1 freeze. The tree has since moved past one of\nits four items, so each was re-checked rather than carried forward.\n\n### ADK middleware is a governance bypass — confirmed, but it was orphaned\n\n**Status: RESOLVED (deleted 2026-08-31).**\n\nThe canon's description was accurate: `services/gateway/src/adk-middleware.ts` fabricated a\n`Capability` with `requiresApproval: false` hardcoded (line 108) and dispatched straight to a\nruntime (lines 114–128) with no Governance call, no Hermes and no authority check in 362 lines.\n\nBut it was **dead code** — nothing imported it outside its own test, and it was absent from the\nGateway's `index.ts` and `runtime-wiring.ts`. It was a *latent* bypass waiting to be wired by\nsomeone who assumed it worked, not an active hole.\n\nThe correct action was therefore deletion, not redesign. The file and its test were removed; no\ndangling references remain.\n\n### Hermes n8n-first orchestration and `spine.write` — already fixed\n\n`services/hermes/src/orchestrator.ts:130–139` rejects both `spine.write` and `http.request` with\n`ungovernedNodeError`, and states the canon's own reasoning in the comment: a Spine write from an\norchestration node bypasses Pipeline promotion; an arbitrary HTTP node bypasses capability\nresolution and Governance. The n8n-first path is gone from the orchestrator.\n\n*Loose end:* the string `n8n` still appears in `services/hermes/src/types.ts` and `index.ts`.\nProbably inert handoff-adapter typing, but unread — it should be removed or explicitly scoped so\nthe next audit does not re-flag it.\n\n### Capability Fabric → Governance → Hermes — correctly built\n\nNot a drift. This is the strongest part of the codebase and matches the canon's authority boundary\nprecisely.\n\n- `services/capability/src/index.ts:51` — *\"Descriptive catalogue only. Resolution, governance and\n  approval happen in the Governance service.\"*\n- `services/govern/src/index.ts` — owns `/v1/capability/prepare`, `/v1/approvals`,\n  `/v1/authority/{decisions, approvals/consume, idempotency/claim, reconciliations}`\n- `services/hermes/src/authority.ts:2` — *\"Hermes reads its authority from Governance, never from\n  itself.\"* Line 115 **fails closed**: a Governance outage is refused rather than read as\n  \"not replayed.\"\n- `services/gateway/src/workbench-capabilities.ts:928,462` — plans are prepared and signed before\n  reaching an approval surface; status `pending_approval`.\n\n**Per canon §5, this separation should not be redesigned.**\n\n### MCP Pool staying out of the core data path — NOT VERIFIED\n\nThe *shape* is right: `services/mcp-pool/src/` is built as a registry and router\n(`registry.ts`, `pool.ts`, `invocation-router.ts`, `manifest-loader.ts`, `health-monitor.ts`),\nand the Workbench data plane runs through Projection and context-fetch on separate Gateway routes.\n`services/gateway/src/index.ts:1687` confirms `/api/v1/capabilities/resolve` is introspection, not\nexecution.\n\n**The L1 read path was not traced end to end.** This is deliberately left open. The canon's own\nwarning was that MCP Pool had previously been accepted \"without actual routing evidence,\" and\nconverting an architectural intention into an implementation claim is the exact failure mode this\ndocument exists to prevent.\n\n---\n\n## Nine planes → code\n\n| # | Plane | Status | Implementation |\n|---|---|---|---|\n| 1 | **Identity & Authority** | Question | `packages/auth`, `packages/rbac`, `packages/tenancy`, `services/tenants`, `apps/one-access`, `apps/one-access-console`, `apps/auth` |\n| 2 | **Ecosystem & Integration** | Aligned | `services/connector`, `connector-sync`, `mcp-connector`, `webhook-ingress`, `marketplace-installation`, `packages/connectors`, `packages/connector-contracts` |\n| 3 | **Discovery & Activation** | **Gap** | `apps/activation` (UI), `gateway/platform-discovery.ts`, `gateway/platform-catalog.ts` |\n| 4 | **Ingestion & Normalization** | Aligned | `services/gateway`, `loader`, `normalizer`, `pipeline`, `store`, `folder-watcher`, `packages/loader`, `packages/normalizer` |\n| 5 | **Spine & Continuity** | **Gap** | `services/spine`, `knowledge`, `continuity`, `context`, `signals`, `packages/spine-schema`, `spine-entities`, `hermes-spine-memory` |\n| 6 | **Projection & Experience** | Naming | `packages/projection-engine`, `projection-contracts`, `services/projection`, `context-fetch`, `packages/workbenches`, `apps/web`, `apps/workspace` |\n| 7 | **Cognitive & Agent Runtime** | Partial | `services/twin-orchestrator`, `iw-agent-runtime`, `agent-registry`, `intelligence`, `packages/adk`, `packages/model-gateway` |\n| 8 | **Capability & Governance** | Strongest | `services/capability`, `govern`, `mcp-pool`, `packages/lib/capability-fabric`, `packages/spine-network` |\n| 9 | **Execution & Closure** | Aligned | `services/hermes`, `services/pipeline/promotion`, `packages/core/execution-orchestrator`, `services/workflow` |\n\n### Plane notes\n\n**1 — Identity & Authority.** Well covered, with one open question: the Gateway carries **both**\n`clerk-auth.ts` and `descope-auth.ts`. \"One Auth\" with two identity providers wired needs a stated\nreason — mid-migration, or deliberate IdP layering — or it becomes a drift by accident. *Needs a\nfounder or engineering answer, not a code change.*\n\n**3 — Discovery & Activation.** The weakest plane. **Activation Bridge** — the canon's runtime\nconfiguration compiler, distinct from the human-facing Activation Manager — has zero presence by\nname. **Discovery Engine** matches only UI components and knowledge search, not a discovery\nservice. `packages/bootstrap` has no `src/`. The capability may exist under other names; the\nnaming does not survive a canon reader's grep, which is the test that matters for a freeze.\n\n**4 — Ingestion.** Gateway → Loader → Normalizer → governed writers all present. Flows A/B/C/D are\nnot labelled as such in code — a vocabulary gap, not a capability one.\n\n**5 — Spine & Continuity.** The Business Spine is real and well built. The continuity model is\nnot: only **two** memory scopes exist where canon mandates three. See `G-01`, `G-02`.\n\n**6 — Projection.** Projection Engine and Active Context Bundle both exist and are wired.\n\"Workbench Contract\" does not exist under that name. The word *Workbench* is overloaded — see\n`G-04`.\n\n**7 — Cognitive & Agent Runtime.** Twin, ADK and model routing are present. **Spine Agents** as\ncanon defines them are not first-class; `services/agent-registry/src` is a single file. Blocked\nbehind the memory-scope work.\n\n**9 — Execution & Closure.** Outcome → reconciliation → governed promotion → projection\ninvalidation is implemented end to end. `services/pipeline/src/memory-promoter.ts` enforces the\ncanon invariant directly: Twin-sourced writes can **never** auto-promote into organizational\nmemory, landing in `staging` pending approval. This is the invariant already working in code.\n\n---\n\n## What is already canonical and should not be touched\n\nRecorded explicitly, because an alignment document that only lists problems invites unnecessary\nredesign:\n\n- Capability / Governance / Hermes separation, including fail-closed behaviour on Governance\n  outage.\n- Hermes' refusal to perform canonical Spine writes.\n- Governed memory promotion, including the rule that AI-sourced observations never auto-promote.\n- Projection Engine as the sole composition layer, and the Active Context Bundle.\n- Outcome → sync → verify → reconcile → projection invalidation.\n\n---\n\n# Part II — Gap Register\n\n> ## ⚠️ Ordering superseded — 2026-09-01\n>\n> The entries below remain accurate **as measurements**, but their ranking is superseded by the\n> priority stack in\n> [ADR-2026-09-01-02](adr/ADR-2026-09-01-02-reference-execution-is-the-next-design-target.md).\n> The next design target is the **Reference Execution — Business Context to Verified Outcome**, and\n> `G-04` is explicitly deprioritized to P2.\n>\n> ## Survey refreshed against the 6.1 suite — 2026-09-03\n>\n> The suite (adopted verbatim in\n> [ADR-2026-09-03-05](adr/ADR-2026-09-03-05-founder-canon-6-1-schema-ssot-expansion.md)):\n> [`00-SPINEWORKSPACE-INTEGRATEWISE-CANON-6.1.md`](00-SPINEWORKSPACE-INTEGRATEWISE-CANON-6.1.md),\n> [`02-BUSINESS-CONTEXT-SPINE-6.1.md`](02-BUSINESS-CONTEXT-SPINE-6.1.md),\n> [`06-CONNECTOR-SCHEMA-CAPABILITY-CONTINUITY-6.1.md`](06-CONNECTOR-SCHEMA-CAPABILITY-CONTINUITY-6.1.md).\n>\n> The repository was re-surveyed at\n> `22013618a50ea8c6b7f7d75ba980c48b11440454`. The previous stale-stamp warning no longer applies.\n> `G-17` through `G-21` record the additional schema, mapping, KPI/signal, Work/continuity and\n> connector-lifecycle gaps found in that survey. Earlier entries remain as dated measurements.\n\n> ## Re-verified against the founder records — 2026-09-04\n>\n> Re-surveyed at `b60d21ec` after the founder Architecture Flow / Final Goal / Final Architecture\n> records landed ([ADR-2026-09-04-01/02/03](adr/)). Every G-17–G-22 claim was re-verified by\n> reading the file it names; verdicts are recorded per gap. Three new gaps found: `G-23`\n> (memory/continuity/reconciliation planes contracted in surface bindings but never persisted),\n> `G-24` (governance outcome vocabulary drift), `G-25` (stale agent-roster references).\n> Positive alignment also recorded: Hermes implements the canon execution law; the surface\n> contract system (~30 surfaces) is a working projection-binding registry; storage planes\n> (Valkey, Vectorize, R2) are wired; creamy/breadth hydration phases exist in sync adapters.\n\n> ## Gap-closure pass — 2026-09-04 (functional verification included)\n>\n> A fix pass closed `G-22`, `G-24` and `G-25`, authored the `G-23` persistence, and — via the\n> governed-chain test suite (`pnpm test:governed-chain`) — found and fixed a live functional\n> break: the projection engine's D1 entity read path returned zero entities because\n> `mapSpineEntitiesToView` was imported from `types.ts` (which lacks it) instead of\n> `types/index.ts`; the TypeError was swallowed and the Workbench silently composed empty\n> (`packages/projection-engine/src/assemblers/entity-assembler.ts:2`). With the import corrected,\n> `@integratewise/projection-engine` passes 54/54 and `@integratewise/capability` 50/50,\n> including new `denied` / `bounded_delegation` cases. See per-gap notes below for status.\n\nRanked by structural consequence, not by effort.\n\n---\n\n## G-12 · Business context never reaches the action surface — **CRITICAL · STARTED 2026-09-03**\n\nThe largest gap between the product thesis and the code.\n\n**Canon §1A:** *\"Business Context is the only thing that connects the entire workspace to every\nother feature. Without business context, there is no meaning in working in SpineWorkspace.\"*\nBusiness context must lead every surface, every action and every ranking, and **priority is\nbusiness priority** — objectives, goals and KPIs decide order.\n\n**Code:** the four context actions resolve against `ActiveContextBundle`. That contract carries\n`principal`, `projection`, `selection`, `entityContext`, `entity360`, `formation`, `knowledge`,\n`memory`, `evidence`, `capabilities`, `policy`, `freshness`, `uncertainty`, `returnState` — and\n**no objectives, goals or KPIs**. Zero matches for those terms anywhere in\n`packages/context-contracts`.\n\nKPI *measures* exist, but only as entity-level fields in the Projection Engine — `target_value`,\n`current_value`, `health_score`, `probability`, `stage`, `target_date`, under the comment\n\"Canonical KPI & Business Context dimensions (§11.1a)\"\n(`packages/projection-engine/src/types.ts:137`). They are assembled at entity level and stop there.\n\n**Consequence:** an action can see *what this record is*, but not *which goal it serves or how it\nranks*. Nothing in the running system can order work by business priority, because the dimension\nrequired to do so never reaches the surface that would use it. The Mission → Objectives → Goals →\nKPIs → Work chain from canon §13 exists in doctrine and not in the contract.\n\n**Decision:** [ADR-2026-09-01-01](adr/ADR-2026-09-01-01-context-actions-are-ambient.md)\n\n**Shape of the fix:** extend `ActiveContextBundle` with a business-context / intent section\ncarrying the entity's place in the objective chain and its governing KPIs, have the Projection\nEngine populate it from dimensions it already assembles, and have `ContextActionSlot` resolve\navailability and ranking from it. This touches the Projection Engine and every consumer of the\nbundle — scoped, not started.\n\n**STARTED 2026-09-03 (first slice):**\n- `ActiveContextBundle.businessContext?: BusinessContextAlignment` added\n  (`packages/context-contracts/src/active-context.ts`) — optional for backward compatibility.\n- `context-fetch` assembler populates it from the entity's canonical KPI dimensions\n  (`target_value`, `current_value`, `health_score`, `probability` via selection attributes),\n  with `chainComplete: false` — honest partial: KPI measures surface, the objective/goal chain\n  above them is still not populated anywhere in the data.\n- Consumer: `ContextualTwinInvocation.businessAlignment` (Twin context now receives the KPIs this\n  work serves) and `ContextActionSlot` renders the business-priority line with a visible\n  `(partial chain)` marker when `chainComplete` is false.\n\n**Remaining:** objective/goal chain data source (lifecycle chain from canon §13), priority\nranking of actions from business priority, projection-engine-side objective resolution.\n\n---\n\n## G-13 · The Platform view has three homes — **HIGH** *(new, 2026-09-01)*\n\nCanon §2A requires User, Platform, Package, Pipeline-execution and Agentic-execution views to be\n**distinct**. The Platform view is not one surface.\n\n**Code — three candidate homes:**\n\n| Location | State |\n|---|---|\n| `apps/web/app/platform/` | A platform surface **inside the user-view app**. Sections include integration-manager, connector-marketplace, telemetry, tool permissions, autonomous policy gates. |\n| `apps/platform/` | Has `app/architecture`, `tailadmin-architecture`, `api`, a shell. |\n| `apps/platform-console/` | Has `src/app` with `organizations` and `users`. The name matching canon §25 (\"Platform Console\") — but the thinnest of the three. |\n\n**Consequence:** an operator cannot be pointed at *the* Platform view, and a change to operator\nexperience has three places it might belong. It also puts operator-shaped sections inside the\napplication whose entire job is to hide infrastructure from the user (canon §10, Appendix C item\n22).\n\n**Unverified — needs checking before it is treated as a security finding.**\n`apps/web/app/platform/` contains no in-page authorization: no `useSession`, `auth()`,\n`currentUser`, role or redirect. Next.js middleware does cover the path\n(`matcher: [\"/((?!_next/static|_next/image|api/|favicon.ico).*)\"]`), so it is not unprotected by\ndefault — **but I did not verify whether that middleware enforces an operator role for\n`/platform`.** Confirm before concluding either way. Much of the content also reads as descriptive\nrather than operational, so this may be an informational page rather than a live console.\n\n**Decision needed:** which surface is the canonical Platform view, and what happens to the other\ntwo. Canon §25's naming points at `apps/platform-console`, but that is the least built.\n\n---\n\n## G-11 · A surface implements the four actions outside the governed path — **CLOSED 2026-09-03**\n\n**Code:** `apps/web/app/app/workbench/sales/page.tsx` renders \"Store in Spine\" three times\n(lines 117, 155, 194), each driven by local `setShowStoreModal` component state rather than\n`ContextActionSlot`.\n\nThe *placement* is correct — per-card, not a toolbar, consistent with\n[ADR-2026-09-01-01](adr/ADR-2026-09-01-01-context-actions-are-ambient.md). The *path* is not: no\ngovernance decision, no evidence requirement, no proposal, no approval, no reconciliation.\n\nSame class as `G-06` — a parallel ungoverned path — though a UI one. The page has no inbound links\nand appears to be an orphaned demo, which is why it is HIGH rather than CRITICAL. Confirm it is\ndead, then delete it or route it through the slot.\n\n**CLOSED 2026-09-03:** confirmed dead (zero inbound links; `/workbench/*` permanently redirects to\n`/work`) and deleted. The four actions exist only through `ContextActionSlot` (governed path).\n\n---\n\n## G-01 · Three continuity domains collapsed into two — **CLOSED 2026-08-31**\n\n**Was:** `packages/hermes-spine-memory/src/types.ts:29` defined\n`MemoryScope = \"personal\" | \"org\"`, and the namespace header described `personal:user:{id}` as\nholding *\"twin chat history, personal notes\"* — one namespace, two participants. `routeTwinMemory()`\ncould only route Twin into `personal` or `org`; AI had no namespace of its own.\n\n**Now:** three scopes — `org` (tenant-addressed), `personal` (user-addressed), `ai`\n(agent-addressed). Twin defaults to its own `ai` continuity. Every scope refuses to resolve without\nthe subject it addresses, rather than falling back to another participant's id. 27 tests added; the\npackage previously had none.\n\n**Also fixed:** a latent round-trip bug where `dbNameFromPath(ns.path)` and `ns.dbName` produced\n**two different database names for the same namespace**. The path grammar is now uniformly\n`{scope}:{subjectType}:{subjectId}`.\n\n**Decision:** [ADR-2026-08-31-02](adr/ADR-2026-08-31-02-three-continuity-scopes.md)\n\n**Correction to the original assessment:** this register previously implied live commingled data.\nIt does not exist. `packages/hermes-spine-memory` has **zero consumers**; `services/continuity`\nbinds D1 exclusively and no longer has a CouchDB client; `apps/web/lib/core/twin-memory/store.ts`\nis an in-memory `Map` marked dev-only. **No CouchDB memory databases are provisioned, and AI\ncontinuity has no persistent home today.** No migration was required — see `G-10`.\n\n**Note:** the promotion side was already correct — `memory-promoter.ts` never auto-promotes\nAI-sourced writes. Unchanged.\n\n---\n\n## G-02 · Personal Contextual Spine does not exist — **CRITICAL**\n\n**Code:** no match for the term anywhere across `services`, `packages`, `apps` or `contracts`. The\nclosest construct is the `personal` memory namespace, which is a memory store, not a contextual\nspine.\n\n**Canon:** a first-class personal context plane, distinct from both organizational Spine truth and\nAI continuity, with its own privacy boundary and governed promotion rules.\n\n**Decision:** [ADR-2026-08-31-03](adr/ADR-2026-08-31-03-personal-contextual-spine.md)\n\n---\n\n## G-03 · \"Twin Workbench\" contradicts \"AI Workbench\" — **CRITICAL**\n\nTwo live documents, two different models — and this is the drift that caused the whole class of\nproblem.\n\n**Code / docs:**\n- `apps/web/public/docs/architecture/PRODUCT_FRAMING_LOCK.md` §8, §15 — defines *Twin Workbench*\n  as \"the agentic work environment used by the user's Twin.\" Per-user, Twin-owned. Was still\n  marked **CURRENT PRODUCT FRAMING**.\n- `docs/architecture/SPINEWORKSPACE_CANONICAL_PRODUCT_MANUAL.md` — headed *\"THE DEFINITIVE\n  END-STATE MODEL… frozen source of truth.\"* Lists **Twin Workbench** as architectural layer 10\n  and **Coworker** as layer 9.\n\n**Canon:** *Twin is not the AI Workbench.* Twin is the human-facing AI coworker operating inside\nthe AI Workbench, which hosts Twin **and** Spine Agents.\n\n**Decision:** [ADR-2026-08-31-01](adr/ADR-2026-08-31-01-ai-workbench-supersedes-twin-workbench.md).\nBoth documents have been stamped superseded.\n\n**Coworker — RESOLVED against the Founder Canon.** This was previously recorded as needing a\nfounder decision. The Founder Canon settles it: \"coworker\" appears only as a **common noun\ndescribing Twin** — *\"Twin is the human-facing contextual AI coworker operating within the AI\nWorkbench\"* (§0.3 item 6, §32) — never as a distinct layer or component. Appendix C item 5 names\nthe human-AI interface as **Twin**, with no Coworker beside it.\n\nSo the Product Manual's layer-9 *Coworker* is **retired, absorbed into Twin**. Not a separate\nconcept, not a second orchestration authority.\n\n> **Update 2026-09-04:** the founder's Final Architecture record\n> ([`FOUNDER-FINAL-ARCHITECTURE-2026-09-04.md`](FOUNDER-FINAL-ARCHITECTURE-2026-09-04.md) §13,\n> [ADR-2026-09-04-03](adr/ADR-2026-09-04-03-founder-final-architecture.md)) restores **Coworker**\n> as a distinct concept — the contextual companion that helps assemble active context and\n> communication, still not a second orchestration authority. As the later founder decision it\n> supersedes this entry's resolution; the text above stands as the dated measurement of the\n> 2026-08-31 Founder Canon era. Product/UI surfaces follow ADR-2026-09-04-03.\n\n---\n\n## G-04 · \"Workbench\" means several different things — **PARTLY CLOSED 2026-08-31**\n\n### Correcting the original entry\n\nThis entry originally said `WorkbenchType` was a departmental enum competing for the word, and\nprescribed \"rename the departmental lens — mechanical but wide.\" **Both halves were wrong**, and\nthe correction matters more than the original finding.\n\n**`WorkbenchType` was dead.** `packages/types/src/projection-layers.ts` had **zero importers** —\nall 25 exports unreferenced. The apparent hits on `Twin` (1,179), `Insight` (52), `Correlation`\n(21) and `WorkbenchContext` (5) were coincidental collisions with types defined independently\nelsewhere; none imported from this file.\n\n**The live departmental model is somewhere else, and it is load-bearing.**\n`packages/workbench-config` and `packages/workbenches` carry the real departmental surface, and\nthey are consumed by the Gateway (`projections.ts`, `cors.ts`), the Projection Engine, and\n`services/projection`. Critically, `DomainWorkbench` carries a **`hostname`** field — these map to\ndeployed subdomains. Renaming them is not a mechanical rename; it is a routing, CORS and\ndeployment change.\n\n**There are at least three senses in play, not two:**\n\n| Sense | Where | Example values |\n|---|---|---|\n| Participant class *(canon)* | `00-INTEGRATEWISE-CANON.md` | Human Workbench, AI Workbench |\n| Department / domain *(live)* | `packages/workbench-config`, `packages/workbenches` | cs, finance, engineering, founder |\n| Surface / modality *(live)* | `apps/web/components/workbenches/` | email, calendar, tasks, inbox, approvals |\n\n### Action taken\n\n`packages/types/src/projection-layers.ts` **deleted**, and its barrel export removed from\n`@integratewise/types`. Beyond squatting on `WorkbenchType`, it defined **`TwinWorkbench`** — the\nexact term superseded by [ADR-2026-08-31-01](adr/ADR-2026-08-31-01-ai-workbench-supersedes-twin-workbench.md)\n— and being barrel-exported made it reachable by autocomplete and adoptable at any time. Same\nshape as `G-06`: dead code encoding a superseded model.\n\nDeleted rather than renamed, because renaming would have preserved a duplicate of a model the live\npackages already implement better. Full suite before and after: identical (61 failed / 50 passed —\nall pre-existing unresolved imports in an unbuilt workspace).\n\n### Deliberately not done\n\n**The live departmental surface keeps its name.** Renaming it would touch ~315 files plus Gateway\nCORS and hostname routing, to resolve a vocabulary concern. That is a bad trade, and the canon does\nnot require it — canon requires that *Workbench* mean participant class in canonical documents and\nnew work, not that every existing identifier be rewritten.\n\nNote the live app layer already disambiguates better than the dead type did:\n`apps/web/lib/core/workbenches/types.ts` uses **`DepartmentWorkbench`**.\n\n**Open:** whether to adopt `DepartmentWorkbench` / domain-lens naming consistently in new code. A\nnaming convention question, not a refactor.\n\n---\n\n## G-05 · Spine Agents are not first-class — **HIGH**\n\nNamed, not modelled.\n\n**Code:** the term appears in two files. `services/agent-registry/src` is a single `index.ts`. No\nagent-owned memory namespace, no per-agent authority record.\n\n**Canon:** governed organizational AI actors carrying identity, authority, memory namespace and\ncapabilities, cooperating through shared Work and evidence state rather than agent-to-agent\nre-explanation.\n\n**Depends on G-01** — agents cannot have memory namespaces until the scope model supports them.\n\n---\n\n## G-06 · Orphaned governance-bypass middleware — **RESOLVED 2026-08-31**\n\n`services/gateway/src/adk-middleware.ts` — 362 lines, `requiresApproval: false` hardcoded at line\n108, direct runtime dispatch at 114–128, zero importers outside its own test. Harmless as it\nstood; a live bypass the moment anyone wired it.\n\n**Action taken:** file and test deleted. No dangling references remain.\n\n---\n\n## G-07 · Activation Bridge and Discovery Engine unfindable — **HIGH**\n\nPlane 3 has no named home.\n\n**Code:** no match for Activation Bridge. Discovery Engine matches only UI components and\nknowledge search. `packages/bootstrap` has no `src/`. What exists: `apps/activation` (UI),\n`gateway/platform-discovery.ts`.\n\n**Canon:** Discovery Engine discovers data, systems, models, agents and capabilities. Activation\nBridge compiles runtime configuration — distinct from the Activation Manager surface.\n\n**Action:** establish the canonical name → implementation mapping, or build what is missing.\nEither resolution is acceptable; leaving the plane unnameable is not.\n\n---\n\n## G-08 · Documentation has no single canonical root — **MEDIUM (partially addressed)**\n\n**State at survey:** 2,586 md/mdx files across three roots — `docs/` (5),\n`apps/docs/` (1,921), `apps/web/public/docs/` (661). **Four** documents claimed canonical\nauthority and disagreed with each other. ADR numbering collides: two independent sequences both\nstart at `ADR-001` (`apps/docs/internal/adr/decision-register.md` 001–014, and\n`apps/web/public/docs/adr/` 001–007).\n\n**Addressed:** `docs/canonical/` now exists with the CANON / ALIGNMENT doctrine, source\nprecedence, and date-namespaced ADR IDs that cannot collide with either legacy sequence. The two\ncompeting canonical documents are stamped superseded.\n\n**Remaining:** merging the two legacy ADR sequences into this tree, and consolidating the three\ndocumentation roots. Both are disruptive moves that deserve their own change.\n\n---\n\n## G-09 · Contracts tree is one-eighth built — **LOW**\n\nContracts exist, but not where canon looks.\n\n**Code:** `contracts/` holds only `shared-workbench/`. Authority contracts live in\n`services/govern`; projection contracts in `packages/projection-contracts`.\n\n**Canon:** `/contracts/` covering schemas, commands, events, capabilities, projections, authority\nand executions.\n\nLargely a **topology** gap — most contracts exist, they are simply not collected.\n\n---\n\n## G-10 · AI Continuity is neither persisted nor grounded — **HIGH** *(new 2026-08-31, reframed 2026-09-01)*\n\n### The question was wrong\n\nThis entry originally asked: *\"which store backs AI Continuity Memory?\"* Canon §1A reframes it, and\nthe reframing is the more important half:\n\n> **How does AI maintain independent continuity while remaining grounded in, and accountable to,\n> the authoritative Business Context Spine?**\n\n*Accountable to*, not merely *grounded in* — the AI's continuity must be answerable to business\ncontext, not just correlated with it.\n\nStorage is an implementation of grounding, not a substitute for it. Both personal and AI memory\n*operate on* Business Context — they do not replace it. A persisted AI memory that drifts from the\nSpine would satisfy the original question and still fail the product: it would be an AI with a good\nmemory of things the organization no longer believes.\n\nSo this gap has two halves, and only the first was previously recorded.\n\n### Half one — nothing persists it\n\nAI continuity has no persistent home. Neither candidate substrate is live.\n\n**Code:**\n- `packages/hermes-spine-memory` — a complete CouchDB substrate (client, namespaces, continuity\n  object CRUD) with **zero consumers**. Nothing imports it.\n- `services/continuity` — binds `env.DB` (D1) exclusively. Its `wrangler.toml` carries the note\n  *\"SUPABASE_* secrets removed — service uses env.DB (D1) exclusively (DECISION 22)\"*, and\n  `src/couchdb.ts` no longer exists.\n- `apps/web/lib/core/twin-memory/store.ts` — in-memory `Map` implementation, headed *\"Production:\n  Replace with Supabase or database backend.\"*\n\n**Consequence:** the three-domain model now exists correctly in types (`G-01`), but nothing writes\nthrough it. Twin's working memory does not survive a process restart.\n\n**Stale documentation to correct:** `services/continuity/README.md` still instructs\n`wrangler secret put COUCHDB_URL / COUCHDB_USER / COUCHDB_PASSWORD`, and\n`apps/web/public/docs/internal/status/SERVICE_ARCHITECTURE_REPORT.md` lists a `src/couchdb.ts` that\nno longer exists. Both imply a CouchDB deployment that is not there.\n\n### Half two — nothing grounds it\n\nEven once persisted, there is no mechanism keeping AI continuity anchored to the Spine:\n\n- **No grounding reference.** `ContinuityObject` carries `references: ObjectReference[]` typed as\n  `entity | document | session | task | decision | signal` — but nothing requires a continuity item\n  to reference the business context it was formed against, and nothing invalidates it when that\n  context changes.\n- **No staleness signal.** `ActiveContextBundle` has `freshness` and `uncertainty` for the context\n  it assembles, but AI continuity is not assembled through that path, so it inherits neither.\n- **No business anchor to ground *to*.** Per `G-12`, objectives, goals and KPIs never reach the\n  context surface — so even a grounding mechanism would have nothing to bind against beyond entity\n  identity.\n\n**G-10 half two is therefore blocked on `G-12`.** Business context has to arrive at the surface\nbefore AI continuity can be held against it.\n\n### Decisions needed\n\n1. **Grounding contract** (architecture, blocked on `G-12`) — what a continuity item must reference\n   in business context, and what happens to it when that context moves. This is the decision that\n   matters.\n2. **Store** (implementation) — the existing CouchDB substrate, D1 alongside `services/continuity`,\n   or something else. Answer this *after* (1), so the store is chosen to serve grounding rather\n   than grounding retrofitted onto a store.\n\n---\n\n## A note on \"memory scope\" meaning three different things\n\nNot a gap, but a trap for the next reader. Three unrelated axes share the word *scope*:\n\n| Location | Axis | Values |\n|---|---|---|\n| `packages/hermes-spine-memory` | **Ownership / continuity domain** | `org`, `personal`, `ai` |\n| `apps/web/lib/core/twin-memory/types.ts` | **Durability / lifetime** | `SESSION`, `WORKING`, `LONG_TERM`, `ORGANIZATIONAL` |\n| `packages/context-contracts/src/active-context.ts` | **Retrieval facet** (Active Context Bundle) | `session`, `user`, `work`, `entity`, `organization` |\n\nOnly the first is the canonical three-domain model. The other two are legitimate but differently\nnamed concepts, and both use `organization`/`ORGANIZATIONAL` in a sense that overlaps but is not\nidentical to `org`. Renaming is deferred — recorded so nobody \"fixes\" the wrong one.\n\n---\n\n## Open questions (not gaps)\n\nRecorded because they need an answer from someone, not a code change from anyone.\n\n| # | Question |\n|---|---|\n| Q-1 | The Gateway carries both `clerk-auth.ts` and `descope-auth.ts`. Is \"One Auth\" with two IdPs a migration in flight, deliberate layering, or accidental drift? |\n| Q-2 | Is MCP Pool in the L1 read path? Requires tracing, not opinion. |\n\n**Closed:** *\"Is Coworker an aspect of Twin, or retired?\"* — answered by the Founder Canon. Retired, absorbed into Twin. See `G-03`.\n\n\n## G-14 · Agent Home is not a unified runtime — **HIGH** *(new, 2026-09-03, from Canonical Product Spec)*\n\nThe spec names **one governed Agent Home per workspace**: `shared/` (workspace context, policies,\nknowledge, capabilities, model registry), `twin/` (orchestration + continuity state), and `runs/`\n(specialist agents as isolated scoped runs). Code has fragmented pieces (agent registry, Twin\nruntime, twin-memory store) but no unified Agent Home runtime, and the \"runs as scoped tasks, never\ncompeting user-facing identities\" model is unbuilt. Twin intervention levels 0–5 (Observe → Inform\n→ Explain → Propose → Prepare → Execute) are likewise not modeled explicitly. Users must see\noutcomes, evidence, decisions, and approvals — never an \"Agents\" menu.\n\n---\n\n## G-15 · Fortress audit plane does not exist as a named plane — **HIGH** *(new, 2026-09-03, from Canonical Product Spec)*\n\nThe spec defines **Fortress**: an append-oriented, tamper-evident, retention-governed audit plane\n(decisions, approvals, policy checks, actions, outcomes, verification) with a defined decision-trace\nshape: context snapshot refs, evidence refs, rationale summaries, model/version, proposal/approval,\ntool calls, results, verification state. Raw chain-of-thought must NOT be retained as an enterprise\npersistence contract. Audit logs exist (canon §17) but no unified Fortress plane or decision-trace\nshape.\n\n---\n\n## G-16 · Role grammar (16 sections) and role-specific entity models — **MEDIUM** *(new, 2026-09-03, from Canonical Product Spec)*\n\nThe spec freezes a 16-section workbench grammar (Home/Role Brief, My Work, Primary Portfolio,\nEntity 360, Pipeline/Queue, Timeline, Calendar, Communications, Documents & Knowledge, Signals &\nRisks, Approvals, Planning Canvas, Reports & Metrics, Automation & Playbooks, Recent Work, Twin\nDetail — Twin Detail is click-triggered, never a permanent sidebar) and 12 canonical roles with\ndistinct entity models (Founder→Strategic Objective, Sales→Opportunity, Legal→Contract/matters/\nclauses, Technology→Service/repos/PRs, Support→Ticket/SLAs/escalations, …). Current code has 10\ndepartment configs; the grammar and role-specific entity models are not yet projection contracts.\n\n---\n\n## G-10 (updated) · AI Continuity — L1–L8 promotion stages not modeled — *(reframed 2026-09-03)*\n\nThe spec fixes the memory lifecycle as an eight-stage pipeline: L1 Twin insight → L2 Intake → L3\nTriage → L4 Evolution → L5 Promotion candidate → L6 Approval → L7 Organizational continuity → L8\nVerified knowledge. Dynamic records must retain tenant/entity linkage, confidence, generating actor,\nand OODA episode association; canonical promotion requires governed review; memory supports\nprovenance, correction, supersession, expiration, retention, and conflict resolution. The existing\npromotion law satisfies the boundary; the explicit stage model does not exist yet.\n\n---\n\n## G-17 · Entity ontology and universal envelope do not match 6.1 — **HIGH** *(new, 2026-09-03)*\n\n**Canon:** §3 and §4 define a 26-field universal Spine record envelope and 20 primary business\nentities. The Business Context Spine extends that inventory with 20 additional canonical objects.\nRequired envelope concerns include workspace identity, primary source, record state, confidence,\nfreshness and visibility — not only an ID, tenant and JSON payload.\n\n**Code:** the active vocabulary is both narrower than 6.1 and internally inconsistent:\n\n- `packages/spine-schema/src/entities.ts:11-21` exports ten `RootConcept` values.\n- `services/spine/src/canonical-store.ts:17-42` labels its model \"16 Root Concepts\" plus seven\n  operational primitives and stores all of them through one generic entity contract.\n- `sql-migrations/081_neon_workbench_spine_v1.sql:147-165` constrains `spine.entities` to those 16\n  entity types and places most record-specific state in `data`, `metadata` and `provenance` JSON.\n- Richer definitions such as `Account` and `Contact` exist in\n  `packages/spine-entities/src/account.ts` and `contact.ts`, but the package barrel exports neither\n  (`packages/spine-entities/src/index.ts:9-41`). They are not the active canonical store contract.\n\n**Consequence:** canon entities such as Contract, Subscription, Invoice, Ticket, Meeting, Employee,\nFeature, EngineeringIssue, Release and Deployment have no consistently exported, persisted 6.1\nidentity. Envelope fields cannot be validated uniformly, and connector mappings can collapse\nbusiness meaning into a generic type or JSON payload.\n\n**Required fix:** adopt one versioned 6.1 entity registry; implement the universal envelope as a\nshared persisted contract; export the canonical object schemas; migrate the D1/Neon constraints and\nread/write paths; and provide compatibility mappings for existing 16-type records. This is a schema\nmigration, not a terminology-only rename.\n\n**Re-verified 2026-09-04 (`b60d21ec`) — HOLDS.** All four claims re-read and confirmed. Refinements:\n`spine-schema` RootConcept is the ten values `Organization, Workspace, Person, Team, Process,\nProject, Objective, Outcome, Asset, Opportunity`; the barrel now additionally exports operational\ntypes (`Connection`, `Connector`, `SyncJob`, `Webhook`, `Schema`, `Capability`, `TimelineEvent`,\n`PlatformEvent` with `ReconciliationStatus`/`ProjectionFreshness`) — `account.ts`/`contact.ts`\nremain unexported. The universal envelope concerns (`workspace_id`, `external_ids`,\n`source_systems`, `source_primary`, `record_state`, `confidence`, `freshness_at`,\n`visibility_scope`, `classification`) appear nowhere on `spine.entities`; `external_ids JSONB`\nexists only in domain depth tables (`sql-migrations/048_spine_universal_depth.sql:62,227,260`).\n`082_spine_tenant_user_lifecycle.sql` adds a real lifecycle/RBAC plane (business domains, app\ncategories, `domain_entity_types`, lifecycle stages, `domain_workbench_bindings`, five projection\nviews) but does not adopt the 6.1 entity set or envelope.\n\n---\n\n## G-18 · Versioned field-mapping plane and conflict resolution are absent — **CRITICAL** *(new, 2026-09-03)*\n\n**Canon:** §11.1 and Connector Specification §5 require a durable, versioned, per-tenant mapping\nrecord: provider object class, canonical object and field, transformation, identity and relationship\nrules, source precedence, conflict policy, write mode, sync direction and provenance. Canonical field\nstate must represent `source_conflict`, `stale`, `unverified`, `missing`, `invalid` and\n`pending_promotion` rather than silently selecting a value.\n\n**Code:** mapping is implemented as disconnected local helpers:\n\n- `services/pipeline/src/canonical/entity-type-map.ts:82-92,385-395` is a process-wide static object\n  map and defaults unknown provider types to `Asset`.\n- `services/integration-management-mcp/src/schema-manager.ts:11-53` keeps tenant-tagged schemas in an\n  in-memory `Map`; its versioned result is not a durable activated tenant policy.\n  `normalizeSchema`/`computeFieldMapping` (`:201-240`) perform vocabulary substitution only.\n- `packages/connectors/src/sync-adapters.ts:35-84` hardcodes provider-specific field transforms in\n  connector functions.\n\nThere is no single persisted mapping activation record, provider-object classification registry,\nsample-test gate, tenant source-precedence engine or canonical field-conflict state machine.\n\n**Consequence:** the same provider field can acquire different business meaning depending on which\npath ingests it. Mapping changes are not auditable or safely reversible, tenant precedence cannot be\nenforced, and contested values can be promoted without an explicit resolution state.\n\n**Required fix:** build the semantic mapping plane as a durable tenant-scoped service/schema;\nversion object and field mappings immutably; activate versions only after sample-record tests; add\ntransformation, identity, relationship, write and conflict policies; persist field-resolution state\nand provenance; and route every connector/normalizer through the activated mapping version.\n\n**Re-verified 2026-09-04 (`b60d21ec`) — HOLDS.** All three claims re-read and confirmed. Note:\n`packages/spine-entities/src/schema.ts` defines a `Schema` shape with `canonicalMappings`,\n`version` and `hash`, but it is a type definition, not a durable activated tenant mapping policy.\nPositive: `packages/connectors/src/sync-adapters.ts` implements the founder record's hydration\nphases (`opts.phase === \"creamy\" ? 10 : …`) — creamy/breadth hydration exists at the sync layer\neven though the mapping plane above it is still absent.\n\n---\n\n## G-19 · KPI and Signal are not first-class business objects — **HIGH** *(new, 2026-09-03)*\n\n**Canon:** §6 defines KPI as a governed object with metric identity, target, actual, thresholds,\nownership, period, trend and alert policy. §9 defines Signal with source, severity, baseline, delta,\nimpact, evidence and recommended Work. Together they form the traceable KPI → Signal → Work chain.\n\n**Code:** `services/signals` is an event bus. Its `SignalMessage`\n(`services/signals/src/index.ts:24-36`) carries routing/event data, while `SignalStore` persists bus\nprocessing state (`services/signals/src/store.ts:1-13,32-42`). It is not the canonical 24-field\nbusiness Signal contract. KPI appears only as projection alignment dimensions in\n`BusinessKpiAlignment` (`packages/context-contracts/src/active-context.ts:177-198`); there is no\nfirst-class KPI record with thresholds, ownership and alert policy.\n\n**Consequence:** targets and thresholds cannot be governed and queried independently of a\nprojection, and a detected event cannot retain a canonical baseline, delta, impact and recommended\nWork. The system cannot evidence which KPI produced a Signal or which Work resolved it.\n\n**Required fix:** add versioned KPI and Signal schemas and persistence; connect KPIs to entities,\ngoals and evidence; implement threshold/trend evaluation that creates canonical Signals; link each\nSignal to recommended or created Work; and project those records through the existing context and\nsignal-delivery paths. The event bus should transport Signal changes, not substitute for the Signal\nbusiness object.\n\n**Re-verified 2026-09-04 (`b60d21ec`) — HOLDS.** `SignalMessage` remains an event-bus envelope\n(`signal_type`, `source_service`, `event_name`, `correlation_id` — no baseline/delta/impact/\nrecommended_work); `SignalStore` remains bus state (`pending/processed/failed/replayed`);\n`BusinessKpiAlignment` remains projection dimensions. One richer element than previously recorded:\n`BusinessContextAlignment` already models the Mission → Objectives → Goals → KPIs chain with an\nexplicit `chainComplete: false` honesty flag — the chain skeleton exists, the governed KPI/Signal\nrecords do not.\n\n---\n\n## G-20 · Formal Work identity and ContinuityRun execution chain are missing — **HIGH** *(new, 2026-09-03)*\n\n**Canon:** §8 makes `Work` the durable human-AI coordination object, including context contract,\ncurrent holder, handoff state, authority, evidence and outcome. §19 requires `ContinuityRun` to keep\none trace from intent and context through capability selection, governance, execution, verification,\nreconciliation and canonical-state refresh.\n\n**Code:** `services/continuity` models conversational `SessionContainer`, `SessionEvent` and\ncheckpoints (`services/continuity/src/types.ts:31-88`). Operational tasks live in\n`spine.activities`; the schema explicitly says Activity is a primitive rather than a canonical root\nand provides task/message/meeting/approval rows (`sql-migrations/081_neon_workbench_spine_v1.sql:261-286`).\nNeither contract carries the canonical Work identity, `context_contract`, `current_holder` or\n`handoff_state`, and no `ContinuityRun` joins the execution-and-closure stages.\n\n**Consequence:** a task, conversation, approval, capability execution and verified outcome cannot\nreliably share one stable business-work identity. Handoffs require reconstruction, and end-to-end\ncontinuity is lost when the model, participant, provider or execution route changes.\n\n**Required fix:** implement `Work` and `ContinuityRun` as first-class canonical records; preserve\nWork ID across projections and provider routes; bind Work to goals/KPIs, Signals, context snapshots,\nevidence, decisions and commitments; and append each governance, Hermes, outcome, verification and\nreconciliation transition to the same ContinuityRun. Existing activities and sessions should link\nto Work rather than be relabelled as Work.\n\n**Re-verified 2026-09-04 (`b60d21ec`) — HOLDS, with one new partial to credit.**\n`services/intelligence/src/handoff/` implements a real handoff state machine\n(`state-machine.ts` — `ALLOWED_TRANSITIONS`, persisted `handoff_packages`/`handoff_state_log`\nwith actor + reason, 409 on invalid transitions), and\n`packages/contracts/src/surfaces/platform.ts:415` names a `spine_continuity_runs` supporting\ntable. This is handoff/continuity infrastructure, not the canonical Work object: no record\nanywhere carries `context_contract`, `current_holder`, `handoff_state` or Work identity, and no\n`ContinuityRun` joins governance → execution → verification → reconciliation stages.\n\n---\n\n## G-21 · Connector revocation does not complete the degradation lifecycle — **MEDIUM** *(new, 2026-09-03)*\n\n**Canon:** Connector Specification §10 requires revocation to stop sync, invalidate credentials and\nroute-dependent capabilities, retain historical canonical state, visibly degrade freshness, expose\nstale projections and retain the audit trail.\n\n**Code:** the connector route marks `tenant_connections.status = 'revoked'`\n(`services/connector/src/routes/capability.ts:242-249`). Projection governance can block a capability\nalready marked `degraded` or `unavailable`\n(`packages/projection-engine/src/evaluators/governance-evaluator.ts:71-79`), and the context contract\ncan describe generic stale sources (`packages/context-contracts/src/active-context.ts:126-141`). The\nsurvey found no end-to-end path that converts the revoked connection into both route-capability\nstatus and source-specific freshness degradation in projections. The freshness source contract also\nhas no connection/revocation reference.\n\n**Consequence:** historical values sourced only from a revoked provider can remain visually\nindistinguishable from live data, while capability availability and data freshness may disagree.\nUsers and AI can therefore reason from stale context without seeing why it degraded.\n\n**Required fix:** emit and audit a revocation lifecycle event; stop scheduled and queued sync;\ninvalidate credentials; recompute route-dependent capability availability; mark records and\nprojection sources from that connection stale with last-successful-sync and revocation reason; and\nverify re-install, retention and reconciliation behavior end to end.\n\n**Re-verified 2026-09-04 (`b60d21ec`) — HOLDS.** The revocation handler remains a single\n`UPDATE tenant_connections SET status = 'revoked'` returning `{revoked: true}` — no event, no\ncredential invalidation, no sync stop. The governance evaluator's healthy-path comment (\"A\ncapability whose connection is not healthy cannot resolve, so the Workbench shows it as blocked\")\nand `FreshnessSource {sourceRef, observedAt, status}` confirm both halves exist with no link\nbetween them.\n\n---\n\n## G-22 · Superseded v11.0-era doctrine is still live in active instructions and contracts — **HIGH** *(new, 2026-09-04)*\n\n**Canon:** the Founder Canon (2026-08-31) and the founder Architecture Flow record\n(`FOUNDER-ARCHITECTURE-FLOW-2026-09-04.md`, see ADR-2026-09-04-01) fix the AI work model as\n**Twin + governed Spine Agents** coordinating through Work, evidence and handoff, with knowledge\npromoted through the governed Spine path. The January 2026 \"v11.0 Master Lock\" marketing pack and\nits vocabulary are superseded (ADR-2026-09-04-01 §F-3).\n\n**Code:** superseded doctrine and vocabulary remain in active, non-archive surfaces:\n\n- `.github/agent.md:169-171` instructs agents: \"**Only One Cognitive Twin** … a single Cognitive\n  Twin per tenant/workspace, **not multiple specialized agents**.\" This directly contradicts the\n  Twin + Spine Agents model and would steer new implementation away from governed specialist\n  agents.\n- `contracts/shared-workbench/CHANGELOG.md:20,36` still maps the `knowledge` projection input to\n  \"IQ Hub context\" and states \"`knowledge` comes from IQ Hub, never from Spine directly\";\n  `packages/projection-engine/ARCHITECTURE.md:21,83` repeats the \"IQ Hub\" enrichment language.\n  The retired name aside, an absolute \"never from Spine\" rule conflicts with the canonical\n  knowledge/evidence promotion path (`KnowledgeRecord`/`EvidenceRecord` in the 6.1 canonical\n  inventory) and needs re-scoping to personal knowledge surfaces versus promoted organizational\n  knowledge.\n\n**Consequence:** agents reading `.github/agent.md` will implement against retired doctrine;\ncontract language pins the projection layer to a retired product concept, so future work either\npropagates stale vocabulary or diverges from the written contract.\n\n**Required fix:** rewrite the agent-doctrine section to the Twin + Spine Agents model with the\ncurrent vocabulary; re-scope the `knowledge` projection contract to explicit personal-knowledge\nversus Spine-promoted knowledge inputs and update the projection-engine architecture references;\nkeep archived v11.0 documents as lineage only.\n\n**Re-verified 2026-09-04 (`b60d21ec`) — HOLDS, expanded.** All three original claims re-read and\nconfirmed. Two refinements: (1) the same \"Only One Cognitive Twin\" doctrine is duplicated at\n`apps/web/public/docs/team/AGENTS_SUPPLEMENT.md:159-161`; the codebase it describes already has\nspecialist agents (`services/iw-agent-runtime/src/agents/` — triage, schema, discovery,\nautotuner, collaboration-log) and a `services/twin-orchestrator`, so the doctrine contradicts\nreality, not just canon. (2) The \"knowledge from IQ Hub, never from Spine\" line echoes a\ndeliberate boundary documented in `apps/web/public/docs/adr/005-iq-hub-derived-intelligence-only.md`\n(derived intelligence never stores canonical state; Spine reads entities) — the *boundary* is\nADR-backed, the *name* is retired; the fix is re-scoping and renaming, not reversing the\nfact/inference separation.\n\n**Fix 2026-09-04 — CLOSED.** Doctrine rewritten in `.github/agent.md` §8 and\n`apps/web/public/docs/team/AGENTS_SUPPLEMENT.md` §8 (\"One Twin, governed Spine Agents\" with the\nfour governance outcomes and explicit-delegation rule); the `knowledge` contract line in\n`contracts/shared-workbench/CHANGELOG.md` now scopes the derived-intelligence plane against the\nSpine promotion path; `packages/projection-engine/ARCHITECTURE.md` references the derived\nknowledge plane instead of IQ Hub.\n\n---\n\n## G-23 · Memory, continuity and reconciliation planes are contracted but never persisted — **HIGH** *(new, 2026-09-04)*\n\n**Canon:** the founder records and Canon 6.1 make Organizational Memory, Personal Contextual\nMemory and AI Continuity Memory three governed planes, with promotion, continuity runs and\nreconciliation records as durable state (6.1 §19 ContinuityRun; final-architecture record §8).\n\n**Code:** the surface contracts already bind the Workbench to these planes —\n`packages/contracts/src/surfaces/platform.ts:405-421` (`memoryContinuitySurface`) declares\n`primaryTable: spine_memory_items` and `supportingTables: spine_memory_candidates,\nspine_memory_promotions, spine_continuity_runs, spine_continuity_checkpoints,\nspine_continuity_episodes, spine_reconciliation_records`, with governed commands\n(`memory.promote`, authority `human_approval`); `admin.ts` references the same table family.\nNo migration creates any of them: a sweep of `sql-migrations/` (including `d1/`) and\n`services/*/migrations` finds no `CREATE TABLE` for this family. The continuity service types map\nto a `memory.*` schema (`memory.session_containers`, `memory.session_events`,\n`memory.continuity_checkpoints`) whose creation is likewise not in the migration tree.\n\n**Consequence:** the Memory & Continuity surface is wired to tables that do not exist, so the\nplatform's memory/continuity/reconciliation story is presented in contracts while having no\ndurable state; promotion and reconciliation cannot be audited because their records cannot be\nstored.\n\n**Required fix:** add the migration set for the memory/continuity/reconciliation table family\n(or reconcile the contract table names to wherever this state actually lives); wire\n`services/continuity` and `services/pipeline/src/memory-promoter.ts` to the persisted tables; and\nmake `spine_continuity_runs`/`spine_reconciliation_records` the join points required by G-20.\n\n**Fix 2026-09-04 — PARTIAL.** `sql-migrations/084_spine_memory_continuity_reconciliation.sql`\ncreates the full seven-table family in the 081 Neon style (`spine.memory_items`,\n`memory_candidates`, `memory_promotions`, `continuity_runs`, `continuity_checkpoints`,\n`continuity_episodes`, `reconciliation_records`), including the promotion-queue fields from the\nfinal-goal record and the ContinuityRun join refs. Still open: runtime wiring of\n`services/continuity` and the memory promoter onto these tables (they currently write\n`org_memory`/`memory_promotion_audit` on the D1 edge), and Neon migration application.\n\n---\n\n## G-24 · Governance outcome vocabulary and delegation outcome drift from canon — **MEDIUM** *(new, 2026-09-04)*\n\n**Canon:** Governance has four outcomes — ALLOW, DENY, REQUIRE_APPROVAL, BOUNDED_DELEGATION\n(Founder Canon §19; ADR-2026-09-04-01 flag set).\n\n**Code:** `packages/projection-engine/src/evaluators/governance-evaluator.ts:65,76,90,99` emits\n`decision: \"blocked\" | \"approval_required\" | \"allowed\"`; `services/govern/src/index.ts` operates\non the same vocabulary. There is no `denied` outcome distinct from `blocked` and no\nbounded-delegation outcome anywhere (`BOUNDED_DELEGATION` / bounded delegation: no matches in\n`services/govern`, `packages/projection-engine`).\n\n**Consequence:** governance decisions cannot express delegation-with-bounds, and the mismatch\nbetween canon outcome names and code decision values makes policy review and audit mapping lossy.\n\n**Required fix:** align the decision vocabulary to the four canon outcomes (or version the\nmapping explicitly in a contract), and implement BOUNDED_DELEGATION for capability invocation\nunder delegated authority.\n\n**Fix 2026-09-04 — CLOSED.** `packages/capability/src/governance.ts` now resolves to\n`allowed | denied | approval_required | bounded_delegation | blocked` (canon four plus `blocked`\nreserved for integrity/availability non-resolution, documented at the type). Explicit policy\nrefusals (`blockedCapabilityIds`, `blockedRiskThreshold`) emit `denied`;\n`PolicySnapshot.delegatedCapabilityIds` implements BOUNDED_DELEGATION — a non-human actor with an\nexplicit capability-scoped delegation executes without an approval token, while explicit refusal\nstill wins over delegation. `authorization.ts` refuses `denied` (`decision_denied`) and the\nprojection-engine evaluator projects policy-denied capabilities as `denied`. Tests updated and\nextended (denied, bounded delegation, denial-beats-delegation); capability 50/50,\nprojection-engine 54/54.\n\n---\n\n## G-25 · Agent-roster documentation references a Coworker implementation that no longer exists — **MEDIUM** *(new, 2026-09-04)*\n\n**Canon:** ADR-2026-09-04-03 restores **Coworker** as a distinct concept — the contextual\ncompanion that helps assemble active context and communication, not a second orchestration\nauthority (superseding the G-03 retirement annotation).\n\n**Code:** `packages/skills/src/agent-roles/SKILL.md:5,24,235,457` documents a \"Coworker Agent\"\nand points to `services/iw-agent-runtime/src/agents/coworker-agent.ts`; that file does not exist —\nthe agent directory holds `adaptive-autotuner-agent.ts`, `collaboration-log-agent.ts`,\n`discovery-agent.ts`, `schema-agent.ts`, `triage-agent.ts`, and\n`services/pipeline/src/memory-promoter.ts:96` records the rename (\"coworker\" legacy marker —\nclass renamed to CollaborationLogAgent).\n\n**Consequence:** with Coworker restored at the founder level, the runtime has no Coworker actor\nunder that name, and the skills documentation routes contributors (and agents) to a path that\n404s. Context-assembly companion behavior is either scattered or mislabeled.\n\n**Required fix:** reconcile the agent roster with the restored canon concept — either restore a\nCoworker agent (context-assembly companion role) in `iw-agent-runtime` or rename the\nCollaborationLogAgent role explicitly; update `packages/skills` paths and the type union to match\nreality.\n\n**Fix 2026-09-04 — PARTIAL.** `packages/skills/src/agent-roles/SKILL.md` now points at\n`collaboration-log-agent.ts`, documents the rename and the ADR-2026-09-04-03 restoration. Still\nopen: a dedicated Coworker actor (context-assembly companion) in `iw-agent-runtime` — the\nCollaboration Log Agent currently carries the behavior under the old name.\n\n---\n\n## Verified alignment strengths (2026-09-04)\n\nRecorded so gaps are read in context:\n\n- **Hermes implements the execution law** — `services/hermes/src/index.ts`: executes only\n  already-authorized `AuthorizedExecutionCommand`s, verifies tenant/workspace/actor match, plan\n  immutability, governance decision validity/expiry, capability/tool-capability/connection match,\n  approval token, replay/idempotency; never writes canonical truth (outcomes promote through the\n  Pipeline); exposes `projectionInvalidationKeys` and `isPresentableAsComplete`.\n- **Projection-binding registry exists in practice** — ~30 `SurfaceBackendContract`s across\n  `packages/contracts/src/surfaces/` bind route → `projectionId` → `primaryTable` →\n  `supportingTables` → governed `commands` (capability, authority, `governanceRequired`);\n  `services/projection/src/manifest-loader.ts` loads projection manifests;\n  `packages/projection-engine/src/` has assemblers/enrichers/evaluators/resolvers;\n  `sql-migrations/082` adds `product.domain_workbench_bindings` and RBAC projection views.\n- **Storage planes are wired** — Valkey (`services/context-fetch`, `services/knowledge`,\n  `services/intelligence`), Vectorize (`services/connector`, `services/loader`,\n  `services/intelligence`), R2 (`services/admin`, `services/connector-sync`, `services/hermes`,\n  `services/context-fetch`, `services/folder-watcher`, `services/intelligence`).\n- **Creamy/breadth hydration** exists in `packages/connectors/src/sync-adapters.ts`, matching the\n  founder Architecture Flow record's onboarding doctrine.\n---\n\n## G-29 · An orphaned surface still exposes four literal context-action buttons outside the governed path — **HIGH · FIXED 2026-09-04** *(new, 2026-09-04)*\n\n**Canon:** §3A — the four context actions are ambient affordances bound to a specific owner, never\na persistent toolbar: *\"the interface never exposes four literal global controls\"*\n([ADR-2026-09-01-01](adr/ADR-2026-09-01-01-context-actions-are-ambient.md)).\n\n**Code:**\n- `apps/web/components/workbench/department-workbench.tsx:237-266` renders a sticky footer grid of\n  four literal `Observe` / `Orient` / `Decide` / `Act` buttons — exactly the anti-pattern.\n- `apps/web/components/workbench/workbench-router.tsx:183-186` wires `onOODAAction` to a bare\n  `console.log` — no `ContextActionSlot`, no governance decision, no proposal, no approval, no\n  reconciliation. Same class as the closed `G-11`.\n- The router itself is orphaned: zero usages of `WorkbenchRouter` outside its own file (verified\n  2026-09-04 at the UI-alignment pass).\n\n**Consequence:** a copy-paste-ready ungoverned four-button pattern sits in the component tree; the\nnext surface builder can inherit it as if it were an approved pattern.\n\n**Required fix:** delete the orphaned `workbench-router` + `department-workbench` pair, or rebuild\nit against `ContextActionSlot` with the actions surfaced per-owner. Do not ship the literal\ntoolbar anywhere.\n\n**Fixed (2026-09-04, later the same day):** deletion chosen, following the G-11 precedent. Deleted\nin one commit:\n- The G-29 pair plus **seven more orphaned files** in `apps/web/components/workbench/`\n  (`five-zone-shell`, `ooda-buttons`, `entity-detail`, `entity-grid`, `lifecycle-view`,\n  `store-spine-modal`, `twin-signal-feed`) — all with zero importers (verified 2026-09-04).\n  `action-ledger`, `dashboards`, `role-based-workbench`, `workbench-shell` remain: they are the\n  only files still imported (solely by `components/_deprecated/**`).\n- **A live sibling of the same class, found during deletion prep:**\n  `apps/web/app/workspace/sales/page.tsx` rendered the four literal action buttons\n  (`Store in Spine / Ask your Twin / Assign Your Twin / Approve Twin's Action`) via\n  `components/workspace/ooda-buttons.tsx`, plus an ungoverned four-button row inside\n  `sales-workbench.tsx` — with fake-governance modals (hardcoded demo data, no `ContextActionSlot`,\n  no receipts). The route had zero inbound links (not in nav or landing surfaces), so it was\n  unreachable; the page and its three components were deleted.\n\n**Addendum (2026-09-04, all-apps re-sweep):** one more live sibling, in the platform app —\n`apps/platform/components/home/command-rail.tsx` rendered the same four literal OODA buttons\n(OODA control grammar) on the platform shell home. Deleted, with its import/usage removed from\n`app/(shell)/page.tsx`, a dead `fourButtons` import removed from `app/(shell)/agents/page.tsx`,\nand the `OodaAction`/`fourButtons`/`oodaPhase` data model removed from `apps/platform/lib/data.ts`.\nZero OODA references remain in `apps/platform` (verified 2026-09-04).\n\n---\n\n## G-30 · UI surfaces spoke the pre-canon vocabulary — **MEDIUM · PARTIALLY FIXED 2026-09-04** *(new, 2026-09-04)*\n\n**Canon:** §1 (SpineWorkspace is the product; IntegrateWise is the company/infrastructure), §3\ncanonical vocabulary and drift watch, [ADR-2026-08-31-01](adr/ADR-2026-08-31-01-ai-workbench-supersedes-twin-workbench.md).\n\n**Fixed in the 2026-09-04 UI-alignment pass:**\n- `apps/workspace/src/app/page.tsx:137` — \"customer-facing IntegrateWise product\" → \"customer-facing\n  SpineWorkspace product\".\n- `apps/web/app/login/page.tsx:83` and `apps/one-access/src/app/page.tsx:15` — sign-in h1 presented\n  the product as \"IntegrateWise\" → now \"SpineWorkspace\" (company marks such as the `iW` logo and\n  one-access sign-in/sign-up logos retained as company attribution).\n- `apps/web/components/views/settings-view.tsx:695,700` — \"Clear Twin Memory\" → \"Clear AI Continuity\n  Memory\" (canon §3 drift watch).\n- `apps/web/lib/twin-handoff.ts` / `apps/web/components/l1/personal/hub-home-view.tsx:21,152` —\n  `openTwinWorkbench()` renamed `openAIWorkbench()`; the `integratewise:twin-context` event string\n  was intentionally left stable (no in-repo listeners found; avoid breaking unknown consumers).\n\n**Still open:**\n- **\"AI Workbench\" appears zero times in any UI.** The canonical second Workbench is unnamed on\n  screen while Twin-labelled code carries its role. Whichever surface becomes the AI Workbench\n  entry point needs its canonical name.\n- **WIG anti-pattern inventory — cleared 2026-09-04 (all-apps design-system sweep):** all 251\n  `transition-all` uses converted to `transition` (bounded property lists) across `apps/*`; 78\n  focus-visible outline repairs applied to interactive fields (web, platform, platform-console —\n  the latter using its `--iw-ring` convention); 8 `transition: all` CSS rules expanded to explicit\n  property lists (`spine-theme.css` in marketing and web, landing-page `styles.css`). Two upstream\n  shadcn sites (`components/ui/tabs.tsx`, `components/ui/input-otp.tsx`) and two marketplace fields\n  with existing `focus:border-primary` indication intentionally left as-is. Typechecks pass\n  (web, platform, platform-console, workspace).\n\n**Required fix:** name the AI Workbench surface when it is built/promoted; keep new UI copy inside\nthe §3 vocabulary.\n\n---\n\n## G-31 · Alignment spec and root agent instructions point at retired documents and a nonexistent app — **MEDIUM · FIXED 2026-09-04** *(new, 2026-09-04)*\n\n**Code:**\n- `apps/web/public/docs/architecture/CODEBASE_ALIGNMENT_SPEC.md:77,128` — names `apps/live` as the\n  primary frontend (\"User Workbench (primary)\") and lists it under Frontend Apps; **no `apps/live`\n  exists in the repository** (verified 2026-09-04).\n- Root `AGENTS.md` — header still says \"Current framing: 2026-08-25\" and orders agents to read\n  `PRODUCT_FRAMING_LOCK.md` first, which is stamped **SUPERSEDED 2026-08-31** by\n  [`docs/canonical/00-SPINEWORKSPACE-INTEGRATEWISE-CANON.md`](00-SPINEWORKSPACE-INTEGRATEWISE-CANON.md).\n\n**Consequence:** agents and contributors are routed to a superseded framing (Twin Workbench,\ntwo-scope memory) as their first read, and the service-alignment plan references an app that does\nnot exist.\n\n**Required fix:** update `AGENTS.md` to read order from the current canon (`00-SPINEWORKSPACE-INTEGRATEWISE-CANON.md`, then the 6.1 suite) and correct the alignment spec's frontend table to the actual app set — or stamp the spec superseded if the live gap register has replaced it.\n\n**Fixed (2026-09-04):**\n- Root `AGENTS.md` — header now points at the Founder Canon as current authority; \"Current\n  framing\" corrected to 2026-08-31; §2 read order is now Canon → gap register → ROADMAP →\n  `ARCHITECTURE_LOCK.md`, with `PRODUCT_FRAMING_LOCK.md` and the other legacy architecture docs\n  demoted to a lineage-only item (\"treat any conflict with the Founder Canon as superseded\").\n- `CODEBASE_ALIGNMENT_SPEC.md` — stamped **SUPERSEDED (2026-08-31)** in the same day's docs pass,\n  satisfying the spec half via the stamp option (the live gap register has replaced it).\n\n---\n\n## G-26 · Pre-canon doctrine live in the public docs bundle and remaining product copy — **HIGH** *(new, 2026-09-04, PARTIALLY FIXED)*\n\nSame class as G-22, in a scope G-22 did not cover. An `apps/*`-wide alignment sweep (2026-09-04)\nfound **70 documents** under `apps/web/public/docs/**` and `apps/docs/architecture/**` still\nteaching pre-canon doctrine — **Twin Workbench**, **Twin Memory** as a substrate, retired\npositioning — with no supersession marker, served publicly by the web app. This is the surface\nthat presents the platform's own architecture story.\n\n**Code (fixed this pass):**\n- UI copy — four remaining \"IntegrateWise\"-as-product instances: `apps/web/components/core/auth/login-page.tsx:99` (→ \"Sign in to SpineWorkspace.\"), `apps/one-access/src/app/layout.tsx:5-6` (title/description → SpineWorkspace), `apps/web/components/core/site/landing-page.tsx:196` (hero alt text), `apps/web/components/iw/config/platform-inventory.ts:149` (→ \"SpineWorkspace shell\").\n- **70 pre-canon docs** bulk-stamped with a uniform `SUPERSEDED (2026-08-31) — lineage only` banner linking to the Founder Canon and naming the known drift (ADR-2026-08-31-01/02). Excluded from stamping: `*/_archive/**` and `apps/web/public/docs/archive/**` (lineage folders), already-stamped docs, and the two canon-aligned frozen docs `architecture/FULL_END_TO_END_ARCHITECTURE_v1.md` and `architecture/ARCHITECTURE_LOCK_v2.md`.\n\n**Still open:**\n- Banner contents are only stamped; the 70 documents' bodies still teach the retired model.\n  Rewriting them into the canon model (or deleting them from the public bundle) is a dedicated\n  documentation pass and must not happen silently.\n- `apps/mobile`, `apps/desktop`, `apps/connector`, `apps/auth`, `apps/activation` were swept this\n  pass and are clean — only legitimate company usage (publisher names, `IntegrateWiseMobileClient`\n  class names) remains there.\n- Metadata titles in the live `/workspace` surfaces (\"Founder Dashboard\", \"Template Library\")\n  presented the product as \"IntegrateWise\"; fixed 2026-09-04 in the G-29 deletion pass →\n  \"SpineWorkspace\".\n\n**Addendum (2026-09-04, all-apps re-sweep):** three further pre-canon docs missed by the bulk\nstamp are now stamped — `apps/docs/architecture/GLOSSARY.mdx` (with a drift note that the OODA\n\"control grammar\" framing is retired — context actions are ambient per the canon),\n`apps/docs/architecture/TWIN_WORKBENCH.mdx`, and `apps/docs/architecture/TWIN.mdx` (no H1; banner\ninserted after frontmatter). One remaining product-name drift fixed: `apps/workspace/src/app/layout.tsx`\npage title \"IntegrateWise Workspace\" → \"SpineWorkspace\"; and `apps/web/app/capabilities/page.tsx`\nOODA prose reworded (\"observe, orient, decide, act\" → \"from signal to governed action\").\n\n**Required fix:** a documentation pass that rewrites or prunes the 70 stamped lineage docs; until\nthen the banners prevent readers from treating pre-canon doctrine as authority.\n\n## G-27 · App UI tokens drifted off the Salesforce-blue design-language foundation — **MEDIUM · PARTIALLY FIXED 2026-09-04** *(new, 2026-09-04)*\n\n`SPINE_DESIGN_LANGUAGE_V1.md` §3.1 declares the base identity: **Salesforce blue on white**\n(light `#0176d3`, dark `#00a1e0`), implemented canonically in\n`packages/design-system/src/foundation/tokens.css` (`--iw-primary` and friends). The all-apps\ntoken sweep (2026-09-04) found three apps hard-coding their own brand hue instead of consuming\nthe foundation:\n\n- `apps/web/app/globals.css` — \"Webflow-inspired cooler theme\" with indigo\n  `oklch(0.55 0.18 265)` primary/accent/ring/charts/sidebar tokens overriding the foundation\n  it already imports.\n- `apps/platform/app/globals.css` — same indigo palette, no design-system dependency at all.\n- `apps/docs/app/globals.css` — literal copy of web's indigo theme (\"mirrors apps/web\"),\n  no design-system dependency.\n- `apps/portfolio/app/globals.css` — v2-style HSL vars with an indigo-leaning\n  `--primary: 223 67% 54%`.\n\n**Fixed 2026-09-04:** web light + dark blocks re-pointed (`--primary`, `--primary-foreground`,\n`--accent`, `--accent-foreground`, `--ring`, `--chart-1/2`, `--sidebar-*` family) to\n`var(--iw-*)` foundation refs, keeping local neutral surfaces; platform and docs gained the\n`@integratewise/design-system` workspace dependency plus first-line\n`@import \"@integratewise/design-system/styles.css\";` and the same re-pointing\n(`--success` oklch token left as-is); portfolio primary/ring re-hued to `207 99% 42%`\n(light) / `197 100% 44%` (dark) and the accent family re-hued to match\n(`210 99% 26%` foreground light, `197 90% 85%` dark). Neutral surfaces (hue 250 oklch,\nhue 211 HSL) intentionally retained per app.\n\n**Still open (deliberate sub-brand/legacy flags):**\n- `packages/one-access-ui` ships a distinct green sub-brand (`--oa-primary: #1f6f43`)\n  consumed by `apps/one-access-console` and `apps/auth`. Not a drift — a bounded sub-brand —\n  but it should be ratified in the design language doc before it spreads.\n- `apps/marketing` landing page and `apps/web` `spine-theme` use warm-dark sand/gold surfaces\n  that sit outside the Salesforce-blue identity; reconcile in a dedicated pass.\n- `apps/docs` landing-page palette (forest-green/paper) likewise predates the design language.\n- `apps/web/styles/globals.css` is an unused legacy neutral shadcn file unreferenced by code;\n  delete in a cleanup pass.\n\n**Required fix:** extend `SPINE_DESIGN_LANGUAGE_V1.md` to ratify (or retire) the green\none-access sub-brand and the warm-dark/forest-green marketing surfaces, then converge those\ntokens; until then the four fixed apps now resolve brand color from the single foundation\nsource.\n\n\n## G-28 · `apps/mcp-servers` is an unwired skeleton that cannot build — **HIGH · OPEN** *(new, 2026-09-04)*\n\nAll-15-apps wiring-readiness verification (2026-09-04): 10 apps typecheck green, 13 apps\nbuild green (12 Next builds + desktop `electron-vite build`). Two apps had no verification\nharness; mobile was fixed, mcp-servers was not fixable in place:\n\n- `apps/mcp-servers` has **no package.json**, so pnpm excludes it from the workspace and it\n  has no install, typecheck, or build path. Its `wrangler.toml` points at `src/index.ts`\n  (Cloudflare Worker, `itty-router`), and `src/middleware/*` is complete — but\n  `src/index.ts` imports **nine `./handlers/*` modules (claude, openai, github, slack,\n  postgres, brave-search, playwright, sentry, grafana) that do not exist**: `src/handlers/`\n  is absent entirely. The source cannot compile even with a manifest.\n\n**Fix required before MCP route wiring:** decide whether mcp-servers is a deliverable. If\nyes: restore/implement the handlers, add a package.json (wrangler + itty-router +\n`@cloudflare/workers-types`, `typecheck` + `deploy` scripts) so it joins the workspace\nbuild; if no: move it out of `apps/*` into an archive dir so the app count and readiness\nmatrix stay truthful.\n\n**Resolved in the same pass — mobile harness gap:** `apps/mobile` (Expo 52) had no\n`tsconfig.json` and no `typecheck` script, and shipped `lib/supabase-provider.tsx`, which\nimported `@integratewise/supabase/native` — a package that exists nowhere in the monorepo —\nand had zero importers. Deleted the orphaned provider (G-11/G-23 precedent), removed the\nalso-unused `@supabase/supabase-js` dependency, added `tsconfig.json` (`expo/tsconfig.base`,\nstrict) and a `typecheck` script. `pnpm --filter @integratewise/mobile typecheck` is now\ngreen. Mobile still has no local build (EAS device builds are external by design);\ndesktop likewise verifies via `electron-vite build` only.\n\n---\n\n# Gap register vs the Canonical Operating Model — 2026-09-04\n\n**Survey base:** `facd8b03` (main) — the commit that landed\n[`01-SPINEWORKSPACE-OPERATING-MODEL.md`](01-SPINEWORKSPACE-OPERATING-MODEL.md),\n[`18-CANONICAL-GLOSSARY.md`](18-CANONICAL-GLOSSARY.md) and ADR-2026-09-04-04…13.\n**Method:** [Repository Archaeology Protocol](../agent-context/REPOSITORY-ARCHAEOLOGY-PROTOCOL.md)\n— every claim closed by reading the file it names; strict status labels; evidence-only, no\nsolutions. Entries use `GAP-` IDs (not `G-`) because the G-sequence is concurrently maintained by\nother writers. Existing `G-` entries that already measure a requirement are cross-referenced\nrather than duplicated.\n\n| ID | Canonical requirement | Current evidence | Status | Confidence | Risk | Dependency | Recommended next action |\n|---|---|---|---|---|---|---|---|\n| GAP-001 | OneAuth is the single entry resolving identity, org, workspace, **host identity, host connections, connector projections, plugins, MCP capabilities, activation policy** | Auth exists (`services/gateway/src/auth.ts`, `clerk-auth.ts`, `descope-auth.ts`, `oauth.test.ts`); per-installation identity/workspace/consent in `services/marketplace-installation/src/index.ts` (state machine); versioned platform read contract with OneAuth law reference at `services/gateway/src/platform-discovery.ts:225` — but no single resolution surface that also returns host connections, projection grants and activation policy | Partial | High | High | Identity boundary (G-01/Q-1) | Trace the gateway auth composition; design the OneAuth resolution response as one contract before host-entry work |\n| GAP-002 | Host-first capability routing: request classification, `HostCapability` (confirmed/declared/unknown), `SpineCapability`, route resolver with read/write precedence, `ConnectionBinding` | No matches for `HostCapability`, `ExecutionRoute`, `RequestClassification`, or a host-vs-spine precedence resolver anywhere in `services/` or `packages/`; cascade discovery exists (`packages/host-platform-connector/src/services/cascade-discovery.ts`) and the capability package resolves provider routes, but neither implements host-first precedence or confirmed/declared availability | Absent | High | High | GAP-003, capability fabric | Design the route resolver against the existing `@integratewise/capability` resolution pipeline; do not bolt a second resolver beside it |\n| GAP-003 | Connector projections: per-workload projections (read/sync/search/event/approved-write) of host-owned connections carrying scopes, approval requirements, retention, classification, rate limits, revocation state; connection-reuse-first | `platform.connector_connections` (`sql-migrations/081:56-77`) carries provider, connection_ref, status, scopes, supported_capabilities, health — a connection record, not per-workload projection records; no retention/classification/per-projection revocation columns; no reuse-first activation flow evidenced | Partial | High | High | GAP-002, G-18, G-21 | Extend the connection model with projection records and route the marketplace-installation `binding` stage through them |\n| GAP-004 | Activation Hub stages 3–4: connection activation creates projections; **Activation Bridge** compiles config + identity + connections + policy into an active workspace | An `ActivationManagerClient` exists and is invoked by cascade discovery (`cascade-discovery.ts:27-37,144`) and an `ActivationManagerView` ships in `packages/platform-mfe/src/index.ts:47`; no Activation Bridge (runtime compiler) evidence; `services/schema-ai/src/index.ts` offers `/schema/adapt`, `/schema/generate`, `/schema/:tenant/lifecycle` (compiler-adjacent) | Partial | Medium | High | GAP-001, GAP-003 | Trace what `ActivationManagerClient.startActivation` actually calls before designing the bridge |\n| GAP-005 | Discovery Engine emits one **workspace bootstrap contract** (identity, workspace, connections, projections, plugins, MCP servers, tools, models, knowledge, memory scopes, role views, policies) | Discovery exists in pieces: `services/schema-ai` (infer/register/drift/adapt/generate/discover/lifecycle), discovery agent (`services/iw-agent-runtime/src/agents/discovery-agent.ts` with `DiscoveredCapability` kinds), MCP Pool `GET /capabilities`, cascade discovery — but no unified bootstrap-contract output consumed by onboarding | Partial | High | Medium | GAP-001 | Compose the bootstrap contract from the existing discovery surfaces before inventing new ones |\n| GAP-006 | Spine Cache: policy-filtered, rebuildable, default agent read surface; Active Context Bundle with completeness level | `services/pipeline/migrations/0007` creates `operational_entity_cache`, `operational_projection_cache`, `operational_promotion_staging`, `operational_sync_receipts`, `operational_flow_log`; `services/context-fetch` is the Gateway-only bounded Active Context Worker with `ContextScope`, `EffectiveCapability`, `EvidenceBoundOutput`, `FreshnessSource` | Implemented (read path) | High | Medium | G-21 freshness | Verify rebuildability and policy filtering end-to-end; wire freshness degradation into cache invalidation |\n| GAP-007 | ACP: agent ↔ agent / Twin ↔ agent governed handoff transport carrying Work ID, authority scope, correlation/causation | No matches for ACP or an agent-communication protocol in `services/` or `packages/`; handoff machinery exists (`services/intelligence/src/handoff/state-machine.ts`, `handoff_packages`) but as DB state, not a transport with the canon envelope | Absent | High | Medium | G-20 (Work identity) | Defer transport design until Work identity exists — ACP carries Work IDs it does not create |\n| GAP-008 | Bridge message envelope: communication attached to Work with tenant, principal, Work ID, authority context, correlation/causation, provenance, sensitivity | No `communication_type` / Work-bound communication envelope in `packages/context-contracts/src` or `services/context/src`; communication content is ingested as Flow B context, not carried as governed Bridge messages | Absent | High | Medium | G-20, GAP-007 | Model the envelope in `packages/context-contracts` alongside the Active Context types |\n| GAP-009 | Model profile resolver: stable profiles (`fast`, `reasoning`, `code`, `specialized`); no model version in the durable contract | `packages/model-gateway/src/types.ts` carries provider usage plumbing (`reasoning_tokens` details at `:151`); no profile abstraction in `model-gateway` or `omni-router` | Absent | Medium | Medium | — | Add the profile layer in the model gateway; keep vendor models behind it |\n| GAP-010 | UI auto-tuner proposes **versioned projection patches**; never rewrites components | Adaptive autotuner exists (`services/iw-agent-runtime/src/agents/adaptive-autotuner-agent.ts` — `TuningRun` targeting `profile \\| prompt \\| model` with outcome feedback); no projection-patch proposal path evidenced | Partial | Medium | Medium | ADR-2026-09-04-12 | Route tuner proposals through the projection manifest versioning, not component edits |\n| GAP-011 | Standard tenant-table envelope: `workspace_id`, `version`, `created_by`, `trace_id`, `correlation_id` on tenant-owned tables | 081 tables carry tenant_id/status/created_at/updated_at; `spine.entities` lacks workspace_id, created_by, trace_id, correlation_id; envelope concerns measured under G-17 | Partial | High | High | G-17 | Fold into the G-17 envelope migration rather than a separate pass |\n| GAP-012 | Spine Access Plane (scoped/redacted continuity for external hosts; Cache + Mirror internals) has persisted state | Surface contract binds `primaryTable: spine_access_projections` (`packages/contracts/src/surfaces/spine-access-plane.ts`); no migration creates `spine_access_projections` or spine-mirror tables — same contracted-but-unpersisted class as G-23 | Absent | High | High | GAP-001, G-23 | Author the access-plane migration alongside the G-23 wiring pass |\n\n**Survey-positive findings:** the versioned platform read contract (`services/gateway/src/platform-discovery.ts:1-16` — `PlatformResponse` with contractVersion/traceId/freshness/state/provenance) and the Gateway-only Active Context Worker (`services/context-fetch`) implement the \"frontend never touches a store\" law; the operational cache family (pipeline 0007) gives GAP-006 its substrate; cascade discovery already invokes an Activation Manager (GAP-004 partial credit).\n\n**Deliberately not re-measured here:** G-17–G-25 (earlier 2026-09-04 re-verification) and G-26–G-28 (concurrent writers) stand as dated measurements at their own stamps.\n"}