Documentation
Dashboard tour
A guided walk through every page on app.prom.codes — sign-in, switcher, API keys, audit log, settings, members.
The dashboard at app.prom.codes is where
you provision API keys, manage members, and audit what your tenant
actually did. It is intentionally small — one page per concept,
no nested menus.
1. Sign in
app.prom.codes/sign-in
Email + magic link. There is no password to forget. The link expires in one hour and is single-use; clicking an old link prompts you to request a fresh one.
On first sign-in the system auto-provisions a personal tenant named
after your email handle and seeds a default workspace. You land on
/app/dashboard already enrolled — no setup wizard.
2. Tenant switcher
Top-left of every authenticated page. If you belong to a single
tenant you see a plain label; once you join a second, the label
becomes a dropdown. Switching writes a signed prom_tenant cookie
(60-day TTL, .prom.codes scope on production) and records a
tenant.switch row in the audit log.
The switcher only shows tenants you are a current member of. Pending invitations are not listed here — accept them through the invite link first.
3. Dashboard
app.prom.codes/dashboard
The landing page. Shows the active tenant, the active workspace, your role inside the tenant, and a small panel of recent activity. Treat it as a one-glance status check, not a control surface.
4. API keys
app.prom.codes/api-keys
Create, view, and revoke the keys your MCP server and CI jobs use. The full lifecycle — including the one-time copy moment — is documented on its own page: API key lifecycle.
Owner and admin roles can mutate; members see a read-only list.
5. Audit log
app.prom.codes/audit
The append-only record of every action your tenant has taken. Filterable by:
- Action — e.g.
api_key.create,member.invite,workspace.update. - Status —
successorfailure. - Date range — ISO date inputs, server-paginated.
The Export CSV button on the same page emits exactly the rows matched by your current filter, with stable column order so you can diff exports across time. RLS still applies — the CSV only ever contains rows your tenant owns.
6. Settings
app.prom.codes/settings
Three blocks on one page:
- Workspaces. List, rename, create, delete. A tenant always has at least one workspace — deleting the last one is rejected with an explanatory error.
- Members & invitations. List current members, invite new ones by email, revoke pending invites, remove existing members. Role rules and guardrails are documented on Members & invitations.
- Tenant name. Owner-only rename of the tenant itself. The change propagates to the switcher on next render.
Every mutation here writes an audit row, so the Audit page is the authoritative log of who did what.
7. Sign out
Top-right menu. Drops your Supabase session cookie and any
prom_tenant selection. On the next sign-in your last-used tenant
is restored from the cookie if you still belong to it; otherwise the
resolver falls back to your first membership.