drakezhang ee620acf64 docs(skill): give probe-hover a decidable trigger condition ...

The previous wording asked the agent to notice when a page "looks like"
it hides content behind hover. That is not something an agent reading a
text tree can judge: hover-only content is invisible by definition, and
the marker that used to point at it came from the probing that is now off
by default.

Replaces it with a condition the agent can actually evaluate — an
expected control is missing and no [has-submenu] marker points at a
trigger — and places it on the escalation ladder ahead of get-html and
screenshot, which is where that dead end is currently reached.

Also documents [has-submenu]/[expanded] as the primary hover signal. It
comes from aria-haspopup in the accessibility tree, costs nothing, and is
unaffected by probing being off, so it covers menus that are marked up
correctly.

2026-09-02 10:59:18 +08:00

..

bsk-cli

docs(skill): give probe-hover a decidable trigger condition

2026-09-02 10:59:18 +08:00

bsk-protocol

perf(vom): make active hover probing opt-in on observe

2026-09-02 10:59:18 +08:00