@micha.bigler/ui-core-micha 3.14.4 → 4.0.1

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

@@ -1,244 +0,0 @@
-# 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.

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

@@ -1,238 +0,0 @@
-# WORK ORDER MSG-6h (ui-core-micha) — attachment gallery (thumbnail/lightbox/right-click download), reaction overlap
-
-**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 report 2026-08-03 from a staging screenshot, seen
-now for the first time end-to-end because `django-core-micha` `MSG-10` just fixed attachment uploads
-(they were unconditionally rejected before — this display code has effectively never been exercised
-against a real upload on the platform path).
-
-## TIER
-Tier 2 — shared-core UI consumed by every app. Independent `reviewer` + `ui_reviewer` mandatory.
-
-## SCOPE
-
-**A. Attachment gallery.**
-
-Current state (`AttachmentList.jsx`): each attachment renders as a `Button` containing a 36×36px
-thumbnail (if the file is an image and its thumbnail loaded) plus a text label
-`t('MessagingAttachments.DOWNLOAD', { name: nameOf(attachment) })`. `nameOf` is
-`attachment.filename || attachment.name || attachment.id` — since dcm's `serialize_attachment` has
-never returned `filename` (see `django-core-micha` `work-orders/MSG-12.md`, its companion, fixing
-that), this **always** fell through to the raw UUID `id`. Clicking anywhere on the button downloads
-the file — there is no preview step.
-
-Operator's target shape, verbatim: *"bitte kleines Vorschaubild, bei Klick darauf grosse Vorschau,
-rechtsklick zum Kontextmenu mit Download (analog Whatsapp)"* — a small thumbnail; clicking it opens a
-large preview (lightbox); right-click opens a context menu with a download action.
-
-Build this:
-- **Image attachments**: small thumbnail (reuse the existing `getAttachmentThumbnail` fetch — already
-  wired). Click → a lightbox (MUI `Dialog` or `Modal`) showing the full-size image, fetched via the
-  existing `getAttachment` blob endpoint. Right-click (`onContextMenu`) → a small context menu (MUI
-  `Menu`, matching the pattern already used for message actions in `MessageBubble.jsx`) with a
-  Download action, calling the same download logic `AttachmentList` already has.
-- **Non-image attachments** (no thumbnail available): keep a compact file-type indicator (icon +
-  filename, once `MSG-12` supplies a real one) as the tap target; single click downloads directly
-  (there is nothing to preview) — right-click still offers the same context menu for consistency, even
-  though its one item duplicates the click action.
-- Filename: once `MSG-12` ships, `nameOf` should read the real `filename` first; keep the existing
-  `|| attachment.id` fallback for interop with a not-yet-bumped dcm pin (an older host may still be on
-  a dcm version that omits it) — never let a missing filename break rendering, just fall back visibly.
-- Keep the download-only design principle: bytes never touch anything but the existing authenticated
-  `getAttachment`/`getAttachmentThumbnail` blob fetches already in `MessagingProvider`. No new
-  endpoints, no new byte-handling path.
-
-**B. Reaction bar overlap.**
-
-`MessageBubble.jsx:139` renders `ReactionBar` as a sibling *after* the bubble's `Paper`, with
-`sx={{ mt: -0.5, ml: 0.75, position: 'relative', zIndex: 1 }}` — a small negative top margin
-deliberately pulls it up to overlap the bubble's bottom edge (a common "chip peeking out" treatment).
-Operator report: this overlap now reads as broken/unnatural, screenshotted on a message that has
-attachments — worth checking specifically whether the fixed `-0.5` offset was tuned against a
-plain-text bubble and no longer sits right against the bottom of an attachment row or (from `MSG-6g`)
-a poll's result bars, both of which changed the bubble's actual bottom content since this offset was
-last touched.
-
-**Live-verify against the operator's original screenshot before considering this closed** — the
-Orchestrator does not have staging credentials this round; if a local repro isn't conclusive, say so
-and ask the operator to confirm the fix visually rather than guessing further.
-
-## NON-GOALS / DO NOT TOUCH
-- Do not touch `PollCard.jsx`, `ReadTicks.jsx`, or conversation titles — unrelated recent WOs.
-- Do not add any new backend endpoint — scope A only consumes what already exists (plus `MSG-12`'s
-  additive `filename` field).
-- Do not change the reaction *toggle* logic (`ReactionBar.jsx`'s `react`/`pending` mechanics) — only
-  its positioning relative to the bubble, scope B.
-- Do not implement a generic lightbox/gallery component library dependency — build directly with MUI
-  primitives already used elsewhere in this codebase (`Dialog`, `Menu`), matching existing patterns.
-
-## RISKS
-- A right-click context menu on a message bubble already exists for message-level actions
-  (`MessageBubble.jsx`'s `openMenu`/`canOpenMenu`, triggered by `onContextMenu`). An attachment's own
-  right-click context menu must not fight with or accidentally trigger the message-level one when the
-  attachment sits inside the bubble — `event.stopPropagation()` where appropriate.
-- Lightbox must be keyboard-dismissable (Escape) and trap focus reasonably — it is a modal.
-- The thumbnail fetch already exists and works (`AttachmentList.jsx`'s current `useEffect`); reuse it,
-  don't re-invent — but the full-size lightbox fetch (`getAttachment`) is a new call path, verify it
-  doesn't double-fetch what the thumbnail effect already has cached.
-
-## REQUIRED TESTS TO WRITE
-Narrow and behavioural. Do NOT run the full suite.
-
-1. An image attachment renders a thumbnail; clicking it opens a lightbox showing the full image
-   (fetched via `getAttachment`).
-2. Right-clicking an image attachment opens a context menu with a Download action; selecting it
-   downloads (same assertion shape as the existing pre-redesign download test, if one exists — check).
-3. A non-image attachment (no `thumbnail_url`) renders a file indicator, not a broken image; clicking
-   it downloads directly.
-4. `nameOf` prefers `attachment.filename` when present, falls back to `attachment.id` when absent
-   (interop with a dcm pin that predates `MSG-12`) — assert both cases render without crashing.
-5. The attachment's own context menu does not also trigger the message-level action menu (no
-   double-open, no propagation leak) — regression guard given `MessageBubble.jsx` already has its own
-   `onContextMenu`.
-
-## TEST SCOPE FOR THE GATE (orchestrator)
-Attachment- and reaction-bar-adjacent messaging test files. Not the full suite.
-
-## TARGET REPO
-`C:\Users\biglmi\Documents\webapps\ui-core-micha`. Branch `main`. Publish per the repo's release flow;
-consuming pin bumps (jg-ferien, and `django-core-micha` `MSG-12` for the filename) are separate,
-subsequent steps — **but per standing feedback this session, do not report this WO as "done" until
-those consuming steps have actually landed**, not merely published.
-
-## MINI-HANDOVER (pastable)
-
-> Repo: `C:\Users\biglmi\Documents\webapps\ui-core-micha` (branch `main`). Work order:
-> `work-orders/MSG-6h.md` — read it fully, then follow the `orchestrate-codex` skill.
->
-> Two independent scopes, both operator-reported live on staging: (A) `AttachmentList.jsx` needs a
-> real thumbnail-click-lightbox / right-click-download-menu gallery, WhatsApp-style, instead of a bare
-> download button showing a raw UUID (the UUID-fallback root cause is fixed separately in
-> `django-core-micha` `MSG-12`, a companion WO — consume its new `filename` field with a graceful
-> fallback for an older pin). (B) `MessageBubble.jsx:139`'s `ReactionBar` has a fixed `mt: -0.5`
-> negative-margin overlap trick that now reads as visually broken against certain bubble content
-> (attachments, and possibly `MSG-6g`'s poll bars) — investigate and fix, but flag if it needs a live
-> staging screenshot to confirm rather than guessing blind.
-
-## 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.**
-
-### Scope A — `src/messaging/AttachmentList.jsx` (full rewrite)
-
-- Each attachment is now a 64×64 `ButtonBase` tile (not a full-width text button): an image
-  attachment shows its existing thumbnail fetch (unchanged `getAttachmentThumbnail` `useEffect`,
-  reused verbatim); a non-image attachment shows a generic file icon +
-  filename (`InsertDriveFileOutlinedIcon`).
-- Click: image → `openLightbox` (fetches the full-resolution blob via the existing `getAttachment`,
-  cached per-attachment in a `fullUrlCacheRef` so a re-open within the same mount doesn't re-fetch);
-  non-image → `download` (unchanged logic, just relocated).
-- Right-click (`onContextMenu`): opens a MUI `Menu` (anchored to click position) with one Download
-  item, for both image and non-image attachments. `event.stopPropagation()` inside the handler stops
-  it from also reaching `MessageBubble.jsx`'s own bubble-level `onContextMenu` (verified with a
-  dedicated regression test, item 5 below).
-- Lightbox: a MUI `Dialog` with the full image + a close `IconButton` (also closes via the Dialog's
-  own backdrop-click/Escape handling, native to MUI).
-- `nameOf(attachment)` unchanged in shape (`filename || name || id`), now actually resolves to a real
-  name once the host's dcm pin includes `MSG-12`; falls back to `id` for an older pin (test 4).
-- 3 new i18n keys: `MessagingAttachments.PREVIEW`, `.CLOSE_PREVIEW`, `.DOWNLOAD_ACTION`. Existing
-  `.LABEL`/`.DOWNLOAD` kept — `.DOWNLOAD` is now also the accessible name for a non-image tile (no
-  visible "Download X" text on it any more, per the new compact-tile design — updated one pre-existing
-  test in `messagingCompactBubble.test.jsx` that asserted on the old visible text).
-
-### Scope B — `src/messaging/MessageBubble.jsx:139`
-
-- `ReactionBar`'s `sx` changed from `{ mt: -0.5, ml: 0.75, position: 'relative', zIndex: 1 }` to
-  `{ mt: 0.5, ml: 0.75 }` — a small **positive** gap instead of the negative-margin "peek from the
-  bubble's bottom edge" trick. That trick pulled the chip up into whatever sits immediately above it
-  in normal document flow, which used to always be plain text or the compact meta row; since MSG-6g
-  added poll bars and this WO's own gallery redesign changed the attachment row's height/borders, the
-  fixed offset started visually cutting into bordered, boxier content instead of text. Also dropped
-  `position: relative` / `zIndex: 1`, no longer needed without the overlap.
-- **Not independently visually re-verified against the operator's original staging screenshot** — no
-  staging credentials this round (same limitation noted when the ucm pin bump was last reported). The
-  fix is a conservative, low-risk "stop overlapping anything" change; flagging per the WO's own
-  instruction to say so rather than claim a live-confirmed fix.
-
-### Tests
-`tests/messagingMsg6h.test.jsx` (new) — the 5 WO-required cases. `tests/messagingCompactBubble.test.jsx`
-updated (pre-existing test asserted on now-removed visible DOWNLOAD text). No other existing test
-needed a change (`messagingComposer.test.jsx`'s AttachmentList smoke test only checked the outer
-`aria-label`, unaffected).
-
-### Verification (pre-review)
-Full suite 241 → 246 (5 new), `tsc` clean.
-
-### Independent review: `reviewer` + `ui_reviewer`, both mandatory (author = Orchestrator, not Codex)
-
-Both reviews converged on the same core gap from different angles — fixed together in one pass.
-
-**`reviewer` — 3 findings:**
-- **R1 (P2, real regression):** the pre-diff design let every attachment (image or not) download via a
-  direct click/Enter/Space on a plain `Button`. The redesign made an image's click open the lightbox
-  instead, which had only a Close button — the *only* way left to download an image was a real mouse
-  right-click, unreachable by keyboard or (with no long-press) touch. **Fixed**: the lightbox now has
-  its own Download `IconButton`, so download is reachable via click, Tab+Enter, or touch, without ever
-  needing the context menu.
-- **R2 (P2):** the new lightbox fetch had no loading or error state — a click gave no feedback until
-  the network round trip resolved, and a failure silently no-opped. **Fixed**: `lightbox.status`
-  (`'loading' | 'ready' | 'error'`) drives a `CircularProgress` while fetching and an `Alert` on
-  failure; a stale in-flight fetch (opened, then a *different* attachment opened before the first
-  resolves) is guarded by comparing the resolved attachment's id against the current lightbox state
-  before applying the result.
-- **R3 (P3):** the lightbox `Dialog` had no accessible name. **Fixed**: `aria-label` on the `Dialog`
-  itself, set to the previewed attachment's name.
-
-Verified correct, no bug: object-URL lifecycle (no leak/double-revoke/revoke-while-displayed), the
-context-menu `stopPropagation` (traced against React's synthetic event dispatch + the dedicated test),
-no stale-closure risk in the menu's download handler, `fullUrlCacheRef` can't go stale across messages
-(`Thread.jsx` keys `MessageBubble` by `message.id`, always unmounts on swap), i18n coverage.
-
-**`ui_reviewer` — 6 findings:**
-- **U1 (P1, same root cause as R1):** touch users had no way to download an image at all (no
-  long-press implemented, lightbox had no download control). **Fixed by the same lightbox Download
-  button as R1** — one fix closes both findings.
-- **U2 (P2):** no visual affordance signals a tile is right-clickable, and right-click-for-download is
-  a non-obvious pattern without a fallback for a mouse user who doesn't know it. **Resolved by the R1/U1
-  fix, not a separate change**: right-click is no longer the *only* path to anything — an image is
-  fully reachable via primary click → lightbox → visible Download button, and a non-image already
-  downloads on primary click. Right-click remains a discoverable-if-you-know-it shortcut, not a
-  required, hidden one; adding a second, redundant hover-reveal affordance on top of an already-fully-
-  reachable primary interaction would be scope creep past what the finding's own root concern requires.
-- **U3 (P2):** a non-image tile's filename truncates in a 64px box with no way to recover the full name
-  before downloading. **Fixed**: `title={nameOf(attachment)}` on the tile (native browser tooltip on
-  hover).
-- **U4 (P3):** the French `PREVIEW` translation (`'Aperçu de {{name}}'`, noun-first) broke grammatical
-  parallelism with the sibling `DOWNLOAD`/`DOWNLOAD_ACTION` (verb-first). **Fixed**: `'Prévisualiser
-  {{name}}'`.
-- **U5 (P3):** the lightbox close button omitted the `boxShadow` the codebase's analogous floating-icon
-  pattern (`MessageBubble.jsx`'s hover-revealed `MoreVertIcon`) uses for contrast. **Fixed**: both the
-  new Download button and the Close button now carry `boxShadow: 1`.
-- **U6 (P3, not fixed, disclosed):** `openLightbox`'s failure path is a silent no-op if `getAttachment`
-  is bypassed some other way — the reviewer themselves noted this mirrors `download()`'s own
-  pre-existing silent-failure shape, not a new defect class. Left as-is, consistent with that existing
-  convention elsewhere in this component; R2's loading/error state above already covers the actual
-  reachable failure path (a real fetch rejection).
-
-### Not independently visually re-verified
-Scope B's `ReactionBar` spacing fix (`MessageBubble.jsx:145`) was not confirmed against the operator's
-original staging screenshot — no staging credentials this round. Both reviewers examined it by static
-code reading only and found the fix low-risk (a strict `mt` sign flip, no z-stacking or other side
-effect traced), but this is a judgment call, not a live-rendered confirmation. Flagging per the WO's
-own instruction rather than claiming a visual fix I have not actually seen.
-
-### Re-verification after all fixes
-Full suite 241 → 249 (8 new: 5 original + 3 closing R1/R2), `tsc` clean.