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

package/work-orders/UCM-AUTH-11.md

@@ -1,185 +0,0 @@
-# UCM-AUTH-11 — `UserListComponent` offers an admin the delete action on their own row
-
-# A. Envelope — authored by the Expertenchat
-
-## Goal & expected outcome
-
-- Goal: the user list never offers anyone the deletion of their own account.
-- Expected outcome:
-  - In `UserListComponent`, the row of the signed-in user renders **no** delete button — not a
-    disabled one, none at all. Every other row behaves exactly as today (enabled or disabled per
-    `canDeleteUser` / the default).
-  - This holds for every consumer, **including one that passes its own `canDeleteUser`**
-    (`AccountPage` forwards it as `userListCanDeleteUser`): a prop that returns true for the own row
-    does not bring the button back.
-  - Released; the Envelope's done-state is the release (consumer bumps are separate, see Risks).
-
-## Context — measured 2026-09-30 against `main` at 3.9.0
-
-- **Operator decision 2026-09-30 (from django-core-micha `DCM-AUTH-4`, dropped there): UI-only.**
-  The backend keeps allowing an admin's generic self-delete (`BaseUserViewSet.destroy()` refuses
-  only a non-admin's self-delete since dcm 2.44.1); the list simply stops offering it.
-- `src/components/UserListComponent.jsx`:
-  - `defaultCanEdit` (~l.128) returns true for `currentUser.is_superuser` and for role `admin` on
-    every row, the own row included (only the `teacher` branch excludes self).
-  - `canDelete` (~l.151) returns `canDeleteUser(...)` when that prop is a function, otherwise
-    `canEdit(targetUser)`.
-  - The delete button (~l.438-452) renders whenever `showDeleteAction` is true and is only
-    `disabled={!canDelete(row)}` — so a row that may not be deleted still shows a disabled button.
-- `src/pages/AccountPage.jsx` forwards `userListShowDeleteAction` (default true) and
-  `userListCanDeleteUser` (default null).
-- Consumers measured: kerzenziehen and reimbursements render `AccountPage` without these props, so
-  an admin there sees an enabled delete button on their own row today. jg-ferien passes its own
-  `userListCanDeleteUser`, which already returns false for the own row (the button shows disabled).
-
-## Scope + non-goals
-
-- In scope: the own-row rule in `UserListComponent` (identity by `id` of the row vs. the current
-  user), tests, CHANGELOG entry, release.
-- Explicit non-goals / do-not-touch:
-  - No backend change (dcm untouched).
-  - Rows other than the own row keep today's disabled-vs-enabled behaviour; no change to
-    `defaultCanEdit`.
-  - No other action on the own row changes (edit, extra row actions).
-  - Consumer pin bumps are not part of this WO.
-
-## Tier · gates
-
-- **Tier 3** — change inside shared-core, permission-adjacent UI.
-- Precondition: none.
-
-## Risks
-
-- **Reaching the two affected apps needs a major bump:** kerzenziehen and reimbursements pin
-  `@micha.bigler/ui-core-micha` **2.41.3**; 3.0.0 removed chart layout props (`UCM-CHART-12`). The
-  fix only reaches them with that bump, which is its own work per app and is classified there by
-  the dependency-bump rule.
-- The current user may be unknown while loading; with no current user the own-row rule must not
-  hide buttons on other rows or throw.
-- `id` types: compare the row id and the current user id so that `3` and `"3"` match.
-
-## Required tests to WRITE (you write them and run YOUR OWN new ones; the orchestrator's run is the gate)
-
-In `tests/UserListComponent.test.jsx`:
-
-1. Superuser, no `canDeleteUser`: own row has no delete button; another row has an enabled one.
-2. Role `admin`, no `canDeleteUser`: same as 1.
-3. `canDeleteUser` returning true for every row: own row still has no delete button.
-4. Current user not yet loaded: other rows unaffected, no error.
-5. **Mutation proof:** remove the own-row rule → tests 1 and 3 fail.
-
----
-
-# B. Implementation map — filled by the Orchestrator — ADDRESSED TO THE IMPLEMENTER
-
-## Context package
-
-- File: `src/components/UserListComponent.jsx` (current state, verified against `main` at `3.9.0`
-  post-`UCM-AUTH-10`, line numbers below are exact).
-- **The fix must gate RENDERING, not just the disabled state.** `canDelete(row)` (line 151-156)
-  already decides enabled-vs-disabled; the delete `Button` (line 441-453) already renders
-  `disabled={!canDelete(row)}`. If the own-row rule were added INSIDE `canDelete`, the button would
-  still render, just permanently disabled — that is explicitly NOT what the Envelope asks for ("no
-  delete button — not a disabled one, none at all"). The rule must wrap the render, so a consumer's
-  `canDeleteUser` returning `true` for the own row cannot bring the button back (Required Test #3).
-- Add a small helper next to `canDelete` (around line 156):
-  ```js
-  const isOwnRow = (targetUser) => {
-    if (currentUser?.id == null || targetUser?.id == null) return false;
-    return String(targetUser.id) === String(currentUser.id);
-  };
-  ```
-  - `currentUser?.id == null` (loose check, catches both `undefined` and `null`) covers the "current
-    user not yet loaded" risk: when there is no current user at all, every row's `isOwnRow` is
-    `false`, so nothing is hidden and nothing throws (Required Test #4) — this function must NOT be
-    the place that decides "hide everything while loading"; it only ever answers "is THIS row me",
-    and answers `false` when that question is unanswerable.
-  - `String(...) === String(...)` is the fix for the Risk note's `id` type mismatch (`3` vs `"3"`).
-- Wire it into the existing render condition at line 438 — change
-  `{showDeleteAction && (` to `{showDeleteAction && !isOwnRow(row) && (` (the `Tooltip`/`Button`
-  JSX inside is otherwise byte-identical — do not touch its internals, only the gating condition
-  that decides whether that whole block renders at all).
-- Do not touch `canDelete`/`canEdit`/`defaultCanEdit` (line 128-156) — the non-goal is explicit that
-  every OTHER row's enabled-vs-disabled behaviour stays exactly as today; this fix only removes the
-  own row's button, it does not change what `canDelete` returns for anyone (a consumer's
-  `canDeleteUser({ targetUser, currentUser, extraContext })` for the own row may still return
-  `true` internally — that return value is simply never consulted for the own row anymore, because
-  the render is gated before `canDelete(row)` is ever reached for that row's button).
-
-## Test file — `tests/UserListComponent.test.jsx` (existing — read it first for the render harness,
-## the `react-i18next`/`i18n` mock shape `UCM-AUTH-10` already fixed there, and `authApi` mocking
-## convention already established; extend it, do not replace its structure)
-
-Five cases, matching the Required Tests 1-5 exactly:
-1. `currentUser = { id: 99, is_superuser: true, ... }`, `fetchUsersList` resolves a list including a
-   row with `id: 99` (the signed-in user) and at least one other row (e.g. `id: 1`); no
-   `canDeleteUser` prop passed. Assert: querying delete buttons by accessible name/role yields exactly
-   one (for the OTHER row), and it is not disabled; no delete button exists for the row whose `id`
-   is `99` (e.g. scope the query to that row's `TableRow` — check how existing tests in this file
-   locate a specific row, or use `within(row)` from `@testing-library/react` if not already
-   imported).
-2. Same shape, `currentUser.role = 'admin'` instead of `is_superuser` — same assertions.
-3. Pass `canDeleteUser={() => true}` (unconditionally true for every row, including the own one) —
-   assert the own row STILL has no delete button, while the other row's is enabled (proves the
-   render-level gate wins over a consumer prop, not just over the default `canEdit`-based logic).
-4. Render with `currentUser = null` (or omit the prop) while `fetchUsersList` resolves a list
-   including a row that happens to share no id with anyone — assert the component does not throw
-   (no unhandled rejection/render error) and renders without crashing; per the Envelope's own
-   framing, unauthenticated/loading state does not by itself grant any row a delete button (this
-   test is about NOT crashing and NOT hiding unrelated rows, not about granting new permissions —
-   keep whatever the existing default-canEdit-based enabled/disabled state would be for other rows
-   in this configuration, do not assert a specific enabled/disabled state you have not verified from
-   `defaultCanEdit`'s own logic for a null `currentUser`, which already returns `false` unconditionally
-   at line 129 — so with the default `canDeleteUser`, every row is disabled-but-present in this
-   configuration; assert exactly that: buttons present and disabled, none of them thrown away).
-5. **Mutation proof required by the Envelope itself:** after writing tests 1 and 3, temporarily
-   comment out or revert the `!isOwnRow(row)` addition in your own working copy, re-run tests 1 and
-   3 ONLY, confirm both fail, then restore the fix and confirm the full focused file is green again.
-   Narrate this in `PROGRESS` (which two tests failed, then the restore) rather than leaving a
-   permanently-broken toggle in the committed test file — same pattern already used successfully in
-   this repo's own `UCM-THEME-15`/`UCM-PRIM-2` work orders for an identical "prove it would fail"
-   requirement.
-
-## Do-not-touch / invariants
-
-- No backend change (dcm is a separate repo, untouched, and out of scope regardless).
-- No change to `defaultCanEdit`/`canEdit`/`canDelete`'s return values for any OTHER row.
-- No change to any other action on the own row (role select, extra row actions) — only the delete
-  button's presence.
-- No consumer (`AccountPage`, etc.) touched — this fix is entirely inside `UserListComponent.jsx`.
-
-## 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` + `sec_reviewer`; release (patch: behaviour fix of an existing component); register row stays `released` until consumers bump; register the kerzenziehen and reimbursements bumps in their own registers; commit.)*

package/work-orders/UCM-AUTH-12.md

@@ -1,98 +0,0 @@
-# UCM-AUTH-12: Optional profile statement text on the account page
-
-# A. Envelope — operator-approved scope
-
-## Goal and expected outcome
-
-Expose `AccountPage.showProfileStatements` so an app without privacy/cookie statement
-endpoints can suppress the explanatory statement panels and their requests. The default
-is `true`, preserving every existing consumer's behavior. With `false`, the account profile
-still renders and submits both existing consent fields.
-
-The operator explicitly approved this switch, its release and the innoservice pin bump on
-2026-10-13. innoservice CI38387014900 records privacy/cookie 404s; auth policy returns 200.
-
-## Scope and non-goals
-
-- Add the optional prop and pass it to the existing ProfileComponent statement switch.
-- Publish a minor release 3.13.0; innoservice consumes it under INNO-FIX-13.
-- Do not change consent defaults, payloads, validation, permissions, authentication,
-  account navigation, statement fetching implementation, theme tokens or other consumers.
-- Do not fix UCM-SHELL-8 or invent statement endpoints/content.
-- No new visual design or prototype; this config uses the existing ProfileComponent surface.
-
-## Tier, risk and required tests
-
-Tier 3: source inside shared-core on an account surface. Compatibility rests on default true.
-Tests to write: render the real AccountPage and ProfileComponent; omission of the new prop
-fetches both statements and presents the existing panels; false performs neither request and
-hides the panels, while both consent controls remain editable and their values reach the
-existing updateUserProfile submission. Keep the existing account-navigation tests.
-
-# B. Implementation map — ADDRESSED TO THE IMPLEMENTER
-
-## Target and ownership
-
-Target: `C:/Users/Micha Bigler/Documents/webapps/ui-core-micha`.
-Native bootstrap retains workspace-root cwd; use explicit absolute paths and workdirs.
-You are not alone in the workspace. Own only:
-- `src/pages/AccountPage.jsx`
-- new `tests/AccountPage.profileStatements.test.jsx`
-
-## Context package
-
-`src/pages/AccountPage.jsx:39` exports named AccountPage with destructured optional props.
-Its profile branch near line228 renders ProfileComponent with showName/showPrivacy/showCookies.
-Its existing handleProfileSubmit calls updateUserProfile(payload), then AuthContext.login(updated).
-`src/components/ProfileComponent.jsx:23` exports named ProfileComponent; showStatements defaults
-true, independently of showPrivacy/showCookies. Its statement-loading effect at83 returns before
-either fetch when showStatements is false. Panels at255 are also controlled by showStatements.
-Consent controls at230/242 and payload at130/133 depend only on showPrivacy/showCookies.
-Use that established switch; leave this component untouched.
-
-Read only these targets plus `tests/AccountPage.test.jsx` for theme/router/AuthContext setup,
-and `src/auth/authApi.jsx` for the four API export names if necessary. Do not explore broadly.
-The existing navigation test mocks ProfileComponent, so it cannot prove the no-request and
-consent invariant: write a separate test file rendering both real components. Stub network API
-functions and unrelated account children only. Relevant real accessible labels are translation
-keys Profile.ACCEPT_PRIVACY_LABEL, Profile.ACCEPT_COOKIES_LABEL, Profile.PRIVACY_STATEMENT_TITLE,
-Profile.COOKIES_STATEMENT_TITLE and Profile.SAVE_BUTTON.
-Use the suite's established translation seam; never mock AccountPage/ProfileComponent under test.
-
-## Preamble
-
-> This committed WO is the COMPLETE spec. You are the initial implementer, not the reviewer.
-> Preserve other edits. Edit only the two owned source/test paths using explicit UTF-8 I/O.
-> Do not edit dependencies, lockfiles, package/version/changelog/register/README/governance,
-> settings, environment, other repos or memory. Never read .env or dump settings/environment.
-> No installs, package-manager commands, containers, git operations, self-review or subagents.
-> Write the required tests and run your own new file ONCE with the existing Node/Vitest runtime,
-> maxWorkers=2; no affected/full suite, build or app startup. If unavailable, report the obstacle.
-> The orchestrator's tests and separate reviews are the acceptance gate. Leave uncommitted.
-> Start PLAN, emit PROGRESS before relevant actions without silence over two minutes, then
-> exactly one final RESULT: DONE or RESULT: BLOCKED.
-
-# C. Orchestrator only — NOT ADDRESSED TO THE IMPLEMENTER
-
-> IMPLEMENTER STOP HERE. You ARE the initial implementation instance. No steps below belong to you.
-
-Gate #1: operator explicitly approved the exact API/default, retained consents, release and pin
-bump in the innoservice orchestration chat on 2026-10-13. Native plain worker requested
-codex/gpt-6-luna, fresh context, full committed WO inline. Record accepted ID and actual metadata;
-effective provider/model stays unverified when the API does not expose it. No protection-parity claim.
-
-Parent owns version/changelog/README/register and pnpm state. Independent four lenses plus UI
-and security concurrently, full scoped context, CLI read-only without bypass. Parent fixes findings.
-Scoped gate: new real-component tests, existing AccountPage navigation and affected auth tests.
-Publish workflow on main already runs build/full tests; shared-core ripple justifies that existing
-release suite. Do not dispatch publish manually; normal reviewed main push triggers it. Check
-publish job success before app pin. Minor 3.13.0 is additive; read exact release diff before app bump.
-Final core row includes deduplicated review totals and test results; second register commit before
-one main push. innoservice AccountPage/WelcomePage statements false and capture evidence remain
-INNO-FIX-13; keep existing consents, request diagnostics and capture checks intact.
-
-Accepted native implementer: `/root/kit_account_statements`, explicit requested gpt-6-luna,
-high reasoning, fresh context, complete WO inline. Effective native provider/model metadata
-was not exposed and remains unverified. Source/test edits only; the one permitted author test
-attempt failed before collection with temporary-file EPERM (zero tests). Parent runs the
-authoritative scoped gate through the normal runtime approval path. No author review or git.

package/work-orders/UCM-AUTH-13.md

@@ -1,47 +0,0 @@
-# UCM-AUTH-13 — Preserve profile edits during a same-person refresh
-
-## A. Envelope — operator-approved correction
-
-The Spesix first-steps browser trace proves that a background current-user response can arrive while the privacy checkbox is being edited. `ProfileComponent` currently resets every form field whenever the context user object changes, losing the person's input.
-
-Expected outcome: preserve unsaved name and consent edits across a background refresh of the same person. Continue to refresh untouched fields from server data. A change of person, including logout followed by login, must initialize the form from the new person's data and never transfer consent or edits between people. Initial asynchronous user hydration must still work.
-
-Scope: the existing shared ProfileComponent form state, targeted regression tests, a patch release, and subsequent Spesix dependency consumption. No change to authentication, permissions, consent policy, API payload shape, statement requests, layout or copy. No prototype; existing components and labels remain the visual specification. Token delta: EMPTY. Copy list: EMPTY.
-
-Tier 3: shared-core and profile/consent surface. Operator explicitly approved correction, checking, publication and Spesix pin update in the Spesix orchestration chat on 2026-10-14.
-
-Risks: stale pristine fields, failure to hydrate an initially absent user, or carrying unsaved consent into a different account. Tests to write: same-person object replacement preserves typed first/last names and both edited consent values in the submitted payload; untouched fields update; different identity and logout/login reset all fields; initial hydration works. Use real form controls and context rerenders.
-
-## B. Implementation map — addressed to the implementer
-
-Target: `C:/Users/Micha Bigler/Documents/webapps/ui-core-micha`.
-
-Own only `src/components/ProfileComponent.jsx` and new `tests/ProfileComponent.refresh.test.jsx`. Read `tests/AccountPage.profileStatements.test.jsx` for the existing Vitest/jsdom, MUI and AuthContext conventions; `src/auth/AuthContext.jsx` for user identity shape; and `src/pages/AccountPage.jsx` for the caller contract. The library is not a joined application: one author owns component and focused unit tests.
-
-The synchronization effect at ProfileComponent lines 56–65 currently depends on `[user]` and unconditionally assigns username, email, first/last name and both consent flags. The editable controls are near lines 205–250. `handleSubmit` near line 117 constructs the existing optional-fields payload; preserve it. Username/email remain read-only. Statement loading effects and visibility props are unchanged. AccountPage passes its profile update callback into this component. Work from these seams; do not broadly explore or change AuthContext or callers. Verify the identity contract before choosing synchronization behavior; do not use object reference as person identity.
-
-### Required preamble and progress contract
-
-The text above is the COMPLETE spec. Read root AGENTS.md and `.codex/skills/frontend-engineering/SKILL.md` only for conventions. Stay in scope. Do not edit WORK_ORDERS.md, MEMORY.md, package files, lockfiles, changelog, CI or unrelated files. Tools are only for reading the named context and editing assigned source/tests, plus one run of the new tests using the existing direct Vitest runner. No installs, package-manager commands, git, self-review or reviewer dispatch. Leave edits uncommitted. Your run is not the gate; the Orchestrator runs the affected set and independent reviews.
-
-Use explicit UTF-8 file I/O. You share this checkout: preserve all other edits, including the foreign scratchpad directory. Native cwd bootstrap is the workspace root; assigned paths and test cwd must be absolute, without changing the shared process cwd. Start with `PLAN: ...`, report `PROGRESS: [n/total] ...` at meaningful actions with gaps below two minutes, and finish with exactly one `RESULT: DONE|BLOCKED <reason>`.
-
-## C. Orchestrator only — NOT addressed to the implementer
-
-> STOP here if you are the implementer. Everything below belongs to the Orchestrator after implementation. Do not execute it or dispatch anyone.
-
-Dispatch a fresh native worker, explicit codex/gpt-6-luna, fresh context. Record requested and exposed effective metadata honestly; native provider/cwd/sandbox are unverified if not exposed.
-
-Gate #1 is the explicit operator approval recorded above. Run independent envelope, regression, duplication and tests lenses plus UI and security concurrently on the corrected diff, read-only, configured Luna. Parent checks profile payload/identity boundaries in addition. Run focused ProfileComponent and existing AccountPage tests and the build. Root owns patch metadata and publication through the existing main-push workflow; no workflow dispatch is authorized by this file. Verify published version before changing Spesix pin, and inspect the intervening 3.12.0-to-current changes. No screenshots are needed for this state correction.
-
-Foreign scratchpad is excluded. Commit only owned explicit paths. Update register with actual author, reviews, checks, release and consumption evidence; never claim completion before those checks.
-
-### Execution and gate evidence
-
-Fresh native `/root/ucm_auth13_author`, requested codex/gpt-6-luna/high, completed only the two assigned files; no git or package operations. Native provider/cwd/sandbox are not exposed. Author's one test attempt failed before collection on Windows Vitest cache EPERM. Parent authoritative elevated run passed: ProfileComponent.refresh (5) and existing AccountPage suites (6), 11 tests in 3 files. Parent added the independently edited-versus-pristine editable-fields case. Existing-dependency TypeScript build passed. Diff whitespace check passed. Root checked unchanged payload construction, statement effects, visibility flags and server-side authority; local edit tracking resets at identity/logout boundaries.
-
-Six fresh CLI codex/gpt-6-luna read-only lanes ran concurrently against the same frozen diff, including package/changelog and complete component/caller context. Each exited 0 with requested model, openai provider and library cwd confirmed in banner. Envelope, duplication, UI and security reported No findings. Regression raised mutable fallback identity for consumers without IDs: not accepted as a defect in the supported AuthContext contract, which maps the immutable API id; without an immutable identity the component cannot establish that two changed fallback identities are the same person, and preserving consent across them would weaken account isolation. Tests raised that identity/logout/hydration guards also pass against the previous code: not accepted; these are explicitly required preservation cases and catch a naive freeze-after-first-hydration fix, while two same-person tests discriminate the actual defect and submitted consent values. Review: codex/gpt-6-luna; lenses envelope, regression, duplication, tests, ui, security; 2 raised, 0 accepted, worst accepted none. Some optional narrow reads failed process setup; reviewers completed from the full inline diff/context. UI attempted a second blocked narrow read; no command actually executed. No screenshots or image reviews.
-
-npm version verified as 3.13.1 before reserving patch 3.13.2. Existing publish.yml builds and runs the library suite on main push before Trusted Publishing; no manual dispatch. Root inspected the consumer's intervening 3.12.0-to-3.13.1 code: AccountPage adds optional showProfileStatements default true, preserving existing controls/payload; SectionNav adds ListItem wrappers with existing selection/callbacks/labels. No changed exports or dependency requirements. Published patch and Spesix installed-package proof remain pending.
-
-Release completion: main f29d1dd, publish workflow38640512864 succeeded (build,90 test files and npm Trusted Publishing). Public registry confirms3.13.2, published2026-10-14T21:33:03Z after propagation. Spesix consumed exact3.13.2 in a30de18; real installed Welcome/ProfileComponent, AuthRoutesIntegration and AccountHub tests8/8 passed, shared i18next resolution confirmed. Spesix's separate SPX-DEP-5 owns its pending real-browser/capture CI38641555651@7eaefcc. The library correction/release is complete; no production app promotion occurred.

package/work-orders/UCM-AUTH-9.md

@@ -1,207 +0,0 @@
-# UCM-AUTH-9 — Auth flows that dead-end: a rejected password removes the invite form, a closed signup looks open
-
-# A. Envelope — authored by the Expertenchat
-
-## Goal & expected outcome
-
-- Goal: every auth page leaves the person a way forward and says why something failed.
-- Expected outcome:
-  - Invite/reset page: a server-side rejection of the password keeps the form, shows the reason
-    (e.g. "too common") at the field, and lets the person retry. After success the person sees a
-    confirmation, not a silent jump to the login page.
-  - Signup page: when self-registration is off (`signup: false`, `signup_modes: []`), the page says
-    so instead of rendering a form whose submit can never enable.
-  - User list: a role change confirms that it was saved, or shows why not.
-
-## Context — measured 2026-09-29 in jg-ferien's local browser test (ucm 3.5.0 installed there)
-
-- `src/pages/PasswordInvitePage.jsx`: the form renders only when `!successKey && !errorKey`
-  (~l.142); any error — including the server's `Auth.RESET_PASSWORD_INVALID` with
-  `messages: ["This password is too common."]` — removes both password fields and the button;
-  only a reload recovers. The reason is not shown. Client-side validation keeps the form.
-- After a successful set the page navigates to login (~l.102) with no confirmation.
-- `src/pages/SignUpPage.jsx`: submit is `disabled: submitting || signupModes.length === 0 ||
-  (turnstileRequired && !turnstileToken)`; with no signup modes the page still shows e-mail and
-  access-code fields and a permanently grey button, no explanation.
-- `src/components/UserListComponent.jsx`: role selects save without any feedback.
-
-## Scope + non-goals
-
-- In scope: the three behaviours above.
-- Explicit non-goals / do-not-touch:
-  - Password rules and the backend responses (dcm) stay as they are.
-  - Strings and the formal/informal choice are `UCM-I18N-4`.
-
-## Tier · gates
-
-- **Tier 3** — shared-core auth screens.
-- Reviewer: `reviewer` (all lenses) · `sec_reviewer` (auth flow) · `ui_reviewer`.
-- **Done means released and jg-ferien's pin bumped.**
-
-## Risks
-
-- An invalid/expired token must still end in the "link invalid" state without a form — only a
-  password rejection keeps the form. The two error classes must be told apart by code, not by text.
-
-## Required tests to WRITE (you write them and run YOUR OWN new ones; the orchestrator's run is the gate)
-
-1. Server rejects the password → form still present, reason shown, retry possible.
-2. Invalid token → invalid-link state, no form.
-3. Success → confirmation visible.
-4. Signup with no modes → explanatory message, no form.
-5. Role change → success or error feedback.
-
----
-
-# B. Implementation map — filled by the Orchestrator — ADDRESSED TO THE IMPLEMENTER
-
-## Context package — three independent fixes
-
-### 1. `src/pages/PasswordInvitePage.jsx` — the dead-end form + silent navigate
-
-- **Root cause of both bugs: ONE shared `errorKey` state variable covers two structurally
-  different failures**, and the render condition `{!successKey && !errorKey && <PasswordSetForm
-  .../>}` (line 142) hides the form for EITHER. The link-validity check (`verifyResetToken`, the
-  `useEffect` at line 36) and the password submission (`setNewPassword`, `handleSubmit` at line 56)
-  are two separate API calls that already fail independently — the fix is to stop collapsing their
-  results into one state variable, not to inspect error codes at render time.
-- **Fix — split the state:**
-  1. Keep `errorKey` (rename mentally to "link check result") for the `useEffect` at line 36–54
-     only — this is the existing "invalid/expired link" path and must keep hiding the form (the
-     Risk note: "an invalid/expired token must still end in the 'link invalid' state without a
-     form"). No change needed to this effect's logic.
-  2. Add a new `submitErrorKey` state, set ONLY inside `handleSubmit`'s `catch` block (line
-     103–105) instead of reusing `errorKey`. Read the human-readable reason from the response body
-     the backend actually sends: `normaliseApiError` (see `src/utils/auth-errors.js`) puts the
-     whole response body on `err.raw`; a password-policy rejection carries
-     `err.raw?.messages` (an array of strings, e.g. `["This password is too common."]"`) alongside
-     `err.code`. Prefer joining `err.raw.messages` when it's a non-empty array; otherwise fall back
-     to `t(err.code || 'Auth.RESET_PASSWORD_FAILED')`, same as today.
-  3. Change the render condition so the form shows whenever the LINK itself is valid, regardless
-     of `submitErrorKey`: `{!errorKey && !successKey && <PasswordSetForm .../>}` (drop the old
-     shared `errorKey` check that also hid it on submit errors — `errorKey` from here on only ever
-     means "link invalid", never "password rejected"). Display `submitErrorKey` in its own
-     `<Typography color="error">` above or below the form, distinct from the existing `errorKey`
-     alert.
-  4. Pass `submitErrorKey` down or keep it page-local and render it directly — `PasswordSetForm`
-     itself does not need to change (it already renders its OWN `localErrorKey` for client-side
-     validation; the server-rejection message is a page-level concern rendered alongside the form,
-     not inside `PasswordSetForm`).
-- **Fix — success confirmation instead of a silent jump:** in `handleSubmit`'s try block (line
-  66–102), the code currently computes `target` and calls `navigate(target)` immediately after
-  `setSuccessKey(...)` — the navigation happens before the success message can ever be seen. Stop
-  calling `navigate` automatically. Instead:
-  1. Keep the existing `successKey` set exactly as today (line 68–72) and the existing
-     `safeNextPath`/`target` computation (line 73–101) — that same-origin validation logic is
-     correct and must not change.
-  2. Store the computed `target` in a new state variable (e.g. `continueTarget`) instead of
-     navigating with it immediately.
-  3. Where `{successKey && <Typography color="primary" ...>}` already renders (line 136–140), add
-     a `<Button variant="contained" onClick={() => navigate(continueTarget)}>` reading
-     `t('Auth.SIGNUP_GO_TO_LOGIN')` (existing key, reused — this button always leads to the login
-     page, same destination the automatic navigate used to go to) right below the confirmation
-     text. The person now sees the confirmation and clicks through themselves.
-- Test file: extend whatever test already covers `PasswordInvitePage` (grep `tests/` for
-  `PasswordInvitePage` — if none exists, create `tests/PasswordInvitePage.test.jsx` following
-  `tests/AccountPage.test.jsx`'s page-level render pattern: mock `../src/auth/authApi`'s
-  `verifyResetToken`/`setNewPassword` with `vi.mock`, wrap in a router since the page uses
-  `useNavigate`/`useParams`/`useLocation`).
-  1. `verifyResetToken` resolves (valid link), `setNewPassword` rejects with
-     `{ response: { data: { code: 'Auth.RESET_PASSWORD_INVALID', messages: ['This password is too
-     common.'] } } }` (the shape `normaliseApiError` reads) → after submit, the `PasswordSetForm`
-     (its password fields) is still present, "This password is too common." is visible, and the
-     user can submit again.
-  2. `verifyResetToken` rejects → the invalid-link message is shown and `PasswordSetForm` is
-     ABSENT (`screen.queryByLabelText`/`queryByRole` for a password field returns null).
-  3. `verifyResetToken` resolves, `setNewPassword` resolves → after submit, the success message is
-     visible AND a "go to login" button is visible (and the test can assert `navigate` was NOT
-     called automatically — only after clicking the button, if you choose to test the click too).
-
-### 2. `src/pages/SignUpPage.jsx` — signup closed but form still renders
-
-- `signupModes` (line 51–59) is already computed as an empty array when self-signup is off. The
-  page currently still renders the mode-picker (only if `signupModes.length > 1`, so with zero
-  modes that block is already skipped) AND the full email/access-code form regardless, with the
-  submit button just permanently disabled (line 234: `disabled={submitting || signupModes.length
-  === 0 || ...}`) and no explanation anywhere.
-- **Fix:** immediately after the `NarrowPage`'s `<Helmet>` block (after line 165), add:
-  `{signupModes.length === 0 ? (<Alert severity="info" sx={SIGN_UP_PAGE_ALERT_SX}>{t('Auth.SIGNUP_CLOSED', 'Sign-up is currently closed for this project.')}</Alert>) : (<>...the existing success/error
-  alerts + mode-picker + form + "already have an account" block, unchanged...</>)}` — i.e. wrap
-  everything from the existing `successKey` alert (line 166) through the "already have an account"
-  block (line 254) in this conditional, so a zero-modes project shows ONLY the explanatory message,
-  no form at all. New translation key `Auth.SIGNUP_CLOSED` needs an entry in `authTranslations.ts`
-  (all locales the file already carries: de/fr/en/sw) — do not leave it English-only via the
-  `t(key, fallback)` default-only pattern, add the real bundle entry.
-- Test file: extend whatever exists for `SignUpPage` (grep `tests/` for `SignUpPage`).
-  1. `authMethods.signup_modes = []` and `authMethods.signup = false` → the explanatory message is
-     shown, no email/access-code `TextField` and no submit button are present.
-  2. Existing signup-open behaviour (at least one mode) is unchanged — re-run/extend whatever
-     assertions already cover the working case so this fix can't be a silent regression.
-
-### 3. `src/components/UserListComponent.jsx` — role change has no feedback
-
-- `handleChangeRole` (line 106–124) already has a `catch` that shows `alert(...)` on failure — that
-  half already satisfies "or shows why not". The missing half is SUCCESS feedback: today a
-  successful role change just silently re-fetches (`await loadUsers()`, line 120) with nothing
-  telling the person it worked.
-- **Fix:** add a lightweight success signal after the `await loadUsers()` call inside the `try`
-  block (line 106–120) — the simplest, lowest-risk option consistent with this component's existing
-  style (it already uses the browser's own `alert()`/`window.confirm()` for feedback elsewhere in
-  this same file, e.g. line 93, 102, 122 — match that existing convention rather than introducing a
-  new Snackbar/Toast pattern this component doesn't otherwise use):
-  `alert(t('UserList.ROLE_UPDATE_SUCCESS', 'Role updated.'));` right after `await loadUsers();`.
-  New key `UserList.ROLE_UPDATE_SUCCESS` needs a real bundle entry (all locales) in
-  `authTranslations.ts` — this key is new to `I18N-4`'s hardcoded-English-string list too; if
-  `I18N-4` lands first in the register it may already exist, check before adding a duplicate.
-- Test file: extend the existing `UserListComponent` test (grep `tests/` for
-  `UserListComponent`) — assert that a successful `onChangeRole`/`updateUserRole` call triggers the
-  new success signal (mock `window.alert` with `vi.spyOn(window, 'alert')` and assert it was called
-  with the translated success text), and that the existing failure path is unaffected (still calls
-  `alert` with the error path, exactly as today — do not weaken that assertion).
-
-## Do-not-touch / invariants
-
-- Password rules and the backend responses (dcm) stay as they are — this WO only changes how the
-  frontend reads/displays what the backend already returns.
-- Strings and the formal/informal address choice belong to `UCM-I18N-4`, not here — new keys added
-  here (`Auth.SIGNUP_CLOSED`, `UserList.ROLE_UPDATE_SUCCESS`) get plain, correct de/fr/en/sw values,
-  not the informal-German variant mechanism (that mechanism is `I18N-4`'s own scope).
-- Do not touch `SignupConfirmPage.jsx` — out of scope (not named in the Envelope's Context), even
-  though it has a structurally similar immediate-navigate-after-success pattern; note it in the
-  register Notiz as a possible follow-up, do not fix it here.
-
-## 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) + `sec_reviewer` + `ui_reviewer`; release; jg-ferien pin bump; register rows here and in jg (`JG-UX-19`).)*