Sync upstream v2 (cd6048d26) and version apps 0.0.1-beta.119.shuv.1

.changeset/app-files-before-page-work.md

@@ -0,0 +1,8 @@
+---
+"apps": patch
+---
+
+`apps/ui/serving` exports `appFile`, which answers a version's own file, or a 404 for a missing
+dotted path, and returns `None` for the page itself, so hosts can serve files before page work.
+`appDocument` renders only the document and inlines the version watcher; `appWatchScript` is
+removed, along with the hosts' `/_executor/watch.js` routes.

.changeset/background-service.md

@@ -0,0 +1,20 @@
+---
+"@executor-js/local-server": minor
+"@executor-js/app-management": patch
+"@executor-js/desktop": minor
+"@executor-js/app-templates": patch
+---
+
+`executor` now starts one background Executor per data directory, shared by the command line,
+`executor apps` and the desktop app, and exits once the dashboard opens; the background Executor
+runs until `executor service stop`. `executor service` starts, stops and configures it, and
+`executor upgrade` stops it and starts it again on the new version. `executor apps` commands
+without `--host` or `EXECUTOR_HOST` use it and need no API key, as the app-authoring skill now says.
+Executor 1's `executor service install` and `executor service uninstall` name what to run instead.
+
+Executor desktop no longer runs its own server: it starts or joins the same background Executor and
+uses the command line's data directory, `~/.executor/v2/cli`. Its first launch moves the data of an
+earlier desktop release there, once. Command-line data already in that directory, with its apps and
+accounts, moves to `~/.executor/v2/backups/cli-data-<time>`, which the desktop names; nothing is
+merged or deleted. The command line's settings carry over, except its port and the `env` variables
+that belong to the replaced data, and the desktop says which changed.

.changeset/confirmed-read-retries.md

@@ -0,0 +1,12 @@
+---
+"@executor-js/sdk": patch
+---
+
+A failed call to a tool that only its MCP server labels read-only (`readOnlyHint`) is no
+longer offered as a retry. Executor keeps a read's retry advice, and repeats a refused call
+with renewed credentials, only for a query the app confirms: a declared operation, a `kinds`
+entry, an OpenAPI read method or a GraphQL query (`kindConfirmed`). Other queries fail like
+mutations, with `mayHaveWritten` and `retryable: false`. The confirmation comes only from a
+listing already kept for the app, so a failed call never evaluates the app again; a query whose
+app's tools nobody listed is unconfirmed. Apps built before `kindConfirmed` existed get this for
+every query until they are rebuilt.

.changeset/confirmed-tool-kinds.md

@@ -0,0 +1,10 @@
+---
+"apps": patch
+---
+
+Tool listings mark a kind that the app's code or the tool's protocol decides
+with `kindConfirmed`: declared operations, `kinds` entries, OpenAPI HTTP methods
+and GraphQL operation types. A kind that comes only from an MCP server's
+`readOnlyHint` is not marked, so Executor does not offer a failed call to such a
+tool as a read's retry. A `dynamicRouter` can set `kindConfirmed` on the tools
+it lists.

.changeset/execute-results-whole.md

@@ -0,0 +1,16 @@
+---
+"@executor-js/mcp": patch
+"@executor-js/sdk": patch
+"@executor-js/app-templates": patch
+---
+
+`execute` and `call` no longer limit the size of a result. A value over
+100,000 bytes used to come back from `execute` as a success with its JSON cut
+into a string that could not be parsed, and `call` refused it; both now return
+the whole value, and logs come back whole. Approval requests and an app's own
+questions are no longer refused for their size either. A failure that matches
+the runtime's 32 MiB limit on one value crossing Workers RPC now names that limit
+as the likely cause and says to ask for less if the result could be that large;
+the app's Worker can produce the same text, so a read stays retryable once. On
+local and self-host the runtime's reason for a failed call now reaches the host.
+The code-mode skill states this.

.changeset/failed-poll-statement.md

