The collections and properties lists follow the company selection
One browser tab, four stops on stage: Properties under one company shows that company's buildings; the next bare Collections page remembers it; switching to a second company moves both lists.
22 Sept 2026 · branch fix/collections-org-scope · captured against propflow-stage · at 3c407d8cb1+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 · 1 · Properties, one company picked — that company's buildings and no other
Arriving on /properties with Fairhaven Residential (TEST) picked. Before this change the grid read every company's buildings off one estate-wide query whatever the picker said — Gera: "why do properties show properties from other orgs?" Now the SSR seed and GET /api/properties both mint the selection and intersect its building set into the property ∩ org chain, so the roster on screen is Fairhaven's ten buildings and the four child reads (units, work orders, conversations, leases) address only those partitions.
Asserted in the captured DOM — Properties · Fairhaven Residential (TEST) · August Court · Brightwater Flats · Copperline Commons. The switcher names the picked company and the grid carries its buildings. No JPCO or Wei Slope building is on this page — read the grid.
2 · 2 · Collections, bare address — the remembered company, not the estate
The same tab loads bare /collections. The cookie stop 1 wrote answers the selection, the seed mints it, and the island's poll carries org=… on its URL. Before this change this page scoped on role grants plus the legacy single-building cookie and never read the company at all — a platform viewer with one company picked was shown every company's past-due residents (Gera: "why do i see camelia when i have western for org on delinquency?"). Every row and the KPI total above the table now belong to the picked company; a company with nobody past due renders its honest empty state.
Asserted in the captured DOM — Collections · Fairhaven Residential (TEST). The switcher still names Fairhaven on a bare address, and the page is that company's.
3 · 3 · Switch to a second company — Properties follows the pick
Open the switcher, tick JPCO, untick Fairhaven, close. The commit reaches the cookie, the provider refreshes the layout, and the grid re-reads under the new company: JPCO's two buildings replace Fairhaven's ten. The island's cache key already carried the selection; what changed is that the route it polls now honours it.
Asserted in the captured DOM — Properties · JPCO · Juniper Whitaker · Camellia Alexis. After an in-app pick, the grid is the second company's roster.
4 · 4 · Collections under the second company
Bare /collections again, now under JPCO. Same page, different company, different rows — the seed and the poll resolve one scope, so the first paint and the refreshed payload agree. The "pick one company" empty state this PR adds is NOT what an all-companies viewer sees: it appears only when two or more companies are ticked at once, which the route refuses by name rather than unioning.
Asserted in the captured DOM — Collections · JPCO. The switcher names JPCO and the page is that company's.
What this capture cannot show, and what pins it
A screenshot cannot prove which DynamoDB partitions were read, only what was rendered. The read bound is pinned in the unit suite: api/collections/__tests__/route.selection.test.ts and api/properties/__tests__/route.selection.test.ts assert, for a platform caller, which building ids reached the per-building readers under a selection cookie (the other company's never do), and collections-and-properties-ssr-seed-carry-the-selection.test.tsx pins the argument each seed hands its loader. There is no before section here: it would need a second dev server on main, and the before is the defect these two founder reports describe.