Workspaces & Collaboration

A workspace is the scope everything else sits in: its projects, its settings, its secrets, its members, and its own database hosted by Trinity, which every member sees the same view of in real time. Your account starts with one, and you can create more: one account owns at most ten workspaces, and the one you start with is the first of the ten. Belonging to a workspace somebody else owns costs you nothing against that — only the ones you own count.

Collaborating is adding a member to a workspace. There is no separate solo mode — a workspace with only you in it runs the same rules as one with ten people, and it grows into a shared one the moment you invite somebody.

The Workspace Switcher

The workspace switcher sits at the top of the sidebar and always names the workspace you are working in — its projects, its settings, and its data are what every page below it is reading. Click it and everything the workspace itself is hangs off that one control.

Picking one. The menu opens on the list of every workspace you belong to, with a crown beside the ones you own and a shield beside the ones you manage. Click one to switch into it; the switch lands you on the dashboard, because projects, runs, and stories are all workspace-owned and the URL you were on belongs to the workspace you just left.

Acting on the one you picked. Under that list, separated by a rule, sit three rows:

Members — who is in this workspace, and where you invite somebody into it
Settings — what this workspace answers for everyone in it, and your own defaults inside it (see Workspace Settings)
New workspace — name it, and Trinity provisions its database and switches you into it

The menu is there whether you belong to one workspace or five: administering a workspace and creating another are worth reaching either way.

A brand-new workspace hasn't been set up yet, so the first screen you land on is the setup gate asking for a git account, a default destination, and an agent CLI — see Signing In → First-Time Workspace Setup.

The switcher carries a dot on any workspace with something in it waiting for you, so you can see it without switching in — see Inbox.

The workspace your account starts with is named from your @handle — handle ozner-omali gives Ozner-omali's Workspace — and it reads that way everywhere: the switcher, workspace settings, the members page, your inbox, the website dashboard, and any invite you send from it. The 's Workspace ending is what keeps the workspace distinct from you, since the two would otherwise read identically. This derived name is worked out from the owner's handle each time it is read rather than stored, so changing the owner's handle renames it too — and so does transferring ownership, since the new owner's handle takes over. A workspace you create yourself keeps the name you gave it at creation instead.

Either way, an owner or manager can hand-type a name at any time from Workspace Settings → Access Control → Workspace Name (see Workspace Settings). A hand-typed name is stored, so it stops following the owner's handle and survives an ownership transfer untouched. Clearing the field back to empty and saving lets it go, and the derived <Handle>'s Workspace resumes.

Names do not have to be unique — two people can each hand-type Acme. In the switcher, a workspace somebody else owns carries their name beneath it, which is the one thing that separates two rows reading the same name.

The website carries the same list at Dashboard → Workspaces, with a Create a Workspace card and, for each workspace you belong to, its members, pending invites, and storage.

Roles

Role	Can do
Owner	Everything — manage members, billing, secrets, delete projects, configure permissions, transfer ownership, delete the workspace
Manager	Same as owner except transferring ownership, removing the owner, and deleting the workspace — manage settings, approve project transfers, and promote or demote other members
Member	Edit PRDs, run stories, respond to every gate including quality checkpoints, create projects (plus any actions opened up by permission overrides)

Owners and managers promote a member to manager, or demote a manager back to member, from the Members page in the desktop app and from Dashboard → Workspaces on the website. Only an owner can hand ownership over, and doing so makes them a regular member. Ownership can only go to somebody with room for it: a member who already owns ten workspaces is at the limit, and the transfer is refused rather than pushing them past it.

Configurable Permissions

Two actions default to owner-only and can be opened up to every member:

Permission	Default	Description
Manage Secrets	Owner Only	Who can create, edit, delete, or reveal secret values
Delete Projects	Owner Only	Who can archive (soft-delete) projects

Gates are not among them. Any member of the workspace can respond to any gate on a project they can reach — a quality checkpoint included — so there is nothing to configure there. Responding to a gate that lands a commit or a merge additionally needs write access to the repo, which comes from GitHub rather than from Trinity.

Set them in Workspace Settings → Access Control → Permissions, or override one per project in Project Settings → General → Permissions.

The cascade is: Project → Workspace → Default (owner only), and it runs in every workspace. A workspace with only you in it is not exempt — it resolves the same cascade and you pass it as that workspace's owner. The Permissions and Transfers tabs are hidden there, since both are entirely about other members acting; they appear as soon as somebody else joins.