@@ -0,0 +1,7 @@
+---
+"@executor-js/sdk": patch
+"@executor-js/telemetry": patch
+---
+
+A failed poll's root span now names the statement that failed: its operation,
+its table and the database's kind of failure, never its SQL or values.

.changeset/failed-poll-traces.md

@@ -0,0 +1,10 @@
+---
+"@executor-js/sdk": patch
+"@executor-js/hosted-server": patch
+"@executor-js/telemetry": patch
+---
+
+A check for due runs, queued provisioning jobs or event deliveries that fails is
+traced again, though a check that finds nothing is not. Each failure is
+exported as its own root span with the error it recorded, as are a failed
+claim of a due event delivery and failed event retention.

.changeset/graphql-stated-errors.md

@@ -0,0 +1,11 @@
+---
+"apps": patch
+---
+
+A `graphqlRouter` failure now quotes the errors the GraphQL server stated in its response's
+`errors` list: each message, its response path and the scalar `extensions` entries, such as
+`code`, bounded and with account secrets replaced. A client error status, such as HTTP 400 for a
+request that fails validation, reads its GraphQL errors too, from a JSON body of at most 64 KiB
+that arrives within 2 seconds; past either, the failure keeps the status and says the body was not
+read. Before, every such failure reached the caller as "GraphqlError was thrown without a
+message" with only its phase, reason and status.

.changeset/host-api-cache.md

@@ -0,0 +1,22 @@
+---
+"@executor-js/sdk": patch
+"apps": patch
+---
+
+A host can pass `hostApi` to `createExecutor`: the SHA-256 of the API document
+it serves, the URLs it serves it at, and which app versions read it. Those
+versions' app cache and kept tool listings are keyed by the revision too, so
+after the host's API changes they read the new API on their next call instead
+of listing its removed tools until their cached document expires. That holds for
+a version that owns a database as well. Invocations carry the revision to the
+runner, whose outbound network, the data facet's included, refuses a document
+from those URLs with a different SHA-256, so a caller and an API deployed at
+different moments never keep one revision's API under the other's name. The
+app's `fetch` then rejects with the code `EXECUTOR_API_CHANGING`, and the agent
+is told that Executor's API is changing and to retry shortly; a tool call that
+may have written is told the API is changing but not to repeat it. A caller refuses
+the result of a remote runner that does not confirm the check.
+
+An app failure's `code` is the thrown error's own, or else the code of the
+error it wraps, such as the platform rejection inside the `HttpClientError`
+that `ctx.fetch` rejects with.

.changeset/mcp-optional-event-stream.md

@@ -0,0 +1,9 @@
+---
+"apps": patch
+---
+
+`mcpRouter` no longer fails discovery when a Streamable HTTP server refuses the
+optional GET event stream, for example with a 401, while answering every POST.
+The client carries on without the stream, as the MCP SDK does. A refused POST
+still reports rejected credentials, and the legacy SSE transport's GET, which is
+its session, still fails as before.

.changeset/mcp-reported-tool-errors.md

@@ -0,0 +1,12 @@
+---
+"@executor-js/mcp": patch
+"@executor-js/app-templates": patch
+---
+
+A remote MCP tool result with `isError: true` is now listed as a `failure` in the `toolCalls` of
+`execute`, `call` and `resume`, and is no longer counted in `executor.tool_call.succeeded`. It
+was listed as a `success`, though Executor already recorded the call as failed in its traces and
+analytics. The call still returns the whole result instead of throwing, so programs that read
+`isError` keep working. Fields an app defines, such as `ok: false`, are not interpreted. The
+code-mode skill and the MCP docs say to check `isError`, that a failed call may still have had
+effects, and that `success` only means no tool error was reported, not that the action happened.

.changeset/motel-store-low-water.md

