feat(settings): mock service account creation form for #491

[alukach]

What this is

A non-persisting design mock of the service-account creation flow proposed in #491, so the data model can be reviewed in a browser before we build it.

Nothing is saved. Submitting the form renders the database rows the creation would write.

Where to find it

Settings → Service Accounts, on both individual and organization accounts (either can own a service account). Visible to anyone who can manage the account.

What it demonstrates

The four decisions from the epic, in order:

1. Name — a human-friendly name; the stored id is derived from it and previewed live as svc--<sanitized>. Sanitization collapses double hyphens, so a name can never forge a second reserved prefix (ID_REGEX forbids -- in human account ids, which is what makes the prefix collision-proof).
2. How software signs in — one or many. A GitHub repository + ref (no secret stored), or an API key that expires in 30/90/365 days or never. Every route reaches the same account with the same access.
3. What it can reach — the whole owner account, or specific products, each read or read-write.
4. Which roles it may use — Full access and Read only, both ticked by default. The form notes that both-ticked is a no-op and that unticking Full access is the durable restriction.

Submitting lands on a mock detail view of the integration — the page a real create would redirect to — with an Edit button that returns to the form with every answer intact. If a key sign-in method was chosen, the detail view shows the one-time API key with copy-now framing.

The detail view shows:

• accounts (existing table) — the new service row with owner_account_id and allowed_roles
• identity_bindings (new table) — one row per sign-in method, all pointing at the same principal
• memberships (existing table) — one row per grant; account-wide access collapses to a single row with no repository_id, which is already how hasRole reads it
• Ready-to-paste config per sign-in method: a GitHub Actions workflow using aws-actions/configure-aws-credentials@v4, or the CLI + env-var form for keys. The role in both changes if Full access is unticked.

Plus the caveats worth seeing next to the model: what doesn't exist yet, that roles only subtract, and that revoking a grant stops new access in ~60s while issued credentials last up to an hour.

Notes for review

• plan.ts is pure and holds all the model logic; plan.test.ts covers it (14 tests) — namespacing, the GitHub sub claim shape, per-product vs account-wide membership rows, one binding per sign-in method, and the validation rules including the empty-role-set case that would leave an account unable to authenticate at all.
• The page is gated on PutAccountProfile, not ListAccountMemberships — the latter returns true for any signed-in user (authz.ts:1242-1252), which would have exposed the mock on other people's accounts.
• No API routes, no server actions, no schema changes. The only edits to existing files are a nav entry and a URL helper.

Two things the mock deliberately surfaces for decision

• aws-actions/configure-aws-credentials also calls GetCallerIdentity, which /.sts does not implement. Since that action is how most people will first try this, the mock shows it and flags the gap.
• Keys with no expiry are offered, but Epic: machine identity for unattended workflows #491 currently says keys cannot be issued without one. The mock calls this out as a departure rather than quietly picking a side.

Not included

Key issuance, revocation, the delete permission question, and custom roles. This is the create flow only.

🤖 Generated with Claude Code

https://claude.ai/code/session_01HGZ598AJ1F7NWoyPpgepBt

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
source-cooperative	Ready	Preview	Aug 24, 2026 4:22am

[claude]

Claude finished @alukach's task in 1m 45s —— View job

---

Review

✅ No blocking issues — safe to merge.

This is a pure, client-side design mock with no persistence, no new API routes, and no schema changes, so the blast radius is small. I checked the areas that matter most for a mock like this:

• Access gating (guard.ts:13-19, layout.tsx:130-137): correctly gated on Actions.PutAccountProfile, not ListAccountMemberships. Verified against authz.ts:1242-1252 (listAccountMemberships returns true for any signed-in, non-disabled user) vs. authz.ts:639-668 (putAccountProfile requires admin, account owner, or org owner/maintainer). The nav item visibility and the actual page load both use the same check, so there's no way to reach the page via a direct URL that the nav wouldn't have shown.
• Reserved-id collision safety (plan.ts:83-93): sanitizeName collapses any run of non-[a-z0-9] characters (including repeated hyphens) into a single -, so svc--<name> can never contain a second --. Confirmed ID_REGEX (types/shared.ts:25) independently forbids -- in human-chosen ids, matching the comment's claim. Covered by the evil--thing test case in plan.test.ts:85-87.
• plan.ts purity: no I/O, no mutation of shared state; planChanges/planDelete/planDisable are deterministic functions over their inputs, matching the "nothing persists" claim in the PR description.
• XSS/injection surface: all user-controlled strings (name, repo, ref, product ids) are rendered through JSX text nodes / <Code>, never dangerouslySetInnerHTML or raw HTML — no injection vector despite fields like repository and ref being free text.
• Mock API key (ServiceAccountForm.tsx:32-40): uses crypto.getRandomValues, generated and held only in client state, never transmitted — consistent with "nothing is saved."

No correctness bugs, security issues, or best-practice violations found in the diff.

[alukach]

Some design concepts for the cards:

Going with option C for now.