Opened on a Settings page, search starts with a removable @settings tag; picking a setting opens its page with that row lit up.
24 Sept 2026 · branch sr-search-settings-p1 · captured against propflow-stage · at 56c0b04f43
Data note. Every name and balance below comes from propflow-stage, which is anonymized by construction (ADR-0097/0110 — phones in the impossible +1000 NPA, emails @example.test). The identical capture against prod would carry real tenants' names and balances and is not safe to attach anywhere, which is why the generator refuses to run against one.
Opened the global search from the Profile page. Because this is a Settings page, the box starts with a removable @settings tag and reads Search settings…: only settings are searched, and nothing is fetched. Typed your phone: the hit sits in the Settings group, names its card (Profile) and carries the page chip.
Asserted in the captured DOM — @settings · Settings · Your phone · Profile · Searching settings only. The tag, the Settings group, the setting's label, its page chip and the scoped footer are all in the captured palette.
Same search, then Enter. The palette closes, the page opens at #profile-phone, waits for the row to render (the page paints a loading ghost first), scrolls it into view and draws a soft accent ring around the Phone field for about two seconds. The capture waits for the highlight attribute, so this picture only exists if the row was actually found.
Asserted in the captured DOM — Phone. The run waits on the highlight attribute before shooting, so a row that was never found aborts the capture instead of publishing a plain page.
Same page, then Backspace in the empty box: the tag is gone, the placeholder is back to Find anything, and the normal Jump-to pages (Dashboard first) show again.
Asserted in the captured DOM — Dashboard · Search across pages, sections, and your data. The unscoped header and footer only render once the tag is removed.