fix(sdk): re-point functions.deploy onto unified apply + transfer-accept keys

The gateway deleted POST /projects/v1/admin/:id/functions (live on main), so
r.functions.deploy() 404s in prod. Re-point it onto the unified apply engine
(a one-function functions.patch.set ReleaseSpec) — the same path the rest of
the SDK uses. Auth shifts from the service-key bearer to the standard apply
credential (SIWX wallet, or the v3.1.0 project.deploy operator-approval gate).
Public signature + FunctionDeployResult shape unchanged; runtime_version and
deps_resolved are null on the deploy result (apply returns release-level data —
they live on the functions-list record).

Wire `deps` end-to-end through the apply engine (capability
apply-v1-function-deps, verified on origin/main): public FunctionSpec.deps, the
validateSpec field allowlist, normalizeFunction, and functionToWire. Without all
four, functions.deploy({ deps }) would silently drop deps at the wire.

transfer-accept (#428): AcceptTransferResult gains anon_key/service_key, and
accept() persists them via saveProject + setActiveProject (mirroring provision)
so the new owner can operate the inherited project with no extra provisioning.

Tests: rewrote the SDK + MCP deploy tests onto the apply flow (plan+commit;
empty missing_content skips upload, terminal ready skips poll); added
transfer-accept persistence tests. Corrected the now-false docs (unified deploy
does accept deps; the deploy result no longer surfaces runtime_version /
deps_resolved). npm test green (0 fail), build clean.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Author: MajorTal

cli/lib/functions.mjs

@@ -87,12 +87,12 @@ Notes:
     export default async (req: Request) => Response
   Deploy may require payment if the project lease has expired.
 
-  The deploy response includes:
-  - runtime_version: the bundled @run402/functions version (e.g. "1.48.0")
-  - deps_resolved: map of each --deps name to the actually-installed
-    concrete version (e.g. {"lodash":"4.17.21"})
-  - warnings (optional, top-level, sibling to the record): non-fatal
-    notes such as bundle-size advisories
+  Deploy routes through the unified apply engine (functions.patch.set), not
+  a legacy admin route. The result sets runtime_version and deps_resolved to
+  null (apply returns release-level data, not per-function build metadata) -
+  read the resolved versions from 'run402 functions list', whose records
+  carry both. The result still includes an optional top-level warnings:
+  string[] for non-fatal notes such as bundle-size advisories.
 
 Examples:
   run402 functions deploy prj_abc123 stripe-webhook --file handler.ts

cli/llms-cli.txt

@@ -228,7 +228,7 @@ Manifest format mirrors a v2 `ReleaseSpec`. For editor autocomplete, use top-lev
 
 File entries accept a bare UTF-8 string, `{ "data": "...", "encoding": "utf-8" | "base64", "content_type": "..." }`, or `{ "path": "dist/index.html", "content_type": "text/html" }`. In `--manifest` files, relative paths resolve against the manifest file's directory; in `--spec` / stdin they resolve against the current working directory. Migration entries may use `"sql_path"` or `"sql_file"` instead of inline `"sql"`. The CLI and MCP adapters share the SDK's typed `normalizeDeployManifest` path, so the same JSON can become SDK-native `ReleaseSpec` code without reimplementing base64 or path handling. The adapter is strict: only top-level `$schema` metadata is ignored; unknown fields and no-op specs are rejected before deploy planning, so typos like `"subdomain"`, `"site.replcae"`, `"functions.replace.api.deps"`, or `"functions.replace.api.config.schedule"` do not become partial deploys.
 
-Function specs in unified deploy manifests accept `runtime` (`"node22"`), exactly one code source (`source` for a single module, or `files` plus `entrypoint` for multi-file functions), `config.timeout_seconds`, `config.memory_mb`, and `schedule` as a sibling of `config`. In patch mode, omit `schedule` to leave it unchanged and use `"schedule": null` to remove an existing schedule. Unified deploy manifests do not accept `deps` yet; bundle dependencies into the function files or use `run402 functions deploy --deps` for the standalone function path.
+Function specs in unified deploy manifests accept `runtime` (`"node22"`), exactly one code source (`source` for a single module, or `files` plus `entrypoint` for multi-file functions), `config.timeout_seconds`, `config.memory_mb`, and `schedule` as a sibling of `config`. In patch mode, omit `schedule` to leave it unchanged and use `"schedule": null` to remove an existing schedule. Unified deploy manifests accept `deps` (a `string[]` of npm specs) under capability `apply-v1-function-deps`; the gateway installs and bundles them. `run402 functions deploy --deps` builds a one-function `functions.patch.set` and rides this same unified-apply path (the legacy standalone deploy route was removed).
 
 Deploy preflights obvious tier function caps after manifest normalization but before CAS upload or `/apply/v1/plans`: timeout, memory, cron interval, and scheduled-function count. Structured local failures use `code: "BAD_FIELD"` with `details.field`, `details.value`, `details.tier`, the relevant limit e.g. `tier_max` or `min_interval_minutes`, and `details.limit_source` (`tier_status` or `local_static_fallback`). Current authoring caps: prototype 10s / 128 MB / 1 scheduled fn / 15 min, hobby 30s / 256 MB / 3 / 5 min, team 60s / 512 MB / 10 / 1 min. `run402 tier status` shows live function caps and current scheduled usage when the gateway returns them.
 
@@ -589,7 +589,7 @@ Create a manifest file `app.json` (use the `project_id` from provision):
 
 `project_id` is required (from `run402 projects provision`). All other fields are optional; omitted top-level sections are carried forward from the current release. The adapter is strict: only top-level `$schema` metadata is ignored; typo fields e.g. `subdomain`, `site.replcae`, `functions.replace.my-fn.deps`, or `functions.replace.my-fn.config.schedule` fail before planning.
 
-Function specs accept `runtime: "node22"`, exactly one code source (`source`, or `files` plus `entrypoint`), `config.timeout_seconds`, `config.memory_mb`, a sibling `schedule`, and the v1.51+ auth-gate fields `require_auth` / `require_role` (see "Function-level auth gates" below). Omit `schedule` in patch mode to leave it unchanged; set it to `null` to remove the schedule. Unified deploy manifests do not accept `deps`; bundle dependencies into the function files or use `run402 functions deploy --deps`.
+Function specs accept `runtime: "node22"`, exactly one code source (`source`, or `files` plus `entrypoint`), `config.timeout_seconds`, `config.memory_mb`, a sibling `schedule`, and the v1.51+ auth-gate fields `require_auth` / `require_role` (see "Function-level auth gates" below). Omit `schedule` in patch mode to leave it unchanged; set it to `null` to remove the schedule. Unified deploy manifests accept `deps` (npm specs) under capability `apply-v1-function-deps`; `run402 functions deploy --deps` rides this same unified-apply path.
 
 Function-level auth gates (v1.51+). Two optional declarative fields on each function spec:
 
@@ -890,7 +890,7 @@ One noun, two rails: a **wallet** recipient is a two-party wallet transfer; an *
 - `run402 transfer init --to <wallet|email> [--project <id>] [--billing-policy migrate] [--message <text>] [--kysigned <record_id>] [--retain-collaborator developer]` — initiate (owner-only). `--to` routes by recipient kind: a wallet starts a transfer, an email starts a handoff. Returns `{ transfer_id, expires_at, ... }`. `--retain-collaborator developer` (v1.91, **email handoffs only** — rejected with `BAD_FLAG` on the wallet rail; only `developer` is valid) asks to keep a `developer` membership in the recipient's org after handoff; the recipient must accept it at claim time, and omitting it is a full severance (the default). Gateway codes: `INVALID_RETAIN_ROLE`, `RETAIN_SUBJECT_REQUIRED`.
 - `run402 transfer preview <transfer_id> [--handoff]` — fetch the preview document (either party); `--handoff` previews an email->org handoff. Lists custom domains, subdomains, function names, secret NAMES (never values), CI bindings that will be revoked on accept, mailbox summary, billing implications.
 - `run402 transfer list [--incoming | --outgoing | --handoffs] [--limit N] [--offset N]` — `--incoming` (default) shows wallet transfers OFFERED TO you; `--outgoing` shows transfers you initiated; `--handoffs` shows incoming email->org handoffs. Each entry includes `preview_path`.
-- `run402 transfer accept <transfer_id>` — accept a WALLET transfer (recipient). Atomically flips ownership, revokes the previous owner's CI bindings on the project, and stamps a `secrets_rotation_advised` advisory. Secret VALUES are inherited; the response returns `secret_names_inherited[]`.
+- `run402 transfer accept <transfer_id>` — accept a WALLET transfer (recipient). Atomically flips ownership, revokes the previous owner's CI bindings on the project, and stamps a `secrets_rotation_advised` advisory. Secret VALUES are inherited; the response returns `secret_names_inherited[]`. The accept response also returns the new owner's project `anon_key` + `service_key` (#428), and the SDK/CLI persist them into the local keystore and set the project active — so you can deploy / set secrets / run SQL on the inherited project with no extra provisioning step.
 - `run402 transfer claim <transfer_id> [--into <organization_id>] [--accept-retained-collaborator]` — claim an incoming EMAIL handoff into an org you own (omit `--into` to claim into a brand-new org). The handoff analog of `accept`. `--accept-retained-collaborator` accepts the sender's v1.91 retained-`developer`-membership offer (visible as `retain_collaborator` on `transfer preview`); omit it for a full severance. The claim result carries `retained_collaborator_principal_id` (or `null`).
 - `run402 transfer cancel <transfer_id> [--reason <text>] [--handoff]` — cancel (either party); `--handoff` cancels an email->org handoff.
 
@@ -1040,11 +1040,11 @@ For routed browser 500s, copy `X-Run402-Request-Id` or the JSON `request_id` fro
 - Limits: max 30 entries, max 200 chars per spec.
 - Native binary modules (sharp, canvas, native bcrypt, etc.) are rejected.
 
-The deploy / list / update responses include two fields populated under bundling-at-deploy:
+`run402 functions deploy` routes through the unified apply engine, so its **result** sets `runtime_version` and `deps_resolved` to `null` (apply returns release-level data, not per-function build metadata). Read the resolved values from `run402 functions list` (and `update`), whose records carry both fields populated under bundling-at-deploy:
 - `runtime_version` — the bundled `@run402/functions` version (e.g. `"1.48.0"`). Surface this as "Functions runtime version" — never bare "runtime", which already names the Node runtime (e.g. `node22`). `null` for legacy functions.
 - `deps_resolved` — map of each `--deps` name to the -installed concrete version (e.g. `{"date-fns": "3.7.0"}` for a `^3.6.0` spec). Direct deps only; this is not a lockfile. `{}` for an empty `--deps`; `null` for legacy functions.
 
-The deploy response also gains an optional top-level `warnings: string[]` (sibling to the function record, not inside it) for non-fatal deploy notes e.g. bundle-size advisories. Omitted or `[]` when there are no warnings.
+The deploy result still includes an optional top-level `warnings: string[]` (sibling to the function record, not inside it) for non-fatal deploy notes e.g. bundle-size advisories. Omitted or `[]` when there are no warnings.
 
 #### Function authoring limits by tier
 

openspec/changes/repoint-functions-deploy-and-transfer-keys/.openspec.yaml

@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-06-17

openspec/changes/repoint-functions-deploy-and-transfer-keys/design.md

@@ -0,0 +1,71 @@
+## Context
+
+Two gateway changes (run402-private, Jun 16-17) landed after the public client was last synced:
+
+- **`d38a2e51`** deleted `POST /projects/v1/admin/:project_id/functions` (~160 lines) and removed it from `openapi.json` + `llms-full.txt`. The commit body self-corrects: *"the route WAS in openapi+llms (the proposal wrongly said absent)."* The gateway kept `deployFunction` in services (used by `/apply/v1` + bundling) and the `/functions/:name/*` management sub-routes + the GET-list. It migrated its own test callers onto a `deployFunctionViaApplyV1` helper: compute SHA-256 of the code, CAS-upload, build a `functions.patch.set` `ReleaseSpec`, POST `/apply/v1/plans` → commit → poll, return the legacy `{name,url,status,schedule}` shape.
+- **`ea6bc171` (#428)** added `anon_key`+`service_key` to the transfer-accept 200 body (derived post-commit via `deriveProjectKeys(project_id)` — stateless JWTs, never persisted, same as `POST /projects/v1`). `acceptTransfer` (the service) stays pure; keys are a route-layer concern.
+
+Public state: `r.functions.deploy()` POSTs the deleted route with the service-key bearer; `AcceptTransferResult` is a closed interface with no key fields and `accept()` does a bare request with no keystore write.
+
+## Goals / Non-Goals
+
+**Goals:** restore function deploy (it 404s in prod) by routing through the same `/apply/v1` engine the rest of the SDK uses; give the transfer recipient working keys with no extra step; keep both public method signatures + return types stable.
+**Non-Goals:** changing the deploy-spec / apply surface; the handoff (email→org) path (#428 touched only the wallet-transfer accept); re-adding any deleted gateway route.
+
+## Decisions
+
+### Decision 1 — `functions.deploy()` delegates to the apply engine, not a hand-rolled dance
+
+`new Deploy(this.client)` is constructible from the kernel `Client` (exactly what `Run402` does for `_applyEngine = new Deploy(client)`). `deploy()` builds a one-function `ReleaseSpec` and calls `engine.apply(spec, {})`:
+
+```
+{ project: projectId,
+  functions: { patch: { set: { [opts.name]: {
+    source: { data: opts.code, contentType: "text/javascript; charset=utf-8" },
+    ...(opts.config ? { config: { timeoutSeconds: opts.config.timeout, memoryMb: opts.config.memory } } : {}),
+    ...(opts.deps ? { deps: opts.deps } : {}),
+    ...(opts.schedule !== undefined ? { schedule: opts.schedule } : {}),
+  } } } } }
+```
+
+The engine handles the CAS upload of `source` (a polymorphic `ContentSource` — inline bytes are normalized + uploaded automatically), the plan/commit/poll state machine, and safe-retry. We do NOT reimplement the gateway test helper's manual CAS dance — the SDK already owns it. **Alternative — hand-roll plan/upload/commit in `functions.deploy`** (mirror the gateway test helper): rejected, it duplicates `_applyEngine` and drifts.
+
+**`deps` is preserved — verified against `origin/main`.** The riskiest correctness property: would re-pointing through apply silently drop the documented `deps` option? The local private working tree (`0cda4ebf`, stale) shows apply activation passing `undefined` for deps ("not surfaced through the v2 spec yet") — but that predates `d38a2e51`. On `origin/main` (the prod deploy source) the apply path fully supports function deps via capability **`apply-v1-function-deps`**: `functions.patch.set.<name>.deps: string[]`, validated at `apply-v1.ts:1417` and persisted into the staged `config` JSONB. The gateway's own `deployFunctionViaApplyV1` migration helper sets `fnSpec.deps = args.deps`, and the prod-validated `deps-smoke` test (deps:[lodash], "6/0 against prod") rides this exact path. So `functions.deploy` carries `deps` straight into `FunctionSpec.deps` with no loss. This required adding the missing **`deps?: string[]`** field to the public `FunctionSpec` type (the apply surface was deps-capable on the wire but the SDK type never exposed it).
+
+### Decision 2 — Map `DeployResult → FunctionDeployResult`, best-effort, `runtime_version`/`deps_resolved` → `null`
+
+`DeployResult` carries `release_id`, `operation_id`, `urls`, `diff`, `warnings` — not per-function build metadata. So the mapping is:
+- `name` ← input; `status` ← `"deployed"` (apply reached terminal success); `schedule` ← input echo; `runtime` ← `opts.config?.runtime ?? "node22"`; `timeout`/`memory` ← input config (or tier defaults); `created_at` ← now.
+- `url` ← `result.urls[name]` if present, else derived `…/functions/v1/<name>` from the project's site host (best-effort).
+- `warnings` ← `result.warnings` mapped to their messages.
+- `runtime_version` / `deps_resolved` ← **`null`**. They were fields of the deleted route's response and are not on the apply result. The gateway's own migration shim returns only `{name,url,status,schedule}`, so this matches; both fields are already typed `?: … | null`. Documented as "not surfaced via deploy; the function record carries them."
+
+### Decision 3 — Auth shifts from the service key to the `project.deploy` gate
+
+The old route took `Authorization: Bearer <service_key>`. `/apply/v1` authorizes via the standard credential (SIWX wallet, or — for a wallet-less human — the operator-approval `project.deploy` gate shipped in v3.1.0). This is correct: deploying a function IS a `project.deploy`. An agent with a wallet is unaffected; a wallet-less human gets the operator-approval flow automatically. `deploy()` still calls `getProject(projectId)` first to fail fast with `ProjectNotFound` on an unknown id (and the spec needs the id), but no longer sends the service key.
+
+### Decision 4 — transfer-accept mirrors `provision`'s persistence
+
+`AcceptTransferResult` gains `anon_key: string` / `service_key: string`. After the accept request returns, `accept()` does the same persistence `provision` does:
+
+```
+if (creds.saveProject) await creds.saveProject(result.project_id, { anon_key, service_key });
+if (creds.setActiveProject) await creds.setActiveProject(result.project_id);
+```
+
+so the new owner's keystore has the project + it's active. Gated on the optional provider methods (sandbox providers without persistence simply skip). The CLI prints the accept result as-is (the `service_key` JWT is identical to what `provision` already prints). The handoff/claim path is untouched (#428 changed only the wallet-transfer accept).
+
+## Risks / Trade-offs
+
+- **`runtime_version`/`deps_resolved` degradation** → documented; both already nullable; matches the gateway shim. A consumer needing them reads the function record (kept GET routes).
+- **`url` is best-effort** → derived from `urls[name]` or the site host; a future enrichment could read the materialized route, but is out of scope for restoring deploy.
+- **Auth shift could surprise a service-key-only caller** → in practice `functions.deploy` callers are the wallet/agent flow or the CLI (which has a wallet/operator session); the gate is the same one `deploy apply` uses.
+- **Persisting `service_key` to the keystore** → identical to `provision`; the new owner legitimately holds it.
+
+## Migration Plan
+
+Additive/behavioral, client-only, non-breaking to the public signatures. Ships in the normal lockstep release (urgent — the function-deploy 404 is live). Rollback = revert; the gateway routes are independent.
+
+## Open Questions
+
+- Whether to enrich `runtime_version`/`deps_resolved` via a post-deploy function-record read — deferred (extra round-trip; both nullable; not needed to restore deploy).