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. A workspace is either a personal one or a team one; the difference is who it is for, not what it can hold.

The three 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.

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.