dx: show asset dispatch in the Query Monitor panel #178

Context

#37's implementation is merged in #177 and present at main 15cac4c2. src/Infrastructure/ServiceBasedPlugin.php:1990-2105 dispatches assets and contains failures: debug rethrows, production skips that service's remaining assets for the enqueue point. It deliberately keeps asset delivery separate from the service's registration result (:1814-1821).

The optional panel displays registration history: src/Infrastructure/QueryMonitor/RegistrationOutputFactory.php:132-165, src/Infrastructure/Registration/RegistrationRecord.php:127-195 and views/query-monitor-registration.php. Query Monitor opt-in is in RegistrationPanel.php:96-107. A developer cannot currently use that panel to inspect an asset declaration or a production asset-loading failure. This supplies the driving scenario.

Out of scope

Changing the asset error boundary, making an asset failure undo registration, editor-content loading (#179), translations/localized data (#180), or implementing a new record/API before approval.

Scope and next deliverable

Prepare a design proposal for asset-dispatch diagnostics in Query Monitor. Compare extending RegistrationRecord with a separate asset record/report and explain the consequences of each for existing report consumers. Propose what information the panel should show, without assuming new public schema or visual styling is approved. Preserve the optional integration and disabled path from #38/#163.

Acceptance criteria

• Post the current registration/asset boundary and recording options, trade-offs, principle fit and recommendation.
• Specify which events are observable (declarations, no assets, successful dispatch, identical repeats, conflicts/failures and late catch-up), and what can actually be inferred at the Assets adapter boundary. Do not label a WordPress enqueue as proof of printed output.
• Describe panel content and its association with service, enqueue context and asset handle; identify any actual visual-design questions separately.
• Assess opt-in timing, disabled-path cost, failure reporting safety, custom Assets implementations, re-entrancy, and API/migration impact. Identify any breaking contract requiring a ruling.
• Include a test plan for enabled/disabled observation, both debug modes, late registration and unchanged registration state.
• Post the proposal, add needs: decision and remove agent-ready; wait for approval before implementation.

Verification

Review the cited implementation, tests/php/Unit/AssetLoadingTest.php, RegistrationRecordingTest.php and RegistrationPanelTest.php. The eventual change must pass composer test and composer lint in the supported CI environment. Proposal work changes no runtime code.

Impact on generated plugins

None during investigation. Existing RegistrationReport consumers must be assessed before changing records or constructor contracts. Add breaking if the chosen proposal changes a contract generated plugins rely on.

Priority p2: ordinary unscheduled observability work with a concrete failure-diagnosis scenario. The unsettled software design is the next deliverable, so agent-ready is for a proposal only.

Updated 2026-10-24: Completed the asset-diagnostics brief against merged #177, with proposal-only acceptance criteria and verification. Added p2 and agent-ready; no record schema, panel design or implementation was selected. Reviewed origin/main 15cac4c2.