@micha.bigler/ui-core-micha 3.14.3 → 4.0.0

package/work-orders/UCM-CHAT-2.md

@@ -1,75 +0,0 @@
-# UCM-CHAT-2 — Readable driver names in the chat model picker
-
-Prepared: 2026-10-15. Target repository: `ui-core-micha` (`main`). Correction to `UCM-CHAT-1`, found at acceptance.
-
-# A. Envelope — addressed to everyone
-
-## Goal and expected outcome
-
-The model picker of the shared chat surface groups its entries by driver. In the UCM-CHAT-1 implementation, each group heading shows the raw driver id the catalogue returns (`claude_cli`, `anthropic_api`, `openai_api`). The prototype `work-orders/assets/UCM-CHAT-1-ai-chat.html` shows readable names instead.
-
-Expected outcome: the three drivers that `django-core-micha/DCM-CHAT-1` ships appear under readable, translated names, both in the picker and wherever else ui-core-micha shows a driver. An unknown driver id still appears as its raw id, so a driver added later (`django-core-micha/DCM-CHAT-2`) stays usable before it gets a name.
-
-## Scope
-
-- A mapping from the three driver ids to translated names, registered in ui-core-micha's chat translations:
-
-| Driver id | en | de | fr | sw |
-|---|---|---|---|---|
-| `claude_cli` | Claude Code subscription | Claude Code (Abo) | Claude Code (abonnement) | Claude Code (usajili) |
-| `anthropic_api` | Anthropic API | Anthropic API | API Anthropic | API ya Anthropic |
-| `openai_api` | OpenAI API | OpenAI API | API OpenAI | API ya OpenAI |
-
-- The picker's group heading and the group's accessible name use the translated name.
-- Any other place in the chat surface that shows a driver uses the same name. One example is the model-change divider in the thread.
-- Unknown driver ids fall back to the raw id.
-
-## Copy list (released with this Envelope)
-
-The twelve names in the table above, verbatim. No other new text.
-
-## Non-goals
-
-- Any change to the catalogue contract or to django-core-micha. The names live in ui-core-micha.
-- Other picker behaviour, layout or styling.
-- The post-landing re-review of UCM-CHAT-1's last fix batch. That is UCM-CHAT-1's own follow-up.
-
-## Tier
-
-Tier 3: a change inside shared-core. Small and copy-only in effect.
-
-## Risks
-
-- **Id mismatch:** the ids must match exactly what DCM-CHAT-1 returns (`django_core_micha/assistant/catalogue.py`, `DRIVERS`). A mismatch silently falls back to raw ids. The existing picker test fixture uses `openai`, which is not a real driver id.
-
-## Required tests to write
-
-- Picker: groups for `claude_cli`, `anthropic_api` and `openai_api` show their translated names as heading and accessible name. Fixtures use the real driver ids.
-- Unknown driver: an entry with an unknown driver id is grouped under its raw id.
-- Translations: the three new keys exist in all four languages.
-
-# B. Implementation map — addressed to the implementer
-
-## Context package
-
-Tier 3 · tests: picker + translations (see Part A). Work from this package; do not explore broadly. Target working directory: `C:/Users/Micha Bigler/Documents/webapps/ui-core-micha` (never the workspace root).
-
-- `src/chat/ModelPicker.jsx` — `groupByDriver` groups `entries` by `entry.driver`; the group is rendered at about line 38 as `<Box key={driver} role="group" aria-label={driver}>` with `<Typography variant="overline">{driver}</Typography>`. Both the accessible name and the heading must show the translated name. `t` comes from `useTranslation()` already in the file.
-- `src/i18n/chatTranslations.ts` — one `chatTranslations` const, entries `'Chat.xxx': { de, en, fr, sw }`. Add exactly three keys, flat like the existing `Chat.effort.low`: `Chat.driver.claude_cli`, `Chat.driver.anthropic_api`, `Chat.driver.openai_api`, with the Envelope's twelve names verbatim (en/de/fr/sw columns). No other new text.
-- A small helper keeps the lookup in one place: export `driverName(t, id)` from `src/chat/ModelPicker.jsx` (or a new `src/chat/driverName.js` if cleaner) returning `t(`Chat.driver.${id}`, { defaultValue: id })`, so an unknown id falls back to the raw id with real i18next. Use it in the picker. The thread's model-change divider (`src/chat/ChatThread.jsx`, `selectionLine`) shows only model and effort, no driver; leave it unchanged. No other place in `src/chat/**` renders a driver id (verify with a search for `driver`).
-- Tests: `tests/chatPicker.test.jsx` mocks `react-i18next` with `t: (key) => key`; make the mock return `values.defaultValue` when the key starts with `Chat.driver.` and a `defaultValue` is given and the id is not one of the three known ids, and the key otherwise, so every other assertion keeps expecting keys. Update the fixture entries to the real ids `claude_cli`, `anthropic_api` (replace the fake `openai`), keep one extra fixture with an unknown id (for example `mystery_driver`). Assert: group role name and heading text for each known driver equal the translation KEY `Chat.driver.<id>` (the mocked t returns keys); the unknown id group is named by the raw id. Also assert with the REAL `chatTranslations` that the three keys exist with the Envelope's exact English names, and that each key is non-empty in de/en/fr/sw (add to `tests/chatTranslations.test.js`). `tests/chatWorkspace.test.jsx` uses `openai`/`claude_cli` ids in its catalogue fixture and finds the group by name `openai`: update that lookup to the new key-based name.
-- Do not edit: `package.json`, lockfile, CHANGELOG, README, `WORK_ORDERS.md`, anything outside `src/chat/**`, `src/i18n/chatTranslations.ts`, `tests/chat*.test.*`. No catalogue contract change.
-- Pitfall: the existing aggregate test `tests/i18nAggregate.test.js` iterates all bundle keys; every value needs all four locales as non-empty strings.
-
-## Preamble
-
-> The text above is the COMPLETE spec — the committed WO file's content, not a plan to refine; there is no separate plan file. Read the nearest `AGENTS.md`, the relevant `.codex/skills/<role>/SKILL.md`, and the app `MEMORY.md` ONLY for conventions. Stay in scope; do not touch auth/permissions/deps/schema/CI unless the spec says so; do not update `MEMORY.md`. **Do NOT edit `WORK_ORDERS.md` — the register row and the review verdicts are the orchestrator's alone.** **Your tools are for editing source and test files and for running the tests you wrote — nothing else.** Do NOT install dependencies, touch a lockfile, run a package manager, or tidy up stray files; if something in the repo state blocks you, stop and report it as `RESULT: BLOCKED <reason>` instead of fixing it. Do NOT `git add`/`commit`/`push` — leave every change uncommitted in the working tree for the orchestrator's independent review. WRITE the tests the `Required tests` section calls for AND **RUN the tests you just wrote** to confirm they execute and pass — that is the ONLY test run you do (NOT the app's affected/full suite, NOT any review). The orchestrator re-runs the authoritative set + does the independent review after you finish — those are the gate; your own run does not count as the gate.
->
-> Narrate continuously: a `PLAN: <step1> | <step2> | …` line up front, then a single-line `PROGRESS: [<n>/<total>] <present-tense action>` before every relevant action (and `… done` on completion), spaced so no gap exceeds ~2 min, stdout unbuffered, plus exactly one final `RESULT: DONE|BLOCKED <reason>`.
-
-
-# C. Orchestrator only — not addressed to the implementer
-
-> **If this WO was dispatched to you as an implementer: STOP here.**
-
-Gate #1 open until recorded in the register row. Publish as a patch release; cockpit/CP-CHAT-4 pins the release that contains it.

