Bump cloudflare os 79f87d19

.agents/skills/cloudflare-os-operator/SKILL.md

@@ -245,6 +245,8 @@ After first production provisioning, inventory the actual resource identities. C
 
 Disabling it is a deliberate choice with a consequence: every user must then supply their own model API keys, and a deployment migrated from the hosted flow shows an empty model picker because `wrangler deploy` replaces `vars` wholesale and drops the hosted `CF_AI_GATEWAY*` values. Confirm the operator wants that before setting it false.
 
+The AI Gateway Auto Router provider, whose one model is **Auto**, is turned on under Providers in `/admin`, not listed in `aiGateway.providers`.
+
 Decisions to confirm:
 
 1. Which gateway. `default` is created on first use; a migration from the hosted deploy must reuse `<instance>-ai` (see `docs/migrate-from-hosted.md`).

.agents/skills/cloudflare-os-operator/references/updating.md

@@ -18,6 +18,7 @@ Check the upstream range for each of the following. When none of them touches th
 - A new preinstalled Gatekeeper or Worker.
 - Build tooling changes.
 - Renamed paths, packages or variables.
+- A new Workshop storage-schema version (a `version.put(` in `packages/workshop-backend/src/storage-schema/overseer-migrations.ts`). It needs nothing here, but once deployed the Workshop cannot roll back to the old pin, and the summary has to say so.
 
 ## Gatekeeper Contract Changes
 

README.md

@@ -40,7 +40,7 @@ This repository adds deployment controls around a pinned [Cloudflare OS](https:/
 | Routing | A production [Custom Domain](https://developers.cloudflare.com/workers/configuration/routing/custom-domains/) or a `workers.dev` evaluation route |
 | Data | Existing KV/R2 resources or [automatic provisioning](https://developers.cloudflare.com/workers/wrangler/configuration/#automatic-provisioning) |
 | Integrations | Wrapper-owned Gatekeepers and service bindings without patching upstream |
-| AI | A [Workers AI](https://developers.cloudflare.com/workers-ai/) model catalog through [AI Gateway](https://developers.cloudflare.com/ai-gateway/) out of the box, with no API token; which providers and which gateway |
+| AI | A [Workers AI](https://developers.cloudflare.com/workers-ai/) model catalog through [AI Gateway](https://developers.cloudflare.com/ai-gateway/) out of the box, with no API token; which providers and which gateway, and an **Auto** model that lets the gateway choose among them, turned on in `/admin` |
 | Operations | [Structured logs, traces, explicit error reports](docs/observability.md), validation, deployment order, and upgrades |
 
 ### Architecture

docs/customization.md

@@ -195,6 +195,7 @@ The binding stays bound whatever you configure here: as well as carrying gateway
 | --- | --- |
 | `enabled: true`, `providers: ["cloudflare"]` | Workers AI models over the binding. No token, no keys of your own. The default. |
 | Add `anthropic` or `openai` | Their models appear too. Keys live on the gateway ([Unified Billing or BYOK](https://developers.cloudflare.com/ai-gateway/get-started/#provider-authentication)), not in this repository. Still no token. |
+| Turn on **AI Gateway Auto Router** under Providers in `/admin` | One more model, **Auto**, which lets the Gateway's [Auto Router](https://developers.cloudflare.com/ai-gateway/features/auto-router/) choose among the other providers that are on. It is not one of `providers`. |
 | Add `google` | Needs `CF_AI_GATEWAY_API_TOKEN`. pi's Google adapter refuses a custom fetch, so Google inference cannot ride the binding. |
 | `accountId` set to another account | Needs `CF_AI_GATEWAY_API_TOKEN`. The binding only reaches gateways in the Worker's own account, so the generated config sets `CF_AI_GATEWAY_USE_BINDING: "false"` and the HTTPS transport takes over. |
 | `enabled: false` | No deployment-managed catalog. Each user supplies their own model API keys — and a Workshop [migrated from the hosted deploy](migrate-from-hosted.md) will show an empty model picker. |
@@ -248,6 +249,6 @@ Moving the submodule past the starter's pin is a review of its own. `npx cf-os@l
 4. Compare three entries of `cloudflare-os/pnpm-workspace.yaml`'s `catalog:` with this repository's: `capnweb`, `typescript` and `@cloudflare/workers-types`. Only those three have to match. The packages here `link:` to the submodule's rather than sharing a workspace with them. So the submodule's dependencies come from its own lockfile, and this catalog does not govern them. Types still cross the link, though. Each install has its own `capnweb` copy whatever the version, and today only its types cross. Keeping the ranges in step keeps those types compatible, and keeps the two copies from diverging if runtime code ever crosses too.
 5. Run `pnpm install`, then `pnpm lint` and `pnpm cf-os check`. The root `postinstall` (`cf-os install`) reinstalls the submodule's workspace from its lockfile. `optimisticRepeatInstall: false` makes it run even when this repository's own lockfile has not changed, which is what a gitlink bump looks like from here. If the hook was skipped (`--ignore-scripts`), `pnpm cf-os install --check` and every build, test and deploy entry point stop and tell you to run `pnpm cf-os install`.
 6. Deploy and verify Access, administrator access, storage, configured AI, Context, Scheduler, Web Search, custom observations, a connection through each optional Gatekeeper, and the Error Reporter query surface.
-7. If needed, restore the previous gitlink and redeploy, or use [Workers rollback](https://developers.cloudflare.com/workers/versions-and-deployments/rollbacks/) when bindings remain compatible. Neither works across a Durable Object migration: once a pin that adds a `migrations` tag to a Worker's `wrangler.jsonc` has deployed, that Worker can only be repaired forward. Check for new tags in step 3, the Workshop's especially, before deploying.
+7. If needed, restore the previous gitlink and redeploy, or use [Workers rollback](https://developers.cloudflare.com/workers/versions-and-deployments/rollbacks/) when bindings remain compatible. Neither works across a Durable Object migration: once a pin that adds a `migrations` tag to a Worker's `wrangler.jsonc` has deployed, that Worker can only be repaired forward. The same goes for the Workshop's own storage schema, which no tag reveals: its Overseer migrates each workspace on first open, and the previous code misreads the new shape. Each step is a `version.put(` in `cloudflare-os/packages/workshop-backend/src/storage-schema/overseer-migrations.ts`. Check for new tags and schema versions in step 3, the Workshop's especially, before deploying.
 
 Do not update the submodule blindly. The deploy derives from upstream configs so incompatible base changes remain visible during review and checks.