@@ -0,0 +1,13 @@
+---
+"@executor-js/telemetry": patch
+"@executor-js/hosted-self-host": patch
+---
+
+The bundled Motel collector no longer churns once its store is full. It used to
+evict back to exactly its 1 GiB bound, so the next export crossed it again, and
+every export, about one a second on an idle server, paid for an eviction pass
+that scanned the whole store. A full store now evicts down to 90% of its bound
+and then stores exports without evicting until it fills again. On a full 1 GiB
+store with an idle server's exports, the collector's CPU fell from about 9% of a
+core to under 1%, its reads from about 30 MiB/s to about 1 MiB/s, and each
+export's time from about 120 ms to about 20 ms.

.changeset/oauth-refresh-redirect-uri.md

@@ -0,0 +1,5 @@
+---
+"@executor-js/sdk": patch
+---
+
+Preserve the original authorization redirect URI on OAuth authorization-code grants and reuse it when refreshing their tokens.

.changeset/oauth-resource-indicator.md

@@ -0,0 +1,5 @@
+---
+"apps": patch
+---
+
+The blocked-app notice for a `credentials_rejected` account reads "credentials not working at last check" instead of "sign-in rejected", because the reason also covers a sign-in that expired before any request.

.changeset/openapi-declared-server-errors.md

@@ -0,0 +1,10 @@
+---
+"apps": patch
+---
+
+An OpenAPI operation that declares an error response for a 5xx, 401 or 429 status
+now quotes that response's declared code and message on the provider failure, as
+the service's stated error. Before, the status alone decided the failure and the
+body was not read, so an API that explains its server errors, such as Executor's
+own API through the Executor app, read as a bare "server error". The failure keeps
+its reason, status, account recovery and retry policy.

.changeset/openapi-held-names.md

@@ -0,0 +1,12 @@
+---
+"apps": patch
+---
+
+An OpenAPI operation keeps its tool name when a later sibling's refined name
+would land on it. The sibling is refined further instead, so a name an agent or
+an approval policy already uses keeps calling the same operation. A document
+that already declares both operations names them the same way, so an app that
+upgrades to this release sees those two names change once: in a document with
+`GET /forks` and `GET /stars` (both `operationId: list`) and `GET /starred`
+(`operationId: listStars`), `repos.listStars` calls `/starred` again and `/stars`
+becomes `repos.listGet`.

.changeset/openapi-parameter-descriptions.md

@@ -0,0 +1,8 @@
+---
+"apps": patch
+---
+
+OpenAPI tools keep each parameter's `description` and `deprecated` in their
+input schema, so `describe` shows agents a path, query, header or cookie
+parameter's documentation beside it, as it already does for body properties and
+MCP tool properties. Search's one-line input types are unchanged.

.changeset/openapi-v1-documents.md

@@ -0,0 +1,16 @@
+---
+"apps": patch
+---
+
+`liveOpenapiRouter` imports the OpenAPI documents Executor v1 imported. A schema
+reference may reach any schema in the document: a component whose name is not
+URI-encoded, a property inside a component, or a schema under `paths` or another
+component. An operation that answers with an event stream or another type, such
+as JSON, is a tool that asks for the other type. A path may carry a fixed query,
+sent before the operation's own parameters, or a fragment, which is not sent; it
+does not change the tool's name. An empty field such as `operationId:` counts as
+absent, a parameter in a location OpenAPI 3 does not have is not an input, and a
+request body without media types sends no body.
+
+`openapiOperationNames` lists every operation a document declares with the name
+the router gives it, reading the document as the router does.

.changeset/queue-read-indexes.md

@@ -0,0 +1,6 @@
+---
+"@executor-js/sdk": patch
+---
+
+Webhook source ticks and account check reads use indexes instead of reading
+every row of their tables. Storage version 4.0.16 adds the indexes.

.changeset/request-rejections-declared.md

