@micha.bigler/ui-core-micha 2.21.3 → 2.23.0

package/work-orders/MSG-6f.md

@@ -0,0 +1,214 @@
+# WORK ORDER MSG-6f (ui-core-micha) — the host title resolver is never called for broadcasts, and the read ticks claim a delivery that does not exist
+
+**EXECUTION DIRECTIVE.** If you are the implementer reading this as your own spec, this section is not
+addressed to you — it tells the Orchestrator how to invoke you; you ARE that invocation, do not shell
+out to `codex exec`. Orchestrator: implement through `codex exec` in the background, invoked **directly
+via Bash** (never the `debugger`/`*_coder` Agent wrappers) with **both** flags `--skip-git-repo-check`
+and `--dangerously-bypass-approvals-and-sandbox`, prompt passed as a positional argument from this
+file. Fall back to direct Claude implementation only on Codex quota / rate-limit / non-zero exit.
+
+Feature-level WO (Expertenchat envelope). Both defects were found by **verifying the landed MSG-6e /
+MSG-7 / MSG-8 / MSG-10 work in a running app** (jg-ferien local, flag on, ucm 2.21.3, dcm 2.39.5,
+2026-08-03). Both are cases of "the other side shipped its half; ucm still renders the old behaviour".
+
+## TIER
+Tier 2 — shared-core, consumed by every app. Independent `reviewer` mandatory. `ui_reviewer` for
+scope B (it changes what a user believes about message delivery).
+
+## SCOPE
+
+**A. `titleOf` never calls the host resolver for a broadcast — jg's fix is dead code.**
+
+`ConversationList.jsx` `titleOf()` gates the host callback on kind:
+
+```js
+if (conversation.kind === 'managed' && resolveManagedLabel) {
+  const label = resolveManagedLabel(conversation);
+  if (label) return label;
+}
+```
+
+jg-ferien MSG-10 correctly taught its `resolveManagedConversationLabel` to handle
+`kind === 'broadcast'` — but ucm never calls it for that kind, so the branch is unreachable from the
+list and the row still falls through to `t('MessagingList.UNTITLED')`.
+
+**Verified live after MSG-10 landed:** the same conversation (`kind: "broadcast"`,
+`external_key: "broadcast"`, `title: null`) renders **"Unbenannte Unterhaltung"** in the list and
+**"Event-Ankündigungen"** in the open thread header — the thread header works only because jg's own
+`resolveConversationTitle` calls the resolver directly, with no kind gate.
+
+**The fix: stop gating on kind.** Call `resolveManagedLabel` for **every** conversation and let the
+host decide — a `null` return already means "I have no label", which is exactly the delegation contract,
+and the comment directly above `titleOf` already describes the label as host-supplied. Gating on kind
+inside ucm duplicates a decision that belongs to the host and will break again for the next kind.
+
+Check `resolveDirectUserName`'s gate (`kind === 'direct' && other_user_id != null`) in the same pass and
+state whether it has the same problem. Do not change it blindly — a direct conversation is the one kind
+where the id-based lookup is genuinely required.
+
+**B. The read ticks assert a delivery that the platform does not track.**
+
+Operator report, 2026-08-03: *"die Häkchen geben das Gefühl, dass jede Nachricht sofort zugestellt ist,
+auch wenn das Browserfenster geschlossen ist."* Correct, and it is now strictly worse than when it was
+written:
+
+- dcm MSG-7 scope C **removed `delivered_count`** from the `read-status` response — verified live, the
+  response now carries only `all_read` and `recipient_detail`.
+- `ReadTicks.jsx` still renders
+  `t('MessagingReadTicks.DELIVERED', { count: renderedStatus.delivered_count || 0 })`. With the field
+  gone, `undefined || 0` produces the **identical** label as before. Verified live: every own message
+  shows `aria-label="Zugestellt an 0"`.
+
+So the UI states "Zugestellt an 0" — simultaneously claiming a delivery and reporting that it reached
+nobody — on a single outlined check that reads as WhatsApp's delivered-tick. There is no delivery
+signal behind it at all.
+
+**Resolution (operator-directed, 2026-08-03): show a read PROPORTION in group and broadcast, keep a
+two-state tick in DMs.**
+
+The operational need in a camp is *"did a relevant share of the group read this?"* — a leader posting
+"bus leaves at 14:00" to forty participants needs a number, not a checkmark. `all_read` is the wrong
+measurement, not a useless feature: in any group it is essentially never true, so a boolean pins the
+indicator to its first state precisely where the information matters most.
+
+Operator decision, 2026-08-03:
+
+| Conversation kind | Viewer | Display |
+|---|---|---|
+| `direct` | sender | two-state tick — `DoneOutlinedIcon` **light grey** "Gesendet" → `DoneAllOutlinedIcon` **dark blue** "Gelesen" |
+| `group`, `broadcast`, `managed` | team member | a **ratio**: "18/40" (read / members). Numeric, no icon ladder. |
+| `group`, `broadcast`, `managed` | ordinary participant | **nothing** — render no indicator at all |
+| per-recipient detail | team member | unchanged — already correctly gated (see below) |
+
+**The contrast between the two DM states must be clearly stronger than today.** Currently
+`color={status.all_read ? 'primary' : 'inherit'}`, and `inherit` inside the meta `Stack` resolves to
+`text.disabled` — the two states are barely distinguishable. Use an explicit light grey and an explicit
+dark blue rather than `inherit`/`primary`, and verify the difference is obvious at the rendered
+`1rem` icon size in both light and dark theme. The icon shape already differs (`Done` vs `DoneAll`), so
+the distinction does not rest on colour alone — keep it that way.
+
+**"nothing" for an ordinary participant in a group is deliberate, not an oversight.** A permanently
+grey tick — which is what `all_read` would produce in any real group — is the "looks stuck" failure this
+scope exists to remove. No indicator is better than a misleading one.
+
+**No client-side permission logic.** dcm MSG-9 returns the counts only to viewers holding
+`read_receipt_detail`, so the rule is purely shape-driven: *counts present → ratio; else `direct` →
+tick; else → render nothing*. Do not branch on roles or capabilities in ucm.
+
+**The server already has the number and throws it away.** `read_status` (`services.py:344-347`) computes
+`all_read` from exactly the queryset that yields the count:
+`participants.filter(last_read_at__gte=message.created_at).count()` — the same shape as the
+`delivered_count` that had no writer. **A `read_count` + `recipient_count` pair is the counter
+`delivered_count` should have been.**
+
+Adding them is a `django-core-micha` change, not ucm's: **this scope is blocked on `django-core-micha`
+MSG-9**, which adds `read_count` and `recipient_count` inside the existing `read_receipt_detail`-gated
+block. Keep `all_read` — the DM branch still uses it.
+
+Do not derive the ratio client-side by counting `recipient_detail` yourself. It would happen to work
+(both are gated on the same right), but it re-implements a server aggregate in the client and would
+silently produce a wrong denominator the moment dcm's participant filtering changes. Read the counts
+dcm sends, or render nothing.
+
+Retire `MessagingReadTicks.DELIVERED` and its `{{count}}` regardless — the new ratio string is a
+different key with different semantics, and reusing "Zugestellt" would carry the false claim forward.
+Also stop reading the now-always-`null` `last_delivered_at` out of `recipient_detail`.
+
+**Per-recipient detail stays as it is.** `services.py:340` already gates it on
+`kind != DIRECT and "read_receipt_detail" in rights` (in jg: `MANAGER_RIGHTS`), and DMs never expose it
+even to moderators — a documented design invariant. This WO does not touch that; the popover keeps
+working for managers.
+
+**Why not implement delivery tracking as well** (wiring `mark_delivered` from a client ack, technically
+possible since dcm MSG-8 made WS frames arrive): in a browser app "delivered" can only mean "a tab had
+the socket open at that moment". For a recipient who is simply not online it would sit at the first
+state indefinitely — replacing "looks always delivered" with "looks permanently stuck", plus a write per
+received message. It only becomes meaningful with guaranteed device-level push. A read ratio answers the
+real question without that ambiguity. **If the operator wants delivery too, it is a feature WO.**
+
+**C. The read signal misses the most attentive reader — fix this or the ratio understates.**
+
+What `read_count` actually measures must be stated plainly, because it is weaker than "read":
+`mark_read` (`dcm services.py:288-294`) sets `ConversationParticipant.last_read_at` to *now*, and after
+MSG-6e scope D there is exactly **one** caller — `Thread.jsx:58`, a `useEffect` keyed on
+`[conversationId, markConversationRead]`. So the recorded fact is **"opened this conversation"**, and
+`read_count` counts participants who opened it at some point after the message was posted.
+
+It is not tab-open, not socket-connected, not per-message interaction, not viewport visibility.
+
+Two asymmetries follow. The first is acceptable, the second is a defect:
+
+1. Opening a conversation marks its **entire** history read in one stroke. Someone who opens it and
+   leaves immediately counts as having read a 200-message backlog. This is the universal convention
+   (WhatsApp behaves the same) — accept it, do not try to fix it here.
+2. **A participant already sitting in the open conversation when the message arrives is NOT counted.**
+   The effect is keyed on `conversationId`, so it does not re-fire when a new message lands. The person
+   who saw it in real time is recorded as not having read it, until they navigate away and back.
+
+Asymmetry 2 is newly common and newly consequential: before dcm MSG-8 no frame was ever delivered, so
+no thread ever updated live and this case did not arise. Now it is the *normal* case for anyone
+actually paying attention — and it biases the ratio **downward**, which is the wrong direction for a
+leader deciding whether to chase people about the bus time.
+
+**Fix: re-mark read when a new message arrives in the conversation currently open.** Trigger on the
+incoming `message` frame for the active conversation, not on a timer. Guard it: do not fire for the
+viewer's **own** send (dcm already excludes the sender from the fan-out, so no frame arrives — verify
+rather than assume), and do not fire when the thread is mounted but the document is hidden
+(`document.visibilityState`), or a background tab would report reads nobody performed. `mark_read` is
+already idempotent — it only writes when the new timestamp is later (`services.py:291`) — so a
+redundant call is cheap, but a *wrong* one is not.
+
+**Known cost, do not silently ignore:** `Thread` mounts `ReadTicks` per own message and each instance
+fires its own `read-status` request — O(n) for a sender with many messages in a thread, which is exactly
+the broadcast-heavy leader this feature serves. A batch endpoint (message ids → counts) is the natural
+answer and belongs in the same dcm WO. Do **not** fold the counts into `serialize_message` instead:
+`views.py:50-54` documents why viewer-specific read state must stay out of it — it would leak into the
+`message`/`message_edited` realtime frames, the same trap `thread_last_read_at` was kept out of.
+
+## NON-GOALS / DO NOT TOUCH
+- Do not reintroduce `delivered_count` on either side.
+- Do not change `all_read`'s semantics or how `read_state` frames update the cached receipt (that is
+  MSG-6e scope C, already landed — leave it working).
+- No change to `isOwn`/`senderName`/`canShowReadTicks`; the `sender` object from dcm 2.39.4 fixed those
+  and they are **verified working** (all server-loaded messages now render `own` with a tick).
+- Do not touch jg-ferien. Its `resolveManagedConversationLabel` is already correct and must stay as it
+  is — scope A is what makes it reachable.
+
+## RISKS
+- **A changes behaviour for every host app**, including any that relies on `resolveManagedLabel` being
+  called only for `managed`. A host returning a non-null label for an unexpected kind would newly see
+  it win over `conversation.title`. Check the ordering in `titleOf` after the change: a host label
+  should still lose to nothing it previously lost to, apart from the intended new case.
+- B changes a user-facing claim. Getting it wrong in the other direction (removing the indicator
+  entirely) loses the "did my message go out" affordance — hence two states, not zero.
+- The retired i18n key may be referenced by host apps' tests. Grep before deleting and note any hits.
+
+## REQUIRED TESTS TO WRITE
+Narrow and behavioural. Do NOT run the full suite.
+
+1. **A:** a conversation with `kind: 'broadcast'`, `title: null`, and a host `resolveManagedLabel` that
+   returns a string renders **that string**, not `MessagingList.UNTITLED`. This must **fail against
+   today's code** — prove it.
+2. **A:** a host resolver returning `null` still falls through to the existing chain unchanged
+   (regression guard for the delegation contract).
+3. **A:** the existing `managed` / `event_all` / `event_team` behaviour is unchanged.
+4. **B:** `direct` renders the two-state tick and the two states use visibly different explicit colours (assert the resolved colours differ, not just that a colour prop is set); a `group` WITH counts renders the ratio; a `group` WITHOUT counts renders **no** indicator. Assert no label containing "Zugestellt" is produced anywhere in `ReadTicks`.
+   that **no** label containing a `{{count}}`-derived number is produced anywhere in `ReadTicks`.
+5. **B:** `all_read` still renders the double check in `primary` with the unchanged label.
+
+**Non-vacuity:** tests 1 and 4 must fail on the current code. Test 1 is the one that matters — jg
+shipped a fix for this exact symptom that did nothing, because the test asserted on the wrong side of
+the boundary. Assert on the **rendered list row**, not on the resolver function in isolation.
+
+## TEST SCOPE FOR THE GATE (orchestrator)
+`ConversationList` and `ReadTicks` test files plus the messaging i18n tests. Not the full suite.
+
+## TARGET REPO
+`C:\Users\biglmi\Documents\webapps\ui-core-micha`. Branch `main` (or `develop` if present). Publish per
+the repo's release flow. jg's pin bump is a separate step; jg needs it to close its own MSG-9
+finding 4/12, which cannot be fixed from jg at all.
+
+## PROGRESS CONTRACT
+Emit `PLAN: <steps>` up front, then a single-line `PROGRESS: [<n>/<total>] <action>` before every
+relevant action and `PROGRESS: [<n>/<total>] done` on completion, spaced so no gap exceeds ~2 min,
+stdout unbuffered, and exactly one final `RESULT: DONE|BLOCKED <reason>`.

