Capturing a single-route app yields one screenshot of the boot view

[WomB0ComB0]

Overview

ui-capture discovers what to capture by crawling reachable internal routes. That works for a multi-page site, but it cannot capture a single-route application at all.

Concretely: a Three.js operator console served at one URL, whose interesting states — a spawn dialog, an environment dialog, a safety workspace, an editor workspace, a populated multi-domain fleet — exist only after interaction, and are not reachable by following links. Pointed at it today, ui-capture captures the boot view once and reports the site fully covered.

That is worse than capturing nothing, because the report looks like coverage.

Why the existing knobs don't cover it

--menu-selectors exists, but it feeds link discovery — it opens menus so more anchors become findable. It does not produce a capture of the opened state, and there is no way to say "click this, wait for that, then capture and call it spawn-dialog".

What I'd like to happen

A way to declare named states: short, declarative interaction scripts performed on a page before capture, so each state yields its own capture set alongside (or instead of) crawled routes.

Requirements that matter for it to be worth having:

• Declarative and serialisable steps, not arbitrary in-page JS. A capture tool points a browser at a URL someone supplied; an eval step would be unreviewable and unportable, and it would make the step engine untestable without a browser.
• Per-state failure. A state whose selector never appears should fail that state, record it in the report, and let the run continue — the same way a failing route already behaves.
• Determinism. Each state starts from a clean page load unless explicitly chained, so one state cannot silently depend on a previous one's leftovers.
• Backwards compatible. A run with no states declared must behave exactly as it does today.