Inbox

Inbox sits at the foot of the sidebar and holds everything waiting on you, across every workspace you belong to. It carries a single count — unread notifications, the invitations addressed to you, and the requests you are able to act on — and it reaches your whole account rather than one workspace, so the number is right without switching anywhere first.

Two different things share the page and stay two different things. Requests are answers you owe somebody, and they sit at the top because every one of them wants something from you. Notifications are a record of what happened, and they sit below, answered by reading them. The split comes down to how you answer: a request is a yes or a no, settled right there on the row, while a notification takes you to where the answering actually happens, because there's more to it than a yes or a no.

Requests

Invitations

Anything addressed to you personally, each row badged with its kind:

• Workspace Invite — an invitation to join a workspace
• Sponsorship — someone offering to pay for your Trinity membership
• Storage Gift — a 10 GB storage pack gifted to you

While the closed beta runs, a workspace invite is the only kind that reaches you. Every approved account is comped and no storage pack is on sale, so there is no membership to sponsor and no pack to gift — the routes that mint those two offers refuse while the beta is on. Both return once it opens.

Each carries Accept and Decline. Accepting an invite adds you to the workspace immediately and it appears in the workspace switcher; declining removes the invitation. A workspace invitation reaches you before you are a member of the workspace it names, which is exactly why this surface belongs to your account and not to any workspace — see Workspaces.

Access Requests and Project Transfers

Under the invitations, one block per workspace you belong to, each headed with that workspace's name:

• Access Requests — a member who cannot yet push to a project's repositories asking to be let in. Invite grants it in the moment, as your own git identity.
• Project Transfers — a project on its way out of that workspace, waiting on Approve or Reject. If you filed the move yourself, the row is yours to Cancel instead.

Because every workspace's block renders here, an owner or manager acts on all of them without switching workspace, and the workspace switcher carries a dot beside any workspace with something in it you can answer. What counts as answerable depends on your role: a transfer counts if you filed it or hold owner or manager privileges there; an access request counts only for owners and managers, since they are the only people who can grant one.

Notifications

Below the requests, every notification addressed to you, newest first. Trinity raises one whenever work you set going reaches a point you would otherwise have to sit and watch for — and whenever a teammate addresses you directly:

• a story finishing, failing, or being cancelled
• a run parking at a gate, or stalling on a failure that blocks everything behind it
• a run asking you a question it could not settle on its own
• a conversation asking you a question it could not settle on its own, so a session parked on your answer says so from wherever you are rather than only on the thread it is asking from
• an Architect run or a generation landing — and one that runs cleanly but produces nothing says exactly that, rather than arriving as though it were ready
• each phase of a PRD generation as it seals, so a long generation reports five times instead of going quiet until the end
• a run another run kicked off — a diagnosis, a report — reporting its own outcome on its own transcript rather than disappearing into the run above it, while a wave of interchangeable steps still reports once through the run that dispatched it
• a teammate @-mentioning you in a conversation

Each row shows a Kind badge saying how much it wants from you, alongside the project it came from, when it arrived, and a New badge while it is unread. There are five, and they differ in what they ask of you rather than only in wording:

• Needs you — parked until you act: a gate to answer, a question to settle, a run stalled on something only you can clear.
• Failed — it went wrong, and nothing is waiting on your answer.
• Done — it finished, and it produced what it set out to.
• Progress — a step landed and the run carries on. Worth having on the record, never worth interrupting you over.
• Mention — a teammate tagged you in a conversation.

Clicking a row opens the notification, at an address of its own. The detail has a URL you can copy, send to a teammate or come back to later, and the back button closes it again. It names the workspace and project the notification came from in full, and carries an Open button when there is somewhere to go.

Opening that destination takes you straight there, whichever workspace you are in. The address a notification was raised at names its workspace and its project, so following it moves you to both — including on a cold start, and including from a link somebody sent you. A notification with nowhere to go has only its own detail, which is the point of giving the detail an address.

Filtering

Four filters narrow the list, and they read the notifications themselves rather than the workspace you happen to be in:

• Read state — All, Unread, Read
• Kind — All Kinds, Needs you, Failed, Done, Progress, Mention
• Workspace — All workspaces, or one of them
• Project — All Projects, or one of them

The two scope filters cascade: pick a workspace and the project list narrows to that workspace's projects; leave it on All workspaces and the project list spans every one you belong to. Picking a workspace also clears the project you had chosen, since it may belong to a different one.

A filtered view is a view you can keep. The filters sit in the address, so a reload brings the same view back, the back button walks you through the ones you tried, and a filtered inbox is something you can bookmark or send to a teammate. Opening a notification and closing it again returns you to the filters you were reading under.

Mark All Read clears the badge in one go, and each unread row has its own mark-read button. A question's row also clears itself the moment the question is answered — however you answer it, from the card or in the conversation — so the count only ever holds questions still waiting on you.

Desktop notifications

Trinity can also raise a native OS notification as an entry arrives, which focuses the app and opens the entry when you click it. Your operating system asks for permission the first time you open the inbox — that click is the user gesture the prompt needs — and once you have answered, it never asks again.

Progress entries are the exception, and they raise no desktop notification at all: a five-phase PRD generation would otherwise interrupt you five times, each at the same level as the plan itself being finished. They still arrive in the inbox, still count toward the badge, and still filter like anything else — they simply do not knock. Every other kind raises one desktop notification per arrival, and a backlog of unread entries waiting when you start Trinity raises none.

Where the count comes from

The badge on the sidebar entry sums three independent sources — unread notifications, your pending invitations, and the requests you can act on in any workspace — because they answer one question between them. It shows 9+ past nine, and disappears entirely at zero.