The merged tenant read says which thread you clicked
one resident, one timeline, and a band on the thread you came in through
28 Aug 2026 · branch feat/conversation-thread-highlight · captured against propflow-stage · at e1db06e4ba
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 band, and the legend that names it
This is the whole point of the PR, and the thing no unit test can show: a resident with eight separate threads reads as one conversation, and the thread you actually clicked carries a tint so you can still tell where you came in. Gera, 2026-08-27: “people have several conversation items where it should just be one … whichever one we click is highlighted, kind of like the work order handyman is highlighted.”
The band is deliberately not colour alone — the pinned legend states it in words and counts it, so the tint is never the only carrier. That is the same rule the work-order reader’s own legend answers to.
Asserted in the captured DOM — The thread you opened · highlighted. The legend renders only when rows actually painted with the band — it cannot appear over an unbanded thread, which is what the anchor-band suite pins.
2 · View all conversations — same timeline, no band
The unhappy-state counterpart, and the one that proves the band is a distinction rather than decoration. “View all conversations” names no member thread, so there is nothing to single out and the reader renders the same merged timeline with no tint and no legend at all.
If this capture showed a band, the feature would be tinting rows for no reason — which is exactly the failure an earlier version of the count shipped, where the legend read “2 highlighted” over a transcript with zero tinted rows.
Asserted in the captured DOM — Conversation. Asserted on the reader's own chrome. The absence of the legend is the point of this section and is pinned by test ('says nothing when nothing is banded'); a capture can show it but not assert it.
3 · The same band at phone width
Narrow-viewport proof. This reader mounts with hideHeader, so the legend rides a slim pinned bar rather than the header — a path with its own test, because the header route is the one that is easy to check and the wrong one for the surface that actually ships.
Included because the batch this PR belongs to shipped a narrow-viewport regression past a green suite: jsdom performs no layout, so no viewport was ever exercised.
Asserted in the captured DOM — The thread you opened
What these captures do and do not prove
They prove the band paints, the legend names it, both survive a phone-width viewport, and the no-anchor case stays clean. They do not prove the colour is right for a colour-blind reader, and they are a single data source — a resident whose threads all came from one channel would look different.
Worth stating plainly, because this PR only exists in this shape after recon refuted the author’s own earlier estimate of it: the blast radius was posted to Slack as “widen highlightScope inside a ~2,000-line component.” It was one additive optional prop. The field the band reads was already stamped on every merged row.