Cloudflare Workers

Use the repository's architecture, commands, installed types, and runtime compatibility settings. Current documentation explains APIs; a maintenance task does not by itself call for a dependency or compatibility-date upgrade.

Read for the changed boundary:

• Worker handlers, streams, bindings, and verification: Workers.
• Durable Object identity, storage, alarms, and WebSockets: Durable Objects.
• Wrangler commands, environments, deployment, and secrets: Wrangler.
• Choosing between cf, Wrangler, and Alchemy, or discovering an API command: CLI selection.
• Tracing, CPU attribution, or deployed measurements: observability, then its Cloudflare reference as needed.
• Effect HTTP services and bindings at the Worker boundary: Effect integration.
• Infrastructure declarations and deployment lifecycle: Alchemy.
• An application using @cloudflare/sandbox: Sandbox SDK. Ordinary commands inside an agent sandbox do not require the SDK.

Resolve the account, environment, and local or remote target before mutations. Preserve deployed storage migrations, existing authorization, and host ownership of task containers, previews, authentication, and capability URLs. Follow the repository's testing policy and verify the behavior at its actual runtime boundary.

For critical-path changes, use measure-performance. Reuse guidance already loaded and follow only the references needed for the current question.

Attribution is in NOTICE; terms are in LICENSE.