chore(sync): rebase dev onto upstream main

.changeset/core-tools-no-auth-connections.md

@@ -0,0 +1,9 @@
+---
+"executor": patch
+---
+
+`connections.create` now accepts no-auth connections (the `none` template with
+no credential), which previously failed validation with "Expected exactly one
+provider credential origin". Agents can wire up public, no-auth integrations
+(public MCP servers, public REST APIs) programmatically instead of bouncing
+through the web UI. Templates that take a credential still require exactly one.

.changeset/execution-history-content-fit-table.md

@@ -0,0 +1,13 @@
+---
+"@executor-js/plugin-execution-history": patch
+---
+
+Rebuild the runs list as a real semantic `<table>` with content-fit columns.
+Each column now sizes to the maximum width its rows need (browser
+`table-layout: auto`), instead of fixed pixel widths — the sticky `<thead>` and
+the rows share one column model so they stay aligned for free. Short / numeric /
+badge columns (status, duration, tools, interaction, log) are centered; text
+columns (started, trigger, actor, code) are left-aligned. The two columns that
+can run long — `actor` and `code` — are width-capped and truncated (hover shows
+the full value). Removes the fixed-width `COL_*` slot constants and the
+`min-w` horizontal-scroll floor.

.changeset/execution-history-plugin.md

