0.4.3

Fixed

• Hovering a captured web page offers the element under your cursor again, not the page's own layout containers (#134)
• manifest.schema.json said its semantics stopped at format 0.6.0 while packs were already declaring 0.8.0

Added

• Every capture records how long it took to reach a usable editor — the pixels frozen, the pack durable, the editor painted — so a slow capture can be diagnosed instead of guessed at

Improved

• capture-e2e, the CI job that records a real capture and asserts on the pack, is now required rather than advisory. It went red inside a green run once already

---

The picking fix, in one paragraph. On a captured browser window, object picking had begun answering most hover points with a wrapper — a section, a nav, a div holding a chat log — instead of the thing you were pointing at. Measured on a real capture: 94.5% of hover points, with a median offered rectangle covering 32.22% of the frame where a healthy capture sits under 0.4%. The cause was a premise that quietly stopped being true: an exemption written for one element a human had explicitly picked started applying to every element of the whole page once a still began recording the entire visible document. Containers are now judged by the same rule as any other enumerated rectangle and are offered one rung back; an element you actually pick still wins. Nothing is lost — the page is still recorded in full, and a container remains reachable on the refinement rung.

The Windows installer is unsigned, so SmartScreen may warn on first run. SHA256SUMS.txt is published beside it for manual verification, and electron-updater verifies the sha512 in latest.yml.

Full detail: CHANGELOG.md