Inviting Members

Owners and managers invite from the Members page, reached from the workspace switcher:

Click Invite Member
Enter the person's @handle or email address
They get an invitation, which lands in their Inbox and as an email link to /workspaces/invite

Pending invitations are listed under Pending Invites on the same page until they're accepted or declined. The website's Dashboard → Workspaces carries an Invite by email field for the same thing.

Removing Members

Owners and managers remove a member from the Members page in the desktop app, or from Dashboard → Workspaces on the website. Removal locks them out immediately, pulls their access from project repositories, and rotates the workspace encryption key, so secrets written from that point on are unreadable to them. A removal done in the desktop app rotates the key on the spot; one done on the website is rotated by a member's device that holds the key — within seconds if one is open, and at its next start otherwise.

What rotation does and does not protect. Rotating the workspace key protects new secrets only. Anything the member could already read may have been copied while they had access, and no key rotation can take that back. For any credential they could see — an API key, a token, a password — the effective revocation is rotating that credential at its source provider (e.g., generate a new API key and revoke the old one on the provider's dashboard). Treat the in-app rotation as containment for future writes, and the upstream rotation as the actual revocation.

If the removal happened on the website (or the removing device couldn't rotate), the Encryption Keys card in Workspace Settings shows a Workspace key rotation pending warning while that is still outstanding. Nobody has to answer it: a device holding the workspace key rotates on its own — within seconds if one is open when the removal lands, and at its next start otherwise. The card's Rotate workspace key button only skips that wait.

Encryption Keys

Workspace Settings → Access Control → Encryption Keys is where the workspace's shared key lives. The key is generated and held on member devices; the server only relays sealed, signed grants it cannot read.

Two keys are in play, and they are not the same thing:

The workspace key is the group key. Every current member's devices hold it, and it decrypts the workspace's shared rows.
A member key is one person's own key. It decrypts only that person's own rows, and nobody else in the workspace can read them. See Secrets → End-to-end encryption.

Automatic Key Delivery

Creating the key, handing it to a new member, and rotating it after a removal all happen on their own, on the devices of the people already in the workspace. There is no setup step, nothing to switch on, and nobody to approve it. A member's app does the work whenever it has reason to:

when it starts
when you create a workspace — its key exists before you have done anything in it
when you switch to another account
within seconds of a membership change, on any member's app that is already open

That last one is what makes joining feel immediate: accepting an invitation tells every member's app to take another look, and the first one holding the key hands it over.

That leaves the card as a window onto work that mostly happens without it, plus buttons for skipping the wait:

Pending key grants — the members who don't hold the key yet. It reads Every member holds the workspace key when there's nothing outstanding. A row stays here while no key holder's app has been running since that member joined, or while that member hasn't signed in on a device to deliver to yet. Anyone on a device that holds the key can press Grant key to hand it over now rather than waiting.
Create workspace key — shown only when the workspace hasn't got one, and only to the owner, since only an owner's device can make the first one. It gets made unasked; this does it now.
Rotate workspace key — the warning appears for everyone whenever a removal left a rotation owed; the button itself is offered only on a device that holds the key, and is likewise only a shortcut past the wait.
Automatic key delivery is failing on this device — a warning naming the reason, and the one thing on the card you may genuinely need to act on. Everything else here runs unattended, so a device that keeps failing would otherwise leave members locked out of the workspace's secrets with nothing to read about why. The buttons above do the same work by hand, and the warning clears once a later attempt gets through.

If you suspect one of your own keys has leaked rather than a removed member's, you don't have to wait for a rotation to be owed here — rotate directly from Account → Profile → Devices → Rotate your keys, which covers your member key and every workspace key you hold, in every workspace, in one pass.

The owner hears when the key moves. Trinity emails the workspace owner when a member gains the workspace key for the first time, and when the key is rotated. Nobody approves either one, and both usually happen on another member's device, so the email is how an owner learns of them at all — including when the owner's own device did the work, the way the account alerts still reach you for a device you added yourself. Neither carries any key material, and each says when it happened, so it can be lined up against something you already know about.

Workspace Key Resilience

There is no separate code to save for a workspace, and nothing to file away. The workspace key exists as one sealed grant per member — each openable by that member's own personal recovery phrase — plus whatever a running app holds in memory. It never touches disk. So a member who loses every device restores their account from their own 12 words, and their workspace grant opens with it; the key is beyond reach only if every member loses every device and their personal recovery phrase at the same time.

That is why the card nudges toward a second owner or manager holding the key rather than toward another secret. The only secret you manage is your own recovery phrase — see Signing In for how that one is saved and used.

Answering Invitations and Requests

Anything a workspace needs an answer from you about — an invitation to join one, an access request inside one, a project on its way out of one — arrives in the Inbox at the foot of the sidebar. It spans every workspace you belong to at once, which is what lets a workspace invitation reach you before you are a member of the workspace it names, and lets an owner answer a request in a background workspace without switching into it first. See Inbox for what lands there and how you act on it.

Workspace Settings

Settings in the workspace switcher opens the workspace's own settings and your personal ones inside it, on one page with an Editing: Mine | Workspace toggle at the top. Workspace is what this workspace answers for everyone in it — everyone can read it, only owners and managers can change it, and a member who opens it sees a note saying so. Mine is your own answer for your own runs in the same workspace; see App Settings for that side of the toggle.

What You Can Configure

Under Workspace:

Tab	Settings
Automation	Auto Create PR, Auto Merge, Squash Merge, Delete After Merge, Auto-Approve Quality Checkpoints, Auto-Approve Technology Deviations, the Placeholder Audits matrix, and whether agents may file Trinity bug reports
Project Access	Who can actually be granted write access to each project's repositories (below)
Git & Branching	Destination, Branching, Releases, Promotion
AI Models	Default models for each tier (Frontier, Reasoning, Standard, Micro)
Access Control	Business Email, Encryption Keys, Permissions, Transfers, Storage, Local Storage, Workspace Name

Flipping the toggle to Mine keeps you on the same tab wherever the two tiers share one, and drops the tabs that have no personal answer — a project's repository access, where new repos get created, the workspace's encryption keys. What a tab holds is decided by whether the setting is yours to answer at all, so a field the workspace answers once for everybody simply isn't offered under Mine.

Settings Hierarchy

Settings cascade in this order — each layer overrides the previous:

Trinity's own defaults — the floor every unset field falls back to
Workspace settings — what this workspace answers for everyone in it
My workspace settings — your own overrides for your runs in this workspace
Project settings — per-project overrides
My project overrides — your own overrides for one project
Entity (story/release level) — per-entity automation overrides, plus a programmatic model field (no per-story/release model picker in the UI)
Job (run-level) — one-time overrides when starting a run

When a setting shows "workspace" or "not set", it isn't set at that layer and the one above it is answering.

Theme, timezone and auto-update aren't in this list at all — they belong to you rather than to a workspace, and live on the Account page, where they apply everywhere you work.

Push to Projects

The Push to Projects button on the Automation, Git, and AI Models cards resets every project's overrides for those fields back to "inherit", so each project picks up the current workspace defaults — except a project's Staging Targets, which are rows of their own and are untouched by a Git push. Useful after changing a workspace-wide policy. It rewrites every member's projects, so it appears only while the toggle reads Workspace, and only for owners and managers.

Project Access

The Project Access tab shows, per project, whether each member can actually be granted write access to that project's repositories — so you can spot who's blocking a run before they hit a gate. Pick a project from the selector; each member carries one of these states:

Ready — connected, verified, and able to push
Blocked — connected but missing write access on at least one repo
Email needed — connected to a host like Bitbucket or Forgejo without a commit email set yet (see Commit email per account); their own row offers a shortcut to set it in account settings
No account — hasn't connected a git account for the project's host
Invited — has a pending repository collaborator invite (managers can Invite)
Unverified — account connected but not yet verified on the host
Removing — being removed from the project's repos

Managers Invite or Remove a member from a project's repositories here. Every grant runs in the moment, as the acting manager's own git identity — Trinity stores no admin token and runs no background sync.

Business Email Enforcement

Restrict workspace membership to users whose email address matches your organization's domain. When enabled, only users with a matching email domain (e.g., @yourcompany.com) can be invited or accept invitations.

Go to Workspace Settings → Access Control → Business Email
Toggle Require matching email domain
The domain is taken from the workspace owner's email address

Workspace Name

Give the workspace a name of your own instead of the derived <Handle>'s Workspace.

Go to Workspace Settings → Access Control → Workspace Name
Type a name and Save

It reads everywhere the old one did — the switcher, the members page, your inbox, the website dashboard, invite emails — without needing to sign back in. Clear the field and save to let it go: the workspace goes back to the derived name, and keeps following the owner's handle again.

This applies to all new invitations — existing members are not affected.

Workspace Storage

When a project uses Trinity Cloud storage, those bytes come out of the workspace owner's managed storage pool — not a separate bucket per workspace. Each person has a single 10 GB pool shared across every workspace they own, so uploads stake against whoever owns the workspace.

Once the beta opens, an owner who needs more space can add 10 GB packs for $5/month each from Dashboard → Billing. Members cannot buy packs for a workspace they don't own — the owner controls the pool. While the closed beta runs that page is unreachable, so the pool is the 10 GB every owner starts with.

For real volume, switch the project to BYO S3 instead. BYO S3 has no Trinity storage limit; the workspace points at its own bucket and Trinity stays out of the accounting.

Collaboration Features

A shared workspace gets real-time collaboration tools:

Shared AI conversations

Trinity's Architect is a shared, multi-user conversation. You and the other members talk to the AI in the same thread: see who's in the conversation, watch replies stream in, and pick up a chat someone else started. (The Help Assistant is the exception — it's a private, single-user chat, yours alone and global across your projects, not visible to anyone else.) In a shared conversation the agent stays quiet until someone @mentions it, so people can talk things through without it jumping in; on your own it answers every message. Mentioning the agent also pulls the turn onto your machine — whoever addresses it runs it, and the previous runner steps back to watching within about a second. When an agent asks to run a tool, only the person whose agent it is gets the Allow / Deny prompt — everyone else sees a read-only note that approval is pending (and how it was decided), so the whole workspace has awareness without anyone else being able to greenlight it.

Comments

Leave comments on stories, epics, and other entities. Comments sync to every member and show in the entity's detail view. Edit or delete your own comments.

Activity Feed

The Activity page in the sidebar is a global standalone feed showing all actions across your projects. Filter by:

Project — narrow to a specific project
Category — Execution, Stories, Projects, Assets, Planning, Releases, Knowledge, Workspaces, or Comments
Actor — filter by person or system actions

The feed shows activity from every member of the workspace — in a workspace of one that is just your own actions. Each entry shows who did what, when, and on which entity — with links to jump directly to the relevant story, release, or project.

Presence

When viewing stories or other entities, you'll see avatar indicators showing which members are currently viewing the same item. Presence updates in real time.

Entity Timeline

Each entity (story, epic, phase, release) has a timeline tab showing its full history — who changed what, when, and why. Changes are grouped by action with expandable field-level diffs (old value → new value). System actions (from the execution pipeline) show as "Trinity".

Moving Projects Between Workspaces

Move a project from Project Settings → Danger. It goes to another workspace you already belong to: the project's data is migrated into that workspace's database and its cloud assets are re-keyed to match.

You can only pick a destination you are a member of, which is the same authority under which you could have created the project there — so there is nothing to approve on the receiving side.

Stop the project's work first. A move is refused while any of its jobs is still queued, running, or waiting on a gate — that work is claimed by a device in the workspace the project is leaving. Finished jobs come along as history.

A few things stay behind, because they would mean nothing in the new workspace: the project's member list, which you rebuild there; each member's own view of the project, such as their settings and notifications; and any lock or claim held by work that was running here.

Approval Workflow

The workspace a project is LEAVING decides whether that needs an owner's blessing, via Transfers in its Access Control settings:

Policy	Default	Effect
Move Projects Out	Require Approval	Members must get owner/manager approval before moving a project out of here

When approval is required:

The member starts the move — a request is filed, not executed
Owners and managers of that workspace see it in their Inbox
After approval, the move executes on the requester's next sync
Requests expire after 7 days if not acted on

Owners and managers move projects out immediately, bypassing approval. Either way it requires typing the project name to confirm.

A workspace of one doesn't show this policy at all — its only member is its owner, so the approval it would ask for is one they already have. It appears as soon as somebody else is invited.

How Sync Works

Trinity reads and writes through the website's API. Planning data, stories, knowledge base, and execution jobs all live in your workspace's database server-side, so every member sees the same state. The only data that lives on each member's machine is small machine-local state — worktree paths, worker processes, locally-bound projects — kept in a local SQLite file at ~/.trinity/.

Trinity needs an active internet connection. There's no offline mode.