package/work-orders/MSG-6g.md

@@ -0,0 +1,244 @@
+# WORK ORDER MSG-6g (ui-core-micha) — poll UI: tap-to-vote with result bars, no separate vote button
+
+**EXECUTION DIRECTIVE.** If you are the implementer reading this as your own spec, this section is not
+addressed to you — it tells the Orchestrator how to invoke you; you ARE that invocation, do not shell
+out to `codex exec`. Orchestrator: implement through `codex exec` in the background, invoked **directly
+via Bash** (never the `debugger`/`*_coder` Agent wrappers) with **both** flags `--skip-git-repo-check`
+and `--dangerously-bypass-approvals-and-sandbox`, prompt passed as a positional argument from this
+file. Fall back to direct Claude implementation only on Codex quota / rate-limit / non-zero exit.
+
+Feature-level WO (Expertenchat envelope). Operator request 2026-08-03: *"bei der Abstimmung wäre es
+schön, wenn es ähnlicher wie WhatsApp mit dem Balken sowie ohne Abstimmungsbutton möglich wäre."*
+
+This is a **UX improvement, not a defect** — the current poll works. It is scoped separately so it never
+blocks the messaging defect WOs.
+
+## TIER
+Tier 2 — shared-core UI consumed by every app. Independent `reviewer` + `ui_reviewer` mandatory.
+
+## CURRENT STATE
+
+`PollCard.jsx` renders each option as a MUI `FormControlLabel` with a `Checkbox` (multi-select) or radio,
+labelled `"<text> (<vote_count>)"`, plus a separate **"Abstimmen"** submit button and a
+**"Umfrage schliessen"** action for the owner. Voting is therefore a two-step interaction — select, then
+submit — and the result is a bare number in parentheses.
+
+## GOAL
+
+Voting is one tap on the option itself, and the distribution is readable at a glance from proportional
+bars rather than parenthesised counts.
+
+## SCOPE
+
+**A. Tap-to-vote — remove the separate submit button.**
+
+- **Single-choice poll** (`allow_multiple: false`): tapping an option casts the vote immediately.
+  Tapping a different option moves the vote. The "Abstimmen" button goes away entirely.
+- **Multi-select poll** (`allow_multiple: true`): tapping an option toggles that option immediately —
+  each tap is its own vote update, not a batched submit. **Confirm dcm's vote endpoint accepts the full
+  option-id set per call** (it takes `option_ids`, so a toggle sends the new complete set, not a delta);
+  if it does not, stop and report rather than inventing a delta protocol.
+- Every tap is an optimistic UI update reconciled against the server response, following the pattern
+  `MessagingProvider` already uses for sends. **A failed vote must visibly revert** — a silently
+  swallowed failure that leaves the bar showing a vote nobody recorded is worse than the current
+  two-step flow.
+- Keep "Umfrage schliessen" — that is an owner action, not part of voting.
+
+**B. Result bars.**
+
+- Each option shows a horizontal proportional bar plus its count and percentage, in place of the
+  `(<n>)` suffix.
+- The viewer's own choice(s) are visually marked. `voted_option_ids` already exists for this and is
+  carried in the REST vote/create/close response — note the standing constraint documented in
+  `MessagingProvider.jsx`: it is **viewer-specific and never present on a `poll_updated` frame**, so
+  frame handling must not wipe a locally-known selection. Do not regress that; it was a deliberate fix.
+- Denominator: total votes cast, not participant count. A poll's turnout relative to group size is a
+  different question and is **not** in scope.
+- Percentages must not mislead at zero votes — define and implement the zero-vote rendering explicitly
+  rather than letting a division produce `NaN`.
+
+**C. Closed polls.** A closed poll shows final bars and is not interactive. Verify the closed state is
+visually unmistakable — with the submit button gone, "closed" can no longer be inferred from a missing
+button.
+
+## NON-GOALS / DO NOT TOUCH
+- No backend change. If a scope-A requirement appears to need one, stop and report — that is a dcm WO.
+- Do not change `voted_option_ids` handling in `applyFrame` beyond what B needs to read it (see the
+  merge-trap note above).
+- Do not add a "who voted for what" disclosure. Per-voter visibility is a privacy decision nobody has
+  taken, and the existing `voters` data in `serialize_poll` is not licence to surface it.
+- Do not change poll creation (`Composer`'s dialog) — this WO is the display and voting surface only.
+- Do not touch `ReadTicks`, conversation titles, or anything in the MSG-6f scope.
+
+## RISKS
+- **Tap-to-vote removes the "are you sure" step.** On a phone a mis-tap now votes. Mitigate by making
+  the vote reversible (tap again / tap another) and by ensuring the optimistic state is obviously
+  distinct from the confirmed state; do not add a confirmation dialog, which would reinstate the
+  two-step flow this WO removes.
+- Rapid successive taps race. The last write must win deterministically — state how (request ordering,
+  or discard stale responses by comparing against the latest local intent).
+- Accessibility: an option becomes an interactive control with a name, a pressed/checked state and
+  keyboard operability. Bars are decorative; the count and percentage must be in the accessible name or
+  adjacent text, not conveyed by width alone. `ui_reviewer` should check this specifically.
+- Every host app inherits the new interaction — a visible behaviour change beyond jg-ferien.
+
+## REQUIRED TESTS TO WRITE
+Narrow and behavioural. Do NOT run the full suite.
+
+1. Single-choice: tapping an option votes without any further interaction; tapping a second option
+   moves the vote (the first is no longer selected, the counts reflect it).
+2. Multi-select: tapping toggles one option on and off, and each tap sends the complete option-id set.
+3. A rejected vote reverts the optimistic state and surfaces an error — assert the bar returns to its
+   prior value, not merely that an error appeared.
+4. Bars render proportionally, including the **zero-vote** case, with no `NaN` and no division error.
+5. The viewer's own selection survives a `poll_updated` frame that does not carry `voted_option_ids`
+   (the documented merge trap — this must not regress).
+6. A closed poll is non-interactive: tapping an option does nothing and issues no request.
+
+**Non-vacuity:** test 5 must fail if the merge-trap guard is removed. Test 3 must assert the reverted
+value, not the presence of an error message.
+
+## TEST SCOPE FOR THE GATE (orchestrator)
+`PollCard` and its neighbours in the messaging test files. Not the full suite.
+
+## TARGET REPO
+`C:\Users\biglmi\Documents\webapps\ui-core-micha`. Branch `main` (or `develop` if present). Publish per
+the repo's release flow; the consuming pin bump is a separate step.
+
+## MINI-HANDOVER (pastable)
+
+> Repo: `C:\Users\biglmi\Documents\webapps\ui-core-micha` (branch `main`, or `develop` if present).
+> Work order: `work-orders/MSG-6g.md` — read it fully, then follow the `orchestrate-codex` skill.
+>
+> **UX improvement, not a defect — this blocks nothing and is blocked by nothing.** Do not let it hold
+> up the messaging defect WOs (dcm MSG-10, ucm MSG-6f).
+>
+> Frontend only: no backend change is in scope. If tap-to-vote appears to need one, stop and report.
+> Two things that are easy to break and are called out in the WO: a failed vote must visibly revert
+> (not fail silently), and the viewer's `voted_option_ids` must survive a `poll_updated` frame that
+> does not carry it — that merge-trap guard was a deliberate earlier fix and test 5 pins it.
+
+## PROGRESS CONTRACT
+Emit `PLAN: <steps>` up front, then a single-line `PROGRESS: [<n>/<total>] <action>` before every
+relevant action and `PROGRESS: [<n>/<total>] done` on completion, spaced so no gap exceeds ~2 min,
+stdout unbuffered, and exactly one final `RESULT: DONE|BLOCKED <reason>`.
+
+---
+
+## Part B — Implementation map (Orchestrator) / as-built record
+
+**Codex was unavailable (out of credits) — implemented directly by the Orchestrator.**
+
+### Blocker found and resolved before implementation
+
+Line 38-40's own contingency ("confirm dcm's vote endpoint accepts the full option-id set
+per call... if it does not, stop and report") fired for real: `vote_poll` (dcm
+`services.py:247-259`) only cleared prior votes for single-choice polls; multi-select only
+ever `bulk_create`d, so a smaller `option_ids` set never retracted an omitted vote —
+untoggling was silently a no-op. Reported to the operator, who confirmed fixing it
+directly in dcm rather than working around it client-side. Fixed and published as dcm
+`2.40.1` — see dcm `work-orders/MSG-11.md`. `option_ids` is now authoritative (delete
+anything no longer in the set, then re-create the requested set) for both poll kinds.
+
+### Files changed
+
+- `src/messaging/MessagingProvider.jsx`:
+  - New module-level `applyOptimisticVote(poll, previousSelectedIds, nextSelectedIds, userId)`
+    — adjusts only the options whose membership in the vote actually changed (count +/-1,
+    `voters` array +/- the acting user), leaves everything else untouched.
+  - New `pollVoteTokensRef` (per-poll "latest tap wins" token) alongside the existing
+    `activeIdRef`/`seenEventsRef`/`filtersRef`.
+  - `castPollVote(messageId, poll, optionIds)` rewritten: captures `previousPoll` from
+    `cache.messages[messageId].poll` (falling back to the `poll` param), patches the
+    optimistic projection into the cache immediately (same `patchMessage` shape
+    `toggleReaction` already uses), then on success reconciles with the server's poll, on
+    failure reverts to `previousPoll` — both guarded by the token so a stale response from
+    a since-superseded tap can't stomp a newer one.
+- `src/messaging/PollCard.jsx`: full rewrite.
+  - Single-choice (`allow_multiple: false`) → `Radio` per option (native "tap a different
+    option moves the vote, tap the same one is a no-op" semantics — matches the WO's
+    stated design directly, no extra toggle-off logic needed).
+  - Multi-select → `Checkbox` per option (existing toggle semantics preserved).
+  - Whole-option-row tap target (`Box onClick`, `stopPropagation` on the control's own
+    `onClick` to avoid a double-fire) — WhatsApp-style, matches the operator's own framing.
+  - `LinearProgress` bar + `{{count}} ({{percent}}%)` (`MessagingPoll.OPTION_RESULT`, new
+    key) next to each option; `percent = totalVotes > 0 ? round(count/totalVotes*100) : 0`
+    — never `NaN`.
+  - Accessible name (`aria-label` on the control) carries option text + result text +
+    "you voted" — never width-only.
+  - Closed state: `Chip` with a lock icon + `MessagingPoll.CLOSED`, replacing the old
+    caption-only text (now the *only* closed signal, since the submit button is gone).
+  - Local `selected` state + a `voteTokenRef` mirror the provider's own token guard, since
+    `PollCard` is a "dumb" prop-driven component (documented in
+    `tests/messagingPollRendering.test.jsx`) — a rejected vote must revert visibly even
+    when the host never re-passes a fresh `message` prop from its own cache.
+  - Removed: the "Abstimmen" submit button and its `SELECT_OPTION` validation entirely.
+- `src/i18n/messagingTranslations.ts`: removed now-orphaned `MessagingPoll.VOTE` and
+  `MessagingPoll.SELECT_OPTION`; added `MessagingPoll.OPTION_RESULT`.
+
+### Tests
+
+- `tests/messagingMsg6g.test.jsx` (new) — the 6 WO-required cases verbatim.
+- `tests/messagingPollRendering.test.jsx` — updated for radio (not checkbox) on
+  single-choice, the new label/aria-label shape, and the closed-chip instead of a
+  disabled button; its `t` mock upgraded to interpolate `{{count}}`/`{{percent}}` (was
+  bare-key-only, insufficient to assert rendered numbers).
+  `tests/messagingInteractions.test.jsx`'s poll test rewritten for tap-to-vote (no submit
+  click). `tests/messagingCompactBubble.test.jsx`'s poll smoke test needed no change
+  (empty `options: []`, no control interaction).
+
+### Verification
+Full suite 234 → 240, `tsc` clean (pre-review).
+
+### Independent review: `reviewer` + `ui_reviewer`, both mandatory (author = Orchestrator, not Codex)
+
+**`reviewer` — 3 findings, all fixed:**
+- **R1 (P1, real bug):** `castPollVote`'s optimistic count projection was built from the
+  caller-supplied `poll` argument, not from `previousPoll` (the value already freshly read
+  from `cache.messages[messageId].poll` two lines above, and correctly used as the revert
+  target on failure). For a second rapid tap (e.g. switching a single-choice vote A→B)
+  where the caller's `poll` reference hadn't yet been refreshed — exactly how `PollCard`
+  is documented to behave, a "dumb" prop-driven component — the count math computed
+  against the stale pre-first-tap baseline, landing a silently wrong transient
+  `vote_count` in the **shared cache** (not just local render state) until the server's
+  response eventually reconciled it away. Fixed: project from `previousPoll`. Verified
+  non-vacuous: reverted the fix, confirmed the new regression test below fails with the
+  exact predicted wrong number (4 instead of 5), then restored it.
+- **R2 (P2, coverage gap):** no test asserted vote-count values across a multi-tap
+  sequence with non-zero starting counts — the zero-vote fixtures used elsewhere
+  happened to mask R1 via the `Math.max(0, ...)` clamp. Closed by a new
+  `messagingMsg6g.test.jsx` case using non-zero seed counts (5/2) and a genuinely
+  cache-connected reader alongside a *statically-propped* `PollCard` (the scenario that
+  actually reproduces the staleness, per R1's own trace — a cache-connected `PollCard`
+  re-renders with a fresh `poll` prop between taps and would not have caught this).
+- **R3 (P3):** `applyOptimisticVote` could push a literal `undefined` into an option's
+  `voters` array when `user?.id` is momentarily unset (`AuthContext` not yet populated).
+  Fixed with a `userId != null` guard.
+
+**`ui_reviewer` — 2 findings, both fixed:**
+- **U1 (P2):** no visual distinction between an in-flight optimistic vote and a
+  server-confirmed one, contradicting the WO's own risk-mitigation requirement. Fixed by
+  reusing `ReactionBar.jsx`'s established `pending` Set convention — dims the tapped
+  option's bar/text while its request is in flight, but (unlike `ReactionBar`) does
+  **not** disable the control, since the WO explicitly requires rapid re-taps to remain
+  possible and race deterministically (last-write-wins via the token guard), not be
+  blocked.
+- **U2 (P2):** single-choice rendered bare, ungrouped `Radio` controls — no `RadioGroup`,
+  no shared `name`. Diverged from this repo's own established radio idiom
+  (`AuthFactorRequirementCard.jsx`'s `RadioGroup` + `FormControlLabel`) and lost native
+  arrow-key navigation between options plus the screen-reader group announcement. Fixed
+  by wrapping single-choice options in a real `RadioGroup`; multi-select's `Checkbox`
+  options are unaffected (no equivalent ARIA grouping concept applies). Switching to
+  `FormControlLabel` for both control types also let the manual `Box onClick` +
+  `stopPropagation()` whole-row-tap hack be removed entirely — `FormControlLabel`'s own
+  `<label>` wrapping already makes the whole row natively clickable.
+- Found and fixed while addressing U2, not itself a reviewer finding: `RadioGroup`'s own
+  `onChange` only ever hands back `event.target.value`, a DOM string, which would coerce
+  a non-string option id (dcm's are UUID strings today, but the type isn't a guaranteed
+  contract) — caught by `tests/messagingInteractions.test.jsx`'s existing numeric-id
+  fixture failing after the `RadioGroup` change. Fixed by keeping each `Radio`'s own
+  `onChange` (closure-typed, matching the `Checkbox` branch) instead of relying on the
+  group-level handler.
+
+Re-verified after all fixes: full suite 234 → **241** (7 new: 6 WO-required cases +
+1 R1/R2 regression), `tsc` clean.