infrastructure: assets for the content inside the block editor #179

Context

At main 15cac4c2, src/Infrastructure/Asset/AssetContext.php:69-96 defines four enqueue contexts and src/Infrastructure/ServiceBasedPlugin.php:1935-1987 hooks their actions. enqueue_block_editor_assets covers the editor interface; there is no editor-content context for enqueue_block_assets.

The #37 proposal explicitly deferred editor-content loading and its iframe registry handling because no scaffold sample needed it. #177 is merged; it is no longer a pending implementation prerequisite. That deferral does not itself establish a new sample requirement.

Out of scope

Changing the four existing contexts, a build pipeline, translations/localized data (#180), or adding a context before the driving scenario and design are agreed.

Scope and remaining use-case gap

Name one actual sample or downstream asset that must style block content inside the editor. State its source, front-end/editor requirements, applicable editor mode and why the four contexts are insufficient. A hypothetical block stylesheet is an example of the missing evidence, not an approved new sample.

After the scenario is supplied, the next deliverable is a design proposal for context/dispatch semantics and iframe registry handling, verified against the applicable WordPress source. It must compare options and assess duplicate/conflict handling and late registration. Software design itself does not require needs: design.

Acceptance criteria

• Record the concrete asset, owning service, loading contexts and observable desired behaviour.
• After that input, post options, trade-offs, principle fit and a recommendation, including registry swaps, idempotence and compatibility.
• Include a test plan using representative WordPress editor/registry behaviour and the existing asset suites.
• Obtain a maintainer ruling on the proposed API/behaviour before implementation; add breaking if the proposal alters generated-plugin contracts.

Verification

Review the cited source and #37's proposal/ruling. For an eventual implementation run composer test and composer lint, plus the editor-specific verification specified in the approved proposal. No editor loading is claimed or reproduced by this triage.

Impact on generated plugins

No current change. A new context may affect custom asset providers/adapters; assess that in the proposal.

Priority p3: deliberately parked capability expansion until a real editor-content asset drives it. Keep needs: use-case and leave agent-ready off.

Updated 2026-10-24: Added source anchors, scope, acceptance criteria, verification and impact; reconciled merged #177. Added p3 for deliberately parked expansion. Still needs an actual editor-content asset and its loading scenario. Reviewed origin/main 15cac4c2.