Expected editor presentation identities are collected only from inline styles

[chubes4]

Problem

wordpress.editor-open derives its expected editor presentation identity set only from inline editor styles. With bounded external stylesheet delivery the expected set is empty, so presentation can never be evaluated even when every generated stylesheet is loaded in the canvas.

captureExpectedEditorPresentationIdentities in packages/runtime-playground/src/editor-command-runners.ts builds the contract from:

$settings = get_block_editor_settings( ..., new WP_Block_Editor_Context( array( 'post' => $post ) ) );
foreach ( (array) ( $settings['styles'] ?? array() ) as $style ) {
  if ( ! is_array( $style ) || ! is_string( $style['css'] ?? null ) ) { continue; }
  preg_match_all( '/--blocks-engine-presentation:([a-f0-9]{64})/i', $style['css'], $matches );
}

Only inline styles[].css is inspected. An editor stylesheet delivered as a real enqueued asset contributes no expected identity, and the contract still returns complete: true.

Evidence

Automattic/blocks-engine#1478 run https://github.com/Automattic/blocks-engine/actions/runs/33513245334, using released WP Codebox v0.26.5 (which contains the observation-side repair from #2449 / #2451).

editor-summary.json for both solved fixtures:

expectedGeneratedPresentationIdentities: []
expectedGeneratedPresentationIdentitiesComplete: true
generatedPresentationIdentities: []

The editor canvas loaded the generated stylesheets in that same run, for example:

/themes/15-saas/assets/assets/css/engine-support-after-author-1ac9b32b18979682.css
/themes/15-saas/assets/assets/css/engine-support-before-author-12adefbaeb611d18.css
/themes/15-saas/assets/assets/css/wordpress-compat-cf0b049fb2d3214e.css

Downstream result: editor_presentation_status: not_evaluated, coverage_complete: false, and both solved fixtures fail acceptance as solved_regression despite frontend_visual_status: passed, editor_canvas_status: visible, and block_validity_status: valid.

Before v0.26.5 the same fixtures reported expected_identity_count: 6 with observed_identity_count: 0 (missing_styles). The observation side is now correct; the expectation side is what reports nothing.

Expected contract

Expectation and observation should be symmetric. #2451 taught observation to certify an identity from an external stylesheet URL whose canonical version is a 64-hex content hash. The expected-set contract should recognize the same delivery shape: an editor stylesheet registered for the editor whose version is a canonical 64-hex content hash declares that expected presentation identity.

This stays generic. It is a statement about content-hash-versioned editor stylesheets, not about any particular generator.

Acceptance

• Inline --blocks-engine-presentation:<sha256> markers continue to contribute expected identities.
• An editor stylesheet enqueued for the block editor whose version is a canonical 64-hex content hash contributes that expected identity.
• Non-hash versions and unrelated stylesheets contribute nothing, and the fail-closed complete semantics are unchanged.
• A run whose editor loads every generated stylesheet externally reports a complete expected set and full coverage rather than not_evaluated.
• Focused tests cover inline-only, external-only, mixed delivery, and non-hash versions.

AI assistance

OpenAI GPT-5.6 Sol via OpenCode analyzed the promotion evidence, traced the empty expected set to the inline-only contract query, and drafted this issue. Chris Huber directed and owns the work.

[chubes4]

Confirming this from the downstream side, and one design note for the symmetry.

I authored #2451 (the observation half) and then ran the full pin chain to verify it end to end: wp-codebox v0.26.5 released, SSI pin bumped in Automattic/static-site-importer#1482, and Automattic/blocks-engine#1478 moved onto that ref. The observation side behaves correctly, and the empty expected set is exactly what remains, as described here.

Useful control for whoever picks this up: under the same v3 contract and the same v0.26.5 runtime, blocks-engine trunk reports expected 6 / observed 6 and matched_rendering: passed on both solved fixtures, while #1478 reports expected 0 / observed 0. So the delta is purely the inline-versus-enqueued delivery shape, with the runtime held constant. Trunk evidence is in the gate run on Automattic/static-site-importer#1482; branch evidence in https://github.com/Automattic/blocks-engine/actions/runs/33513245334.

Design note on the acceptance criteria

Consider whether an expected identity should be certifiable from a stylesheet that is merely registered/enqueued versus one that actually loaded. My #2451 implementation credits an observed identity from any <link rel=stylesheet> present in the canvas, which counts a stylesheet whose request failed. That is fail-open in a narrow way: a broken asset URL still carries the right ?ver= hash.

If the expectation side is going to declare identities from enqueued styles, the pair is only meaningful if the observation side requires the stylesheet to have loaded. Otherwise a 404'd generated stylesheet reports as full coverage. Adding something like "a stylesheet that failed to load does not certify its identity" to the acceptance list would close that, and it is a small change to the observation helper rather than a new contract.

I am not taking this issue; flagging so the observation-side nuance travels with the expectation-side work.

---

AI assistance disclosure: Claude Sonnet 4.5 via opencode. The model authored #2451, executed the release and pin chain, and produced the trunk-versus-branch control above. Reviewed by me before posting.