Private Teams and Membership

Teams can be public or private. Public Teams are visible to workspace members. Private Teams are visible to their Team members, while non-members receive no private Team detail through normal navigation, search, logs, exports, or agent-assisted surfaces.

Visibility and governance

A redacted governance summary can confirm that a private Team requires administrative attention without exposing its real name, identifier, slug, icon color, description, hierarchy, members, or Team log detail. Workspace administration does not make someone a private Team member.

Coding agents receive the same boundary. They cannot use configuration reads, option discovery, previews, conflict messages, receipts, logs, or routes to enumerate an inaccessible private Team. A hidden or unavailable target returns generic copy and no private counts or configuration.

Create a private Team Admin

The default Team must remain public because it mirrors workspace membership.

Change Team privacy Admin

1. Open Workspace Settings -> Teams.
2. Select an accessible non-default Team.
3. Open General.
4. Change Privacy from Public to Private.
5. Review the conversion warning and confirm.

The conversion updates Team readers and writes audit evidence. Private hierarchy rules still apply: a private parent cannot have an active public descendant.

Manage Team owners and members Admin

Team owners are Team-local administrators. They are separate from workspace owners and admins.

• An active private Team must always have at least one owner.
• Authorized managers can promote a member to owner or demote an owner when another owner remains.
• Team member and role changes update current lists immediately and write Team audit evidence.
• A workspace admin who only has a redacted governance row cannot enter private Team detail or read the member list.

Team owners can manage membership where the Team's Member management policy allows it. Server checks remain authoritative even when a control is visible.

Join, request access, invite, or leave Admin Editor Viewer

Membership actions depend on Team visibility, Team policy, and the viewer's projected capability:

• A workspace member can join an eligible public Team.
• A non-member can request access to a private Team only from an explicitly allowed discoverable entry. Hidden private Teams do not become discoverable through the request flow.
• Team managers can approve or deny pending requests and manage pending invitations.
• A non-manager member can leave a non-default Team when owner and hierarchy safeguards allow it.
• The default Team cannot be left directly because it mirrors workspace membership.

Pending request and invitation lists show current state only. Completed, declined, revoked, or replaced rows leave those queues and remain available as audit evidence.

Use Team identifiers Admin

Every Team has a short uppercase Identifier that is unique inside the workspace. Integrity uses it as the stable prefix for Team-owned Issue keys.

• During Team creation, the Identifier follows the Team name only until you edit it directly.
• Renaming a Team does not regenerate its Identifier.
• Changing an Identifier does not renumber Team Issues.
• A previous Identifier can remain available as an alias so older Issue links continue to resolve.
• Duplicate, blank, invalid, or longer-than-seven-character identifiers are rejected with field-level feedback.

The Team slug remains the stable Team route key; the Identifier is the Issue-key prefix. They are deliberately separate.

Audit and realtime behavior

Team privacy, ownership, membership, request, invitation, capability, hierarchy, and Identifier changes produce typed Team audit entries. Authorized Team viewers can read full Team-scoped audit copy. Aggregate governance surfaces use redacted snapshots and never rely on hiding sensitive metadata only in the browser.

Team list, detail, sidebar, members, counts, requests, invitations, capability controls, and audit readers refresh through private realtime invalidation. Broadcast payloads carry identifiers needed to refetch; they do not carry private Team names, slugs, identifiers, member rows, or request/invitation identities.

Confirmed coding-agent changes reuse these exact writers and readers. A connection that loses Team access receives a private invalidation and its next read returns the redacted or unavailable projection without requiring a new login.

Private Issue sharing

A private Issue can use a narrow direct-share record without making the recipient a Team member. The stored grant vocabulary includes viewer and editor, but direct-share-only access remains read-only until the server projects a separate mutation capability for that surface.

Direct sharing does not reveal the private Team name, route, hierarchy, member list, or Identifier, and it does not let the recipient reshare the Issue. Access is limited to the shared Issue and the allowed sub-Issue context exposed by the Issue access model.

FAQ

Can a workspace admin read every private Team?

No. A non-member admin receives only the redacted governance state defined for that surface. Add the admin as a Team member when full Team detail is genuinely required.

Does joining a Team unlock restricted Modules or evidence?

No. Source Library, Folder, Artefact, Baseline, Review, and other restricted-object permissions remain independent.

Why can't I make the default Team private or leave it?

The default Team mirrors workspace membership and provides a safe workspace landing context, so it must stay public and current with the workspace roster.

Why can I see a disabled action?

Integrity sometimes keeps an action visible to explain a workspace capability or Team policy boundary. The server rejects the mutation when the named capability is unavailable.

Related