package/work-orders/UCM-DEP-1.md

@@ -1,63 +0,0 @@
-# UCM-DEP-1 — All open Renovate updates in one change on main, one CI run
-
-Prepared: 2026-10-15. Target repository: `ui-core-micha` (`main`).
-
-# A. Envelope — addressed to everyone
-
-## Goal and expected outcome
-
-ui-core-micha's eight open Renovate PRs land as one change on `main`, verified by one CI run. A release follows only if a runtime dependency changed; tooling-only updates need none.
-
-## Tier
-
-Tier 3: dependency changes, majors included.
-
-## Operator decisions this Envelope records (2026-10-15)
-
-1. The bundle contains these open Renovate PRs' updates, in one change on `main`:
-
-| PR | Update |
-|---|---|
-| #17 | npm non-major |
-| #18 | github-actions |
-| #19 | actions/checkout v7 |
-| #20 | actions/setup-node v7 |
-| #21 | jsdom v30 (test) |
-| #22 | pnpm v12 |
-| #23 | typescript v7 |
-| #24 | vitest v5 (test) |
-
-2. A major that needs more than small adaptations (configuration, a renamed import, a test helper) is taken out of the bundle, left as its PR, and reported with the reason. The bundle does not grow into a migration.
-3. Verification is one CI run of the repository's own CI on the candidate (for an app: a `ci-test/<ID>` ref with the full job set). A red job is fixed within decision 2 and the run repeated; not more than that.
-4. After the push Renovate closes the PRs whose update landed; a PR it rebases instead is an update that did not land and is reported.
-
-## Scope
-
-1. Dependency manifests and lockfiles, workflow `uses:` pins, image pins the updates touch.
-2. The small adaptations decision 2 allows, with tests where behaviour is touched.
-3. Each update's changelog read for breaking changes before it goes in; a breaking change the code meets is adapted (decision 2) or the update is taken out.
-4. A release per the repository's own publish procedure only when the published package's runtime dependencies changed.
-
-## Non-goals
-
-- No new features, no refactoring beyond decision 2.
-- No change to the Renovate configuration.
-- No pin bump in any consuming app.
-
-## Risks
-
-- pnpm 12 and TypeScript 7 change the build toolchain; the published bundle must stay byte-compatible in its exports. The CI's build and the kit's own tests are the check.
-
-## Required tests to write
-
-None beyond the adaptations of decision 2. The evidence is the CI run of decision 3.
-
-# B. Implementation map — addressed to the implementer
-
-*To be filled by the Orchestrator.*
-
-# C. Orchestrator only — not addressed to the implementer
-
-> **If this WO was dispatched to you as an implementer: STOP here.**
-
-Gate #1 open until recorded in the register row. Part of the PR close-out round of 2026-10-15; stagger the CI run with the other bundles of that round (one heavy run at a time on the shared runner). On 2026-10-15 the working tree carried another session's uncommitted changes to `package.json` and `pnpm-lock.yaml` (likely the dcm/ucm chat migration): the same files this bundle changes. Sequence with that session before starting; never fold its changes into this commit.

