The header and the figures name the same company
Board row bug-the-company-label-and-the-figures-under-it-can-name-different-companies-after-a-switch. PR #9058's capture found the defect on this exact surface and titled its section "the numbers follow, the company's name does not". Re-shot on the fix. EVERY section asserts the company's name AND a per-company FIGURE in the same captured DOM — the counts differ between the two companies, so a section cannot pass on the name alone.
17 Sept 2026 · branch label-names-the-committed-company · captured against propflow-stage · at 8f712a46dd
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 · The control — a hard load at JPCO
The baseline both halves of the bar are measured against. On a hard load the server mints the selection for this very address, so the header and the figures have never been able to disagree here — which is exactly why this section is a control and not evidence. It is here to show the instrument can read both names at all.
Asserted in the captured DOM — JPCO · 83 prospects. The company in the rail's corner AND its own prospect count. The count is what makes this a control rather than decoration: it is a different number from the other company's, so section 3 cannot pass on the name alone. THE COUNT'S SOURCE: it was read off this very page in a probe run before this spec asserted it — JPCO 83, Fairhaven Residential 53, both in the default "Last 60 days" window the page opens on. It is the page's own figure at capture time, not a target number; the generator refuses to render a section whose asserted strings are not in the DOM, so a hopeful count would abort this run rather than ship a wrong picture.
2 · 2 · The other company — a hard load at Fairhaven Residential
The second control, and the one that proves the two companies are actually distinguishable on this page — a soft-switch capture between two surfaces that looked the same would prove nothing.
Asserted in the captured DOM — Fairhaven Residential · 53 prospects. A different company in the corner, and a DIFFERENT count beneath it — the pair the switch has to move together. 53 against section 1's 83 is what makes the two companies distinguishable on this surface at all. THE COUNT'S SOURCE: it was read off this very page in a probe run before this spec asserted it — JPCO 83, Fairhaven Residential 53, both in the default "Last 60 days" window the page opens on. It is the page's own figure at capture time, not a target number; the generator refuses to render a section whose asserted strings are not in the DOM, so a hopeful count would abort this run rather than ship a wrong picture.
3 · 3 · THE SOFT SWITCH — the half PR #9058 could not meet
Arrive at JPCO, open the corner, tick Fairhaven Residential, untick JPCO, close the panel. Closing is the commit — one router.push to the same pathname. Next reuses the matched layout segment, so mintSelection() is not called again and the provider used to keep the company the server minted at mount while the page segment re-rendered against the new address. That is PR #9058's section 3: the numbers follow, the company's name does not. The header now re-derives the committed selection from the address over the server's grants, so it moves with them. The assertion carries the count as well as the name, because a heading that reads the same for both companies could never show a figure moving.
Asserted in the captured DOM — Fairhaven Residential · 53 prospects. ⚠️ THE BAR. The company's name and ITS count, both in one captured DOM after the switch, with the count that belongs to the company now named above it. ⚠️ WHAT THIS ARTIFACT DOES AND DOES NOT PROVE, stated plainly: the BEFORE state is PR #9058's published capture of this same route, whose section 3 is titled "the numbers follow, the company's name does not". This run was NOT executed against the unfixed head, so it is not itself a before/after pair — the red-before evidence for the mechanism is the jsdom suite's mutation controls, where removing the address-derived selection turns the soft-switch arm red. This capture proves the AFTER state on the real page: the name and its own number agree on screen, which is the half a payload assertion cannot reach.
4 · 4 · …and the hard load that follows it agrees
The second half of the row's bar, stated separately because it is a separate claim: a reader who switches and then reloads must land on the same sentence they were already reading. The address the switch produced is the address this section loads, so section 3 and section 4 are the same selection reached two ways.
Asserted in the captured DOM — Fairhaven Residential · 53 prospects. The same name-and-count pair as section 3, arrived at by a full page load instead of a switch — the row's second half, that a reader who switches and then reloads keeps reading the same sentence.
What the two instruments each proved
The jsdom suite drove the mechanism both ways and found TWO causes pointing opposite directions — a proposal without a commit moved the label alone (header Fairhaven, figures JPCO), and a proposal WITH a commit moved the figures alone (header JPCO, figures Fairhaven). Only the second is durable, and only the second is what a person sees. These captures are the second one, on the real page, because the defect lives between the props and the pixels and a test asserting the right props were passed cannot reach it.