Make the rename deployable onto an existing Worker

[codeyogi911]

Two defects stood between the renamed suite and any deployment that already exists. Both were introduced or exposed by the Morrow → Able rename.

The rename rewrote an applied migration tag

v1_voice_demo was edited in place to declare AbleDeskAgent. Cloudflare records migration tags as applied, so on a Worker that already ran v1_voice_demo the tag would never re-run, the Durable Object class would never exist under its new name, and the AbleDeskAgent binding would resolve to nothing.

v1 is restored to the class as first created, and the rename becomes a new tag:

{ "tag": "v1_voice_demo", "new_sqlite_classes": ["AbleDeskVoiceDemoAgent"] },
{ "tag": "v2_rename_desk_agent", "renamed_classes": [{ "from": "AbleDeskVoiceDemoAgent", "to": "AbleDeskAgent" }] }

Correct in both directions: a fresh install applies both in sequence and lands on AbleDeskAgent; a Worker that already applied v1 applies only v2 and keeps its Durable Object state.

A Worker cannot be renamed in place

A deployment already serving custom domains, a Cloudflare Access application and email routing from a Worker named before the rename should keep serving from it, rather than moving all of that to a differently named Worker. ABLE_WORKER_NAME supplies the name exactly the way ABLE_D1_DATABASE_ID and its siblings already do, so the committed default stays able and nothing deployment-specific enters source. The Worker name is not customer-visible when custom domains front it.

Verification

• npm run check — 206 + 4 tests pass, all typechecks clean
• New coverage at the existing createProductionConfig seam: default name preserved, override applied, blank ignored, source not mutated, and invalid names rejected
• Writing that last case found a real gap — the first regex accepted a trailing hyphen, which Cloudflare rejects because the name becomes a DNS label

🤖 Generated with Claude Code