Teams

Teams are workspace groups for organizing work, navigation, and future Issue ownership. Every workspace has one default Team named from the workspace at creation, and admins can create additional Teams.

What Teams are for

Use Teams when you need a stable workspace grouping for ownership and routing:

• Navigate to Team pages from the workspace sidebar.
• Group people into public or private organizational Teams.
• Nest Teams under parent Teams to mirror the way work is organized.
• Assign visible Teams as owning context for Features and Initiatives in Spec-Driven Development.
• Save Team-scoped Issue, Feature, and Initiative views with a consistent table and detail experience.
• Plan Team Issues in independent Team-owned Cycles with shared Issue views, progress, rollover, and calendar feeds.
• Keep a durable Team slug for URLs and future Team-scoped records.
• Review Team lifecycle and membership changes in the right Logs surface.

Teams can be arranged as parent Teams and sub-Teams. Sub-Team members must also belong to active parent Teams, but parent Team membership does not automatically add someone to child Teams.

Authorized users can administer the same Team settings from Codex or another compatible coding agent. Agent actions use the Team's immutable team:<slug> reference, current server-projected permissions, and the same product services as the Integrity interface. High-impact changes are previewed and require a separate exact confirmation before they apply.

Default Team

Each workspace gets exactly one default Team.

The default Team slug is stable. Renaming the workspace or the Team does not change the Team route.

Team pages

Team pages live at:

/workspace/{workspaceId}/teams/{teamSlug}

Opening the workspace root sends you into a Team-owned work surface. Integrity uses your last explicitly opened Team when it is still available, otherwise the first joined non-default Team, then the default Team.

The Team page includes:

• Overview with Team title, description, members, and future shortcut placeholders.
• Hierarchy context for the visible parent and sub-Teams the viewer can access.
• Documents as a placeholder for future Team resources.
• Members with the current Team roster.
• Views for Team-scoped Issue, Feature, and Initiative saved views.

Only workspace admins see Team member-management actions, and only on active Teams.

Private Teams stay hidden unless you can access them. Sidebars, hierarchy labels, and logs use redacted or omitted references instead of exposing private Team names to unauthorized viewers.

Team Views

Every accessible Team has a Views directory at:

/workspace/{workspaceId}/teams/{teamSlug}/views

Use the Issues, Features, and Initiatives tabs to create or open views for the current Team. The create form always shows Save to the current Team. Team Views cannot be saved as Personal or Workspace views, and Team scope cannot be removed from the saved lens.

Browsing a public Team does not grant view creation or management. Without Team view authority, the directory remains readable but create actions are absent; opening a copied create URL returns to the directory without mounting an editor.

Selected views use the same table controls and three-card detail drawer as workspace Views. The summary is calculated from visible filtered rows. Only Team Issue views support saved-view subscriptions.

Planning ownership

Features and Initiatives can carry one or more owning Teams. Team ownership helps people scan who owns planning work, filter/group planning tables, and navigate to visible Team pages.

Team ownership is not permission-bearing. Adding a Team to a Feature or Initiative does not give Team members access to that planning object, sources, folders, artefacts, baselines, reviews, traces, or evidence. Private Team associations stay display-safe: unauthorized viewers see a generic private Team value instead of names, slugs, colors, hierarchy, members, route links, filter labels, exports, or agent-ready detail.

Related