Add Cloudflare Workers community world to worlds manifest

[ataylorme]

Summary

• Adds @ataylorme/workflow-world-cloudflare to worlds-manifest.json as a community world

This is the follow-up to #1372, where @VaguelySerious recommended publishing as a third-party world and adding to the manifest.

The package is published on npm: @ataylorme/workflow-world-cloudflare@1.0.0-beta1

Architecture: Durable Objects for per-run state, D1 for cross-run queries, Cloudflare Queues for message dispatch.

Source: https://github.com/ataylorme/workflow-world-cloudflare

🤖 Generated with Claude Code

[changeset-bot]

⚠️ No Changeset found

Latest commit: 15f4ceb

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[vercel]

@ataylorme is attempting to deploy a commit to the Vercel Labs Team on Vercel.

A member of the Team first needs to authorize it.

[pranaygp]

Opened draft mirror PR #1697 to run upstream CI for this external contribution.

Tracking PR: #1697

If the checks pass on #1697, the plan is to merge this original PR rather than the mirror.

[pranaygp]

just left similar comments on a different community world PR - we need better explanation in the docs but essentially

for community worlds, the docs don't come from a markdown on our site. we currently simply link out to your readme and that's all automatically generated from the worlds-manifest

you can see an example of how the community world will look (https://useworkflow.dev/worlds/redis). This way you can keep the docs upto date on your README easily.

so adding to the worlds-manifest is enough to be added to the list. Additionally, we can setup e2e testing and benchmarking here so that those results are tracked and published to the docs site

the ones like surreal/redis/etc. all run inside github CI environment. but for cloudflare, I suppose we will need to run your world on a cf account we control for.

Let's get this added to the manifest first in this PR (please remove the docs changes - just the manifest) and I'll figure out the CI environment/setup soon after by following your README so we can start tracking and reporting it :)

[pranaygp]

you can copy the jazz example from manifest where we also only list it rn but don't have a CI env setup yet for it - preview

[pranaygp]

Apologies for the late response here. We've been sprinting towards cutting a stable release and going GA

[pranaygp]

btw @ataylorme I was reading through your readme and noticed this. haven't read the code yet, but the DO based implementation is really neat

without reading through the code yet, wondering if you've addressed atomic writes to the DO and the global sqlite? for example - with hooks, you'd need the global state in sqlite to be consistent with the DO's local event log. to enforce hook token uniqueness, for instance. at a minimum, D1 needs to be consulted/updated before the event log is updated in DO. you still run into issues with atomicity incase the sqlite update (ex: to register a hook) succeeds but the DO event log write (hook_created event) fails to write - then you're in a bad state

not a blocker to ship this but just curious

[ataylorme]

btw @ataylorme I was reading through your readme and noticed this. haven't read the code yet, but the DO based implementation is really neat

without reading through the code yet, wondering if you've addressed atomic writes to the DO and the global sqlite? for example - with hooks, you'd need the global state in sqlite to be consistent with the DO's local event log. to enforce hook token uniqueness, for instance. at a minimum, D1 needs to be consulted/updated before the event log is updated in DO. you still run into issues with atomicity incase the sqlite update (ex: to register a hook) succeeds but the DO event log write (hook_created event) fails to write - then you're in a bad state

not a blocker to ship this but just curious

I am going to rethink the approach with durable object facets.