Drive Cloudflare runtime components from generic descriptors

[chubes4]

Problem

The Cloudflare runtime currently encodes its website importer dependency directly in TypeScript: source URL and digest, package-profile name, plugin root, bootstrap loader, ability name, extraction budgets, runtime artifact asset, result fields, and canonical wp-content exclusions all name Static Site Importer.

WP Codebox should know how to materialize and invoke declared runtime components, while a deployment profile chooses which importer provides a capability. The current coupling makes replacing or adding an importer require edits across the corpus generator, Worker, persistence policy, and tests.

This became visible while moving package composition upstream in Automattic/static-site-importer#721 and PR #722.

Target contract

• Define a generic content-addressed runtime archive component descriptor.
• A declarative component file owns source URL/version/digest, package profile, WordPress package root/bootstrap/load mode, named ability aliases, extraction budgets, and migration selectors.
• Corpus generation consumes descriptors generically and embeds the runtime portion in the generated artifact manifest.
• Worker materialization derives paths, loaders, limits, and ability names from the validated descriptor.
• Canonical wp-content persistence excludes descriptor-declared runtime-owned paths without product-specific predicates.
• Runtime core and Cloudflare implementation contain no Static Site Importer names or paths.
• The deployment descriptor may select SSI through its public package profile and ability contract.

Acceptance criteria

• Generic validation rejects unsafe component IDs, package paths, plugin entrypoints, loader paths, ability maps, budgets, and source identities.
• The current website importer archive remains byte-identical during migration.
• Any future source archive without its declared package profile fails closed.
• Static artifact import still creates editable native-block pages with zero fallback, core/html, freeform, or invalid blocks.
• Complete Cloudflare tests, D1 dry-run, and D1 local end-to-end gate pass.
• No production deployment is required by this change.

Related

• Publish capability-scoped runtime package profiles static-site-importer#721
• Publish capability-scoped runtime package profiles static-site-importer#722
• Reduce Cloudflare SSI runtime memory #2013

AI assistance

• Model: OpenAI GPT-5.6 Sol
• Tool: OpenCode
• Used for: Traced the coupling, designed the generic descriptor boundary, and drafted this issue with Chris Huber.

[chubes4]

Implemented in #2013 at commit 733f6604.

The remaining SSI coupling is now confined to packages/runtime-cloudflare/components/website-importer.json, the declarative deployment choice. Generic contracts own:

• source digest and package-profile selection
• content-addressed artifact identity
• WordPress install/bootstrap paths
• named ability aliases
• extraction budgets
• runtime-owned wp-content exclusions
• Worker archive materialization and evidence fields

Runtime core, Worker source, corpus generator, provisioning script, and persistence policy contain no SSI names or paths.

Verification:

• npm run build
• npm run test:cloudflare-runtime
• npm run cloudflare:dry-run:d1
• npm run cloudflare:local-gate:d1
• descriptor-driven archive remained exactly 1,739,484 bytes with SHA-256 c5aa5c2ef67503ed94c7b249b2bf102630f279f985ece44245df83169fa75e27
• D1 import created two editable pages with zero fallback, core/html, freeform, or invalid blocks; publication, restart persistence, and two-site isolation passed

No deployment was performed.