Problem
SSI resolves a canonical WordPress site plan in Static_Site_Importer_WordPress_Site_Plan_Materializer::prepare(), but provider lifecycle preflight later validates canonical binding manifests against the resolved page projection. Canonical search_block_markup retains destination-independent asset tokens while resolved page markup contains runtime theme_uri URLs, causing a deterministic static_site_importer_runtime_binding_cardinality_mismatch.
Canonical fixture 20-switchback-woocommerce-extra-hard reaches this boundary after dependency and provider setup with Blocks Engine PR #825, which exposes resolved bindings in prepared[resolved][runtime_declarations]. SSI still derives lifecycle manifests from the canonical declaration set. The failed receipt has zero pages; missing-front-page/editor/visual findings are downstream. Fixture bytes must remain unchanged.
Owning Path
includes/class-static-site-importer-wordpress-site-plan-materializer.php: prepares the resolved plan.includes/class-static-site-importer-theme-generator.php: validates canonical lifecycle manifests against prepared[resolved].
Acceptance
- Provider lifecycle binding manifests used for runtime preflight/materialization come from resolved runtime declarations, or canonical anchors are resolved through the identical resolver context first.
- Canonical destination-independent declarations remain immutable and auditable.
- Runtime binding cardinality validates against the exact resolved page markup consumed by materialization.
- Mixed plans without provider bindings retain current behavior.
- Contract coverage reproduces canonical token versus runtime URL anchors and fails before the fix.
- Fixture 20 imports, configures its front page, and passes editor binding validation without fixture changes.
Evidence
Exact runtime output: /var/folders/lr/c_cmmt7s0592m4njz99v5yb40000gn/T/opencode/ssi-exact-candidates-final/fixture-20/wp-codebox-output-batch-001.json.
AI assistance
OpenAI gpt-5.6-sol via OpenCode and general OpenCode subagents compared direct runtime evidence with Blocks Engine producer projections and isolated SSI's canonical/resolved lifecycle split. Chris Huber directed the investigation and remains responsible for the issue and resulting change.
Problem
SSI resolves a canonical WordPress site plan in
Static_Site_Importer_WordPress_Site_Plan_Materializer::prepare(), but provider lifecycle preflight later validates canonical binding manifests against the resolved page projection. Canonicalsearch_block_markupretains destination-independent asset tokens while resolved page markup contains runtimetheme_uriURLs, causing a deterministicstatic_site_importer_runtime_binding_cardinality_mismatch.Canonical fixture
20-switchback-woocommerce-extra-hardreaches this boundary after dependency and provider setup with Blocks Engine PR #825, which exposes resolved bindings inprepared[resolved][runtime_declarations]. SSI still derives lifecycle manifests from the canonical declaration set. The failed receipt has zero pages; missing-front-page/editor/visual findings are downstream. Fixture bytes must remain unchanged.Owning Path
includes/class-static-site-importer-wordpress-site-plan-materializer.php: prepares the resolved plan.includes/class-static-site-importer-theme-generator.php: validates canonical lifecycle manifests againstprepared[resolved].Acceptance
Evidence
Exact runtime output:
/var/folders/lr/c_cmmt7s0592m4njz99v5yb40000gn/T/opencode/ssi-exact-candidates-final/fixture-20/wp-codebox-output-batch-001.json.AI assistance
OpenAI gpt-5.6-sol via OpenCode and general OpenCode subagents compared direct runtime evidence with Blocks Engine producer projections and isolated SSI's canonical/resolved lifecycle split. Chris Huber directed the investigation and remains responsible for the issue and resulting change.