📦 Vendor pinned Cloudflare DOFS source

[taras]

Why

Issue #365 needs the pinned Cloudflare Computer DOFS source to be reviewable and reproducible before any XMD adapter or Workspace behavior depends on it. This is the first, dependency-free layer replacing the monolithic draft #387.

What changes

Before:

The repository did not retain or verify the required DOFS production subset.

After:

The repository contains the required DOFS source from Cloudflare Computer commit 63d363632e558f7e077794988d36ed75017c2a62, its complete MIT notice, deterministic generated JavaScript/declarations, provenance, and a SHA-256 inventory. Normal verification rejects missing, extra, changed, or unreproducible generated files without network access, and refuses regeneration when the installed TypeScript compiler does not match the manifest.

How it works

deno task verify → vendor:verify → inventory/digest check → compiler provenance check → deterministic TypeScript emission check

Review guide

Start with: packages/workflow/vendor/cloudflare-computer-dofs/PROVENANCE.md

Then review:

1. MANIFEST.json and the complete MIT LICENSE
2. scripts/verify-cloudflare-dofs.ts
3. scripts/tests/cloudflare-dofs-vendor.test.ts
4. Snapshot-specific verification, lint, typecheck, publish, and runtime-exclusion plumbing

Look carefully at:

• The verifier enumerates the exact snapshot and rejects all missing, extra, changed, generated-output, or compiler-provenance drift.
• Lint, format, and typecheck exemptions name only packages/workflow/vendor/cloudflare-computer-dofs; future vendor trees inherit no exemption.
• No production module imports the vendored snapshot in this layer.

What must stay true

• Upstream inputs remain byte-identical to the pinned commit — enforced by per-file SHA-256 entries and checked by deno task vendor:verify.
• Generated artifacts remain deterministic — enforced by no-network regeneration and byte comparison.
• Regeneration uses the compiler recorded in provenance — enforced by querying the exact installed tsc entrypoint used for emission before it runs.
• Mechanical vendor files do not acquire XMD adaptations — adapters remain outside this snapshot.
• Existing runtime behavior remains unchanged — there are no production imports or Workspace behavior in this PR.

How to verify it

• deno task vendor:verify proves the pinned 104-file inventory reproduces offline with TypeScript 5.9.3.
• scripts/tests/cloudflare-dofs-vendor.test.ts proves the unchanged snapshot regenerates successfully; compiler mismatch, changed source, changed generated output, missing files, and extra files are all refused.
• deno task verify passed all nine applicable commands and confirmed the tracked tree remained unchanged.
• deno task lint, deno task check, deno task test, and deno task check:jsr all pass; the Deno suite reports 400 tests / 2,732 steps with zero failures.
• git diff --check origin/main...HEAD passes.

Scope

Included

• Vendored upstream and deterministic generated DOFS files
• MIT license, provenance, enumerated manifest, and SHA-256 digests
• No-network drift and compiler-provenance verification with regression tests
• Snapshot-specific repository configuration and verification integration

Intentionally unchanged

• No production imports, DOFS adapter, schema initialization, retained roots, filesystem capability, or Workspace publication
• No public <File>, lifecycle, history/fork, Worker Shell, Git, FUSE, subprocess, workerd, GC, or secret-policy behavior
• Draft PR DO NOT MERGE: ✨ Retain atomic workflow Workspaces #387 remains open until the replacement stack is reviewed and Taras approves the transition
• This PR does not close Commit Workspace mutations and journal results atomically #365

Generated or mechanical changes

• upstream/** is the selected production source copied from Cloudflare Computer commit 63d363632e558f7e077794988d36ed75017c2a62.
• generated/** is deterministic TypeScript 5.9.3 compiler output from those pinned inputs.
• MANIFEST.json records every retained file and digest.

Risks and limitations

• This layer intentionally supplies no executable Workspace behavior; later dependent PRs introduce adapters and retained filesystem semantics.
• Recovery or rollback: remove this stack layer before any dependent layer is merged.

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 #389: 📦 Vendor pinned Cloudflare DOFS source

116 files, +8477 / -11

Scope

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

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

🟡 116 files changed. Are all changes related?

🟡 PR mixes config and source changes.

Structural

🟡 1 console statements.

Slop

✅ Slop indicators look low.

Static Analysis

✅ Oxlint found no issues.

Correctness

No extraneous code patterns detected.

[taras]

System/software architecture review

Verdict: APPROVE as stack layer 1. I found no architectural blocker in #389.

This is the correct first boundary for the #365 stack:

• It introduces the pinned implementation dependency without introducing Workspace behavior, changing a public language contract, or allowing Cloudflare types to cross the provider-neutral boundary.
• The dependency direction remains correct: shared workflow code does not import the snapshot; a later Deno host adapter may consume the generated modules behind contextual Workspace APIs.
• The snapshot is mechanically isolated. Upstream inputs stay byte-identical, XMD adaptations remain outside the vendor tree, and lint/format exemptions are scoped to this one immutable snapshot rather than establishing a general vendor exemption.
• Generated ESM and declarations are independently identified and reproduced offline before comparison.
• The normal verification battery owns drift detection, while the published workflow package contains the generated runtime closure and the required license/provenance material rather than the excluded upstream source tree.

I independently compared the snapshot with Cloudflare Computer commit 63d363632e558f7e077794988d36ed75017c2a62:

• all 34 selected upstream source files are byte-identical;
• the MIT license is byte-identical;
• the remaining differences are omissions described by the selection policy: tests, benchmarks, GC, FUSE/provider infrastructure, Worker/workerd paths, backends, and unused synchronization machinery;
• no hidden XMD patch is present.

One wording precision: the offline verifier proves that the checked-in snapshot has not drifted from its recorded inventory; it cannot independently prove that the initial bytes came from the named remote commit. That upstream provenance is established by this review-time comparison and then retained by Git plus the manifest. I recommend describing the SHA-256 inventory as enforcing post-capture byte identity, not as independently proving remote provenance. This is not a merge blocker.

The dependent stack layers must preserve these constraints:

1. Import the generated DOFS modules only from the Deno-host implementation boundary. Do not re-export Cloudflare, SQLite, SQL, or DOFS types through the shared workflow API.
2. Construct exactly one authoritative Cloudflare Database wrapper per WorkflowRun database and serialize local effects on it. The upstream path, blob, and write-buffer caches are keyed by that wrapper; multiple wrappers over one storage are incoherent.
3. Invoke Cloudflare schema initialization only while creating a pristine complete XMD schema-v1 database, inside the XMD-owned transaction/savepoint. Never use its IF NOT EXISTS behavior to repair or migrate an existing run database.
4. Treat DOFS revisions, tombstones, inode identities, caches, and synchronization metadata as mutable provider internals. Immutable Workspace-root identity must remain the XMD canonical logical snapshot defined by the architecture.
5. Keep GC disabled until root-aware retention/deletion exists; no later layer may import the omitted GC path as an incidental convenience.

With those constraints, #389 is a coherent, independently reviewable foundation for #391 rather than an early commitment of the provider-neutral model to Cloudflare internals.