v0.4.0
Plan, Design, and Ship From One Conversation
The Architect becomes the home for your whole project — set it up, plan it, design it, and review it in one conversation your team can join, then hand any of it to someone else as a link. Tune the model behind every step of a run, and ship releases along a promotion path you choose.
New
Set up a new project by talking to the Architect
Starting a project is a conversation now, not a form to fill out. Describe what you want to build and the Architect walks you through a short, adaptive set of questions — clarifying your idea, design direction, tech stack, any services that need keys, and the agent skills to install — then generates your roadmap and first stories. Questions appear inline in the chat, one at a time, with the Architect's recommendation already selected so confirming it is a single tap, and each one also raises a row in your inbox so it reaches you even when you're looking somewhere else; each stays put afterwards as a record of what was picked and who picked it, and you can reconsider an answer you already gave, which reopens the choice and re-plans around your new pick. Paste in a brief or a requirements doc and it gets read adversarially rather than treated as the end of the interview — who this is really for, what it assumes without saying so, where it contradicts itself — with every gap turned back into a question. Anything the Architect sends off while you talk says roughly how long it takes and invites you to keep going, and it checks in with you at the end of each topic rather than marching ahead. Accepting a plan closes that session with a written sign-off — what landed, the shape of it, and what happens next — and your next round opens as a fresh draft carrying the vision and phasing you already settled on. The finished session stays readable, shareable, and exactly as you left it. Your whole team can join the conversation, contribute answers, and pick it back up on any device.Everything your project needs is created the moment you accept a plan
While you plan, the Architect works out the repositories, tech stack, and service keys your project needs and folds them into the plan — describing each repo in plain terms the first time round, rather than making you ask again for a sentence that says something. For a greenfield build it also works out, per codebase, whether that codebase needs Docker Compose and which databases, caches, or queues it runs on, so an API that needs Postgres and Redis sits alongside a marketing site that needs nothing, and a run starts only the services the codebases it touches actually declare. Nothing is created until you confirm: it is all set up in one step when you accept your first plan, so your say-so is the single moment it comes to life. You can also ask the Architect to split part of a repository into its own repo, and it re-homes the affected work for you.Open any part of your plan in its own panel
Your full plan, an incremental change set (what's added, modified, and removed, each with a reason), your roadmap, what your change is building, the tech stack, and your repo structure each live on a rail beside the conversation. Open any one into a focused panel and tell the Architect "looks good" or "change this" without leaving the chat — it revises the same panel in place as you refine it. The rail grows as the conversation decides things rather than showing every panel from the moment it opens, so everything on it is worth opening, and your last-open panel and its size are remembered per device.Your roadmap is part of the plan, phased MVP-first
Every planning round produces two readings of the same decision: the story graph you execute, and the roadmap that says it in plain English — an overview, the vision behind it, how the work is phased, the architecture, and the design system. The Architect sequences your work into ordered phases across the whole project, the first of which is always your MVP, and shows them on their own panel so you can see what ships when. The roadmap travels with its plan rather than sitting in the Knowledge Base: open a PRD and its roadmap is a tab away. Both documents are written together, committed together, and shared as their own separate links. An epic can carry a short summary of what the group is and why it exists, shown right above its stories.Your tech stack shows where every piece stands
The Stack card in project settings labels each service with where it is in its life: Pending Review for something the Architect proposed, Adding while a story is putting it in, Active once that story has shipped, and Planned Removal then Removing on the way back out. Each row names the story that put it there, so you can see what asked for it and when it landed. Accept or reject a proposal on the spot, and if a removal turns out to be a mistake, Re-activate takes it back — right up until the story that removes it ships. None of it is a flag someone remembered to set: where a piece stands is worked out from what your stories actually declared and shipped, and Trinity rescans your repositories whenever a story merges rather than waiting for you to press Scan. Every agent reads the whole picture — what's live, what a story is adding, what's on its way out — so a story implementing a brand-new dependency is briefed with it instead of against a partial list. When the Architect proposes a service it researches the pricing too, and shows it right on the choice — free, freemium, or paid, with a short note and a source link — so you can weigh cost while you shape your stack instead of finding out later.Shape your project's whole design system in the conversation
The Architect proposes a handful of genuinely distinct design directions and renders each as a live-tinted preview of a real design-system page: a card with a heading, copy and buttons above every color role the system carries, each shown as the thing it is, so a supporting color is a filled button and a focus color is a focus ring. Every direction sets its highlight against its main color deliberately, commits the page's own background and text, and tunes its error, warning, success and info colors to belong to that look rather than pasting the same four onto every option — and every filled color is checked against the page behind it, at the bar a filled control actually has to meet, so nothing reaches you washed out. An eye beside each card opens the direction full size, with a Proposed menu beside a Light / Dark control that opens on whichever your computer is already set to — pick any other candidate from it to flip between them at full size; nothing is chosen until you press Pick this. Color is only the first card. Typography, corner shape, elevation, motion and content density each come as their own live preview — font pairings set in the real typefaces, motion animating at its real speed and curve, density shown as real content at that spacing — and each card gets the same full-size eye. Projects whose look lives on emitted light get a glow card too, offering a faint edge-light, a hot sign-tube burn or a broad atmospheric wash, tinted from a color you already picked so it can never drift from your palette. You can open the proposed palette and adjust individual colors in both themes before it saves, and write down the parts a color picker can't hold — "closer to Linear than to Notion", "never gradients" — as design notes the Architect keeps for you. All of it becomes named tokens handed to the planner and to every agent, so generated code writes to theme roles instead of hardcoding one-off values, and a design-system swap is always carried by a story that accounts for it.Import brings your existing design system with it
When you import an existing project, Trinity reads the colors, typography, spacing, type scale and theme out of your actual CSS, Tailwind, or component library, groups your app's surfaces into design systems, and lets you review, rename, split, merge, or skip them before you finish setup — shown as real retinted interface rather than swatches and a type sample. Where your code names its corner rounding, elevation, or animation timing outright, those come across exactly as written. If your project runs a framework Trinity recognises — shadcn or Bootstrap — a stock install comes back with a complete palette rather than the two colors you happened to override, filled in from that framework's own published values, because the ones you never touched aren't missing from your app. Anything your code declares always wins over a framework default, and a swatch is only flagged for a second look when Trinity genuinely had to guess.Design interactive prototypes in the conversation
Ask the Architect for a prototype and it builds one you can click through: several pages that link together, live interactions, and your own fonts and design-system colors. A multi-page prototype settles its screen list and shared foundation first and then builds every remaining page at once, so a large one arrives in closer to the time a small one takes, all of it against the same shared styles. Preview it full-screen at phone, tablet, or desktop size right in the chat, and browse every prototype your project has in a new Design gallery. Each one keeps a history of checkpoints numbered v1 upward with the newest marked Current, each row showing its own rendered preview. Restoring one takes the whole project back to it — every page and the design system they share move together — and lands as the newest checkpoint, so the point you just left is still there to return to. Ask for a different direction and the Architect forks the prototype into a parallel copy: compare any two side by side, then promote the one you want as the design your stories build from. A prototype built from a design system that ships both light and dark opens matching your computer's appearance and keeps following it, with a Light / Dark / System control for when you want to hold it on one side.Turn a review into a report, and find everything the Architect makes in one place
After the Architect reviews your project, ask it to write the findings up and it produces a single self-contained report — the verdict, an architecture score, and every finding grouped by severity. Reports live beside your prototypes in a new Artifacts view, so the three things the Architect makes for you — prototypes, reports, and your PRDs, each one's roadmap included — are all in one place. It opens on an Overview: one card per artifact showing where it stands at a glance, how many PRDs you're carrying, whether a prototype is ready to preview, how many reports have landed, each with its own unread dot and a click away from the thing itself. Once you're inside one, a trail across the top gets you back out, and[and]cycle between the three.Send the Architect off to research something, or to check your code by running it
Ask for research in the conversation, or type@research, and Trinity dispatches a background investigation that plans its own rounds of work, runs them in parallel, and reports each round as it finishes — handing back what it found, or writing it up as a report or building a prototype when the job calls for it. And when a planning or review question only running the code can answer — does the imported project build, do the tests pass, is this change feasible, is that finding real — the Architect sends off a diagnosis that checks the project out, runs whatever the question needs, and reports back with the evidence. Both keep working while you carry on with the conversation, and both get their own entry on the run bar, so you can open one and read every command it ran from any of your machines, during the run and long after it finishes.Follow the Architect's work as a trail you can step into
A bar above the conversation shows what's running as a path — Architect › PRD run › dependency-mapper — so you can see at a glance how deep the work goes. Click a step to drop into that run's own conversation and talk to it directly; hover it for live progress, elapsed time, and who's hosting it; click the arrow beside it to list what it spawned, each marked working, done, failed, or amber for one that's waiting on you. An Agents panel on the rail lays the whole family out as a tree — the conversation at the head, each run beneath it, and anything those runs sent off beneath them — so a run that finished, failed, or stopped reporting stays reachable long after the fact, with every node spelling its state out in words rather than leaving it to colour. A paused run names what it's holding on: work it sent off, a question it put to you, or a question it put to the run that briefed it — an agent that hits an ambiguity can now ask the agent that wrote its instructions instead of stopping to ask you, and when it does, the question shows on the briefing run's own transcript carrying the whole of what was asked. A run can also set itself a wake-up timer for the one thing Trinity can't tell it about — a build running elsewhere, a branch someone's still pushing to — and wait on that for free; so can the Architect, showing a Waiting until 2:07pm chip until it picks the conversation back up. A run paused with nothing left that could ever wake it is reported and closed out instead of sitting there looking busy. Where a message box won't take input — the run has ended, its connection lapsed, or it's a step that takes no direction at all — it says which, and offers a button to the nearest place that can.A long conversation doesn't run out of room
An Architect conversation that grows past what the model can hold keeps going instead of degrading or stopping. Between turns, Trinity summarizes the earlier part of it and carries on from there, with a marker inline in the conversation where each summary picks up — open it to read the summary and see how much it accounts for. Nothing is deleted: every message stays exactly where it was, and the agent can search and re-read the real history whenever the summary isn't enough, so it goes back and checks what was actually said rather than guessing. The skills it loaded are put back in front of it after each summary too, so it keeps following the instructions it started with.Bring images and reference material into your planning
Drop images straight into the Architect chat, and into comments, by dragging, pasting, or picking a file. An Assets · References panel lets you import PRDs, specs, wireframes, logos, and prototypes by dropping files or pasting links, and the Architect reads them before it asks questions or drafts a plan; paste a link and Trinity captures the live page as a full-page screenshot, saved under the page's own title with the original URL alongside. Share something in the conversation and the Architect saves what's worth keeping into your project's library on its own, sorting each one into reading material or a file that ships into your app and asking you when the call is genuinely ambiguous — re-sharing a link it already captured reuses that reference instead of saving it twice. A file dropped anywhere in the conversation attaches with a chip you can see in the composer and in the sent message; attachments are temporary by default and clear themselves out after a while, so a working conversation doesn't quietly fill your library with screenshots, and one click promotes any of them into a permanent project asset, keeping the same file rather than making a copy. An upload that fails says so — including one that would put you over your storage allowance — and a filename carrying accents or emoji keeps the name you gave it.Pick the model for each step of a run
Story settings let you choose the model, tier, and effort independently for every phase of a run — analysis, implementation, review, documentation — so you can spend reasoning power where it matters and keep the routine steps cheap. A Frontier tier sits above your usual choices with no standing default, so it only ever applies where you pick it: one phase of one story, or one turn in the Architect chat. A picker in the Architect's message box switches which model answers on the next turn; it always opens on the selection that reply will actually use — engine, provider, model, and effort — whether that came from your own override or your configured defaults, with Default marking the model your settings resolve to and Reset to default appearing only when there's an override to remove. Whatever you pick has to be a model Trinity actually carries: a typo or an unknown name is refused the moment you save it, in your settings, your team's defaults, a project's overrides, a story's per-step picks, and a release's automation overrides alike. And before a run's first phase begins, Trinity confirms every engine that run will reach for is installed on your machine — including a single step whose own override calls on an engine nothing else in the run touches — so a missing install is caught up front with two ways forward on the gate: install it, or retarget the affected steps onto an engine you already have, at the level the setting actually came from.More models to choose from
Added Anthropic's Claude Opus 5, now the default for the Reasoning tier, alongside xAI's Grok 4.6, Anthropic's Claude Fable 5.1, OpenAI's GPT-6 Astra, and the rest of OpenAI's GPT-5.6 family (Sol, Terra, and Luna). Sakana AI joins as a provider too, served through the Codex engine: Fugu is an orchestration model — one endpoint that routes your request across a pool of specialists and synthesizes the answer — and covers the micro, standard, and reasoning tiers on a Sakana-configured install, with Fugu Ultra as its frontier pick and Fugu Cyber, its cybersecurity specialist, available by pinning it on a story's step configuration once Sakana approves your access request. Models that newer releases have superseded are retired from the picker.Ship releases through staging to production, your way
The release flow moves along a clear path: your release branch merges up to a shared integration branch and on to production. A new Staging Targets board lets you place a release onto one or more staging branches and watch each one's status, drift, and checks at a glance; the Promote panel drives the whole thing with a choice of how to ship — the full path through staging, straight to your integration branch, or a hotfix that goes straight to production — and a one-click Unstage rolls any target back to exactly where it was. Targets come from a catalog you edit for the whole project, with per-repo overrides where one repo needs its own; both editors collect your changes and apply them together on Save. Type a branch the picker doesn't already offer and it's kept as its own target, so it comes back next time instead of being forgotten. When a release spans several repositories, they're tagged together on one matching version, all-or-nothing. Project settings let you pick the shape your project ships in — the full release → dev → production path, or a single trunk for projects that don't want a staging layer — and the wording throughout the Promote panel follows your choice rather than describing a generic path. Staging targets are their own setting, so Push to Projects — which resets a project's other git defaults back to your workspace's — leaves them exactly as you set them. A release with a job waiting at a gate shows Parked in place of its usual status, in the release detail header and in the Multi-Release Status bar, naming the gate kind that's been waiting longest with the reason underneath. And before a plan commits, the Architect asks which release the work belongs to and shows you the choice as a card — every open release plus a fresh one it can mint, with its recommendation already selected.Patch an old version without disturbing the current one
Alongside a standard release and a straight-to-production hotfix, you can ship a patch on a maintenance line — amaint/…branch cut from a version you already shipped — so a customer stuck on an older release gets a fix without inheriting everything since. Trinity keeps the ledger of what each line still owes your trunk: a fix that hasn't been carried back yet blocks that line from releasing again, and a hotfix can't finish shipping until its forward-port lands, so you can't quietly leave a fix stranded on one branch. When two releases target the same shared branch, the second waits on a durable claim rather than both pushing into it — and if the machine holding the claim dies, the claim is released rather than wedging the branch.Connect GitHub with a sign-in code
You can connect a GitHub account by authorizing Trinity with a short code instead of pasting a personal access token. Trinity shows you a code, you enter it on GitHub, and you're connected — no tokens to create, no scopes to figure out.See spend per teammate
Metrics adds a Users tab for team projects that breaks down AI cost and token usage by person, so you can see who's running what and where the spend is going.Mention your teammates in the conversation
Type@in the Architect chat to mention a teammate; they get notified so they can weigh in, and the Architect can mention people back by name when it needs a specific person. Mentions work from a run's steer box too, and reach the person named in both directions.Search your Knowledge Base, and read the User Guide, without leaving Trinity
Press Cmd-K in the Knowledge view to search everything your project has captured, with the most relevant pages ranked to the top; the in-app documentation gets the same instant search. And the Help section opens Trinity's complete user guide in a full-window view, so you can browse how every part of the app works without opening a browser.Tell Trinity what you do, and get explanations pitched for you
Right after you sign in, Trinity asks one short question: what do you do? Add a row for each thing that fits — engineer, designer, product manager, founder, data, QA, DevOps, marketing, student, other — and set the level you work at on each, so "I'm a senior dev and a mid designer" is two rows instead of a compromise. Skip is a real answer and the question never comes back either way; you see it once, on whichever machine you sign in on first, and change it any time from Settings → Profile. Trinity's agents read it as context about whoever is talking, so in a shared conversation the same answer gets pitched two ways to two teammates. It never changes what Trinity offers you, hides an option, or lowers the bar on your plan — saying you're new gets you more explanation, not less rigor.View, regenerate, or rotate your account keys
From Settings you can show or regenerate your recovery phrase any time, and — if your account key is ever compromised — rotate it in one guarded step that re-keys every device and re-issues your workspace keys. A separate Rotate keys issues a fresh generation of the keys you hold, across every workspace, without revoking a device — reach for it if you think a key may have leaked, or to finish a device removal whose rotation never completed. Trinity emails you when a device is added or removed, your recovery phrase is viewed or regenerated, or your account key is rotated, so you notice anything you didn't do.Let agents file Trinity bug reports for you (opt-in)
A new automation setting lets agents report Trinity bugs on your behalf when they hit one, so problems get surfaced without interrupting your run. It's off by default, and on teams the owner controls it.
Improved
You can see who's working alongside you
When you and a teammate are looking at the same plan, story, or release, small avatars show who's viewing right now, so you know when you're working side by side, and a shared decision prompt in the Architect lets everyone weigh in before a choice is locked in. A run is now told who sent each redirect, instead of hearing "make it monthly" from nobody in particular: it can answer the person who asked, and when two of you pull in opposite directions it can say so rather than quietly following whichever landed last. Several teammates writing to a paused run used to arrive merged into one anonymous blob; each message now keeps its own author and can be answered individually. Redirects are still applied one at a time, in the order they were sent.A finished run's notification opens the run
When a background run finishes or fails, the notification it leaves in your inbox now says how long it took, and clicking it lands you on that run's own transcript with the trail above it intact, rather than at the top of the conversation that started it. It holds long after the run is over: open the notification the next morning and it still opens the work it names. Every task in the sidebar's Tasks menu also shows a live elapsed timer, so you can tell at a glance whether something just started or has been going for an hour.A run that can't get what it needs pauses at a gate
If a run can't reach the secrets or environment it needs, or the model you picked has no API key set, it pauses at a clear gate where you can paste the key inline or retry once things are in place, instead of failing the run outright. If a repository isn't ready on disk yet, the run waits and resumes on its own once your workspace is whole — no restart needed.Queued work survives restarts and runs for the whole team
Queued runs are no longer dropped when you restart the app, and Trinity now works through the queued runs of every signed-in teammate, so a colleague's queued work gets picked up without anyone switching accounts.Agents build with your real files
Uploaded assets are taggable and searchable from the Architect, and when a run needs one, Trinity copies your actual file into the code at the right path instead of leaving a placeholder — so your logo, spec, or prototype ends up in the build. A per-file toggle marks whether something is reference material for the agents to read or a downloadable asset that ships into your app, and a missing file pauses the run at a clear gate rather than guessing. The Project Assets card now groups each planning conversation under its own name, or the day you started it, with stack, reports, and references as folders you can open — and asking for a stack suggestion or a pricing check again updates that file and keeps the earlier run as a version, so the group stays readable instead of filling with near-identical copies.Agents run in a locked-down sandbox
Every agent Trinity runs is now fenced into a sandbox: it can only write inside its own workspace, reads your shared project history without being able to change it, and is blocked from touching your secret environment files — so an agent stays inside the job it was given.A tier always picks the best your provider can do
Choosing a tier resolves inside the provider you picked: if that provider has nothing strong enough to reach the tier, you get its strongest model rather than being bounced onto a different vendor's paid API, which matters most when you're running a local model. A pick that sits below the tier's bar is labelled "best available" in the picker, so you can see when that's what you're getting.A plan lands at the size and shape it was planned for
The story, phase, and epic targets a plan is sized against no longer overlap between complexity tiers, and epic counts carry their own budget alongside the story count, so a project's structure lands in one clear band instead of straddling two. When the Architect proposes how many phases your build ships in, it weighs the project's size first and says so on the card — each phase ends in a full quality checkpoint, so more phases means more of those pauses — and asks whether you want it split finer or collapsed further; say yes and every phase reaches your plan exactly as named, in that order, with nothing quietly deferred or renamed along the way. The plan is checked against its budget every time generation saves it, not just when its stories are first drafted, so the tidying that runs after the last planning phase can't push it past that budget or past the ceiling any PRD has. That tidying can only edit the stories that are there — it can't add or remove one — and anything your roadmap promised that no story covers comes to you as a finding to accept, close, or defer rather than as stories written on your behalf. The whole last stretch now shows its progress on the run like every phase before it, and the summary says what it repaired and what it left for you. Committing a change applies as a single all-or-nothing step, so an interrupted save never leaves your story graph half-updated and rejecting a proposal leaves no trace; and because drafts are shared with your team, the save checks for concurrent edits and re-reads the latest state rather than silently overwriting a teammate's work.A long conversation costs less every turn
Trinity now sends an Architect conversation to the model in pieces that only ever grow at the end, so everything the model already read on the previous turn is served from its cache instead of being paid for again. The longer the conversation, the bigger the saving — and nothing about what the Architect reads changes, so answers are the same, they just cost a fraction of what they did and come back sooner.Reading a long conversation stays put
New messages arriving in the Architect no longer snap you back to the bottom while you're scrolled up reading, and neither does any single step inside a reply — a tool call or its result used to do it even when a finished reply wouldn't. A New messages button appears instead and jumps you down only when you choose to, and it now follows the conversation itself rather than anything that makes the page taller: resizing the window or opening a tool call no longer raises it with nothing behind it. Switching to another conversation starts you at the bottom of that one instead of carrying the button and your place across.Stories and diagrams read the way they're written
Story descriptions render with full formatting — lists, tables, code, and diagrams — while titles and acceptance criteria stay clean and single-line. Any diagram the Architect draws opens full-screen with scroll-to-zoom and drag-to-pan, matches your app's theme instead of clashing, and lays out complex flows far more cleanly.Recaps write themselves as they go, and stay put once a day closes
Your weekly and monthly recaps refresh on their own as new activity is summarized, with no reloading to see the latest. A day's recap no longer shifts after the fact either: resetting a story, changing your timezone, or a write-up finishing a day late won't rewrite a recap you've already read, and when a story's documentation lands the day after it merged, that later day's recap notes it with a link back to the day the story actually shipped.The Help Assistant answers from the real user guide
In-app help now grounds its answers in Trinity's actual documentation and links you to the most relevant pages, instead of guessing.Name a release yourself, and rename it later
Creating a release now gives you a name field, filled in with a suggested two-word name you can keep or replace, and the name is a label from then on, so you can rename a release whenever it stops describing the work. Its git branch is settled once, when the release is created, and stays put through any rename or reordering — nothing in flight is orphaned and no work moves branches under you. If you do want the branch itself renamed, Trinity drains the release's in-flight work first, moves each repo's branch in turn, and keeps a per-repo record, so an interrupted rename resumes exactly where it stopped instead of leaving repos half-moved.Tune how hard builds and tests run
Settings now has a Build & test concurrency control, so on a many-core machine you can let more full builds and test runs overlap instead of the default one-at-a-time. It's set per machine and takes effect right away.The numbers Trinity shows you are the real numbers
The AI Usage table adds a Reasoning column showing what each model spent thinking before it answered, and marks the calls Trinity has no price on file for; your total carries the same note, so a headline figure never quietly reads as exact when part of it is the provider's own estimate. The billing page adds up seats and storage into the actual amount you'll be charged, so a multi-seat plan shows the true total rather than a single seat's price. And every place that quotes your managed storage pool — the pricing card, the FAQ, the Terms, your dashboard, the workspace storage card, and a project's storage settings — now reads one figure instead of each keeping its own copy; two cards inside the app had drifted to an older, smaller number and were telling you that you had half the room you actually have. The wording is straightened out too: the pool belongs to whoever owns the workspace and is shared across every workspace they own, rather than being something each seat brings along. Going over the allowance pauses new uploads while your existing files stay readable, and the notices say exactly that.Give a workspace a name of your own
A workspace reads as your account handle until you call it something else. Owners and managers can set a real name for it from the Workspace Name card in Settings, and clearing that name drops it back to the handle-derived one, so there's no way to strand a workspace without a label.Tell two workspaces with the same name apart
Nothing stops two people from each naming a workspaceAcme, and in the switcher they read as two identical rows. A workspace somebody else owns now carries their name underneath it, so you can see which one is which without switching into either.The workspace encryption key looks after itself
It is created on an owner's device, handed to each new member, and rotated after a removal, all on their own — there is no setting for it and no approval step, because delivery waits on nobody's decision. A member who accepts an invitation while someone holding the key has Trinity open is given it within seconds rather than at that person's next launch, and the rotation a removal owes lands on the same timescale. That leaves the Encryption Keys card as a window onto work that has already happened, with buttons that only skip the wait — plus one warning naming a device that keeps failing to do it, which is the one thing there you might actually have to act on. Trinity also emails the workspace owner when a member first gains the workspace key and when the key is rotated — including when it was the owner's own device that did it, the way your account alerts already reach you for a device you added yourself.
Fixed
Setting up, importing, or moving a project stops losing your work
The Import Existing flow saved your progress automatically and then, moments later, wiped it: your scan results, the packages and repositories you'd reviewed, and which step you were on were all discarded by the very save meant to keep them, dropping you back to the start. Separately, while Trinity was extracting your business and contact details in the background, anything else being saved at the same moment could quietly overwrite it, or be overwritten by it — the last save to land won and the other one vanished. And moving a project between your personal workspace and a team left the dependencies between stories and your AI conversation history behind. Everything in an import now survives closing the app and coming back, each project detail is saved on its own so background work and your own edits can happen together, and a moved project now carries everything tied to it — its AI cost history included — instead of a hand-picked few things; a move is refused outright while any of the project's work is still queued, running, or waiting on a gate, so nothing you're actively running gets stranded mid-move.New projects branch by the story, not by a stand-in id
A new project's branches used to read likefeat/ABC123, a sequence id with nothing to say about the story itself. They now read likefeat/setup-auth. This only changes new projects — a project you already have keeps the branch pattern it's always used.Removing a package, or a repo whose package still holds secrets, is refused instead of failing unpredictably
Deleting a repository whose package held a secret, or removing a package directly, could come back as a raw server error with no explanation. Both are now refused outright, naming how many secrets are still stored there, so you know what you'd be giving up before you try again.Deleting a project also deletes the files it stored
Removing a project used to leave every file you'd uploaded to it sitting in Trinity's storage indefinitely, even though the project itself was gone. Deleting a project now removes those files too, unless another project or asset still points at the same one.A run that has stopped is reported as stopped, on every device
If the machine driving a generation crashed or lost its connection, your other devices could show that run as "Running" indefinitely with nothing ever telling you it had died. A run that went quiet for a moment — a long step, a slow connection — could also pick up the "Lost contact" mark and keep it for the rest of its life even while it was plainly still working. And a run that died with the app was correctly marked failed at the next start, then sat there as a Failed entry long after there was anything to look at. A stalled run is now reported as failed everywhere, on every device and in your inbox; a run that checks back in reads as running again on its very next check-in; and a crashed run is cleared out at the next start with its failure reaching you as an inbox notification. Exactly one of your machines drives an agent at a time, and if that machine's connection cut out for long enough the conversation could be left with nothing running it and no obvious way back short of a restart — hosting is now picked back up in place the moment the connection returns, and while it's gone the message box says this device isn't the one running the agent instead of silently swallowing what you type.A conversation you reopen is the one you left
Reloading the Architect could reshuffle a conversation: a reply would sit above the question or the tool call that came before it, anything that arrived while the agent was still writing landed in the wrong place, and reopening moments after a reply could show that reply's text twice. Messages are now recorded where they were actually spoken. A turn that failed on the server used to spin forever, too; it now surfaces a clear, retryable error that clears itself the moment the agent replies again, so a conversation that recovered stops showing a failure that has stopped being true, and a busy agent working through many steps is never cut off early. Two tool calls rendered wrong as well: a shipped skill'sSKILL.mdfinished loading but kept its in-flight spinner with the contents dangling underneath as a separate line, and a file the agent had read printed every line's number twice — once down the side and again baked into the line. Both settle into one card now, with line numbers shown once and matching the file's real numbering even when only part of it was read.Steering a run always lands
Redirecting a run or answering its question after it had finished, failed, or lost its connection used to report success without doing anything, so the Architect could tell you a change had landed on a run that was no longer there. Roadmap generations and diagnoses were offered for steering like everything else, but nothing was listening — your redirect was accepted and quietly went nowhere. And a run that had said it was finished and was then handed something else before it closed came back for one more turn it could never end, sitting idle until a half-hour safety timer stopped it. Every run the Architect starts now folds a redirect into its next turn, a redirect that can't land says so, and a run brought back after finishing ends the moment it says it's done, however many times it's been brought back.Roadmap generation reports its failures, and the roadmap reads as formatted text
A roadmap generation whose draft never actually persisted still reported success, leaving you with nothing to open and no sign anything had gone wrong. Roadmap sections also showed their raw markdown characters instead of rendered headings, lists, and emphasis.A run's merges and failed checks report what really happened
When a repository was missing or skipped during a multi-repo merge, the run could look like it passed cleanly; it now stops at a clear gate, so a stranded repo can't slip through as done. And when a build or test gate failed, Trinity showed you the last few lines of the whole run rather than the output of the step that actually failed — so the thing that went wrong was often nowhere on screen. You now get the failing step's own output.Quality checkpoints behave like the work they guard
A quality checkpoint skipped every check a normal story clears before it starts, so one pointed at a provider with no key — or waiting on a workspace key grant, or blocked on a service that had never been set up — began anyway and died part-way through its audit with the work stranded on its branch. Checkpoints now pause at the same gates a story does, before any agent runs and before a workspace is even created, and answering the gate starts the checkpoint from the top instead of failing the run on a response it didn't recognize. In the plan tree, a checkpoint used to look exactly like a normal story with no way to tell an audit gate apart from planned work, and it inflated your story count; checkpoints now render with their own marker and a muted style, counted separately from your story total.The provider-key gate checks every step and names the one that needs a key
The check used to look at the standard tier's provider only, which was wrong both ways: a story with a phase pointed at a different provider would start and then die partway through on a missing key, while a story that never touched the standard tier could be paused for a key nothing in the run needed. Trinity now checks each phase the run can actually reach, a quality checkpoint's own phases included, and a phase the story will definitely skip no longer blocks anything. The gate dialog also showed only the provider and always pointed you at Settings → AI Models, even when the step's model was pinned on the story itself and that setting had no effect; it now names the step and the model it resolved to, and points you at the right place to change it. The AI-models settings list every provider, warn you up front when a key is missing, and won't start a run against a provider you haven't configured.A story's execution settings name the model it will really run
The Execution Settings card on a story worked out its "Tier default" and its "Effective:" note from your personal settings alone, so on any project carrying a model override it confidently named a model the run would never use — the one thing the card exists to tell you. It now reads the same answer the pipeline resolves for that story, with the project's models, your own per-project choice, and any per-story override all folded in, and while that answer is still on its way it says so rather than filling the gap with a guess.A story's edit lands as one step, not several
If you added a dependency or package to a story alongside other changes in the same save, and that dependency or package turned out to be invalid, the rest of your edit could still go through silently — the story ended up updated, just missing the piece that failed, with nothing telling you. The whole edit now saves together, or not at all.AI cost adds up correctly
Several errors in how spend was calculated are fixed. A turn that used more than one model is priced per model instead of charging the whole turn at one rate; Codex cache reads were counted twice and no longer are; three models had no price on file at all and some cached-input rates were out of date. Prices that change over time, and the higher rates providers charge on very long conversations, are now applied by date and by conversation size rather than from a single flat figure.Trying to subscribe again takes you to manage your existing plan instead
If you already held a live subscription, checkout would still let you start a brand new one, risking a duplicate charge. It now recognizes your active subscription and sends you straight to your billing portal instead.Trials and sponsored seats keep the access they're owed
People still inside their trial, handed-off sponsored seats included, were incorrectly prompted to subscribe. And after a sponsor's subscription ended, sponsored teammates were cut off immediately instead of keeping access through the intended grace period; they now do, and everyone affected is notified.Recaps and charts group by your day, not the server's
Recaps could open on tomorrow's date, and a day's activity could be filed under the wrong day entirely, if your timezone put you behind UTC — at 6:43pm in Costa Rica the page already showed the next day. Which day something counts as is now worked out in the timezone you've set, everywhere it matters: the day Recaps opens on, the day buckets behind the metrics charts, and the window a period preset covers. A past day is measured with the offset that was in force on that day rather than today's, so a recap from January reads correctly when you open it in July, and the days either side of a daylight-saving change are the 23 or 25 hours they really were instead of a flat 24.Dates and times follow your timezone
Timestamps across the app — release history, your inbox, subscription dates, conversation and session lists, activity feeds, the code viewer, and generated documents — rendered in whatever timezone the machine happened to be set to, ignoring the one you'd configured. They all follow your setting now, and generated documents are pinned so a report reads the same wherever it's opened.Activity history keeps the full content
Edits to knowledge pages were clipped in the activity feed, so before-and-after comparisons silently dropped most of the text; the full content is now kept.The agent addresses you by name, not a made-up code
When it couldn't work out who had sent it a message, the agent used to invent a placeholder handle like@user-8f3ac2d1and address you by that. It now uses your real@handle, falls back to your display name when that's not available, and says nothing rather than making something up. It can also only mention people who are actually part of the conversation — someone who's written in it or been mentioned into it — never a teammate who's had nothing to do with the exchange.Options you can't choose look like it
Disabled radio buttons and checkboxes drew at full strength with a normal cursor, so they read as pickable when they weren't.
Breaking Changes
- The workspace recovery code is gone — The 12-word code under Advanced: workspace recovery code, and the stored blob behind it, have both been removed. It was break-glass for a case that cannot be reached: the workspace key already exists as one sealed copy per member, and each copy is opened by that member's own personal recovery phrase — so getting a workspace back means one member restoring their account, not somebody producing a second phrase. Your own recovery phrase stays the only secret you manage.
- The Audit screen is gone — Reviewing your codebase for architecture, security, quality, and pattern issues no longer has its own tab, and saved Audit sessions no longer have a home of their own. Ask the Architect for a review in the conversation instead: findings turn straight into stories in your plan, so diagnostics flow into work you actually ship rather than sitting in a report nobody opens.
- The AI-task concurrency limit is gone — The setting that capped how many AI tasks could run at once has been removed, and so has the stall it could cause: set it low enough and a run waiting on the background work it had just dispatched would wait forever, because that work could never start. Trinity now begins every task you queue, across every project, and lets your AI provider's own rate limit set the pace — hit one and the run shows a short cooldown and picks up where it left off. A run that hands work off suspends itself while that work happens and resumes when it's done, so it costs nothing while it waits.