The building filter follows the company selection
Four stops on stage, one stale building cookie: under one company the picker offers that company's buildings and names none of another's; under every company the same cookie is honoured; Settings → Property refuses to open the other company's building.
23 Sept 2026 · branch fix/picker-follows-selection · captured against propflow-stage · at 98e7498f2f
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 · 1 · One company picked, a stale cookie naming ANOTHER company's building — the picker lists this company only
Fairhaven Residential (TEST) is picked in the rail. The legacy building cookie still names Camellia Alexis — a JPCO building — the way it does after any company switch, because nothing rewrites it. Before this change the trigger read that JPCO building under Fairhaven's name and the list offered every company's buildings (Gera: "I'm currently in Western Slope and I see Camellia Apartments as a drop down"). Now the provider hands every consumer the cookie narrowed to the selection: the trigger reads All Properties, the rows are Fairhaven's buildings, and the count under All Properties is Fairhaven's — read it here and compare it with stop 2.
Asserted in the captured DOM — Fairhaven Residential (TEST) · All Properties · August Court · Brightwater Flats. The rail names Fairhaven, the open picker lists Fairhaven's buildings. No JPCO building is on the trigger or in the list — read the frame.
2 · 2 · Every company — the same cookie IS honoured, and the list is the whole estate
The same browser state on the fleet address (org=*). Fleet means every building the viewer can see, so the cookie's JPCO building is a legitimate pick here: the trigger names Camellia Alexis and the list holds every company's buildings, Fairhaven's ten among them. The All Properties count is the estate's, and the spec refuses to publish unless it differs from stop 1's — that relation, not a pinned number, is the claim.
Asserted in the captured DOM — Every company · Camellia Alexis · All Properties. Under every company the JPCO building is on the trigger and the whole estate is on offer — the count under All Properties is the estate's, refused unless it differs from stop 1's.
3 · 3 · Settings → Property under Fairhaven with the JPCO cookie — the prompt, never the other company's editor
The chrome audit's S1. This page resolves the building it EDITS off the same hook, and before this change it opened Camellia Alexis — JPCO's building — for editing under Fairhaven's name; every save was a write to the other company. It now reads the narrowed value, sees no building picked, and shows its one-target prompt. The sentence is the "choose one in the picker" one, because Fairhaven does have buildings to choose from — not the "no building on this account" one.
Asserted in the captured DOM — Fairhaven Residential (TEST) · Pick a property · Choose one in the property picker. The prompt, under Fairhaven, with the JPCO cookie still set.
4 · 4 · Control — Settings → Property under Fairhaven with a FAIRHAVEN building in the cookie opens that building
The non-vacuity control for stop 3: the same page, the same company, and a cookie naming one of Fairhaven's own buildings (August Court). The narrowing keeps it — the trigger names it and the page is that building's settings — so stop 3's prompt is the selection refusing a foreign building, not the page refusing every building.
Asserted in the captured DOM — Fairhaven Residential (TEST) · August Court. A building inside the picked company is still picked and still edited.
What this capture cannot show, and what pins it
A screenshot shows what the picker offered and what the page opened; it cannot show which value every other consumer of the hook received. That is pinned in the unit suite: property-picker-follows-the-selection.dom.test.tsx (the rows, the count, the trigger, the one ticked row, a one-building selection), property-settings-never-edits-another-companys-building.dom.test.tsx (the write path), resolve-property-filter-follows-the-selection.test.ts (the server seed, including a sibling building under a one-building selection) and sidenav-properties-link-follows-the-selection.dom.test.tsx — each red on origin/main with the provider stashed. There is no before section: it would need a second dev server on main, and the before is the founder report these frames answer.