Roles → Person picker: filter to user-kind principals only (CL-6664)

[TheGreatAxios]

Fixes CL-6664

The "Assign a role" person picker was pulling from the full principals list — people, agents, and workflows — surfacing 49+ duplicate placeholder-named service accounts (e.g. "Dana Reyes Gaj0a5c7 Localhost") indistinguishable from real members.

What changed:

• roles-section.tsx: filter principals to kind === "user" only for both the picker and assignments table, replace optgroup with flat <select>
• identity.ts: updated comment to reflect Roles' picker is user-only
• test/roles-section.test.tsx: 4 rewritten tests covering user-only filter, flat list, agent exclusion from assignments table, and single-kind label artifact

Why component-level filter: The picker already receives the full principals list from the parent. A kind === "user" filter at the component boundary is the simplest, most localized fix — no backend changes, no new API params. The People section already validates that user-kind principals represent actual workbench members.

[TheGreatAxios]

Review — Skywalker (orchestrator)

lens · implementation

Filters the Roles "Assign a role" picker to user-kind principals only, matching the People section roster. Removes now-unused optgroup structure and PRINCIPAL_KIND imports.

Key paths:

• packages/settings-ui/src/roles-section.tsx:320 — principals.filter(p => p.kind === "user") feeds both picker and table
• packages/settings-ui/src/identity.ts:9-13 — comment updated to reflect user-only scope
• packages/settings-ui/test/roles-section.test.tsx — 4 rewritten tests, 11 assertions

Critic review: clean (all findings VERIFIED, zero defects, zero blockers).
Build gate: tests pass (bun test test/roles-section.test.tsx — 4/4). Typecheck: zero errors in changed files.

[TheGreatAxios]

Component-level kind === "user" filter on the Roles picker/table — correctly scoped and tested; no backend or package-move conflicts found.

Must fix

• None.

Consider

• The filter is UI-only: listPrincipals(tenantId) still fetches the full principal list (including the 49+ duplicate placeholders) over the network before this component discards them client-side. Fine for a legibility fix, but worth confirming there's no perf/payload concern if that list grows further, and that no other consumer of listPrincipals in this section relies on seeing agent/workflow entries.
• identity.ts's comment now describes Grants/Roles pickers separately; double check the Grants picker (grants-section.tsx) intentionally keeps agents/workflows (it does — confirmed via PRINCIPAL_KIND_ORDER/PRINCIPAL_KIND_LABEL still imported there), just flagging so reviewers don't read the identity.ts comment as implying Grants changed too.

Verified

• people filter (principals.filter(p => p.kind === "user")) is applied consistently to both the picker <select> and the assignments flatMap, so the table can't show agent/workflow rows either.
• Backend role-assignment route is not kind-restricted (by design — Grants still assigns roles to agents/workflows), so this is correctly a UI scoping change, not a broken/bypassable authz control.
• No references to the deleted hub-client package, and @corbits/error-sink/@corbits/connections are unaffected by this diff (settings-ui's existing error-sink dependency is untouched).
• All 4 CI jobs relevant to this diff pass (build-test, lint, typecheck, structural); rewritten tests in roles-section.test.tsx cover user-only filtering, flat-list rendering, and agent exclusion from the assignments table.