[sinjab]

What

Adds teams react <chat> [emoji] — react to a message (like default, also heart, laugh, surprised), with --msg <id> to target a specific message and --remove to take your reaction off. --headed shows the drive for debugging.

Why not the API

The chatsvc REST API rejects reaction writes outright — PUT .../messages/<id>/properties?name=emotions returns 400 errorCode 201 "Invalid format of emotions property" for every body shape I tried (12, including the exact doc the GET returns, keyed-dict forms, and stringified variants), and the native protocol rides a WebSocket inside a SharedWorker that a CLI cannot join. The web UI is the only scriptable path.

How it works

Reuses the persistent browser profile teams login already maintains:

1. Launch headless Chromium with that profile, wait for the app.
2. Open the chat natively from the chat list — matched by the row's accessibility name (with an optional Unread message/Chat prefix), iterating candidates (one 1:1 can render as several rows) until the target message's heading is found. Opening through the search page was avoided: the thread renders in an embedded pane that can fail with an "Oops" error.
3. Locate the message row by its text — the role=heading match can resolve to a 1x1 accessibility marker, so the drive prefers the group row's bounding box and falls back to walking the DOM from the deepest visible text node.
4. Hover the row's top edge — the quick bar does not reliably trigger from the row center. An offset sweep with retries handles render timing; any message-actions-* button or the picker entry counts as "bar up".
5. Click [data-tid="message-actions-<key>"].

The expanded "More reactions" picker is deliberately not wired: its flyout can anchor to an adjacent message row and react to the wrong message (observed live during testing). Scope stays on the four hover-quick-bar reactions.

Safety

• Server-side verification: after the click, the message is re-fetched and its emotions property is asserted (your MRI present/absent), with retries for propagation lag.
• Re-reacting with an emoji you already set is refused instead of silently toggling it off (the UI treats a repeat click as remove). Same for --remove when you have no such reaction.
• Adds getEmotions/hasMyReaction helpers that tolerate both the plain-array and stringified-JSON property shapes the API returns.

Testing

• 17 new unit tests (108 total pass): reaction-name validation, selector mapping, target-message picking (newest/by id, skips event rows), snippet building (HTML strip, entity decode, truncation), emotions parsing (plain/stringified/malformed/empty-users).
• Live-verified two full cycles (like add/remove, heart add/remove) against a real tenant with server-side verification.

Also bumps playwright to ^1.63.0 (the version the feature was developed and live-tested against).

[sinjab]

Friendly ping — happy to rebase this onto current main if anything has drifted. I'm also sending a few follow-up PRs (#30–#32: --json output, HTML send, file attachments) built on this line of work; no rush, just letting you know they're coming.