Roles & permissions.
What every role can do — full matrix and how workspace + project access compose.
SpecGraph has two layers of access. The first — workspace role — is what you assign on the Team page (Owner / Admin / Editor / Viewer / Stakeholder). The second — project access — is per-project, and matters whenever editors / viewers / stakeholders are involved. This page is the cheat-sheet for what each role can actually do, and where the rules live.
If you're inviting people to a workspace for the first time, start at Team & invites. If you're trying to lock a single project down, jump to Project access.
Role × permission matrix #
| Action | Owner | Admin | Editor | Viewer | Stakeholder |
|---|---|---|---|---|---|
| See projects in the workspace | All | All | Only added | Only added | Only added |
| Create a project (Intake / Discovery / Mockup import) | ✓ | ✓ | ✓ | – | – |
| Edit phase content (Vision, Features, Brief…) | ✓ | ✓ | ✓ | – | – |
| Lock / unlock a phase | ✓ | ✓ | ✓ | – | – |
| Submit wishes | ✓ | ✓ | ✓ | ✓ | ✓ |
| Triage wishes (Accept / Defer / Reject / Merge) | ✓ | ✓ | ✓ | – | – |
| Run the Project Doctor | ✓ | ✓ | ✓ | – | – |
| Open the Amendments panel | ✓ | ✓ | ✓ | – | – |
| Open the BMAD pack | ✓ | ✓ | ✓ | – | – |
| Share a project (invite stakeholders) | ✓ | ✓ | ✓ | – | – |
| Manage project access (add/remove members) | ✓ | ✓ | – | – | – |
| Browse Portfolio | ✓ | ✓ | ✓ | – | – |
| See Team page | ✓ | ✓ | – | – | – |
| Edit workspace Settings (name, departments) | ✓ | ✓ | – | – | – |
| Delete a project | ✓ | ✓ | – | – | – |
| Manage members + roles on the Team page | ✓ | ✓ | – | – | – |
A dash means "the affordance isn't shown." Anyone who tries an action they can't do gets a friendly toast — never a raw server error.
How the two layers compose #
Workspace role is the ceiling. If you're a Viewer in the workspace, no amount of project membership lets you edit a phase or lock anything — you can only read.
Project access is the gate that decides which projects you see at all. Owners and admins always see every project; everyone else only sees projects they're explicitly added to.
So a Viewer added to project Atlas:
- Sees Atlas in their dashboard.
- Can read every phase and submit wishes.
- Cannot edit, lock, share, run the doctor, or open the Amendments panel.
A Viewer not added to Atlas:
- Doesn't see Atlas at all — not in the dashboard, not in command palette search.
- Can't open Atlas via a shared link. The page redirects them to their dashboard with a "That project isn't available" toast.
Special role notes #
Owner is the safety hatch — every workspace must have at least one. Owners can't be removed and can only be demoted by another owner. If you're spinning up a workspace, this is you.
Admin has nearly all of owner's powers but can't delete a project. Use this for trusted operators who shouldn't have the kill switch.
Editor is the default for active spec contributors. Full edit on assigned projects; no team or settings powers. They can invite stakeholders to a project they have access to (because sharing is part of the spec workflow), but they can't add other workspace members to project access — that's an admin/owner action.
Viewer is for read-only stakeholders inside the workspace (a security reviewer, a finance partner who needs visibility but won't edit). They can post wishes — that's the channel for them to influence the spec without touching it directly.
Stakeholder is for people who only attend interviews and submit wishes. It exists for completeness; in practice, most external reviewers come in via the per-project stakeholder portal instead — that's a token-based, link-only flow with no workspace account.
What the server actually enforces #
Every rule above is checked server-side on every mutation, and every read query that returns a full project doc filters by access. The UI gating (hidden buttons, disabled fields, redirects) is a UX layer — pleasant, not load-bearing. If a viewer somehow forces a request through, the server still returns "you don't have permission" and nothing changes.
This split matters for two reasons:
- A bookmarked URL to a project you've lost access to redirects cleanly with a toast — the data never leaks.
- The MCP endpoint and any future API surface inherit the same checks, so coding agents acting on a viewer's token can't escalate.
Changing someone's role #
From Team, click the pencil next to a role and pick the new one. Changes are immediate. If you demote an editor on an open project, their next save attempt toasts a permission error and rolls the field back; the spec is never half-mutated.
If you remove a member entirely, all of their per-project access is dropped at the same time so they can't be silently re-promoted by being re-invited later. See Team & invites · Removing someone for the full flow.