@@ -0,0 +1,14 @@
+---
+"@executor-js/sdk": patch
+"@executor-js/app-management": patch
+"@executor-js/hosted-server": patch
+"@executor-js/hosted-cloud": patch
+"@executor-js/hosted-self-host": patch
+"@executor-js/local-server": patch
+---
+
+A request that does not match its operation's schema now gets a `400 RequestInvalid` that every
+operation in the Cloud, self-host and local management documents declares. It names the rejected
+part and each path with what the schema expects there, never the submitted value. Agents calling
+Executor through the Executor app see that cause instead of an HTTP 400 the document does not
+declare. App ID parameters say they take the app's `id`, not its slug.

.changeset/skills-input-schema.md

@@ -0,0 +1,10 @@
+---
+"@executor-js/mcp": patch
+"@executor-js/app-templates": patch
+---
+
+The MCP `skills` tool advertises the input it accepts: every input except `{}`
+needs `app`, stated as `dependentRequired` in its input schema, which is
+generated from the schema the tool decodes with. The `execute` descriptions and
+the Executor app's entry skill give the exact call,
+`skills({app: "executor", name: "executor"})`.

.changeset/storage-migration-diagnostics.md

@@ -0,0 +1,6 @@
+---
+"@executor-js/sdk": patch
+"@executor-js/hosted-server": patch
+---
+
+Report the storage version, SQLSTATE and error classes of a failed storage upgrade at startup, without its SQL, parameters or driver message.

.changeset/untraced-event-poll.md

@@ -0,0 +1,8 @@
+---
+"@executor-js/sdk": patch
+---
+
+Self-host and local check for due event deliveries every two seconds. That
+check no longer records traces when it finds nothing to deliver; each delivery
+attempt and each subscription it expires is still traced. An idle self-host
+instance no longer fills the bundled Motel store with polling spans.

.changeset/untraced-idle-polls.md

@@ -0,0 +1,11 @@
+---
+"@executor-js/sdk": patch
+"@executor-js/hosted-server": patch
+---
+
+The scheduler's check for due runs, every second on self-host and local, and
+self-host's check for queued provisioning jobs, every second, no longer record
+traces when they find nothing to do. Each scheduled operation a check finds is
+still traced, in its own `schedule.dispatch` trace, and so is each provisioning
+job. An idle self-host instance no longer fills the bundled Motel store with
+polling spans.

.changeset/upgrade-follow-redirects.md

@@ -0,0 +1,7 @@
+---
+"executor": patch
+---
+
+`executor upgrade` on an install from the install script downloads the release again. It checked
+the status of GitHub's redirect to each release file instead of following it, so every upgrade
+failed with "could not download SHA256SUMS" and changed nothing.

.changeset/workflow-control-failures.md

@@ -0,0 +1,23 @@
+---
+"apps": patch
+"@executor-js/sdk": patch
+"@executor-js/app-templates": patch
+---
+
+`ctx.workflows.start`, `get`, `list` and `terminate` work again in apps built on `apps`
+0.0.1-beta.91 or earlier. Since the rename of deployments to versions the host sent runs
+without their former `deployment` field, so those apps could not read any answer and every
+call failed as a retryable `engine` failure, even when the run had started. The host now sends
+runs in their encoded form, with both names.
+
+A control call the host refuses, such as a `key` over 128 characters, fails with reason `input`,
+not retryable, and a message naming the field and the rule it broke; no run is started. A start
+whose run was saved, including one whose storage failed right after the save, fails as `engine`,
+not retryable, with the run's ID. A start whose commit failed or timed out answers with its run
+when Executor can read it back. A start whose save may have committed, and a `start` or
+`terminate` that Executor did not answer or whose answer the app could not read, are not
+retryable either, and their message says the run may have started or stopped and how to check. A
+start without a key is never told to start again, since that would create another run.
+Executor's own errors keep their tag and message through workflow controls.
+
+The app-authoring skill lists the workflow limits and what each control failure means.

AGENTS.md

@@ -135,9 +135,9 @@ a `workflow_call` workflow, so another repository can call the same jobs.
 ### Choosing a PR's E2E scenarios
 
 A pull request runs only the E2E scenarios it selects. Pushes to `main` run the
