[VibeSWE]

Summary

Demo mode's mock backend (frontend/src/lib/demo.ts) accepted role grants that the real backend rejects. It now returns HTTP 400 Role is protected when a grant includes super-admin or any role carrying the SuperAdmin privilege, for:

• creating an API key;
• creating a user;
• adding roles to a user.

This mirrors the backend checks in #67 (API keys and querier user endpoints) and the existing standalone post_user / add_roles_to_user checks. Demo mode has no internal or protected users, so super-admin stands in for the internal-role check.

Follow-up from the #67 review.

Tests

demoTeam.test.ts: 12 cases, committed red then green. They cover rejected grants (including ones mixed with ordinary roles), unchanged state after a rejection, and ordinary admin grants still working.

• Focused suite: 33 passed
• Full frontend unit suite: 2,428 passed, 14 skipped
• format:check and build (includes tsc --noEmit) pass

🤖 Generated with Claude Code

---

^{Need help on this PR? Tag @codesmith-bot with what you need.}

[VibeSWE]

Adversarial review of PR #76 (at a40561fd, fixes in 25f5b6b1)

One Opus 5.5 and one Sol 6.1 reviewer. Neither found a reachable escalation path or anything blocking.

Both found the same two Low issues, fixed in 25f5b6b1 with failing tests first:

Severity	Finding	Fix
Low	The protected check ran before the unknown-role check and read inherited properties, so ['constructor'], ['toString'] or ['__proto__'] threw a DataCloneError/TypeError instead of a 400	Unknown roles are checked against own properties first; new test for all three names on all three methods
Low	['missing', 'super-admin'] returned "Role is protected" for API keys and user creation, where the backend reports the missing role first	API keys and user creation check unknown roles first, role additions protected roles first, as on the backend; new test pins both orders

Also changed: demo roles can only hold admin/editor/reader/writer/ingestor (TypeScript rejects superadmin), so the privilege === 'superadmin' branch was unreachable. The check is now just the built-in super-admin name.

Checked and fine:

• Role create/update rejects superadmin.
• setDefaultRole('super-admin') and putRole('super-admin', …) are already rejected.
• Demo has no group-mutation or API-key edit methods.
• OIDC manualRoles additions go through the new guard.
• Root admin protections and ordinary grants are unchanged.

Local at 25f5b6b1: npm test 2,432 passed, 14 skipped; build (includes tsc --noEmit) and format:check pass.