DO NOT MERGE: ✨ Retain atomic workflow Workspaces

[taras]

Why

Workflow runs retain their filtered journal, but they do not yet retain the filesystem state that live durable effects observe and publish. Issue #365 establishes that provider-level Workspace foundation while preserving the transaction and secret-gate contracts merged in #374.

Closes #365.

What changes

Before:

A WorkflowRun database owns definitions and filtered journal events. Workspace mutations, immutable filesystem roots, and the journal event that observes a root do not share one provider-owned atomic boundary.

After:

Each WorkflowRun path owns one authoritative SQLite connection, Cloudflare DOFS wrapper, Workspace filesystem, cooperative connection queue, and savepoint allocator. A live Workspace effect mutates the filesystem, publishes or reuses a canonical immutable root, passes its protocol result through the existing secret gate, and appends the rooted journal event in one caller-owned transaction.

Complete schema version 1 includes the pinned DOFS schema, immutable root manifests and exact manifest/blob reachability references, the current-root singleton, and a non-null root reference on every journal event. Existing or partial databases are validation-only and corruption is left unchanged.

How it works

live durable effect
  → WorkflowRun transaction
  → operation savepoint and Workspace mutation
  → canonical root retention/current-root update
  → existing secret gate
  → guarded transaction-local journal route
  → journal append and commit

Known provider-domain failures roll back the operation savepoint, retain the previous root, and publish one failed protocol result. Infrastructure, corruption, routing, filtering, serialization, journal insertion, and cancellation failures roll back the outer transaction and publish nothing.

Review guide

Start with: packages/workflow/tests/workspace-filesystem.test.ts

Then review:

1. packages/durable-streams/live-coordinator.ts and the provider-neutral Workspace API
2. packages/workflow/src/deno/database.ts, connections.ts, and savepoints.ts
3. packages/workflow/src/deno/workspace/root.ts and schema.ts
4. packages/workflow/src/deno/journal-route.ts and the secret-gated publication path
5. Vendored DOFS provenance, manifest, verifier, and specification changes

Look carefully at:

• savepoint teardown ordering, stale/foreign route fences, strict schema recognition, canonical root identity, retained blob reachability, and rollback behavior around failed or cancelled publication

What must stay true

• One serialized connection turn owns each WorkflowRun top-level transaction — enforced by the provider registry and cooperative queue, checked by same-run concurrency tests.
• DOFS and the journal use the exact same physical connection and caller-owned transaction — enforced by the shared storage adapter and savepoint allocator.
• Secret filtering precedes transaction-local journal routing — enforced by the existing guarded journal and explicit one-use destination.
• A failed or cancelled outer transaction exposes no filesystem, root, pointer, or event changes — checked by insertion/gate/cancellation tests and the real SIGKILL restart harness.
• Retained roots are immutable, content addressed, complete, and restorable — checked by deterministic identity, historical materialization, topology, metadata, symlink, hardlink, and retained-byte tests.
• Existing or partial databases are never repaired — checked by byte-for-byte corruption and intermediate-Store WorkflowRuns and filtered journals in SQLite #291 rejection tests.
• Shared production APIs remain provider and runtime neutral — checked by Deno and Node type boundaries and the cross-runtime coordinator regression suite.
• DOFS garbage collection remains unavailable in this foundation.

How to verify it

• deno task vendor:verify proves every pinned upstream/generated file matches its recorded SHA-256 and rejects missing, extra, changed, or regenerated drift.
• deno task lint verifies repository lint and formatting rules.
• deno task check verifies the complete Deno workspace type graph.
• deno task test runs 401 tests / 2,736 steps, including atomic Workspace, corruption, restoration, restart, and SIGKILL coverage.
• deno task check:jsr completes the JSR publish dry run.
• deno task verify passes all nine applicable commands concurrently under the repository-pinned Node 22 toolchain and confirms the tracked tree is unchanged.

Scope

Included

• Provider-owned authoritative Workspace storage
• Complete XMD/DOFS schema version 1
• Canonical immutable Workspace root format 1
• Exact retained DOFS manifest/blob references
• Private root restoration
• Shared synchronous and operation savepoints
• Provider-neutral live durable coordinator
• Explicit guarded journal routing
• Atomic Workspace effect publication and failure/cancellation/crash coverage
• Architecture and specification updates

Intentionally unchanged

• Public workflow start/resume
• <File>
• Public history or fork commands
• Worker Shell, Git/Repository effects, FUSE, native subprocess execution, and workerd
• Root deletion or root-aware garbage collection
• Secret policy
• Evidence PRs 🔬 Spike: host Cloudflare DOFS directly in Deno with SQLite (#349) #350 and 🔬 Spike: make Worker Shell effects transactional (#357) #362

New abstractions

• LiveDurableEffectCoordinator lets a provider wrap only live execution and publication while replay remains unchanged.
• Workspace exposes the provider-neutral retained-effect foundation without leaking SQLite, DOFS, or runtime types.
• The connection registry and savepoint allocator centralize the one-connection and nested-transaction invariants.
• Each new abstraction has multiple concrete uses or a clear justification.
• No speculative functionality is included.

New dependencies

• Package: zod ^4.3.6 in @executablemd/workflow
• Used for: strict canonical Workspace root-manifest parsing and corruption recognition
• Why existing dependencies are insufficient: the workflow package now owns a persisted structural format that requires runtime validation at the storage boundary

Generated or mechanical changes

• packages/workflow/vendor/cloudflare-computer-dofs/upstream is the byte-identical required source closure from Cloudflare Computer commit 63d363632e558f7e077794988d36ed75017c2a62.
• packages/workflow/vendor/cloudflare-computer-dofs/generated is the deterministic TypeScript 5.9.3 production output recorded by MANIFEST.json.
• The complete MIT notice and source provenance are in LICENSE and PROVENANCE.md.

Risks and limitations

• Intermediate metadata-only Store WorkflowRuns and filtered journals in SQLite #291 databases are unsupported pre-release artifacts and are refused without mutation; developers delete and recreate them.
• Every published root is retained because root-aware deletion and garbage collection belong to Add workflow inspection, cancellation, suspension, and deletion #367/Add versioned workflow history checkpoints and forks #368.
• This PR provides the provider-level foundation only; it does not expose public lifecycle or history commands.
• Recovery or rollback: expected domain failures restore the operation savepoint; all other publication failures roll back the outer transaction. SQLite recovery hides a process killed with an open transaction.

Scope confirmation

• Every changed file supports the purpose described above.
• Unrelated cleanup and formatting changes are excluded.
• Generated or mechanical changes are clearly identified.
• The description matches the final diff and test results.

[github-actions]

PR #387: ✨ Retain atomic workflow Workspaces

144 files, +11457 / -268

Scope

🔴 PR has 11725 lines changed. Split into focused PRs.

🟡 11725 lines changed. PRs under 400 receive more thorough review.

🟡 144 files changed. Are all changes related?

🟡 PR mixes config and source changes.

Structural

🟡 3 console statements.

Slop

✅ Slop indicators look low.

Static Analysis

✅ Oxlint found no issues.

Correctness

No extraneous code patterns detected.