package/work-orders/UCM-I18N-4.md

@@ -1,226 +0,0 @@
-# UCM-I18N-4 — Let a consumer choose informal German, and translate the hard-coded English in the auth and user screens
-
-# A. Envelope — authored by the Expertenchat
-
-## Goal & expected outcome
-
-- Goal: an app that addresses its users with "du" gets "du" in every ucm screen, and no ucm screen
-  shows hard-coded English in a German UI.
-- Expected outcome:
-  - The kit's German strings exist in a formal ("Sie", today's default) and an informal ("du")
-    variant; a consumer picks one when it registers the kit's strings (the single export from
-    `I18N-1`). Apps that do nothing keep today's formal German.
-  - `UserListComponent`, the invite panel (`UserInviteComponent`, `BulkInviteCsvTab`) and their
-    messages use translation keys for every visible string, in all configured locales.
-
-## Context — measured 2026-09-29 in jg-ferien's local browser test (ucm 3.5.0 installed there)
-
-- jg-ferien addresses its users with "du" throughout; ucm's auth screens use "Sie" — login, signup,
-  reset request, invite and reset pages (`src/i18n/authTranslations.ts`), so the break runs through
-  one flow (`/signup` "Sie", jg's `/signup/confirm` "du"), and one page mixes both (invite page
-  heading "Sie", validation "du").
-- Hard-coded English in German UI: `UserListComponent.jsx` — "All Users", "Search",
-  "Search users...", "Rows per page:", "Successful Login", "Are you sure you want to delete this
-  user?"; invite panel — "Invite a new user", "Bulk Invite via CSV", "Upload a CSV file containing
-  email addresses. Header "email" is supported.", "Upload CSV", "Send Invites", success "Invitation
-  sent.".
-- **Operator decision 2026-09-29: generic fixes go to ucm, app-specific ones to the app.**
-
-## Scope + non-goals
-
-- In scope: the variant mechanism at registration time; the informal German variant of the auth
-  bundle; keys for the hard-coded strings above (de/en/fr at least, plus every locale the bundles
-  already carry).
-- Explicit non-goals / do-not-touch:
-  - Default behaviour for existing consumers stays formal German — no consumer changes wording
-    without opting in.
-  - Behavioural fixes of those screens are `UCM-AUTH-9`.
-
-## Tier · gates
-
-- **Tier 3** — change inside shared-core, a new public option on the registration export.
-- Reviewer: `reviewer` (all lenses) · `ui_reviewer`.
-- **Done means released and jg-ferien's pin bumped with the option set** (separate jg step).
-
-## Risks
-
-- A variant that only covers some keys silently falls back to "Sie" for the rest; a test must prove
-  key parity between the two German variants.
-- Consumers that already override ucm keys locally must keep working (override order unchanged).
-
-## Required tests to WRITE (you write them and run YOUR OWN new ones; the orchestrator's run is the gate)
-
-1. Registering with the informal option yields "du" strings for the auth pages; without it, today's
-   strings.
-2. Key parity: formal and informal German cover the same key set.
-3. `UserListComponent` and the invite panel render no hard-coded English (render in `de`, assert the
-   listed strings are absent and translated keys present).
-4. Four-locale shape test (`I18N-3`) still passes for the new keys.
-
----
-
-# B. Implementation map — filled by the Orchestrator — ADDRESSED TO THE IMPLEMENTER
-
-## Context package — two independent parts
-
-### 1. The variant mechanism + the informal auth bundle
-
-- **What "registers the kit's strings" means today, concretely** (so the mechanism plugs into the
-  real thing, not a hypothetical): every consuming app's own `i18n/index.js` imports the named
-  bundle exports (`authTranslations`, `messagingTranslations`, …) or the single aggregate
-  `uiCoreTranslations` (`src/i18n/uiCoreTranslations.js`, built by `I18N-1`) and spreads them into
-  its own i18next `resources` object — see `jg-ferien/frontend/i18n/index.js` for the exact pattern
-  (not this repo; read it for reference only, do not edit it — jg's own pin-bump/adoption is a
-  separate step, out of this WO). **No app currently imports `uiCoreTranslations` itself** (checked
-  — only per-feature bundles are imported today), so changing how the aggregate is BUILT carries no
-  live migration risk.
-- **Do not change `uiCoreTranslations`'s existing shape or behaviour** — `tests/i18nAggregate.test.js`
-  (`I18N-1`/`I18N-3`) asserts it is byte-identical to the plain merge of the 7 per-feature bundles;
-  breaking that assertion is not this WO's job. Add a NEW function alongside it instead:
-  ```js
-  // src/i18n/uiCoreTranslations.js — ADD this export, keep the existing `uiCoreTranslations` export unchanged
-  export function createUiCoreTranslations({ germanVariant = 'formal' } = {}) {
-    return Object.fromEntries(
-      Object.entries(uiCoreTranslations).map(([key, value]) => {
-        const { de_informal, ...rest } = value;
-        if (germanVariant === 'informal' && de_informal) return [key, { ...rest, de: de_informal }];
-        return [key, rest];
-      }),
-    );
-  }
-  ```
-  This is "the single export a consumer picks a variant with" (the Envelope's phrase) — a future jg
-  adoption step calls `createUiCoreTranslations({ germanVariant: 'informal' })` instead of spreading
-  `uiCoreTranslations` directly; every OTHER existing consumer is completely unaffected (they don't
-  call this function at all, and `uiCoreTranslations` itself is untouched) — this is what "no
-  consumer changes wording without opting in" means mechanically.
-- **The informal German variant itself** — add a sibling `de_informal` field to the `de` value of
-  every key in `src/i18n/authTranslations.ts` where the FORMAL wording actually depends on
-  Sie/Ihr-form address. Do NOT add `de_informal` to a key whose German text has no such dependency
-  (e.g. "E-Mail-Adresse", "Passwort", "QR-Token" read identically either way) — the function above
-  already falls back to the formal `de` value when `de_informal` is absent, so omitting it there is
-  correct, not incomplete.
-  - Find every Sie-dependent key with a word-boundary scan of each entry's `de` value against
-    `\bSie\b|\bIhr\b|\bIhre\b|\bIhrem\b|\bIhren\b|\bIhrer\b|\bIhres\b` (covers "Sie", "Ihr(e/em/en/er/es)"
-    in all inflected forms) — this repo already has one page that MIXES both forms today
-    (`Auth.MFA_RECOVERY_TITLE`'s description at `authTranslations.ts` uses "du" while
-    `Auth.PAGE_INVITE_SUBTITLE` uses "Sie" — measured, not hypothetical), so a plain "does the file
-    already use du sometimes" check is not sufficient; use the regex scan.
-  - For each matched key, write a natural informal ("du"/"dein"/"dir"/imperative-du) rewording as
-    `de_informal`, keeping the same meaning, placeholders (`{{email}}` etc. must appear identically),
-    and punctuation style as the formal version. This is a real translation task — this is a
-    shared-core kit that already ships a disclosed machine-translated Swahili bundle (`I18N-3`); do
-    the same here: **disclose in your final `RESULT:` line that the informal wording was machine-
-    translated by you (the implementing model), not reviewed by a fluent German speaker**, exactly
-    as `I18N-3` did for Swahili. Do not silently imply human review.
-- **Test file:** extend `tests/i18nAggregate.test.js` (it already imports `uiCoreTranslations` and
-  the per-bundle exports — read it first) or add a new `tests/i18nGermanVariant.test.js`, covering:
-  1. For a representative key (e.g. `Auth.PAGE_INVITE_SUBTITLE`),
-     `createUiCoreTranslations({ germanVariant: 'informal' }).['Auth.PAGE_INVITE_SUBTITLE'].de`
-     is the informal wording and does NOT match the Sie-form regex; the default call
-     (`createUiCoreTranslations()`, no argument) returns the SAME `de` value as plain
-     `uiCoreTranslations['Auth.PAGE_INVITE_SUBTITLE'].de` (today's formal string, unopted-in
-     consumers see no change).
-  2. **The real parity guard the Risk note asks for:** scan `authTranslations` for every key whose
-     `de` matches the Sie-form regex above, and assert EACH such key has a non-empty `de_informal`
-     that does NOT itself match the Sie-form regex (proves it was actually rewritten, not copied).
-     This is the test that would fail if a future key were added with formal wording only and
-     forgotten — the actual failure mode the Envelope's Risk names, not a generic "same key set"
-     check (which would be trivially true by construction here and prove nothing).
-  3. Four-locale shape test (`I18N-3`, `tests/i18nAggregate.test.js`'s existing
-     `REQUIRED_LOCALES = ['de','en','fr','sw']` check) still passes — it iterates `uiCoreTranslations`
-     itself, which is unchanged; run it to confirm, do not edit it.
-  4. Existing consumers unaffected: `uiCoreTranslations['Auth.PAGE_INVITE_SUBTITLE']` (the plain,
-     unchanged export) still equals exactly what it did before this WO — read from
-     `authTranslations.ts` directly, minus the new `de_informal` field which existing code never
-     reads.
-
-### 2. Hard-coded English in `UserListComponent`, `UserInviteComponent`, `BulkInviteCsvTab`
-
-- **Every string named in the Envelope's Context already uses `t(key, englishDefault)`** — the
-  translation KEYS are already referenced in the JSX, they are simply missing from every bundle, so
-  `t()` silently falls through to the English default regardless of locale. **In almost every case
-  the fix is adding the bundle entry, not touching the component.** Add these keys to
-  `src/i18n/authTranslations.ts` (all four locales it already carries: de/en/fr/sw — plain, correct
-  translations, NOT the informal-German mechanism from part 1, this is unrelated hard-coded-string
-  work):
-  - From `src/components/UserListComponent.jsx` (verified against the file, line refs current):
-    `UserList.DELETE_CONFIRM` (`:93`), `Common.OPERATION_FAILED` (`:278`), `UserList.NEW` (`:313`),
-    `UserList.SUCCESSFUL_LOGIN` (`:331`), `UserList.ROLE` (`:349`), `Common.ACTIONS` (`:398`),
-    `UserList.TITLE` (`:503`), `Common.SEARCH` (`:509`), `UserList.SEARCH_PLACEHOLDER` (`:510`),
-    `UserList.NO_USERS` (`:560`). (`Common.YES`/`Common.NO`/`Common.DELETE`/`Auth.EMAIL_LABEL`/
-    `Profile.NAME_LABEL` already exist — do not re-add them.)
-  - **One genuine code change, not just a bundle entry:** the `<TablePagination>` at `:581` has no
-    localisation props at all — MUI supplies its own English default "Rows per page:" directly, it
-    is not reachable via `t()` today. Add `labelRowsPerPage={t('UserList.ROWS_PER_PAGE', 'Rows per
-    page:')}` to that element, plus the new `UserList.ROWS_PER_PAGE` bundle entry.
-  - From `src/components/UserInviteComponent.jsx`: `Auth.INVITE_SENT_SUCCESS` (`:29`, `:104` in
-    `BulkInviteCsvTab.jsx` too — shared key), `Auth.INVITE_TITLE` (`:43`). (`Auth.EMAIL_LABEL`,
-    `Auth.INVITE_BUTTON` already exist.)
-  - From `src/components/BulkInviteCsvTab.jsx`: `Account.BULK_INVITE_NO_EMAILS` (`:82`),
-    `Account.BULK_INVITE_PARSE_FAILED` (`:87`), `Account.BULK_INVITE_DONE` (`:117`, has `{{ok}}`/
-    `{{total}}` interpolation — keep both placeholders in every locale), `Account.BULK_INVITE_TITLE`
-    (`:129`), `Account.BULK_INVITE_HINT` (`:132-135`, multi-line `t()` call — easy to miss with a
-    single-line grep, it IS in scope), `Account.BULK_INVITE_UPLOAD` (`:143`),
-    `Account.BULK_INVITE_SEND` (`:147`), `Account.BULK_INVITE_COUNT` (`:150`, `{{count}}`),
-    `Common.STATUS` (`:166`), `Common.DETAILS` (`:167`), `Account.BULK_INVITE_PROGRESS` (`:190`,
-    `{{done}}`/`{{total}}`), `Account.BULK_INVITE_SUCCESS_COUNT` (`:192`, `{{count}}`).
-    (`Auth.EMAIL_LABEL`, `Common.SUCCESS`, `Common.ERROR` already exist.)
-  - **`UCM-AUTH-9` already landed** (earlier in this release's sequence) and touched this SAME
-    file: it added `UserList.ROLE_UPDATE_SUCCESS` (already present, all four locales — do not
-    re-add it) and, after its own review, reused the pre-existing `Auth.SELF_SIGNUP_DISABLED` key
-    for the closed-signup message rather than adding a new `Auth.SIGNUP_CLOSED` key (that key does
-    NOT exist — do not look for it or add it).
-- Test file: extend `tests/UserListComponent`/`UserInviteComponent`/`BulkInviteCsvTab` tests if they
-  exist (grep `tests/`), or add focused new ones:
-  1. Render each of the three components with `i18n.language = 'de'` (or however this repo's test
-     harness sets locale — check an existing test that asserts translated text, e.g.
-     `tests/authTranslations.test.js`, for the pattern) and assert NONE of the literal English
-     default strings listed above are present, and the translated (German) text IS present.
-  2. Four-locale shape test (`i18nAggregate.test.js`) still passes for every new key.
-
-## Do-not-touch / invariants
-
-- Default behaviour for existing consumers stays formal German — `uiCoreTranslations` itself must
-  not change; only the new `createUiCoreTranslations` function is variant-aware.
-- Behavioural fixes of the auth screens are `UCM-AUTH-9`'s scope, not this one — this WO only adds
-  strings/keys and the variant mechanism, it does not change component logic (aside from the one
-  named `labelRowsPerPage` prop addition, which is not a behaviour change).
-- No secrets, no dependency changes — everything here is data (translation bundles) plus one small
-  pure function.
-
-## Target repo working directory (absolute)
-
-`C:\Users\biglmi\Documents\webapps\ui-core-micha` (branch `main`)
-
-## Preamble — a REQUIRED block IN this file, not something appended at invocation
-
-> The text above is the COMPLETE spec — the committed WO file's content, not a plan to refine; there
-> is no separate plan file. Read the nearest `AGENTS.md`, the relevant `.codex/skills/<role>/SKILL.md`, and the
-> app `MEMORY.md` ONLY for conventions. Stay in scope; do not touch auth/permissions/deps/schema/CI
-> unless the spec says so; do not update `MEMORY.md`. **Do NOT edit `WORK_ORDERS.md` — the register
-> row and the review verdicts are the orchestrator's alone.** **Your tools are for editing source
-> and test files and for running the tests you wrote — nothing else.** Do NOT install dependencies,
-> touch a lockfile, run a package manager, or tidy up stray files; if something in the repo state
-> blocks you, stop and report it as `RESULT: BLOCKED <reason>` instead of fixing it. Do NOT
-> `git add`/`commit`/`push` — leave every
-> change uncommitted in the working tree for the orchestrator's independent review. WRITE the tests
-> the `Required tests` section calls for AND **RUN the tests you just wrote** to confirm they execute
-> and pass — that is the ONLY test run you do (NOT the app's affected/full suite, NOT any review).
-> The orchestrator re-runs the authoritative set + does the independent review after you finish —
-> those are the gate; your own run does not count as the gate.
->
-> Narrate continuously: a `PLAN: <step1> | <step2> | …` line up front, then a single-line
-> `PROGRESS: [<n>/<total>] <present-tense action>` before every relevant action (and `… done` on
-> completion), spaced so no gap exceeds ~2 min, stdout unbuffered, plus exactly one final
-> `RESULT: DONE|BLOCKED <reason>`.
-
----
-
-# C. Orchestrator only — NOT ADDRESSED TO THE IMPLEMENTER
-
-> **If you are the implementer reading this work order as your own specification: STOP at this line.
-> Everything below describes what the Orchestrator does AFTER you finish. You do none of it — no
-> reviewers, no verification run, no register edit, no commit.**
-
-*(to be filled by the Orchestrator: execution directive; `reviewer` (all lenses) + `ui_reviewer`; release; jg-ferien pin bump with the informal option; register rows here and in jg (`JG-UX-10`).)*

package/work-orders/UCM-I18N-5.md

@@ -1,211 +0,0 @@
-# UCM-I18N-5 — User-list pagination range text is hard-coded English
-
-# A. Envelope — authored by the Expertenchat
-
-## Goal & expected outcome
-
-- Goal: the user list's pagination reads in the user's language.
-- Expected outcome: `UserListComponent`'s `TablePagination` renders its "1–4 of 4" text through a
-  translation key (de/en/fr and every locale the bundles carry), the way `labelRowsPerPage`
-  already does.
-
-## Context — measured 2026-10-01 in jg-ferien's local browser (ucm 3.7.0 installed there)
-
-- `/account?tab=users` in German: "Zeilen pro Seite: 25 ▾ · **1–4 of 4**". `UserListComponent.jsx`
-  (~l.589-600) sets `labelRowsPerPage={t('UserList.ROWS_PER_PAGE', …)}` but no
-  `labelDisplayedRows`, so MUI's English default renders. It is the only `TablePagination` in ucm.
-- Follows `UCM-I18N-4` (hard-coded English in the user list).
-
-## Scope + non-goals
-
-- In scope: `labelDisplayedRows` via a key with count interpolation; tests; release.
-- Explicit non-goals / do-not-touch: no other change to the user list.
-
-## Tier · gates
-
-- **Tier 3** — change inside shared-core (small).
-- Done means released AND jg-ferien's pin bumped.
-
-## Risks
-
-- The "more than" form (`count === -1`) must have a wording too, or it renders "of -1".
-
-## Required tests to WRITE (you write them and run YOUR OWN new ones; the orchestrator's run is the gate)
-
-1. In `de`, the pagination shows the German range text; in `en` the English one.
-2. Key-parity: every locale bundle has the new key.
-
----
-
-# B. Implementation map — filled by the Orchestrator — ADDRESSED TO THE IMPLEMENTER
-
-## Context package
-
-### The call site
-
-`src/components/UserListComponent.jsx:589-601`:
-```jsx
-<TablePagination
-  component="div"
-  count={sortedUsers.length}
-  page={page}
-  onPageChange={(_, newPage) => setPage(newPage)}
-  rowsPerPage={pageSize}
-  onRowsPerPageChange={(event) => {
-    setPageSize(Number(event.target.value));
-    setPage(0);
-  }}
-  labelRowsPerPage={t('UserList.ROWS_PER_PAGE', 'Rows per page:')}
-  rowsPerPageOptions={[10, 25, 50, 100]}
-/>
-```
-`t`/`i18n` come from `useTranslation()` (`react-i18next`), already in scope at l.53.
-
-### MUI's `labelDisplayedRows` contract
-
-MUI's own default (`node_modules/@mui/material/TablePagination/TablePagination.js:119-124`,
-for reference only — do not import it):
-```js
-function defaultLabelDisplayedRows({ from, to, count }) {
-  return `${from}–${to} of ${count !== -1 ? count : `more than ${to}`}`;
-}
-```
-The prop signature is `({ from, to, count, page }) => ReactNode`. `count` is `-1` when the total
-is unknown/unbounded — this component always passes a real `sortedUsers.length`, but the prop
-contract still has to handle `-1` defensively (the Risk note): MUI itself would call the function
-with `-1` only if `count={-1}` were passed, which this component doesn't do — handle it anyway
-since the function must satisfy the full contract, not just this component's current call site.
-
-### The translation bundle has FOUR locales, not three
-
-`src/i18n/authTranslations.ts` (flat `export const authTranslations = { "Key.NAME": { de, fr, en,
-sw }, ... }`) carries `de`/`fr`/`en`/`sw` for every existing key, confirmed by grepping all locale
-codes in the file — **sw (Swahili) is real and already translated throughout, not a stub**. "every
-locale the bundles carry" in the Envelope means these four, not jg-ferien's usual three. Add the
-new key(s) in the same shape, next to `UserList.ROWS_PER_PAGE` (~l.2050-2055) for locality.
-
-Proposed keys (interpolated, i18next `{{var}}` syntax — do not reserialize the whole file through
-`JSON.parse`/`JSON.stringify`, this is a `.ts` module, not JSON; a plain text insert keeps every
-other entry byte-identical):
-```ts
-"UserList.DISPLAYED_ROWS": {
-  "de": "{{from}}–{{to}} von {{count}}",
-  "fr": "{{from}}–{{to}} sur {{count}}",
-  "en": "{{from}}–{{to}} of {{count}}",
-  "sw": "{{from}}–{{to}} ya {{count}}"
-},
-"UserList.DISPLAYED_ROWS_MORE_THAN": {
-  "de": "{{from}}–{{to}} von mehr als {{to}}",
-  "fr": "{{from}}–{{to}} sur plus de {{to}}",
-  "en": "{{from}}–{{to}} of more than {{to}}",
-  "sw": "{{from}}–{{to}} ya zaidi ya {{to}}"
-}
-```
-The `sw` wording reuses "ya" for "of"/possessive, already used this way elsewhere in the same file
-(e.g. l.57 `"ruhusa ya kutuma mialiko"`, l.114 `"barua pepe ya kuweka upya"`) and "zaidi ya" ("more
-than") as a plain compositional phrase — a reasonable best-effort construction, NOT a
-native-speaker-verified translation; say so plainly in your own report rather than presenting it as
-settled, same as you would for any other claim you can't independently verify.
-
-Call site becomes:
-```jsx
-labelDisplayedRows={({ from, to, count }) =>
-  count === -1
-    ? t('UserList.DISPLAYED_ROWS_MORE_THAN', '{{from}}–{{to}} of more than {{to}}', { from, to })
-    : t('UserList.DISPLAYED_ROWS', '{{from}}–{{to}} of {{count}}', { from, to, count })
-}
-```
-
-### Existing test harness to extend, not duplicate
-
-`tests/userScreenTranslations.test.jsx` already renders `UserListComponent` through a REAL
-`i18next` instance pinned to German (`withGermanI18n`, ~l.22-30, built from
-`authTranslations.*.de`) and asserts rendered German strings plus `expectNoEnglishDefaults()`
-(~l.34-39, checks `document.body.textContent` against an `ENGLISH_DEFAULTS` list, ~l.33-46). The
-test `'renders UserListComponent in German, including pagination and action feedback'` (~l.97-125)
-already fetches exactly 1 user, so the pagination currently renders English "1–1 of 1" — add that
-literal string (or your chosen German text) to the existing `for (const german of [...])` loop
-(~l.115) to assert the real rendered pagination text, and add the English range phrasing (e.g.
-`'of 1'` or similar, whatever actually changes) to `ENGLISH_DEFAULTS` so `expectNoEnglishDefaults()`
-(already called at line 124) starts actually catching a regression here — today it does NOT, since
-no "of N" string is in that list, which is why this bug shipped unnoticed.
-
-Required test 1 (German vs English) is naturally satisfied by extending this file: German via the
-existing `withGermanI18n` harness, English via a parallel small i18next instance (or reuse the
-`en` resources the same way `germanResources` is built from `.de`) rendering the same component and
-asserting the English range text.
-
-Required test 2 (key-parity across all four locales) — check whether a generic "every key has
-every locale" structural test already exists in this repo (grep `authTranslations` test files for
-something like `Object.values(...).every(...)` or a locale-set check) before writing a new one;
-extend it if so, add a small standalone one for just these two new keys if not.
-
-## Target repo working directory (absolute)
-
-`C:\Users\biglmi\Documents\webapps\ui-core-micha` (branch `main`)
-
-## Preamble — a REQUIRED block IN this file, not something appended at invocation
-
-> The text above is the COMPLETE spec — the committed WO file's content, not a plan to refine; there
-> is no separate plan file. Read the nearest `AGENTS.md`, the relevant `.codex/skills/<role>/SKILL.md`, and the
-> app `MEMORY.md` ONLY for conventions. Stay in scope; do not touch auth/permissions/deps/schema/CI
-> unless the spec says so; do not update `MEMORY.md`. **Do NOT edit `WORK_ORDERS.md` — the register
-> row and the review verdicts are the orchestrator's alone.** **Your tools are for editing source
-> and test files and for running the tests you wrote — nothing else.** Do NOT install dependencies,
-> touch a lockfile, run a package manager, or tidy up stray files; if something in the repo state
-> blocks you, stop and report it as `RESULT: BLOCKED <reason>` instead of fixing it. Do NOT
-> `git add`/`commit`/`push` — leave every
-> change uncommitted in the working tree for the orchestrator's independent review. WRITE the tests
-> the `Required tests` section calls for AND **RUN the tests you just wrote** to confirm they execute
-> and pass — that is the ONLY test run you do (NOT the app's affected/full suite, NOT any review).
-> The orchestrator re-runs the authoritative set + does the independent review after you finish —
-> those are the gate; your own run does not count as the gate.
->
-> Narrate continuously: a `PLAN: <step1> | <step2> | …` line up front, then a single-line
-> `PROGRESS: [<n>/<total>] <present-tense action>` before every relevant action (and `… done` on
-> completion), spaced so no gap exceeds ~2 min, stdout unbuffered, plus exactly one final
-> `RESULT: DONE|BLOCKED <reason>`.
-
----
-
-# C. Orchestrator only — NOT ADDRESSED TO THE IMPLEMENTER
-
-> **If you are the implementer reading this work order as your own specification: STOP at this line.
-> Everything below describes what the Orchestrator does AFTER you finish. You do none of it — no
-> reviewers, no verification run, no register edit, no commit.**
-
-**Execution directive:** dispatch via `codex exec --skip-git-repo-check
---dangerously-bypass-approvals-and-sandbox -m gpt-5.6-luna - < work-orders/UCM-I18N-5.md` (today,
-2026-10-02, already recorded `available` in `webapps/.claude/codex-status.md`), cwd =
-`C:\Users\biglmi\Documents\webapps\ui-core-micha`. Monitor for `RESULT: DONE|BLOCKED`.
-
-**Review routing:** Tier 3 (shared-core) — full `reviewer` lens set (`envelope`, `regression`,
-`duplication`, `tests`, codex/gpt-5.6-luna, one concurrent batch, diff inline) PLUS `ui_reviewer`
-(frontend-adjacent: a rendered component's i18n text). `duplication` should specifically check
-whether any OTHER app already patched around this same MUI default locally (a local workaround that
-this shared-core fix should make redundant, worth naming even if out of this WO's scope to remove).
-
-**Tests:** the Orchestrator re-runs `tests/userScreenTranslations.test.jsx` (and any new/renamed
-key-parity test file) as the gate — not ucm's full suite (Tier 3 but a small, local-only change;
-no cross-app ripple to justify a full run per `AGENTS.md` → Test scope).
-
-**Release:** patch bump (3.11.0 → 3.11.1) — this extends `UCM-I18N-4`'s existing i18n-gap category
-in the same component, not a new capability area, per the project convention (version bump reflects
-scope, not mere newness). Update `package.json` + `CHANGELOG.md`, then the repo's normal publish
-path (check `.github/workflows/` or `package.json` scripts for how a previous release like
-`UCM-THEME-14`/3.11.0 or `UCM-AUTH-11`/3.9.1 actually published, don't assume `npm publish` by
-hand — follow the established mechanism).
-
-**jg-ferien pin bump:** after the release is live, bump `ui-core-micha`'s pin in
-`jg-ferien/frontend/package.json`, install, run jg-ferien's own affected tests (anything touching
-`UserListComponent` consumption, if jg-ferien renders it at all — check first; if jg-ferien doesn't
-use `UserListComponent`, the pin bump itself plus jg-ferien's existing suite staying green is the
-evidence), commit + push to jg-ferien's `develop`.
-
-**Register:** `done` only once BOTH halves land — the release AND the jg-ferien pin bump (the WO's
-own Tier line: "Done means released AND jg-ferien's pin bumped"). Row here (ui-core-micha's
-`WORK_ORDERS.md`) AND a row in jg-ferien's own `WORK_ORDERS.md` noting the pin bump, per the
-Envelope's own closing instruction.
-
-**Commit:** ui-core-micha lands on `main` (no `develop` branch here, confirmed in `AGENTS.md`'s
-branch table). jg-ferien's pin bump lands on `develop` as usual.