Action cards get the message menu: ⋯ over the top-right on hover, time bottom-right

Localhost preview against stage (synthetic caller at a test building), round 2 after Gera's notes: horizontal dots, shown on hover, allowed over the text, on a soft chip so they read. Every event card carries the same menu the message bubbles use; the clock sits at the card's bottom-right.

4 Nov 2026 · branch feat/action-card-dots-preview · captured against propflow-stage · at 681212aaff6+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 · Desktop, at rest: no dots until a card is hovered

The same thread with the pointer away from the cards: no ⋯ anywhere, only the time at each card's bottom-right.

Asserted in the captured DOM — couldn't take this call · didn't pick up

Desktop, at rest: no dots until a card is hovered
Sections 2–9

2 · Desktop, hovered: the ⋯ chip over the card's top-right, time bottom-right

Hovering the fallback note shows the horizontal ⋯ on a soft chip in the card's top-right corner. It sits over the text (no column is reserved for it), and the chip's opaque, slightly tinted ground keeps it readable over the words. The other cards show no dots until hovered. The time is at the bottom-right of every card.

Asserted in the captured DOM — couldn't take this call · didn't pick up

Desktop, hovered: the ⋯ chip over the card's top-right, time bottom-right

3 · Desktop, open: the fallback note's ⋯

The same popover as a message's menu: the exact time on top, then what happened (each rung and its outcome, read from the rows already on this record), where (building), and the ids at the bottom (conversation, the call's CallSid, the row). Ids copy on click.

Asserted in the captured DOM — Rung 1 · Then · Building · Conversation · Call

Desktop, open: the fallback note's ⋯

4 · Desktop, open: a rung card's ⋯ carries its own call leg

A missed rung: the menu names the ring leg (DialCallSid) that row stamped, beside the caller's CallSid.

Asserted in the captured DOM — Leg · Call

Desktop, open: a rung card's ⋯ carries its own call leg

5 · Desktop, open: the transfer card's ⋯

Earlier call, where Clara filed a work order and handed the caller to the office: when the office picked up, the work order that call is tied to (a link), and the ids. Who the call went to is NOT shown on a person's merged page: that field lives on the call's own record and the merged view does not carry it, which is also why this card reads "Transfer attempted" here instead of naming who answered. Listed as a follow-up.

Asserted in the captured DOM — Picked up at · View work order

Desktop, open: the transfer card's ⋯

6 · Phone, hovered

Phone width. The capture browser has a mouse, so the chip is shown by hovering. On a real touch screen (no hover) the chip is always visible on every card, so it stays reachable with a tap.

Asserted in the captured DOM — couldn't take this call

Phone, hovered

7 · Phone, open

The same menu at phone width.

Asserted in the captured DOM — Rung 1 · Conversation

Phone, open

8 · Dark mode, hovered

The chip at rest-on-hover in dark mode.

Asserted in the captured DOM — couldn't take this call · didn't pick up

Dark mode, hovered

9 · Dark mode, hovered and open

The same chip and menu in dark mode: the chip's ground is the card colour tinted toward the text colour, so it stays visible on a dark card.

Asserted in the captured DOM — Rung 1 · Then · Building · Conversation · Call

Dark mode, hovered and open
PropFlow Docs