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
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.
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-contentexclusions 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
wp-contentpersistence excludes descriptor-declared runtime-owned paths without product-specific predicates.Acceptance criteria
core/html, freeform, or invalid blocks.Related
AI assistance