The customer page's frame stays put across its tabs
The name, the ⋯ and the Overview | Paths row are mounted once; a tab switch swaps only the body.
30 Oct 2026 · branch feat/customer-tabs-layout · captured against propflow-stage · at de8a21c9522+local
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.
1 · Overview, on the branch
A TEST company (Fairhaven Residential (TEST)) on stage data. The name, the ⋯ and the tab row now come from the customer layout, above the body. Pixels match the old page: the frame uses the same classes DetailPage already used.
Asserted in the captured DOM — Fairhaven Residential (TEST) · Overview · Paths · Customer details
Sections 2–3
2 · Paths, on the branch
The same frame over the Paths body: the name, the ⋯ (now on both tabs) and the tab row. The header is identical on both tabs, so Paths' one-line rule moved from the header subtitle to the first line of the body. That a tab SWITCH keeps the header node and never blanks the name is proven by the committed check scripts/ui-capture/customer-tabs-frame-check.ts (same DOM node, 0 ms without the name on every switch), not by a still picture.
Asserted in the captured DOM — Fairhaven Residential (TEST) · Overview · Paths · One mode per path
3 · Paths on main (before)
The same page on main: each tab drew its own header, so a switch remounted the name and the tabs, and the name was blank until that tab's own read came back (1.4 to 15.9 s per switch on the dev server).
Asserted in the captured DOM — Fairhaven Residential (TEST) · Overview · Paths
