One exchange, one band

Rendered evidence for PR #7482 — furniture and segment headers stop splitting the conversation highlight.

Captured 2026-09-09 from the branch’s own dev server (highlight-band-spans-furniture, commit 8a4683e) · fixture data only, no PMS read and no customer row

A merged person read anchored on one voice call painted as three tinted boxes. Every splitter was a row the thread injects between two rows of the same call — not a message from another one. It now paints as one.

The report

Gera, 2026-09-09, on /people/pers_4a21…/conversation?thread=conv_voice_2944…:

“This one has three highlights, though, but they’re all essentially the same, but they’re being blocked by like some components like listen to transfer or went to voicemail or the calendar like pill. … this could have been one big card background as compared to three.”

Before / after

origin/main — 3 boxes

Three separate tinted bands broken by the transfer divider and the email segment header

this branch — 1 box

One continuous tinted band spanning the whole exchange

Same fixture, same anchor, same viewport — only the two source files differ. The legend reads 6 highlighted on both sides: set membership did not move, only where the band is drawn.

What was splitting it

Two rungs, because the band is drawn at two: bandBridge buffers furniture inside a section body rather than closing the run, and coalesceBandedSections folds a run of wholly-highlighted sections above it. A real message from another call still breaks the run — it must, or the band would claim rows it is not about.

The border the first fix erased

The bot review caught the second half. .chat-section-header[data-sticky]::before paints a 12px rectangle directly above the header unconditionally, not only while stuck. Rebinding --chat-surface-bg to the band’s tint made it visible: at the band’s own 6px inset it overhung the box as a square-cornered tab, with the top border erased across the header’s width.

Top: the band's top border missing across its width. Bottom: the border continuous after the fix.
Band top edge. Top: colour rebind alone — only the corner arc survives. Bottom: after opening the band by the extension’s own height — border continuous, header with proper air above it.

Measured rather than eyeballed. Sampling the first non-ground pixel at the band’s top edge, at four x positions:

 first non-ground pixelreading
colour rebind alone(236,236,250)no border at all
after the geometry fix(201,198,246)the 22%-primary border

The stuck state still works

The extension exists to cover the scroller’s own top padding when the header pins — without it a bubble shows for those few pixels and is then chopped by a hard edge. Scrolled so the header sticks:

The segment header pinned at the top of the scroller, band tint continuous behind it
Header pinned at the scroller top, band tint continuous behind it, no chopped text and no pale strip — the rebound variable doing its job in the band’s own colour.

What deliberately did not change

PropFlow Docs