Publish operations
Publishing has two phases: a tenant-local commit and asynchronous delivery. The content commit is authoritative and cannot be rolled back merely because a queue or plugin is temporarily unavailable.
Durable state machine
Each tenant workspace stores publish operations beside its documents. Immediate publication commits the typed draft to an immutable published version, creates an operation, and sends a small version-addressed event. Scheduled publication stores the expected draft version and uses the Durable Object alarm; if the draft changes before the alarm, the operation fails with a version conflict rather than publishing unreviewed changes.
Statuses are scheduled, queued, delivering, succeeded, superseded, failed, dead, and cancelled. Queue-send failures leave the publication committed and the operation visibly retryable. An older event becomes superseded when a newer version is already public; it must never overwrite the newer public index.
The management interface can schedule a draft up to 90 days ahead, cancel a still-scheduled operation, inspect attempts/errors, and explicitly retry failed/dead delivery. These effects require content.publish, same-origin protection, confirmation, idempotency, and audit through the shared command layer.
Queue delivery
The non-public tenant workspace Worker consumes wise-wig-publish-events. For the exact published version it:
- replaces the sanitized
PUBLIC_CONTENTrecord used by anonymous MCP; - deletes verified-domain root entries from the named public HTML cache; and
- invokes enabled sandbox plugin
content.afterPublishhooks through the isolated plugin service.
Each message is acknowledged individually. Failures use bounded exponential retry delays, five configured retries, and wise-wig-publish-dlq. The same Worker consumes the dead-letter queue and marks the durable operation dead; operators or authorized site owners can retry it. Delivery is idempotent because the event addresses an immutable version and index/cache writes are replacements/deletes.
The queue Worker has D1 only to enumerate verified hostnames, public-content KV, the tenant namespace, and the isolated plugin service. The anonymous public MCP Worker still receives none of those privileged bindings.
Host adapter boundary
The framework semantics are portable: commit a version, record an operation, enqueue an immutable event, deliver idempotently, and expose status. The Cloudflare adapter implements scheduling with Durable Object alarms, transport with Queues/DLQ, indexing with KV, and invalidation with Cache API. Another adapter may use a database job table, a conventional queue, or host cache purge API while preserving the same state machine.