AUTH-4 — the account user list on a phone

Composition spec for UserListComponent below the md breakpoint. Drawn from ui-core-micha's baseline tokens.

Declared coverage. One surface: the users section of AccountPage — its toolbar, its rows, its pagination. Nothing else.

Not covered, therefore unchanged: every other account section; the section navigation itself (that is SHELL-5); the delete confirmation dialog; the invite flow; the role list an app supplies; and the desktop table above md, which this work order deliberately leaves exactly as it is.

Authority. The Envelope wins on scope. The baseline wins on token values. This sheet wins on composition — what sits where, at which size, in which state. The accent is a neutral placeholder: palette.primary is app identity and the baseline has none, so each app supplies its own. Do not read the blue as a decision.

1. The defect, measured

Measured 2026-08-11 in cockpit at innerWidth 411 CSS px — the mobile preset yields 411, not 375, so at the real target every figure is worse. The table renders 1053 px inside a 325 px container. The container scrolls (overflow-x: auto) and the document does not overflow, so this is not a broken layout: it is a desktop table shown unchanged on a phone.

today — 411 px, 1053 px of table in a 325 px container
Email addressName NewSuccessful Login RoleActions
anna.baumgartner@example.chAnna Baumgartner admin

253 px of that width is columns nobody chose. New (90) and Successful Login (163) are default-on props an app can switch off today — AccountPage forwards all of them — and cockpit simply left the defaults. But the four remaining columns are Email 220 + Name 180 + Role 180 + Actions 220 = 800 px against a 325 px container. Configuration cannot fix this; only structure can. The defaults are deliberately left alone here — flipping them would be a silent estate-wide change.

2. The proposal: a card per user below md

The screen exists so an administrator can change a role or remove someone. Both are per-row controls, so any layout that puts them behind horizontal scrolling defeats the screen's purpose. A card brings them to thumb reach.

proposed — 375 px
Email
anna.baumgartner@example.ch
Anna Baumgartner
Neu Noch nie angemeldet
Rolle admin
t.k@example.ch
kein Name hinterlegt
Angemeldet
Rolle none
michael.hofstetter-brunner@verwaltung.example.ch
Michael Hofstetter-Brunner
Angemeldet
Rolle sekretariat

Four composition decisions, each with its reason:

The email is the card title, the name is secondary. The email is the identity an administrator searches by and the only guaranteed-present field — a user may have no name. A card with a missing name shows a muted placeholder rather than an empty line.

The two boolean columns become labelled chips. In the table they are icon-only with a tooltip, which a touch device cannot show at all. Chips carry the words. This is a small, deliberate improvement over parity, not drift — and it is why the flags cost vertical space rather than being dropped.

Role and delete sit together in a footer, separated by a divider. They are the two actions; grouping them keeps the card's top half purely identifying. The role select fills the remaining width so its label is never truncated; delete keeps the full 44 px touch target.

Sorting needs its own control. A card list has no column headers to click, so the sortable-column affordance disappears with the table. A compact sort control sits beside the search field. Without it the mobile view silently loses a capability the desktop has — the kind of regression that is invisible in a diff.

3. Above md: nothing changes

The table is right for a desktop — six columns are scannable at 1136 px, and it was measured with 570 px of headroom in the section strip beside it. Shown here only so "unchanged" is part of the spec rather than an omission.

unchanged — 1280 px
Email address Name NewSuccessful LoginRoleActions
anna.baumgartner@example.chAnna Baumgartner admin
t.k@example.chkein Name hinterlegt none

4. What the app supplies, and what that costs

UserListComponent already takes extraColumns and extraRowActions, so the column set is app-configurable. The card must therefore render columns it has never seen.

InputIn the card
extraColumns rendered as label: value rows below the chips, in the order given. No new required field on the column definition — an app that wants nothing else gets nothing else, and one that already passes columns keeps working unchanged.
extraRowActions join delete in the footer. Beyond three actions total they must collapse into an overflow menu, or the footer wraps and the card loses its shape.
the three toggleable columns as chips when on, absent when off. An app that switches both flags off gets a shorter card, not an empty chip row.

What this sheet cannot show. No motion, no interaction states beyond the resting one — no hover, focus ring, pressed, or the open select menu. The delete confirmation dialog is untouched and undrawn. A long list is drawn as three cards; the real scroll behaviour and the pagination control at the bottom of a 25-card page are not represented. If DM Sans is not installed locally this page falls back to the system font — sizes and weights are still exact.