Workspaces & roles

What a workspace holds

Every surface in Rezee is workspace-scoped, which is what makes them able to reference each other. An issue can name a repository in the same workspace, a channel can be a repository's home, a document can cut issues, and an agent is a member of one workspace and never wonders which.

Issues are numbered per workspace, not per repository, because the board spans every repository in it. There is one kind of workspace: a workspace you made for yourself and a workspace your company runs are the same thing with different numbers of people in it.

The three built-in roles

Member is the working role. A member reads and writes every surface: files issues, opens pull requests, writes documents, posts in channels, delegates tasks to agents, creates schedules, and reads any repository in the workspace.

Admin adds the things that shape the workspace - people and agents:

• add, remove and change the role of members
• send, see and revoke invitations
• add, configure and remove agents, and mint or revoke their tokens
• manage the workspace's own LLM credentials
• edit the brief and change the mark
• read the audit log

Owner adds four things, and the line between admin and owner is drawn deliberately. Each of these is a way to widen your own reach past the owner's, or to take the whole workspace with you:

• SSO and SCIM. Whoever configures the identity provider decides who becomes a member.
• Runners. A runner token is handed the decrypted secrets of every repository in the workspace, at every claim - and repository secrets are otherwise repo-owner only.
• Billing. Seats and the plan.
• Export. One request bundles every repository and reads every issue, document and message.

Roles you write yourself

The three above are the defaults, not the ceiling. A role is a set of verbs - issues:write, repos:write, teams:write - and a grant says where that role applies: across the whole workspace, or on one team, one project, or one repository. Write a role in Settings → Roles, then grant it at the scope you mean.

Two rules keep that from being a way around everything else. You cannot grant a role carrying verbs you do not hold at that scope, and the refusal names the verbs that stopped it. And five verbs are the owner's for good - SSO, runners, billing, the export, and roles themselves - so no role anybody writes can carry them, not even at an owner's own hand. The way somebody else gets those is the owner role itself, which is one act with a name on it.

Every gate on the server decides on the verb it needs rather than on what a role is called, and the screens do the same: a rail hides Audit because you lack workspace:manage, not because your role is not spelt admin.

Repositories draw their own line

A few things belong to a repository's owner rather than to the workspace's - not even a workspace admin can reach them:

• CI secrets - reading, setting, rotating
• collaborators on that repository
• webhooks
• branch protection rules

A workspace admin who needs to change one of those can be made the repository's owner. What they cannot do is quietly widen a rule on somebody else's repository.

Members and invitations

$ rezee member list
$ rezee member add alice --role admin
$ rezee member remove alice

$ rezee invite create alice@example.com --role member
$ rezee invite list
$ rezee invite revoke <id>

An invitation is by email and carries the role the person will get. It stays in the list until it is accepted or revoked. Repository collaborators are separate and are managed per repository:

$ rezee member repo list
$ rezee member repo add bob --role write

These commands need an unrestricted token - a browser login mints a limited one that deliberately excludes changing access. See the CLI reference.

For a workspace whose membership comes from a directory rather than from invitations, see SSO and SCIM.

Agents count as members

An agent is a row in the member list with a handle, an avatar and a token, and it holds a fixed set of capabilities rather than a role. It can be mentioned and assigned like anybody else. See Agents.

Taking everything with you

A workspace owner can download the whole workspace as one tar archive - every repository as a git bundle, and every issue, document and message. It has its own much stricter rate limit, and the audit log records that somebody asked, before the stream starts, whether or not the download finished.

There is no lock-in to argue about: the repositories are plain git, and the rest is a file you can read.