The transfer player's waveform opened at zero width
It was expanding all along — the seek track was 0px. And on Gera's follow-up, the divider's control now takes the lane in both states, like the call card above it.
9 Sept 2026 · branch fix/transfer-player-waveform-width · captured against propflow-stage · at 7e074355ff+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 · Idle: the control spans the lane, like its twin at the top of the thread
The transfer divider sits directly above the first post-transfer bubble — here, "Hi, y'all. Good afternoon…" — and carries the player for the human leg of the call. Above it, at the top of the same thread, the call card carries the Clara leg and the After-transfer leg.
Those two were shaped differently until this PR. ThreadEventCard is w-full flex flex-col, so the card's pills always spanned the lane; the divider's wrapper is flex flex-col items-center, so its pill was sized to its own text. Gera: "make the divider pill full-lane too." Measured on this page: the divider's control is 404px, the dock's content lane.
fill is opt-in rather than the new default, because both shapes are legitimate — the agent-trace viewer puts this same pill in a flex-wrap row beside a "Caller & property manager" badge, and a lane-wide pill there shoves the badge onto its own line.
Asserted in the captured DOM — Listen to transfer · TRANSFERRED TO PROPERTY TEAM. The pill and the divider it belongs to, both in the captured frame — so the picture really shows the transfer divider rather than some other player on the thread.
2 · Expanded: the progress bar Gera could not see
The bug, in his words: "I don't see the voice kind of sound progress bar thing on the one floating above this… when you click play, it should expand so you can see the progress bar." It was expanding. The seek track was 0px wide.
The waveform's only children are position: absolute (the bars, the position thumb), so its intrinsic contribution is zero. With flex: 1 1 0% that is harmless in a host that stretches the player and fatal in one that sizes it by its contents — and both shrink-to-fit hosts that ship (this divider, and the agent-trace row) opened the player as a play glyph, a speed chip, and nothing between them.
Measured on this page after the fix: the expanded player is 404px — the same width as the idle pill, so pressing play does not move the control — and the seek track inside it is 249px, where the bug drew 0px. The bars in it are the flat neutral field, not a decoded waveform — see the closing note; the claim under review is the track's WIDTH. The width: TRACK_FLOOR_PX[variant] floor is what makes it non-zero in a fit-content host; here the host is lane-wide, so the track takes the room and the floor never binds.
Asserted in the captured DOM — TRANSFERRED TO PROPERTY TEAM · 1×. The divider's own pill, and the expanded player's speed chip — which exists only once the player has left the idle pill. Its presence in the frame is what proves the capture caught the expanded state rather than the pill.
What the browser adds to the measurement
The PR carries a static cross-browser reproduction of both container shapes — chromium, firefox and webkit agreeing that the track is 0px in a shrink-to-fit host and unchanged at every stretched width. That harness earned its keep twice: it rejected the first candidate fix (a min-width floor that overflowed a 300px dock rail by 30px) and it caught my own mis-modelling (the first run double-counted padding because I had not set border-box).
What it could not show is the control in its real host, against its real neighbours. That is what these two captures are, and the numbers agree with the model: 404px in both states, a 249px seek track, no width jump on play.
More on that second shot: the bars are the flat neutral field, not a decoded waveform. Peak decoding is lazy — the player fetches and decodes the file only once it is actually playing, and until the peaks land it deliberately draws a shape nobody measured rather than a decorative one that would read as data. The capture catches that window. The claim under review is the track's WIDTH, which is what these shots show.
Captured against propflow-stage — anonymized by construction (ADR-0097/0110), which is why the names and the +1 (000) phone numbers here are not real people.