Members & roles

Project membership controls visibility and what someone can change inside a specific project. It sits alongside — but does not replace — organization roles. A person must be an org member first; project membership then scopes them to the repos, tasks, views, and agents for that initiative.

Org roles vs project roles

Two layers apply. Organization roles unlock the dashboard and org-wide admin areas; project roles scope day-to-day work.

Organization roles

Project roles

Effective access matrix

*Depends on org settings — some orgs restrict shared view creation to leads and admins.

†When project.agent.manage or equivalent capability is granted; otherwise org admins set policy from the dashboard.

Adding members

1. Open the members panel

   In the Projects app, open your project and navigate to Members. You need project admin or org admin / super admin to add people.

2. Add from the organization

   Search for org members by name or email. You cannot add someone who has not accepted an org invitation — invite them from Dashboard → Members first if needed.

3. Assign a project role

   Choose project admin for leads and tech owners who manage repos and membership; choose member for contributors. Optional assignment labels (e.g. "Backend", "QA") help filtering in large projects.

4. Confirm access

   New members immediately see the project's tasks, views, and allowed repositories. The action is recorded in the organization audit log.

Project lead

Every project can have a lead — the person accountable for delivery, standups, and escalations. The lead is not automatically a project admin, but in practice leads are usually granted admin on their projects.

1. Designate a lead

   From Members, open the lead picker and select a member. Only one lead is shown on the project overview at a time.

2. Transfer lead

   When ownership moves (rotation, re-org), assign the new lead before removing the previous lead from the project if they should lose access entirely.

3. Audit

   Lead changes are written to the org audit log with actor, previous lead, and new lead.

Removing access

1. Remove from project

   Project admins remove the member from the project Members list. They retain org membership but lose visibility into this project's tasks and repos.

2. Remove from organization

   Org admins remove the person from Dashboard → Members. This revokes all project access immediately.

3. Revoke active sessions

   If credentials may be compromised, org admins can revoke desktop sessions from Settings in addition to removing membership.

Teams and projects

Organizations can group members into teams (Settings → Teams). Teams may be linked to projects for budget allocation and model policy overrides. A member gains project access through:

1. Direct project membership, or
2. Team membership when the team is linked to the project (org-dependent configuration).

When both apply, the most specific policy wins: project overrides narrow team defaults; team overrides narrow org defaults.

Team roles in the database

Organization teams use three platform roles stored as x4rge_team_role: admin, member, and viewer. Team admins manage membership and team-scoped policy; members access linked projects and agents within effective catalog rules; viewers get read-only project visibility when the org grants it. These roles are separate from project roles (project_admin / member) — a person can be a team viewer but a project admin on a specific initiative, or vice versa.