sandbox-migrate-to-next

# Migrate stable → Sandbox SDK 1.0 preview (`@next`) **Perform** the port. Follow the steps in order. Depth lives in docs—fetch the linked page when a step needs detail. Human guide: [Migrate](https://developers.cloudflare.com/sandbox/1-0-preview/migrate/) · [1.0 preview](https://developers.cloudflare.com/sandbox/1-0-preview/) **New projects** should start on `@next` (**`sandbox-next`**), not this skill. **Day-to-day stable work** → **`sandbox-stable`**. Deprecated-API cleanup **without** moving to `@next` → [2026 deprecation guide](https://developers.cloudflare.com/sandbox/guides/2026-deprecation/) first if needed. Existing apps should migrate **when you can**, so you are ready when 1.0 becomes the stable release. Do **not** force production cutover without the user agreeing. **Prefer installed `@next` types and the migrate doc over memory.** ## Workflow 1. **Review** hard rules and the replacement map 2. **Audit** the codebase; list hits and target shapes 3. **Clarify** with the user (cutover, bridge, Python image, unclear sites) 4. **Upgrade** package, image, and code 5. **Validate** Stop after any step that needs a user decision. ## Hard rules - Worker package and container image must be the **same** `@next` line. - Production cutover uses **immediate** container rollout. Stable and `@next` control protocols are incompatible both ways; gradual rollout leaves a broken mixed window. In-flight container work can stop. - After cutover, `await sandbox.e...