[Feature]: Project-level members and role-based permissions

Deployment type

Official App

Area

Issues, projects and workspaces

What do you want and why?

Projects currently group work inside a workspace, but they do not appear to provide a project-level membership or authorization boundary. A workspace member can access projects according to their workspace role, so a project owner cannot control which members may view, contribute to, or administer a particular project.

This becomes a problem when one workspace contains work for multiple squads, clients, or initiatives with different sensitivity. Using a separate workspace for every access boundary fragments shared agents, context, and collaboration, while keeping everything in one workspace risks accidental disclosure or modification.

I would like Multica projects to support their own member list and role-based permissions, enforced by the server rather than only hidden in the UI.

Proposed solution (optional)

Add project-level membership and RBAC with at least these role semantics:

• Manager: manage project settings, members, and roles.
• Contributor: read the project and create or update project issues, comments, and deliverables, but not manage access.
• Viewer: read-only access to the project and its visible resources.

The authorization boundary should cover the project itself, project issues, project resources, search/list results, direct URLs, API access, and CLI operations. Web, Desktop, API, and CLI should all rely on the same server-side checks so an alternative entry point cannot bypass the restriction.

Additional requirements:

• Define how workspace owners/admins inherit or override project access.
• Prevent removal or demotion of the last project manager.
• Record project member additions, removals, and role changes in an audit trail.
• Provide a backward-compatible migration and explicit default visibility for existing projects.
• Unauthorized members should not be able to enumerate restricted projects or retrieve their protected resources directly.

Out of scope for an initial version: per-field or per-issue ACLs, replacing GitHub/GitLab repository permissions, external guest links, and cross-workspace sharing.

Related but distinct:

• #5048 covers agent access grants to projects; this request covers human workspace members.
• #7414 proposes a workspace-wide viewer role; this request needs access and roles scoped to an individual project.
• #5529 is a broader enterprise permission request; this issue proposes a concrete project-level slice.

Screenshots / mockups (optional)

No response