-full suite. The static checks (`check`, `apps-version`, `self-host-native`) always
-run, except in a skipped stack layer. Put exactly one fenced `e2e` block in the PR
-description, listing spec files from `e2e/tests/`:
+full suite. The static checks (`check` and the jobs it gates, `apps-version`,
+`self-host-native`) always run, except in a skipped stack layer. Put exactly one
+fenced `e2e` block in the PR description, listing spec files from `e2e/tests/`:
 
 ````md
 ```e2e
@@ -242,14 +242,19 @@ Do not run CI checks on macOS runners. They cost 5-20x as much per minute as Lin
 runners and were most of the CI bill, and no check needs macOS. Fix slow or flaky
 scenarios on Linux instead of moving them to a Mac.
 
-- `check` runs `bun run check`: the format check, `oxlint`, the typecheck, the
+- `check` passes when `select` and each static check job passed. The static checks run as
+  parallel jobs, so a pull request waits for the slowest, about a minute and a half, not their
+  sum. `static` runs `bun run check`: the format check, `oxlint`, the typecheck, the
   no-tests-outside-`e2e/` check and the e2e boundary check.
-  It also builds the public site and runs `bun run site:links`, which fails when
+  `site` builds the public site and runs `bun run site:links`, which fails when
   any marketing or docs page links to a path that would 404. Then
   `bun run hosted:cloud:worker-sizes` builds each Cloud Worker as the deploy does,
   for production and for the pull request's preview, and fails when one exceeds
   its upload budget; the job summary shows each Worker's size, its change from
-  `main` and the packages and files that grew.
+  `main` and the packages and files that grew. `apps-package` checks the apps npm
+  tarball, and `tooling` checks the dependency patches and the scripts that run CI,
+  releases, the public export and deploys. Put a new static check in the job it fits, or
+  in a new job that `check` needs.
 - `select` runs [`e2e/ci-selection.ts`](e2e/ci-selection.ts) and gives each e2e job
   its `--test-name` pattern, or skips the job when none of its scenarios is selected.
   Its job patterns hold the exclusions and splits below.
@@ -278,8 +283,9 @@ scenarios on Linux instead of moving them to a Mac.
   per-address limit off, as deployed test stages do; the scenario that proves the limit gets
   its own local Cloud with it on (`e2e:cloud --auth-rate-limit`).
   Each of these local Clouds is a Cloud job in `e2e/ci-selection.ts`, and its `runner`
-  there puts it on one of three `e2e-cloud` runners that run at once, about four minutes each
-  on a full run. Each runner builds the apps package and Motel once before its runs; runs only
+  there puts it on one of four `e2e-cloud` runners that run at once. On a full run
+  `cloud-product` has a runner to itself, about eleven minutes, and the others take about six or
+  seven each. Each runner builds the apps package and Motel once before its runs; runs only
   serve that Motel bundle, because every target in a run shares it.
 - `e2e` passes when `select` succeeded, every E2E job it chose passed and every other one was
   skipped; it runs even after a cancellation, which fails it. The matrix runners' check
@@ -294,6 +300,14 @@ Release PRs build and test the Linux and Windows targets only. The macOS targets
 on manual dispatch, where they are built, signed, notarized and tested. macOS runners
 cost 5-20x as much as Linux runners, so keep them off pull requests.
 
+A pull request that changes the release paths (the `paths` in
+`.github/workflows/release-artifacts.yml`) also runs "Executor releases". Gate its
+merge on that workflow as on CI: wait for both
+(`ci-wait --workflow CI --workflow "Executor releases"`) and do not merge while
+either fails. Its packaging jobs fail when a native archive exceeds the npm budget
+(`npmArchiveBudgetBytes` in `scripts/releases/config.ts`); an archive over it cannot be
+published, so that failure blocks every later release until it is fixed.
+
 A failed e2e job uploads raw reports and server logs. Product database files,
 runtime dependencies and private `actors.json` sessions are excluded.
 Reports use Vitest's final result, including setup and cleanup failures.