A committed company switch now refetches the conversations list

Board row bug-on-dashboard-and-conversations-…-does-not-refetch-the-page-body. Sections 1 and 2 establish that the two companies genuinely differ in the place section 3 asserts; section 3 is the soft switch. Captured as a platform_admin — the fleet viewer whose building filter a staff-branch bug made invisible to any non-staff capture.

17 Sept 2026 · branch refetch-on-switch-p1 · captured against propflow-stage · at b309ed6187

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 · JPCO, hard load — the company whose figure section 3 asserts

JPCO's conversations list on a plain hard load. Every row's PROPERTY cell reads Camellia Alexis, one of JPCO's two buildings.

Asserted in the captured DOMCamellia Alexis · PROPERTY. A JPCO building, rendered under the PROPERTY column header — label-bearing, and exclusive to JPCO's roster. NOT a bare number: the row's own acceptance records that /api/leasing/stats reports activeLeadsInWindow 53 for BOTH companies, so a bare figure would pass on either page.

1 · JPCO, hard load — the company whose figure section 3 asserts

2 · 2 · Fairhaven, hard load — the SAME place, a different answer

The other company, same route, same viewer. Fairhaven's list is empty — so Camellia Alexis appears nowhere on it.

Asserted in the captured DOMNo conversations found.. This is the differ-proof, and it is why section 3's assertions discriminate: Fairhaven renders NO rows and therefore no PROPERTY cell at all, while JPCO renders Camellia Alexis on every row. The two companies answer differently in exactly the place section 3 reads.

2 · Fairhaven, hard load — the SAME place, a different answer

3 · 3 · SOFT SWITCH Fairhaven -> JPCO, no page load — REQUIREMENT MET

The switch is driven through the rail's own picker — tick JPCO, untick Fairhaven, close to commit. The address changes and no document is loaded.

The body follows. The empty state is gone and JPCO's rows render, each naming Camellia Alexis under PROPERTY. The picker actions abort the run if the listbox never opens, so a section that reaches the shot is one where the control really was driven.

Asserted in the captured DOMCamellia Alexis · PROPERTY. Starts on Fairhaven's EMPTY list, ticks JPCO on and Fairhaven off, closes to commit — no document load. JPCO's building then renders under the PROPERTY header. The previous company's contrasting value is proven absent by the same frame: 'No conversations found.' was the whole body in section 2 and the waitFor above proves it was on screen here before the switch, and the rows that replaced it cannot coexist with it. Before this change the list did not follow the switch at all: 40 of 40 samples over 120 seconds, evidence/ui-s-d-selection-parity.json section 12.

3 · SOFT SWITCH Fairhaven -> JPCO, no page load — REQUIREMENT MET

What this proves, and what it does not

The bar. The board row asks for a rendered-page capture showing, after a committed switch with no page load, at least one label-bearing figure belonging to the NEWLY selected company, with the previous company's contrasting value proven absent — and it warns that both companies' values must genuinely differ in the asserted place, because the capture that found this defect recorded /api/leasing/stats reporting activeLeadsInWindow 53 for BOTH companies.

Why these strings and not a count. Camellia Alexis is a building on JPCO's roster and no one else's, rendered under the PROPERTY column header — so it carries its own label and cannot pass on the other company's page. Sections 1 and 2 are the differ-proof, executed rather than asserted: the same route and the same viewer render Camellia Alexis on every JPCO row and No conversations found. for Fairhaven, which has no such building. The bare {filtered} of {total} count was deliberately NOT asserted — it is exactly the vacuous shape the row warns about.

The previous company's value is absent from the same frame. Section 3 begins on Fairhaven, and its waitFor on No conversations found. proves that empty state was on screen before the picker was touched. After the commit the frame carries JPCO's rows and the empty state is gone — the two cannot coexist, because the empty state renders only when the table has no rows.

What it does not prove. This capture covers /conversations only. The /dashboard half of the same board row is NOT measured here and remains open.

Captured as smoke@propflowai.co, an active platform_admin — deliberately, because a fleet viewer is the population that a staff-branch defect in this change's own narrowing rule made invisible to any non-staff capture. Data source propflow-stage, anonymized by construction (ADR-0097/0110): the +1 (000) numbers are the sanctioned impossible-NPA convention, which is why the contact scan passes on a page that is a list of contacts.

PropFlow Docs