A stale building cookie no longer outranks the tab you are looking at
The legacy per-building cookie is staged in every frame below — which is only possible because this PR taught the capture tool to stage cookies at all.
16 Sept 2026 · branch ui-db-d2-sliceB · captured against propflow-stage · at 565330ffd3
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 · The tab names two buildings, and the legacy cookie names one — the page answers for TWO
The viewer's legacy propflow-property-filter cookie holds one building, left over from an earlier visit. The tab's address names two. Under ruling fa4bc2124 the address wins, so the headline tiles and the ⋯ Split chart answer for the same two buildings — the clause ui-db-d0-r2-metric-semantics states as the selected scope is identical.
This frame could not have been taken before this PR. The tool could stage exactly one cookie — the auth session — so the state that produces this defect was unreachable from a spec.
Asserted in the captured DOM — Split by property · One line per property. The split control is present and per-property, in the state the screenshot shows.
2 · TAB A — the same shared cookie, this tab narrowed to the FIRST building
Two tabs, one browser profile, one shared legacy cookie — and two different selections. This is the ruling's own cost-if-wrong: clearing the shared cookie alone is not sufficient, it cannot guarantee independent tabs.
Asserted in the captured DOM — Occupancy
3 · TAB B — same cookie, same moment, narrowed to the SECOND building
A separate browser context, because cookies are a context property and these two tabs must be able to disagree. The capture tool keys its contexts on (server, cookie set), so the two sections above and below are genuinely two tabs rather than one tab visited twice — also new in this PR.
Asserted in the captured DOM — Occupancy
4 · CONTROL — no address at all: the legacy cookie is still honoured
The transitional path, unchanged and deliberately so (ui-s-a-r2-tab-local-selection: the cookie may be a validated legacy/default hint during transition). The address says nothing, so the cookie still answers — which is what makes this a precedence rule rather than the removal of a feature.
Asserted in the captured DOM — Occupancy
What is NOT here, and why
No BEFORE frame, and it is not available to take. The defect was fixed on main by #8834 and #8831 before this tooling existed, so a before would need a second dev server pinned to an older commit. Rather than stage one, the before-state is carried where it is provable: each of those PRs shipped a mutation control that reverts the code and records the red, and the drift guards name the exact pre-ruling spelling they forbid.
What these frames DO prove is the thing no test could: that the fixed behaviour survives a real browser, a real session and a real stale cookie — and that the capture tool can now stage the state and the second tab that this row's evidence has needed since it opened.