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

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

@@ -1,271 +0,0 @@
-# WORK ORDER MSG-6i (ui-core-micha) — attachment tile size, poll spacing/denominator, wider emoji picker
-
-**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 polish requests 2026-08-03, gathered in a
-requirements round after MSG-6h shipped; four independent, small scopes bundled the same way
-MSG-6f bundled A/B/C.
-
-## TIER
-Tier 2 — shared-core UI consumed by every host app. Independent `reviewer` + `ui_reviewer` mandatory
-(scope C changes poll math, not just styling).
-
-## SCOPE
-
-**A. Attachment tile: 64px → 120px.**
-
-`AttachmentList.jsx`'s tile `sx={{ width: 64, height: 64, ... }}` (both the `ButtonBase` and its
-internal thumbnail `Box component="img"`, which is `width: '100%', height: '100%'` and inherits).
-Change both dimensions to `120`. Check the non-image tile's icon/caption layout still reads well at
-the larger size (currently sized for 64px — `InsertDriveFileOutlinedIcon fontSize="small"` and a
-`caption` typography may look sparse/small inside a 120px box; consider `fontSize="medium"` or larger
-if it looks disproportionate — operator did not specify, use judgement, flag if genuinely unsure).
-`Stack direction="row" flexWrap="wrap"` spacing stays as-is unless the larger tiles visibly break
-wrapping at typical bubble widths.
-
-**B. Poll card: more breathing room, not a wider bubble.**
-
-Operator, verbatim (after seeing a screenshot of the current cramped layout — checkbox, option text,
-and percentage squeezed onto one tight line, thin bars close to the text, minimal gap between options):
-*"Nicht generell breiter, aber luftiger."* (Not generally wider, but airier.) This is **not** scope A
-of a width change — the poll's outer bubble width stays exactly as-is (still shares
-`MessageBubble.jsx`'s `maxWidth: min(75%, 680px)` with every other message type). Increase internal
-spacing in `PollCard.jsx`: the `Stack spacing={0.75}` wrapping the whole card, the per-option
-`Stack direction="row" spacing={0.5}` (control + label), and the `LinearProgress`'s `height: 6` are
-the likely levers — raise spacing values and/or bar height/thickness so the card reads as roomier.
-No prescribed exact values; operator did not send further numeric guidance beyond the "airier, not
-wider" direction — use reasonable judgement (e.g. spacing bumped by ~50%, bar height 8-10px) and
-**flag this specific change for a live screenshot check before considering it closed** — same
-disclosed-limitation pattern as MSG-6h's reaction-spacing fix (no staging credentials this round).
-
-**C. Poll percentage denominator: respondents of this poll, not sum of votes cast.**
-
-**This reverses an explicit non-goal from `MSG-6g`'s own envelope**, confirmed deliberately by the
-operator in this round (not an oversight): MSG-6g stated *"Denominator: total votes cast, not
-participant count. A poll's turnout relative to group size is a different question and is not in
-scope."* — operator's correction: for a **multi-select** poll, summing `vote_count` across options can
-exceed the number of people who actually answered (one person can vote for several options), so a
-per-option percentage computed against that inflated sum reads as misleadingly low and the bars
-don't sum to a sensible 100%. The new denominator: **the number of distinct people who cast at least
-one vote in this poll** — not total conversation participants (an un-started, never-voting group
-member should not silently deflate everyone else's percentages further).
-
-Compute this **client-side, no backend change**: `serialize_poll`'s existing `option.voters` arrays
-(already present, already used for the viewer's-own-vote marking) already carry every voter's id per
-option — the union of all options' `voters` arrays, deduplicated, is exactly "everyone who answered
-this poll." Replace `PollCard.jsx`'s current
-`totalVotes = options.reduce((sum, option) => sum + (option.vote_count ?? option.voters?.length ?? 0), 0)`
-with a respondent count derived from the union of `option.voters` across all options (a `Set` of voter
-ids). **Zero-vote rendering must stay `NaN`-free** (existing guard, do not regress it) — zero
-respondents still means 0% for every option, not a division error.
-
-**D. Composer emoji picker: its own, wider curated list, decoupled from reaction quick-picks.**
-
-`Composer.jsx:144` currently reuses `QUICK_EMOJIS` from `ReactionBar.jsx` (`['👍', '❤️', '😂', '🎉',
-'👀']`, 5 entries) — the same tiny set meant for quick message reactions, not for composing free-form
-text. Operator confirmed direction after discussion: mobile users already have a full native emoji
-keyboard (no in-app work needed there); desktop users lack an obvious equivalent, so a **wider curated
-grid (~20-30 common emojis)** in the Composer's own picker adds real value. **Not** a full
-search-based picker (out of scope — meaningfully more engineering for a need mobile already covers).
-
-Define a new, separate constant (e.g. `COMPOSER_EMOJIS` in `Composer.jsx` itself, or a shared
-`emojiSets.js` if that reads cleaner) with ~20-30 common emojis, grouped loosely by theme (smileys,
-gestures, hearts, objects/travel — operator did not specify an exact list; use a reasonable, common
-default and flag it as easily adjustable). Render as a grid inside the existing `Menu` (currently a
-plain vertical `MenuItem` list — at 25-30 entries that would be a very long scroll; switch to a
-wrapping grid layout, e.g. a `Box` with `display: grid` or `flexWrap`, inside the `Menu`). Keep
-`ReactionBar.jsx`'s own `QUICK_EMOJIS` untouched (5, curated, unchanged) — reactions stay small and
-fast, this is a Composer-only change.
-
-## NON-GOALS / DO NOT TOUCH
-- Do not touch `ReactionBar.jsx`'s own reaction UI or its 5-emoji `QUICK_EMOJIS` — scope D adds a
-  second, separate, larger set for the Composer only.
-- Do not widen the message bubble's `maxWidth` (`MessageBubble.jsx`) — scope B is internal spacing
-  only, confirmed explicitly by the operator.
-- Do not touch `MessageBubble.jsx`'s reaction-overlap fix from MSG-6h, or the lightbox/context-menu
-  logic from MSG-6h — this WO only resizes the tile (scope A), doesn't change its interaction model.
-- No backend change for scope C — the data needed already exists in the current API response.
-- Do not build a full emoji search/picker component (scope D) — a curated grid only.
-
-## RISKS
-- Scope C is a **behaviour change visible to every host app** the moment this version is consumed —
-  a poll's displayed percentages will differ from before for any multi-select poll where the same
-  person voted for multiple options. State this plainly; it is the operator's own explicit correction,
-  not a silent reinterpretation.
-- Scope A's larger tile changes vertical rhythm inside a message bubble containing attachments —
-  check it doesn't visually crowd the meta row (timestamp/read-ticks) directly below it.
-- Scope B and D have no prescribed exact values — implement a reasonable default, disclose the
-  specific choices made (spacing multipliers, the exact emoji list) in the completion note so the
-  operator can request a numeric tweak without re-deriving what was chosen.
-
-## REQUIRED TESTS TO WRITE
-Narrow and behavioural. Do NOT run the full suite.
-
-1. Attachment tile renders at 120×120 (image and non-image cases).
-2. Poll respondent-count denominator: a multi-select poll where one voter voted for two options must
-   show percentages based on the **respondent count** (e.g. 1 respondent → both their chosen options
-   show 100%, not summed-and-diluted), not `sum(vote_count)`. This must **fail against the current
-   `sum(vote_count)` code** — prove it with a case where the two differ (multi-select, one voter,
-   two options voted).
-3. Poll respondent-count denominator: the existing single-choice zero-vote case still shows 0%, no
-   `NaN`, no regression (reuse/extend the existing MSG-6g zero-vote test's assertion shape).
-4. Composer emoji picker: opening it shows more than 5 emoji options (the expanded set, not
-   `ReactionBar`'s `QUICK_EMOJIS`); selecting one still inserts it at the cursor position (existing
-   `insertEmoji` behaviour, unchanged — just fed from the new list).
-5. `ReactionBar`'s own picker is unaffected — still exactly its original 5 `QUICK_EMOJIS` (regression
-   guard that scope D didn't leak into scope-unrelated reaction UI).
-
-## TEST SCOPE FOR THE GATE (orchestrator)
-Attachment-, poll-, and Composer-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;
-the jg-ferien pin bump is part of THIS WO's completion, not a deferred step (standing correction this
-session: publish alone is not delivery).
-
-## MINI-HANDOVER (pastable)
-
-> Repo: `C:\Users\biglmi\Documents\webapps\ui-core-micha` (branch `main`). Work order:
-> `work-orders/MSG-6i.md` — read it fully, then follow the `orchestrate-codex` skill.
->
-> Four independent scopes: (A) attachment tile 64px→120px in `AttachmentList.jsx`. (B) `PollCard.jsx`
-> internal spacing increased ("airier, not wider" — bubble maxWidth unchanged) — no exact numbers
-> given, use judgement, flag for a live screenshot check. (C) poll percentage denominator changes from
-> `sum(vote_count)` to the count of distinct respondents (union of all options' `voters` arrays,
-> client-side, no backend change) — **this deliberately reverses an explicit MSG-6g non-goal**, operator
-> re-confirmed. (D) Composer's emoji picker gets its own ~20-30-entry curated grid, decoupled from
-> `ReactionBar`'s 5-entry `QUICK_EMOJIS` (untouched) — no full search picker, mobile already has a
-> native one.
-
-## 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 — `AttachmentList.jsx`
-Tile `sx={{ width: 64, height: 64, ... }}` → `120, 120`. Non-image tile's icon bumped
-`fontSize="small"` → `"large"` and its `Stack` spacing `0.25` → `0.75` — the original
-small icon+caption pairing read sparse against the much larger tile.
-
-### Scope B — `PollCard.jsx` spacing
-Outer `Paper` padding `p: 1` → `1.5`; outer `Stack` (question/options/close-row) spacing
-`0.75` → `1.5`; per-option `richLabel` `Stack` spacing `0.25` → `0.75`; `LinearProgress`
-`height: 6` → `8`. No exact values were specified by the operator beyond "airier, not
-wider" (confirmed via a screenshot of the cramped original) — **not independently
-visually re-verified against a fresh screenshot before closing** (no staging/live
-credentials for this specific check this round); flagging per the same disclosed-
-limitation pattern as MSG-6h's reaction-spacing fix.
-
-### Scope C — `PollCard.jsx` percentage denominator
-`totalVotes = sum(option.vote_count)` replaced with
-`respondentCount = new Set(options.flatMap(option => option.voters || [])).size` — the
-count of distinct people who voted for *any* option, computed client-side from data
-already present in the response (`voters` arrays, already used for the viewer's-own-vote
-marking). `percent` now divides by `respondentCount`.
-
-### Scope D — `Composer.jsx` emoji picker
-New `COMPOSER_EMOJIS` (28 entries) defined locally in `Composer.jsx`, rendered as a
-7-column CSS grid of `IconButton`s inside the existing `Menu` (replacing the old
-`QUICK_EMOJIS.map(... <MenuItem>...)` vertical list — `MenuItem` import removed, now
-unused). `ReactionBar.jsx`'s own `QUICK_EMOJIS` (5, curated) untouched.
-
-### Companion fix found and fixed — `Thread.jsx` (not in this WO's original scope)
-Discovered while live-verifying jg-ferien's `MSG-18` (mobile Composer hidden behind the
-fixed bottom nav) in the *same* browser session as this WO's own work: after fixing every
-jg-side layout offset, the Composer was **still** rendering behind the nav. Root cause
-traced into this package: `Thread.jsx`'s root `<Stack>` had no `flex`/`minHeight`, and its
-scroll `Box` used a **hardcoded `maxHeight: 560`** — neither participates in a host's
-flex-column layout at all, so on a short mobile viewport the thread never shrinks to fit,
-regardless of how correctly the *host* sizes its own containers. Fixed: both the root
-`Stack` and the scroll `Box` gained `flex: 1, minHeight: 0` (the classic flex-item
-`min-height: auto` trap — a flex item won't shrink below its content's natural size
-without this). `maxHeight: 560` kept as an upper-bound fallback, so a host that does
-**not** embed `Thread` in a flex-column context sees **zero behaviour change** (both new
-properties are no-ops outside a flex context). Live-verified end-to-end (see MSG-18's own
-as-built record in jg-ferien for the full trace): the composer moved from `top: 742`
-(inside the fixed nav's own `740–812` range) to `top: 629.5` (a clean 64px gap above the
-nav at `740`), by locally building this package's `dist/` and patching it into jg's
-`node_modules` for verification — no publish needed to prove the fix, but IS needed to
-actually ship it (bundled into this same release, not deferred).
-
-### Tests
-`tests/messagingMsg6i.test.jsx` (new) — 7 tests: all 5 WO-required cases, one extra
-(emoji-insertion behaviour still works from the new grid), plus a 6th added post-review
-(see R3 below) asserting `Thread.jsx`'s `flex`/`minHeight` are actually applied.
-
-### Verification (pre-review)
-Full suite 249 → 255 (6 new), `tsc` clean.
-
-### Independent review — `reviewer` + `ui_reviewer`, both run in parallel, findings + fixes
-
-Both reviewers independently converged on the same P2 keyboard-navigation regression
-(scope D) — treated as one finding below (R1/U1).
-
-- **R1/U1 (P2, confirmed by both reviewers) — Composer's emoji grid broke MUI `Menu`'s
-  arrow-key roving-focus.** Nesting the 28 `IconButton`s inside an intervening
-  `<Box role="group">` meant `MenuList`'s `moveFocus` (which only traverses **direct**
-  children) saw a single non-tabbable child, so ArrowDown/Up/Home/End all became dead —
-  none of the 28 buttons reachable via the menu's own keyboard model, and nesting
-  `role="button"` descendants under `role="menu"` isn't a conformant ARIA pattern either.
-  **Fixed**: swapped `<Menu>` for `<Popover>` (`Composer.jsx`) — a grid of plain buttons
-  was never actually a linear menu, so this stops advertising semantics it can't deliver
-  and leaves keyboard traversal to the browser's native Tab order, which does reach every
-  button. Replicated Menu's default `anchorOrigin`/`transformOrigin`
-  (`{vertical:'bottom',horizontal:'left'}` / `{vertical:'top',horizontal:'left'}`) so the
-  picker's on-screen position is unchanged.
-- **R2 (P2, `reviewer`) — optimistic vote could desync `vote_count` from `voters`.**
-  `MessagingProvider.applyOptimisticVote` bumped `vote_count` unconditionally but only
-  updated `voters` when `userId` was known (a documented "brief window" before
-  `AuthContext` populates `user` — in practice also the default state for any host/test
-  that doesn't wrap `MessagingProvider` in `AuthContext` at all, confirmed while fixing
-  this). Scope C's new `respondentCount` denominator reads only from `voters`, so that
-  window could show a transiently inconsistent/>-100% percentage. **Fixed**: added a
-  sentinel (`OPTIMISTIC_ANONYMOUS_VOTER`, a space-prefixed string no real UUID can match)
-  used in place of `userId` in `voters` when it's unknown, so `vote_count` and `voters`
-  move together in every case — the real vote still overwrites this on
-  reconcile/revert. Re-ran every existing poll-vote test
-  (`messagingMsg6g/Interactions/PollRendering/CompactBubble/Api`) to confirm the
-  already-tested optimistic-count behaviour (which relies on the no-`AuthContext` test
-  shape) still holds — it does.
-- **R3 (P2, `reviewer`) — `Thread.jsx`'s flex/minHeight companion fix had zero regression
-  coverage**, and the "not meaningfully assertable via jsdom" justification didn't hold up
-  (this WO's own tile-size test already proves resolved `sx` values ARE readable via
-  `getComputedStyle` without real layout). **Fixed**: added test 6 to
-  `tests/messagingMsg6i.test.jsx`, asserting `flexGrow`/`minHeight` on both `Thread`'s
-  root `Stack` and scroll `Box`, plus that `maxHeight: 560` is still present as the
-  fallback cap.
-- **U2 (P3, `ui_reviewer`) — hardcoded `fontSize: '1.15rem'`** on the per-emoji
-  `IconButton`. No existing theme/typography token covers emoji-glyph sizing (checked
-  `ReactionBar.jsx`'s own emoji rendering for precedent — none exists there either).
-  **Not fixed** — P3, no clear correct token to switch to; noted here rather than
-  silently dropped.
-- **U3 (P3, `ui_reviewer`) — the emoji grid reused `MessagingComposer.ADD_EMOJI`** as its
-  `role="group"` `aria-label`, identical to the trigger button's own label, so a screen
-  reader announces "Add emoji" twice back-to-back. **Fixed**: added a dedicated
-  `MessagingComposer.EMOJI_PICKER` key ("Choose an emoji" / "Emoji auswählen" / "Choisir
-  un emoji") for the grid.
-- **R4 (P3, `reviewer`) — test 4b's assertion (`input.value.length > 2`) didn't prove
-  cursor-position insertion**, only that something got appended. **Fixed**: rewrote it to
-  match the exact expected string at a mid-string cursor position (same shape as the
-  pre-existing `messagingComposerChunk5.test.jsx` assertion).
-- **R5 (P3, `reviewer`) — residual, not fixed**: the 120px tile stretches whatever
-  `getAttachmentThumbnail` returns via `objectFit: cover`; if that thumbnail is
-  server-sized for the old 64px target, the larger tile could show blur. Not verifiable
-  from this repo (backend-controlled, untouched by this WO) — flagged as disclosed
-  residual risk, consistent with scope B's own "no live screenshot check this round" note.
-
-### Verification (post-review)
-Full suite (single-forked to avoid an unrelated vitest worker-pool timeout seen under the
-default parallel pool): **45 test files, 256/256 passed** (255 + 1 new). `tsc -p
-tsconfig.build.json --noEmit` clean.

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

@@ -1,117 +0,0 @@
-# WORK ORDER MSG-6j — poll option row collides with its vote count under a tight bubble width
-
-**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 screenshots from `jg-ferien` production, 2026-08-04:
-a poll option's label text runs directly into its vote-count/percent text with **zero visible gap**
-("soidfsdoöifn**2** (100 %)" — the bold "2" is the vote count, not part of the option text). The
-percentage math itself is confirmed correct once both votes had landed (a second screenshot showed
-"2 (100 %)" / "1 (50 %)" as expected) — **this WO is width/layout only, no data or percentage logic
-change.**
-
-## TIER
-Tier 2 — `ui-core-micha` is shared-core, which forces Tier 2 regardless of change size per AGENTS.md.
-Independent `reviewer` mandatory. No `sec_reviewer` needed (pure layout, no data/permission surface).
-
-## ROOT CAUSE — verified against the landed code (`src/messaging/PollCard.jsx`, `MessageBubble.jsx`)
-
-`MessageBubble.jsx:100` sizes every message bubble as `width: 'fit-content', maxWidth: 'min(75%, 680px)'`
-— it shrinks to exactly the width its content needs, with **no minimum floor**. Inside a poll,
-`PollCard.jsx`'s `optionLabel()` renders each option's label and its `resultText` ("{count} ({percent}
-%)") in a `Stack direction="row" justifyContent="space-between"` with **no `spacing`/`gap`** of its
-own (`:112-116`). `justifyContent: 'space-between'` only inserts space when the row has *leftover*
-width beyond what its children need — but here the bubble's own width is derived FROM this exact
-content (`fit-content`), so by construction there is no leftover space, and space-between reserves
-**zero minimum gap**. The label (`Typography noWrap`, which MUI resolves to
-`overflow:hidden;textOverflow:ellipsis;whiteSpace:nowrap`) shows its full text without truncating
-because the row isn't actually being squeezed narrower than content — it's exactly content-width, so
-label and result text end up flush against each other with nothing between.
-
-Two independent, additive fixes, both needed (confirmed by re-reading the code, not guessed):
-
-1. **Give the label/result row an explicit minimum gap that `space-between` cannot collapse to zero.**
-   Add `spacing={1}` (or equivalent `gap`) to the `Stack direction="row" justifyContent="space-between"`
-   at `PollCard.jsx:113` (inside `optionLabel()`'s `richLabel`). MUI's `Stack` applies its `spacing`
-   prop as margin between children, independent of `justifyContent` — this guarantees a floor gap
-   even when the row has no leftover width to distribute.
-2. **Give the poll card itself a sensible minimum width** so a short question/option set doesn't pull
-   the whole bubble in tighter than is comfortable to read (the operator's "insbesondere in der Breite
-   mehr Platz" — more room specifically in width). Add a `minWidth` to the `Paper` at
-   `PollCard.jsx:123` (e.g. `minWidth: 280` — pick a value that reads comfortably at this repo's base
-   font size; check against `MessageBubble.jsx`'s own `maxWidth` ceiling so a minWidth poll never
-   exceeds the bubble's own max on a narrow viewport — clamp or use `Math.min` logic if needed, verify
-   in the browser at a mobile width e.g. 375px, not just desktop).
-
-## NON-GOALS / DO NOT TOUCH
-
-- Do not touch percentage/vote-count computation (`respondentCount`, `optionLabel`'s `percent`
-  calculation) — confirmed correct by the operator's second screenshot; this WO is layout-only.
-- Do not touch `MessageBubble.jsx`'s own `maxWidth`/`width: fit-content` — other message kinds
-  (plain text, attachments, announcements) rely on that tight fit; scope the fix to the poll's own
-  minimum, not a global bubble-sizing change.
-- Do not touch `applyOptimisticVote`, `castPollVote`, or any vote-casting logic.
-
-## RISKS
-
-- A `minWidth` on the poll `Paper` that isn't reconciled against `MessageBubble`'s `maxWidth` could
-  overflow the bubble container on a narrow mobile viewport (375px) if chosen carelessly — verify at
-  that width explicitly, not just desktop, per the WO's own note in `PollCard.jsx`'s existing
-  accessibility comment about width assumptions.
-- `spacing` on a `Stack` that already has other margin/padding assumptions elsewhere in the row could
-  shift alignment of the progress bar below it (`LinearProgress` sits in the same parent `Stack`,
-  outside the row) — verify visually that the bar still aligns with the row above it.
-
-## REQUIRED TESTS TO WRITE
-
-Narrow, matching this repo's existing `PollCard` test conventions — extend
-`tests/messagingPollRendering.test.jsx` (the file covering poll rendering today) rather than
-inventing a new file. `tests/messagingMsg6i.test.jsx` and `messagingMsg6g.test.jsx` are the other two
-poll-adjacent suites; skim them for the established assertion style before writing new tests.
-
-1. A poll with a short question/options renders its `Paper`/container at at least the chosen minimum
-   width (assert a computed style or a `sx` prop value — whatever this repo's existing width
-   assertions already use elsewhere, e.g. `MessageBubble`'s own tests, follow that pattern).
-2. The label/result-text row has non-zero spacing between its two children even when both are their
-   natural (non-ellipsized) width — a regression test for the exact reported bug: render a poll with
-   one option's label + result text combined width close to the container's available width, assert
-   there is a rendered gap (e.g. via a wrapping element's `gap`/margin style, or simply that the
-   two `Typography` nodes are not adjacent DOM siblings with zero computed margin — use whatever
-   assertion style this repo's other spacing regression tests already use, e.g. MSG-6i's own
-   `getComputedStyle`-based test for `Thread.jsx`'s flex fix, same technique).
-
-**Non-vacuity:** test 2 must fail against the pre-fix code (space-between with no `spacing`) — verify
-that before considering this WO done.
-
-## VERIFICATION
-
-Live browser check at both a normal desktop width and a 375px mobile width (this repo's own
-established convention per prior MSG-6 WOs) with a real poll: two options with realistic-length text,
-confirm the label and vote-count/percent never visually touch, and the card is not uncomfortably
-narrow for a two-option poll.
-
-## TARGET REPO
-
-`C:\Users\biglmi\Documents\webapps\ui-core-micha` (branch `main`, no `develop` in this repo).
-
-## MINI-HANDOVER (pastable)
-
-> Repo: `C:\Users\biglmi\Documents\webapps\ui-core-micha` (branch `main`). Work order:
-> `work-orders/MSG-6j.md` — read it fully, then follow the `orchestrate-codex` skill.
->
-> `PollCard.jsx`'s option row uses `justifyContent: space-between` with no `spacing`, inside a message
-> bubble that is `width: fit-content` — so there is never leftover space for space-between to
-> distribute, and the option's label text runs directly into its vote-count/percent text with zero
-> gap. Fix: add `spacing` to that row, and add a sensible `minWidth` to the poll's `Paper` (reconciled
-> against `MessageBubble.jsx`'s `maxWidth: min(75%, 680px)` ceiling, verified at 375px too). No
-> percentage/vote-count logic changes — that part is already correct.
-
-## 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/NOTIF-12.md

@@ -1,214 +0,0 @@
-# WORK ORDER NOTIF-12 (ui-core-micha + django-core-micha) — popup channel via the wizard renderer
-
-**EXECUTION DIRECTIVE.** 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). Seams verified against ucm 2.12.0 / dcm 2.32.0.
-
-## HARD GATE — SATISFIED 2026-07-30
-NOTIF-13 landed and published: ucm **2.13.0** (`7a83ee9`), dcm **2.33.0** (`de77335`), both verified
-live on npm/PyPI. This WO was re-verified against the landed code on 2026-07-30 and the context
-package below describes the **actual shipped API**, not the pre-NOTIF-13 state. Cleared to start.
-
-## TIER
-Tier 2 — this extracts a renderer out of `OnboardingWizard`, which **cockpit and jg run in
-production**. The roadmap calls the popup channel "uncritical"; that refers to business urgency, not
-blast radius. Independent `reviewer` mandatory. `sec_reviewer` only on explicit operator request.
-
-## SCAFFOLDING NOTICE — READ FIRST
-**This channel ships with zero producers, deliberately.** Verified 2026-07-29 across dcm, jg-ferien,
-cockpit, hram, spesix and survey_app: **no notification type declares `popup` in `eligible_channels`**,
-so `resolve_channels()` will never route anything to it until some app opts a type in. The operator
-decided to build the scaffolding anyway (2026-07-29), having been shown this.
-
-Two obligations follow, and they are part of the acceptance criteria:
-1. **Do not overclaim.** The CHANGELOG entry and any docstring must state plainly that the popup
-   channel is wired but inactive until a notification type declares `popup`. Precedent: NOTIF-4's
-   reviewer (R1) had to soften a CHANGELOG that promised retry behaviour no shipped dispatcher could
-   reach. Do not repeat that.
-2. **Scaffolding must be tested scaffolding.** Register a test-local notification type that declares
-   `popup` and prove the whole path end-to-end. Untested dead code is not an acceptable outcome.
-
-## GOAL
-Make `popup` a real delivery channel: a notification whose type opts into `popup` is rendered to the
-recipient in a modal that reuses the onboarding **wizard renderer**, with its seen/dismissed status
-recorded on `NotificationRecipient` — **not** in the onboarding progress store.
-
-## EXPECTED OUTCOME
-- dcm's `PopupDispatcher` stops being a logging stub and delivers for real.
-- ucm exports a popup surface that renders popup-eligible notifications and marks them via the
-  existing `feed/mark/` path.
-- Onboarding behaviour is bit-for-bit unchanged for existing consumers.
-- With no producer registered, nothing visibly changes in any app.
-
-## CONTEXT PACKAGE — verified current state
-
-**dcm `notifications/dispatch.py`:**
-- `PopupDispatcher` (`:117-121`) is a stub: logs "queued for unimplemented popup channel" and returns
-  `DeliveryResult(ok=None, error="pending")`. It is registered in `_DISPATCHERS` (`:126-133`).
-- The model to copy is `ChipDispatcher` (`dispatch.py:64-75`, post-NOTIF-13): it calls
-  `push_to_users([recipient.user], notification_envelope({"type": notification.notification_type, "content": ..., "notification_id": ...}))`
-  and returns `DeliveryResult(ok=True)`.
-
-**How NOTIF-13 actually shipped — read this before writing scope D.** The envelope is a
-**domain-level** discriminator, not a per-channel one:
-- `delivery.py:25` `NOTIFICATION_ENVELOPE = "notification"`; `delivery.py:28-35`
-  `notification_envelope(payload)` merges `{"envelope": "notification"}` into any payload. **Additive**
-  — the pre-existing fields, including the overloaded `type`, are unchanged.
-- ucm `src/notifications/realtime.jsx:68` routes purely on `data.envelope ?? DEFAULT_ENVELOPE`, then
-  fans to every handler subscribed to that envelope.
-- **Inside** the notification envelope, `NotificationsProvider` keeps the original two-way split:
-  `data.type === 'notification.status'` patches status (`:98`), and **everything else is appended to
-  the feed with `unreadCount + 1`** (`:120`).
-
-**Consequence — the trap this WO must avoid:** if `PopupDispatcher` simply calls
-`notification_envelope({...})` like Chip does, its message is **indistinguishable from a chip
-message**. The popup surface subscribing to the `"notification"` envelope would receive every chip
-notification and pop up for all of them, and a notification routed to *both* chip and popup would
-produce **two feed entries and `unreadCount + 2` for one notification**. Scope D and D2 below exist
-to close exactly this.
-- `_render_content(content, user)` (`:44-60`) renders `title_key`/`body_key`/`params` in the
-  recipient's language — reuse it rather than re-deriving text client-side if the payload needs text.
-- `prefs.py:22` already treats `popup` as a channel defaulting to True; `router.py:24` narrows to
-  `ntype.eligible_channels`. **No prefs or router change is needed** — only a type opting in.
-
-**ucm `src/onboarding/OnboardingWizard.jsx` (75 LOC)** is the renderer to reuse:
-- MUI `Dialog open fullWidth maxWidth="sm"` (`:59`), `DialogTitle` with a step counter +
-  `LinearProgress` (`:60-67`), `DialogContent` rendering
-  `<StepComponent onComplete={...} onDismiss={...} ctx={...} />` (`:69`).
-- Step contract: `{ id, Component, blocking, persistDismissed }`. `blocking` disables escape/backdrop
-  close (`:59`).
-- **The parts that must NOT come along** (design decision D-F7,
-  `django-core-micha/docs/design/notifications-platform.md:70-71`): `onboarding.markStepSeen` (`:35`),
-  `dismissStep` (`:54`), and the sequential progress store behind them. Popup status lives on
-  `NotificationRecipient`.
-- Exported at `src/index.js:61`; the four existing steps at `:62-65`.
-
-**ucm notification status API:** `useNotifications()` already returns `markSeen` / `markDismissed` /
-`markDone`, backed by `feed/mark/`. Use `markSeen` when a popup is shown and `markDismissed` when the
-user closes it. **Never `markDone`** — done is a todo-channel semantic.
-
-## SCOPE
-
-**A. ucm — extract the dialog shell.** Lift the presentational shell out of `OnboardingWizard` into a
-reusable renderer (dialog frame, counter/progress header, the `onComplete`/`onDismiss`/`ctx` child
-contract). `OnboardingWizard` keeps its current behaviour by composing that shell with the onboarding
-store; the popup surface composes the same shell with notification state.
-
-**B. ucm — the popup surface.** A component that renders popup-eligible notifications through the
-shell, marks `seen` on display and `dismissed` on close. For live popups it subscribes via
-`useRealtime()` to the **`"notification"` envelope** (`DEFAULT_ENVELOPE` — there is no popup-specific
-envelope, see D) and filters on `channel === "popup"`, ignoring `notification.status` messages and
-channel-less legacy payloads. Export additively from `src/index.js`.
-
-**C. Coexistence rule with onboarding — specify and test it.** Both surfaces render a MUI `Dialog`, so
-two modals can be open at once. Required behaviour: **a blocking onboarding step wins**; the popup
-waits until no blocking onboarding step is active. Non-blocking coexistence must not stack two dialogs.
-
-**D. dcm — implement `PopupDispatcher.deliver`, with a channel discriminator *inside* the envelope.**
-Emit through `notification_envelope()` (so Layer-1 routing stays domain-keyed and messaging can still
-ride alongside) and add an explicit **`"channel": "popup"`** field to the payload. Return
-`DeliveryResult(ok=True)`. Keep delivery-record semantics identical to `ChipDispatcher` — the
-surrounding `dispatch()` machinery already records pending → sent/failed; do not re-implement it.
-
-**Do NOT invent a second envelope value** (e.g. `"notification.popup"`). The envelope discriminates
-*domains* so a future messaging stream can share the socket; overloading it with channels would
-undo NOTIF-13's design. Channel selection belongs inside the payload.
-
-For symmetry and so the client can tell the cases apart, `ChipDispatcher` should carry
-`"channel": "chip"` as well. **Backward compatibility:** a payload with **no** `channel` field must
-keep behaving exactly as today (feed entry + unread increment), because an app pinned to an older dcm
-will still send channel-less payloads.
-
-**D2. ucm — de-duplicate by `notification_id` in `NotificationsProvider`.** A notification routed to
-both chip and popup now produces two WS messages. The provider must fold them into **one** feed entry
-and **one** unread increment (de-dupe on `notification_id`, last-write-wins on content). Without this,
-enabling popup alongside chip double-counts the badge. This is an edit to `NotificationsProvider`,
-which is explicitly in scope here — it is not part of NOTIF-13's realtime core.
-
-## DO NOT TOUCH
-- **The onboarding progress store** — `markStepSeen`, `dismissStep`, `persistDismissed` persistence,
-  `OnboardingProvider`'s step-selection semantics, `stepSelection.js`.
-- The four existing step components (`CookieConsentStep`, `CompleteNameStep`, `BrowserPushStep`,
-  `PwaInstallStep`) and their props.
-- **NOTIF-13's realtime core** (`src/notifications/realtime.jsx`) — consume `useRealtime()` /
-  `subscribe(envelope, handler)`, do not restructure it. In particular leave the `seeded` gate, the
-  backoff/reconnect semantics and the envelope-routing alone. (`NotificationsProvider` itself IS
-  editable — scope D2 requires it.)
-- `feed/*` REST contract, `NotificationBell`, `NotificationSettings`.
-- `prefs.py`, `router.py`, `resolve_channels` — popup already works there; a type opting in is an
-  app-side change, not this WO's.
-- Schema, migrations, dependencies, CI.
-- **Do not register a `popup` producer in any app.** This WO ships the channel only.
-
-## RISKS
-- **Onboarding regression** is the main risk: the shell extraction touches a wizard that cockpit and jg
-  run in production. The step counter (`totalRef`/`completed`), the session-dismissed Set, and the
-  `blocking` escape-key behaviour are easy to break silently.
-- **Stacked modals** if C is skipped — two dialogs, neither reachable.
-- **Badge double-count** if D2 is skipped: a notification routed to both chip and popup arrives as two
-  WS messages and increments `unreadCount` twice for one notification. This is the single most likely
-  silent defect in this WO.
-- **Popup storm** if B subscribes to the envelope without filtering on `channel` — every chip
-  notification would pop up a modal.
-- **Regressing the NOTIF-13 R1 fix:** the `seeded` gate in `NotificationsProvider` exists because
-  decoupling the REST seed from the socket connect opened a silent-message-loss race. Do not touch it
-  while implementing D2.
-- **Dead code rot:** with no producer, only the tests exercise the path. Hence the mandatory test-local
-  producer type.
-- **Status semantics drift:** marking a popup `done` instead of `dismissed` would pollute todo-channel
-  semantics.
-
-## REQUIRED TESTS / ACCEPTANCE
-ucm (`pnpm test`, vitest):
-- a popup-eligible notification renders in the shell; `markSeen` fires once on display;
-- closing it fires `markDismissed`, never `markDone`;
-- **coexistence:** with a blocking onboarding step active, no popup dialog renders; once it clears, the
-  popup appears — and never two dialogs at once;
-- **onboarding regression guard:** existing `OnboardingWizard` behaviour unchanged — step counter,
-  progress bar, session-dismissed set, `blocking` disabling escape/backdrop close, `persistDismissed`
-  still calling `dismissStep`;
-- with no popup-eligible notification present, nothing renders;
-- **no popup storm:** a `channel: "chip"` message and a channel-less legacy message both leave the
-  popup surface silent;
-- **no double-count (D2):** two WS messages for the same `notification_id` (one `chip`, one `popup`)
-  yield exactly one feed entry and `unreadCount + 1`;
-- **NOTIF-13 R1 guard:** the `seeded` gate still holds — no socket messages are processed before the
-  REST seed completes.
-
-dcm (`pytest` on the notifications package):
-- register a **test-local** notification type declaring `eligible_channels=["popup"]`, call `notify()`,
-  and assert the dispatcher delivered (`ok=True`) with `envelope: "notification"` **and**
-  `channel: "popup"` on the wire — the end-to-end proof required by the scaffolding notice;
-- a chip delivery still carries `envelope: "notification"` and now `channel: "chip"`, with every other
-  field unchanged (no regression for existing consumers);
-- `resolve_channels` still excludes `popup` for types that do not declare it (no accidental widening);
-- the existing `test_dispatch.py` registry assertion (`:25`) still passes.
-
-Plus `pnpm build` (tsc) green.
-
-## RELEASE
-ucm minor bump + publish. dcm minor bump + publish (publish-from-main), with a **registry live-check
-before any app pin bump**. No app pin bumps in this WO. CHANGELOG in both repos must carry the
-inactive-until-a-producer-opts-in wording from the scaffolding notice.
-
-## TARGET REPO / WORKING DIRECTORY
-- Primary: `C:\Users\biglmi\Documents\webapps\ui-core-micha`
-- Secondary (scope D): `C:\Users\biglmi\Documents\webapps\django-core-micha`
-- Never the workspace root `…\webapps`.
-Both are platform repos: commit directly to the trunk, no feature branches.
-
-## PROGRESS CONTRACT
-Emit a `PLAN: <step1> | <step2> | …` line up front, then a single-line
-`PROGRESS: [<n>/<total>] <present-tense action>` **before every relevant action** (file opened, file
-edited, command/test run) and `PROGRESS: [<n>/<total>] done` on step completion, spaced so no gap
-exceeds ~2 min. stdout unbuffered. Exactly one final `RESULT: DONE|BLOCKED <reason>`.
-
-## MINI-HANDOVER (paste into a fresh Orchestrator session)
-```
-Orchestrator: implement work-orders/NOTIF-12.md in ui-core-micha (main; scope D also touches
-django-core-micha). The NOTIF-13 gate is satisfied (ucm 2.13.0 / dcm 2.33.0). git pull, read the WO,
-then follow orchestrate-codex (Codex-first, own independent review, commit on green).
-```