@@ -0,0 +1,12 @@
+---
+"@executor-js/plugin-execution-history": minor
+---
+
+Add the `@executor-js/plugin-execution-history` plugin — an opt-in execution
+history sink built on the ExecutionObserver foundation. It records every run
+(plus its tool calls and interactions) into three owner-scoped pluginStorage
+collections via a buffered-batch writer (no new tables, no migrations; works on
+D1/libSQL/sqlite/postgres), exposes a `list`/`get`/`listToolCalls` read API over
+HttpApi (`./api`'s `executionHistoryHttpPlugin`), and ships a Runs page UI
+(`./client`) that mounts at `/plugins/executionHistory/`. The base `.` entry is
+SDK-only and never loads `@executor-js/api` or React.

.changeset/execution-history-r2-detail.md

@@ -0,0 +1,18 @@
+---
+"@executor-js/plugin-execution-history": minor
+---
+
+Move per-run detail to an append-only R2 object and slim the D1 index. The
+`runs` row now keeps only list/aggregate fields plus a bounded `codePreview` and
+denormalized `logErrorCount`/`logWarnCount`, so the runs list renders entirely
+from D1 with no per-row blob fetch. Full `code`, `resultJson`, `errorText`,
+`logsJson`, `triggerMetaJson`, and the per-tool-call / per-interaction rows now
+live in one immutable object per run in the plugin blob store (keyed
+`run-detail/<executionId>`) — a code-only stub on `ExecutionStarted`, the full
+detail on finish. The detail drawer reads it in a single request (`get`
+flat-merges the R2 detail onto the slim run); the separate tool-calls endpoint
+and `runToolCallsAtom` are removed, and the `toolCalls`/`interactions`
+collections are gone.
+
+Breaking: the runs list/detail response shapes change and past runs are cleared
+(no backfill, no compatibility shim — the cutover wipe is authoritative).

.changeset/execution-history-rich-list.md

@@ -0,0 +1,15 @@
+---
+"@executor-js/plugin-execution-history": minor
+---
+
+Rework the runs list into a keyset-paginated, aggregate-aware read surface
+backed by the storage JSON pushdown. The `list` endpoint now takes an opaque
+keyset `cursor` (instead of offset), a sort field (`startedAt`/`durationMs`)
+with direction, and a live-tail `after` floor, and returns `{ runs, nextCursor,
+meta }`. The `meta` block — computed once per filter set on the first page —
+carries status/trigger facet counts (each ignoring its own filter), interaction
+counts, a stacked-by-status timeline with a server-chosen bucket width, total
+and filtered row counts, and duration min/max plus P50–P99 percentiles. All
+counts, buckets, percentiles, and pages are pushed to SQL rather than reducing
+the whole collection in memory. Tool-path facets and full-text code search are
+intentionally not included yet.

.changeset/execution-history-runs-ui.md

@@ -0,0 +1,13 @@
+---
+"@executor-js/plugin-execution-history": minor
+---
+
+Rebuild the runs page as an openstatus-style observability table on the keyset +
+aggregate API. The page now has a faceted filter rail (status / trigger /
+interaction / time range with live counts), a cmdk filter command palette, a
+stacked-by-status timeline chart with drag-to-zoom, live tailing, keyset
+infinite scroll, sortable columns, column visibility, keyboard shortcuts, and
+the existing 4-tab detail drawer. List data flows through an Effect-atoms hook
+(`useRunsList`) that accumulates cursor pages and polls the head for live mode;
+the accumulation logic is a pure, unit-tested reducer. Adds `recharts` as an
+optional peer dependency (provided by `@executor-js/react`).

.changeset/execution-metrics-plugin.md

@@ -0,0 +1,13 @@
+---
+"@executor-js/plugin-execution-metrics": minor
+---
+
+Add the `@executor-js/plugin-execution-metrics` plugin — an opt-in metrics sink
+built on the ExecutionObserver foundation. The base plugin drives Effect Metric
+counters and an execution-duration histogram from the event stream; `./api`'s
+`executionMetricsHttpPlugin` exposes them as an auth-gated `GET
+/execution-metrics/metrics` Prometheus scrape for long-lived hosts; and
+`./cloudflare`'s `createWaeMetricsObserver` writes Workers Analytics Engine data
+points on the Cloudflare host (per-isolate Effect metrics being meaningless on a
+Worker fleet). The base `.` entry never loads `@executor-js/api` or
+`@cloudflare/workers-types`.

.changeset/execution-observer-foundation.md

@@ -0,0 +1,14 @@
+---
+"@executor-js/sdk": minor
+"@executor-js/execution": minor
+"@executor-js/api": minor
+---
+
+Add the execution-observer foundation. The execution engine now emits a typed
+lifecycle stream (`ExecutionStarted`/`Finished`, `ToolCallStarted`/`Finished`,
+`InteractionStarted`/`Resolved`), plugins can subscribe via the new
+`plugin.runtime.executionObserver` hook, and `makeExecutionStack` composes every
+registered plugin's observer onto the engine. Behaviour is unchanged when no
+plugin observes — this is the opt-in seam the execution-history and
+execution-metrics plugins build on. Also exposes `Executor.owner` and enriches
+the `mcp.execute` span with the run id and trigger.

.changeset/fumadb-json-pushdown.md

@@ -0,0 +1,16 @@
+---
+"@executor-js/fumadb": minor
+"@executor-js/sdk": minor
+---
+
+Push JSON-document aggregation and keyset pagination down to SQL. FumaDB's query
+layer gains `jsonCount`, `jsonGroupCount`, `jsonTimeBuckets`, `jsonStats`
+(min/max + continuous percentiles), and `jsonPage` (cursor pagination) over a
+JSON document column, implemented natively for the memory and Drizzle
+(SQLite/Postgres) adapters and failing loudly on adapters that don't support
+them. Plugin storage exposes this as `collection.aggregate.{count,groupCount,
+timeBuckets,stats}` and `collection.queryKeyset(...)`, translating a
+collection's indexed-field `where` into JSON-path predicates while owner/tenant
+scoping stays enforced by the storage policy. Aggregates and pages are computed
+in the database instead of by fetching the whole collection and reducing in
+memory.

.changeset/openapi-file-emit-descriptions.md

@@ -0,0 +1,8 @@
+---
+"executor": patch
+---
+
+OpenAPI tools that return a file now spell out how to emit it directly in the
+tool's description, so an agent sees the `emit(result.data)` contract before its
+first call instead of only discovering it after a failed attempt or by reading
+`describe.tool`. Non-file tools are unchanged.

.changeset/semantic-search-manifest-snapshot.md

@@ -0,0 +1,10 @@
+---
+"@executor-js/sdk": minor
+"@executor-js/plugin-semantic-search": minor
+---
+
+Snapshot the tool manifest per reindex run instead of re-reading it from D1 on every scan page.
+
+`createExecutor` now exposes its cache `KeyValueStore` on the executor instance as `executor.cache`, so plugins can reach durable cache storage (Cloudflare KV in production) without re-threading a binding — wrap it with `KeyValueStore.toSchemaStore` for typed entries, the same way the internal `tools.list` / schema-view caches do.
+
+The semantic-search scan phase used to call `tools.manifest()` — a full `tool_schema_manifest` table read — once per partition page, so an unchanged catalog cost `O(N² / pageLimit)` cross-region reads. Now `create` reads the manifest once, partitions it, and writes one snapshot per partition to `executor.cache`; `scan` reads only its partition's snapshot (KV-only, with no D1 fallback on the hot path — a miss fails the message so the queue retries). Snapshots are deleted when the run completes. This collapses the scan's manifest reads from `O(N² / pageLimit)` to a single pass and cuts per-message memory from the whole manifest to one partition's slice.

.changeset/semantic-search-tenant-namespace-prefix.md

@@ -0,0 +1,14 @@
+---
+"@executor-js/plugin-semantic-search": patch
+---
+
+fix: don't default the operator search prefix filter to the tenant namespace
+
+`executor.semanticSearch.search` (the operator `tools.search` surface) overloaded a
+single `namespace` value as both the Vectorize tenant namespace (storage isolation)
+and the optional integration/path-prefix filter. With no operator-supplied prefix it
+defaulted the filter to the tenant namespace (e.g. `"default"`), so the provider's
+`matchesNamespace` required every tool path to start with the tenant id and dropped
+every result — search returned nothing for all queries despite a fully populated
+index. The integration prefix is now applied only when explicitly provided; the
+tenant namespace drives the store query alone and is still reported on the result page.

.changeset/tools-list-revision-cache.md

@@ -0,0 +1,14 @@
+---
+"@executor-js/sdk": minor
+---
+
+Cache `tools.list` by a content-derived catalog revision. `produceConnectionTools` now
+records a per-connection `toolset_revision` — a hash of the connection's manifest
+`(path, index_fingerprint)` pairs — in `plugin_storage`, and `tools.list` keys a KV cache of
+the DB-derived, policy-filtered list on the combined catalog revision plus a policy
+revision (both read live, O(connections)/O(policies), not the full `tool` scan). Static tools
+are unioned live and the `query` substring filter is applied post-cache, so a distinct query
+reuses the same cached set. The cache stays warm through token rotation and unrelated writes
+and invalidates exactly when a connection's tool set, a tool's schema, or a `tool_policy`
+changes — including OpenAPI/MCP tool additions on refresh (a new manifest row) and
+connection/integration removal.

.changeset/tools-schema-precompile-typescript.md

@@ -0,0 +1,15 @@
+---
+"@executor-js/sdk": minor
+"@executor-js/plugin-semantic-search": patch
+---
+
+Always render the TypeScript preview in `executor.tools.schema` and warm it during
+indexing. The `includeTypeScript` option (and the now-empty `ToolSchemaOptions` type) is
+removed — the only caller that passed `false` was the reindex pipeline, which did so to
+skip the CPU-heavy JSON-schema → TypeScript codegen. It now calls `tools.schema` plainly,
+so every reindex pre-warms exactly the schema view the web UI reads on first open (the
+codegen is content-addressed in KV), turning first tool-detail views into cache hits
+instead of a cold compile. The embedding text is unchanged — the indexer only ever read
+the raw schema facets, never the rendered TypeScript. Because `includeTypeScript` is
+dropped from the schema-view cache key, existing cached entries are superseded on the next
+reindex or view (regenerable derived data).

.claude/skills/emulate/SKILL.md

@@ -5,15 +5,18 @@ description: Use the @executor-js/emulate service emulators (GitHub, Google, Str
 
 # Emulate: production-fidelity service emulators
 
-`@executor-js/emulate` (our fork of Vercel Labs' emulate, developed in
-`vendor/emulate` but ALWAYS consumed as the published npm package — never
-import from `vendor/`) provides stateful, wire-level emulators for 16
-services: `github vercel google okta microsoft spotify slack apple aws
-resend stripe mongoatlas clerk x workos autumn`. These are not mocks: real
-SDKs and real product code run against them unmodified — the cloud e2e
-target points the actual WorkOS SDK (sealed sessions, JWKS, hosted AuthKit
-login) and Autumn billing at emulators and exercises the product's real
-auth code.
+`@executor-js/emulate` (our fork of Vercel Labs' emulate) provides stateful,
+wire-level emulators for 16 services: `github vercel google okta microsoft
+spotify slack apple aws resend stripe mongoatlas clerk x workos autumn`.
+These are not mocks: real SDKs and real product code run against them
+unmodified — the cloud e2e target points the actual WorkOS SDK (sealed
+sessions, JWKS, hosted AuthKit login) and Autumn billing at emulators and
+exercises the product's real auth code.
+
+**This repo only consumes the published npm package.** There is no
+`vendor/emulate` submodule — everything imports `@executor-js/emulate` from
+npm. The emulator _source_ is its own standalone project; to change or deploy
+an emulator, see "Changing or deploying an emulator" at the bottom.
 
 ## Two ways to get one
 
@@ -83,6 +86,40 @@ before `createEmulator` so minted MCP access tokens carry the right audience.
 app's real dev stack (recipe in `e2e/setup/cloud.boot.ts`), fronted with
 tailscale HTTPS.
 
+## Changing or deploying an emulator
+
+The emulators live in their own repo — **not** in executor and **not** a
+submodule: `github.com/UsefulSoftwareCo/emulate` (clone it as a sibling of
+executor). It's a pnpm + turbo monorepo on node ≥ 24 — a different toolchain
+from executor's bun, which is exactly why it's standalone rather than
+vendored here.
+
+You have full autonomy over it: **work directly on `main`, and commit, push,
+publish, and deploy without asking.** The loop:
+
+1. Edit in the emulate repo, then **rebuild the package you changed.** It
+   resolves through built `dist`, so a source-only edit does nothing until you
+   build it — this is the single most common mistake. `@emulators/*` packages
+   are a `workspace:*` graph, so adding or renaming one needs an install +
+   rebuild too.
+2. Publish a version bump of `@executor-js/emulate` to npm.
+3. Deploy the hosted Cloudflare emulators (the `emulate-hosts` worker behind
+   `*.emulators.dev`) when behavior the hosted instances serve has changed.
+4. Back in executor, bump the `@executor-js/emulate` dependency to the version
+   you just published. Never point a consumer at a local checkout to ship —
+   publish, then bump.
+
+The emulate repo's own `AGENTS.md` / `README.md` carry the current build,
+publish, and deploy commands (npm + Cloudflare creds are in 1Password). Read
+them there rather than memorizing flags here — they move.
+
+**A hot deploy can redden other people's e2e.** `*.emulators.dev` service
+hosts are shared infrastructure; a control-plane regression there has failed
+unrelated PRs' suites before. When a scenario needs isolation or a behavior
+that isn't deployed yet, pin to a published package version or mint a private
+per-run instance (`POST /_emulate/instances`) instead of mutating the shared
+service host.
+
 ## Gotchas
 
 - **Secure cookies need HTTPS off-localhost.** Browser-driven flows work on

.claude/skills/prod-telemetry/SKILL.md

@@ -0,0 +1,114 @@
+---
+name: prod-telemetry
+description: Query Executor's production telemetry — Axiom traces (executor-cloud dataset), prod Postgres via PlanetScale, PostHog product analytics — through the Executor MCP. Use when investigating prod errors, latency, usage, churn signals, or verifying a deploy's telemetry; includes the dataset field layout, working APL recipes, and the error-attribution join.
+---
+
+# Production telemetry access
+
+All three stores are queryable through the Executor MCP's connected
+integrations — no dashboards or credentials needed. Verify the connection
+exists with `connections.list` if a call fails.
+
+## Axiom traces (`axiom_mcp`)
+
+Tool: `axiom_mcp.user.axiomMcpOAuth.querydataset` — the argument is `apl`
+(NOT `query`). Dataset: `['executor-cloud']` (worker spans; browser spans
+join the same traces via traceparent).
+
+**Field layout (the part you'd otherwise rediscover by failed queries):**
+
+- Custom span attributes live under the JSON map `['attributes.custom']`,
+  NOT as top-level `attributes.*` columns. Read with
+  `['attributes.custom']['mcp.tool.name']`. A nonexistent top-level field is
+  a hard query error ("invalid field"), not an empty result.
+- Span status: `['status.code']` (`"OK"`/`"ERROR"`), `['status.message']`.
+- Exceptions: the `events` column carries `exception.type` /
+  `exception.stacktrace` JSON.
+- OTel basics are top-level: `name`, `trace_id`, `span_id`,
+  `parent_span_id`, `duration`, `_time`.
+
+**Span names worth querying** (and their custom attrs):
+
+- `executor.tool.execute` — `mcp.tool.name` (full address), and since
+  PR #992: `executor.tool.outcome` (`ok`/`fail`),
+  `executor.tool.error_code`, `executor.tool.error_status`,
+  `executor.tenant`, `executor.subject`.
+- `mcp.tool.dispatch` — `mcp.tool.name` (sandbox path),
+  `mcp.tool.integration`, same outcome attrs.
+- `plugin.openapi.invoke` — `plugin.openapi.method` / `path_template` /
+  `base_url`, and since PR #992 `http.status_code`.
+- `mcp.request` (outer) — `mcp.auth.organization_id`,
+  `mcp.auth.account_id`, `mcp.tool.name`, CF edge fields (`cf.country`…),
+  MCP client fingerprint (`mcp.client.name`…).
+
+**Recipe — error signatures by class (the daily-digest query):**
+
+```apl
+['executor-cloud']
+| where _time > ago(1d)
+| where ['status.code'] == "ERROR" and name == "executor.tool.execute"
+| extend msg = substring(tostring(['status.message']), 0, 120)
+| extend tool = tostring(['attributes.custom']['mcp.tool.name'])
+| summarize n = count() by msg, tool
+| sort by n desc
+```
+
+**Recipe — attribute errors to orgs.** Tool spans now carry
+`executor.tenant` directly (post-#992). For spans from BEFORE that deploy,
+join through the outer request span:
+
+```apl
+['executor-cloud']
+| where name == "mcp.request" and isnotnull(['attributes.custom']['mcp.auth.organization_id'])
+| project trace_id, org = tostring(['attributes.custom']['mcp.auth.organization_id'])
+| join kind=inner (
+    ['executor-cloud']
+    | where ['status.code'] == "ERROR" and name == "executor.tool.execute"
+    | project trace_id, msg = substring(tostring(['status.message']), 0, 60)
+  ) on trace_id
+| summarize n = count() by org, msg | sort by n desc
+```
+
+**Recipe — upstream failure rate per integration (post-#992 attrs):**
+
+```apl
+['executor-cloud']
+| where _time > ago(1d) and name == "mcp.tool.dispatch"
+| extend outcome = tostring(['attributes.custom']['executor.tool.outcome'])
+| extend integration = tostring(['attributes.custom']['mcp.tool.integration'])
+| where isnotnull(outcome)
+| summarize calls = count(), fails = countif(outcome == "fail") by integration
+| extend failRate = todouble(fails) / todouble(calls)
+| sort by fails desc
+```
+
+**Known signal caveats** (audited 2026-06-12):
+
+- Pre-#992 spans: `ToolResult.fail` outcomes (upstream 4xx/5xx, auth
+  rejections) are INVISIBLE — they rode the Effect success channel with no
+  span marker. Don't conclude "no errors" from old data.
+- Many pre-#992 ERROR spans have an EMPTY `status.message` (tagged errors
+  without a message field) — group those by `events` exception.type instead.
+- `[object Object]` status messages are the pre-#992 formatting bug.
+
+## Prod database (`planetscale_mcp`)
+
+Read tool needs `{organization: "answer-overflow", database: "executor",
+branch: "main"}`. It returns `ok: true` even when the SQL failed — check the
+result text for `Error:`. Use for tenant/integration/connection facts that
+spans don't carry (row sizes, config shapes, counts).
+
+## Product analytics (`posthog_api` / `mcp_posthog_com`)
+
+Browser-side events only (the ~60-event typed catalog, PR #987; server-side
+events not built). The org-key `posthog_api` connection covers the REST API;
+the OAuth MCP connection covers the higher-level tools.
+
+## Verifying a deploy's telemetry (Layer-0 canary)
+
+After deploying telemetry changes: run a known-failing tool call against
+prod, then assert the expected attributes arrive in Axiom within ~1 min.
+Absence of data looks identical to health — query for the NEW attribute
+explicitly rather than eyeballing dashboards. The e2e equivalent runs on
+every suite: `e2e/cloud/telemetry-contract.test.ts` via the `Telemetry`
+service (motel `/api/spans/search?attr.<key>=<value>`).

.github/workflows/ci.yml

@@ -89,7 +89,7 @@ jobs:
       - name: Build web app
         run: bun run --filter @executor-js/local build
 
-      - name: Build sidecar + stage web UI
+      - name: Build bundled executor
         env:
           BUN_TARGET: bun-linux-x64
         run: bun ./scripts/build-sidecar.ts