{"slug":"canonical/adr/ADR-2026-09-03-01-local-execution-route-scope","title":"ADR-2026-09-03-01 — Local execution route scope","section":"canonical","sectionLabel":"Canon","status":"canon","type":"adr","path":"canonical/adr/ADR-2026-09-03-01-local-execution-route-scope.md","bytes":3017,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\n**Status:** APPROVED — 2026-09-03 (founder decision)\n\n**Decision: APPROVED — Local capabilities use client-proximity scope.**\n\nThe boundary is explicit:\n\n```text\nUser / Client Context\n        ↓\nLocal Capability\n        ↓\nApproved Plan\n        ↓\nGoverned Execution\n```\n\nA bounded server-side local adapter remains a possible future capability if a\nconcrete requirement for server-side execution arises — it would require a new\nADR with a distinct governance risk profile. The canonical fabric therefore\ndeclares no server-side Local adapter; local invocations return their evidence\ninto the governed loop (proposal → approval → local execution → observation →\nreconciliation) from the client side.\n\n## Context\n\nThe canonical capability model names three execution routes: **Local**, **MCP Pool**, and **Spine/Native** (Founder Canon §18; Companion §14). Code evidence (`CAPABILITY_ROUTING_EVIDENCE.md`) shows:\n\n- the **connector** route is code-verified through Hermes → Connector;\n- an **MCP Pool** route is now implemented as a governed adapter (`services/hermes/src/mcp-pool-adapter.ts`), selected by the plan-stamped route and covered by the approval-bound planHash;\n- **Spine** is deliberately not an execution route (writes go through governed promotion);\n- **Local** has no server-runtime implementation. The only \"local\" code is a quarantined UI simulator.\n\n## Decision sought\n\nAdopt one of:\n\n1. **Client-proximity scope (recommended).** Local is a *client-side* execution path — local files, desktop context, local MCP, local runtime — invoked from the participant's own device/surface, never from the server runtime. The server-side canonical fabric declares no Local adapter; local invocations carry their own evidence back into the governed loop (proposal → approval → local execution → observation → reconciliation) rather than the server dispatching \"local\" on a user's behalf. Rationale: a server cannot be \"local\" to anyone; proximity value (private, fast, sandboxed) only exists client-side. This keeps the canonical fabric honest — routes it does not operate are not modeled as server adapters.\n2. **Bounded local adapter.** The server runtime gains a Local adapter for co-located/platform-internal execution (e.g., platform-owned scripts in a Worker-managed sandbox). Requires a strong isolation story and is easy to confuse with \"the platform runs arbitrary code.\"\n\n## Consequences (as approved — option 1)\n\n- Local evidence enters the Spine through the same governed promotion as any other outcome; no server-side Local adapter is ever added without a new ADR.\n- The canonical fabric models only routes the server runtime actually operates (connector, mcp_pool). Local stays a client-proximity path.\n\n## Verification note\n\nThe Local route stays out of `CAPABILITY_ROUTING_EVIDENCE.md`'s \"verified\" column until a live demonstration exists. This approval is a scope decision, not an implementation claim.\n"}