Architect

Architect is the conversational entry point for changing your plan — adding features, modifying existing stories, restructuring work, updating the roadmap, or starting a whole new PRD. You describe what you want in a chat with the Architect agent; it shapes the request into a concrete proposal, surfaces it as a review action in the composer dock (for a plan or changeset) and as live-state panels on the sidebar rail, and — only after you explicitly say yes — commits it into your live plan.

The Architect decides and briefs; it never edits the plan itself. Every change to your plan — a whole new PRD, a restructured phase, or a one-word title fix — is built by a run you can watch and redirect while it works, the same way a PRD generation is (see The run bar under Inside a session below). So a small change is not a different mechanism, just a shorter run, and nothing lands in your live plan until you say yes. It's also where greenfield project setup happens — see Setting Up a New Project.

Workspace slots

Every Architect draft has a working set — a set of typed slots that each hold one piece of the plan. The Architect agent writes to these slots as you shape things together; you read them through the sidebar rail. Nothing in the working set touches your live project until you explicitly accept.

Slot	What it holds
Vision	The project's summary, goals, and constraints
Packages	The codebases this change introduces, each with the things it ships — Web App, Mobile, API, etc.
Stack	Technology choices, per codebase
Docker	Backing-service topology per codebase — whether each one needs Docker Compose and which databases, caches, or queues it runs
Structure	How codebases map to repos
Repos	Git repositories and their layout
Release	Which release this plan lands in
PRD	Phases, epics, and stories — plus that PRD's own roadmap, the same plan read as prose (an overview, the vision behind it, how the work is phased, the architecture, and the design system)
Design system	Colors, typography, density, corner shape, elevation, glow, translucency, motion, and any design notes you've agreed on
Phasing	The ordered list of phases the project ships in — the first one is the MVP
Assets	Uploaded specs, wireframes, and reference material

Sessions

Clicking Architect lands you on the sessions list — your project's collection of Architect sessions, each holding one conversation. The list has Mine / All and Draft / Promoted / Discarded filters, plus a New session button. Each row shows the owner's avatar and when somebody last edited it. A session with a question open shows Waiting on your answer with how long it's been waiting — hover it for the exact time — and rows waiting the longest float to the top of the list, ahead of everything else; the wait resets whenever a new question replaces one still unanswered, but not when you're just staging an answer to the one already open. Discard session closes one without committing — it stays listable under the Discarded filter, and like a promoted session it stays readable but takes no more messages.

An Architect session holds the entire conversation, every decision, and its own working set, so you can close the app mid-design and pick up exactly where you left off — or hand the session to somebody who does.

On a brand-new project with no plan yet, Architect skips the list and opens the project's current open session directly — creating one if the last was committed or discarded; the sessions list appears once your first plan is committed, however small it is. The first time you enter that conversation, a short staged loader runs — Setting up your conversation, Starting the Architect — before the Architect's first message.

A project you're importing from an existing codebase has no Architect until you confirm the import: the sidebar shows Import in its place, and opening Architect takes you back to the import wizard. Once you confirm, Architect appears and opens like any other project's.

Accessing Architect

Click Architect in the sidebar's Project section to open the sessions list.

Inside a session

A session is one continuous conversation. It reads as one: the Architect's replies, the questions it puts to you, and the proposals it asks you to review — not the constant looking-up it does to answer them. Reading your targets, searching your assets, checking what's already planned: none of that gets a line, and none of it interrupts what you're reading. What does get a line — one plain sentence — are the few moments you'd want to know about as they happen: starting a run and who it went to ("Dispatched Dependency mapper"), landing a report or a prototype, and saving a decision to one of the draft's slots, which names the slot and what changed ("Vision updated · goals, constraints"). A save that didn't go through says so instead ("Vision not saved · conflict", when somebody else changed that slot first), and the Architect saves again, so the next line reads updated. Because each save reports itself, the Architect replies once and stops: it doesn't follow its saves with a second message saying what it just saved. A question the Architect asks you shows as its own card instead of a line — the same card that later shows your answer, so it never sits there saying "waiting" once you've already replied. Parking itself until a time works the same way, but as a chip above the message box rather than a card: it reads Waiting until 2:07pm for as long as that's true, and disappears the moment it isn't — a claim the transcript would otherwise have no way to take back once the timer had already fired. A line that clipped something you'd want in full — the brief a run was dispatched with — carries a small arrow you can click to read the rest; the others stay a single line since they already say everything there is. Anything the Architect actually does to a file, a command it runs, or something it looks up on the web keeps its own card.

Everything else on the page is a live reflection of the draft's working set:

• The run bar — a trail sits above the conversation while something is live and gives way to nothing at all once nothing is: no bar on a session that has no run going and no question waiting on you, then a path down into whatever is happening — Architect › PRD run › Dependency mapper — as soon as the Architect has a run going (a PRD, plan change, prototype, tech stack, research, or diagnosis run), one line deep or four — a run, the work it dispatched, and the work that dispatched — never a growing row of tabs. Click a step's name to move the whole conversation view to that level's own transcript, live, exactly as it's being written — the step's own place in the bar already carries what kind of run it is and a mark for its current state (a spinner while it works, a clock once it's parked itself, an amber dot when it's waiting on you — a run that has finished or failed carries no mark, because it has left the bar), so a suspended run reads as parked rather than stalled without anything repeating above the transcript itself; hover the step for the rest of what the transcript doesn't say — what particular slice of work it's on (when the foreman above it dispatched more than one of the same kind), its latest progress line, how long it's been going, and who's running it. A run's transcript reads the way the session conversation does: the run's own narration and the work it actually did — files changed, commands run, searches made — plus a one-line note each time it dispatches a step or asks the run above it a question, so a run that looks idle says what it's waiting on rather than going quiet. Parking itself on a timer shows the same way it does at the session level: a chip above that run's own message box, naming the true deadline for as long as it holds and gone the instant it passes, rather than a transcript line. Asking you directly is different: that's the question card, the same one that later shows your answer, not a line in the transcript. When a step it dispatched reaches back up to it — asking which of two readings of its brief was meant, or flagging something it ran into — that message shows on the run's transcript too, in a card naming which step spoke and carrying the whole of what it said, so the run's answer to it reads as an answer rather than as a line about a question you never saw. The answers a run gets back land on its transcript the same way: when you answer a question a run put to you, or when the run that briefed a step answers that step, a card appears on the transcript of whoever asked, carrying the question and the answer together — so a run picking back up reads as something that was answered rather than as a run that quietly started again, and you don't have to scroll back to the question to know what it was. Every step above the one you're on stays a link back up to it; the step you're currently on is plain text, since you're already there. A step that dispatched work of its own also carries a caret: click it for a menu of the live runs under that step — the same rows the Agents panel draws, each wearing its own mark and, where a foreman handed it its own slice of the work, a second line naming that slice — and jump straight into one without leaving the bar. Because your own siblings are your parent's children, the caret one step to the left is already the list of everything alongside you. When the trail is wider than the window it collapses in the middle to an ellipsis; that ellipsis opens the same kind of menu, listing the steps it stands for, all of them above you. A level you opened from the Agents panel stays in the bar after it settles, unmarked, so there is still a way back up. For the whole picture at once — including runs that have finished or failed — open the Agents panel (see below); the bar shows you where you are and what's live under it.

  The Architect step also carries a dot when something in the sidebar rail is unread.

  Typing goes to whichever level you're on. On Architect that's the session conversation as always; on a run it goes straight to that run — steer it ("focus on mobile first", "drop the pricing section") without leaving the session. When the run you're on is the one waiting on you — the amber mark, meaning it hit a fork it couldn't settle and asked — its question shows as a card on that run's own transcript, the same as an Architect question does: pick an option and submit, or just type your answer straight into the box — either lands the same answer, so you answer it where you're already looking and the run picks straight back up. There's no discuss-further on a run's card; answering it is the only way through. It's the run that judges what you wrote, so a reply that doesn't actually settle the question gets asked again rather than being taken as a decision you didn't make. That works at every level, not just the top one: the steps under a run are runs too, so you can redirect a single PRD phase, a single research strand, or the prototype direction a research run is rendering the moment you see it going the wrong way, instead of waiting for the whole thing to come back. The run above it is still the better place for anything about the work as a whole — it's the one deciding what happens next, so a redirect there shapes everything it hasn't started yet — and a step you steer directly says so in what it reports back, so the run above it isn't left building on a brief that changed under it. Where a level can't take input the box says why — that step isn't a run of its own, or its run has already finished, or its session lapsed — and offers a button to the nearest level that can be steered, which is usually the run just above rather than all the way back to the session. A run keeps working regardless of which level you're looking at, and stays in sync across every member's device, not just the one that started it. Anyone on the project can steer a run this way, and the run is told who sent each redirect — so if two of you ask for opposite things it can say so and answer you both, rather than quietly following whichever arrived last. Redirects are picked up one at a time, in the order they were sent, at the run's next natural pause. When the Architect starts one of these it tells you roughly how long that kind of run usually takes — a couple of minutes for a stack, considerably longer for a full PRD — so you know whether it's worth waiting on. A run leaves the bar the moment it finishes, fails, or its session lapses — and if you were inside it when that happened you land back on the session conversation with a line saying where it went; open the Agents panel afterward and it's still there, exactly as it ended. A run that died with the app reaches you as an inbox notification, and settles into the panel marked failed once we notice its machine stopped reporting — you don't have to reopen the app it died on for that to happen.

  Every run tells you how it ended, whether or not you were watching: when one finishes or fails it leaves a notification in your inbox saying what came of it and how long it took. Clicking that notification opens that run's own transcript, with the trail above it intact so you can step back up to the session — not the conversation that started it, left to find the run yourself. That holds long after the run is over: the transcript is kept, so a notification you open the next morning still lands on the work it names. A run that dispatched work of its own usually reports once, for the whole run, rather than one notification per step — a wave of parallel steps nobody asked for by name would only fill the inbox with rows saying the same thing. The exception is a run whose steps go in a fixed order, where each one landing is the moment before the next builds on it: a PRD generation notifies as each of its five phases seals, and again when the plan itself is done, so a redirect while there's still something to redirect is a decision you get to make rather than one you have to be watching for. Those notifications open the phase's own transcript, exactly as a run's opens the run.

  Restarting Trinity mid-generation doesn't cost you the run. A PRD generation picks up again on its own: a phase that was working starts over from the plan exactly as the last sealed phase left it, with whatever it had half-written taken back out, and the Architect tells you in the session which runs resumed. The Agents panel shows the run as working again and its progress reads "Resumed after restart". A run resumes twice at most, so one that keeps bringing Trinity down fails instead of looping, and then the Architect tells you it failed and offers to retry it. Any other run a restart interrupts fails and gets the same retry offer. A generation that fails leaves no draft behind in the Plan list, so retrying it shows you one PRD draft rather than one for every attempt.

  A restart that lands while the Architect is mid-reply leaves that reply marked Interrupted rather than streaming forever. Trinity never re-runs the turn on its own. If you sent the message that started it, a Continue button sits under the interrupted reply: press it and your message goes to the Architect again, once, as a new message in the conversation, and the button goes away. Only the text is sent again, not attachments or @-mentions, so add those back yourself if the Architect needs them. A reply the Architect was writing in answer to a finished run, rather than to something you typed, shows Interrupted with no button, since there is no message of yours to send again.

  A step that needs the Architect to settle something doesn't wait for you either. Most of the time a step stuck on its brief asks the run that briefed it, and that run answers — but when the fork is about the plan itself rather than about its slice of it, the step asks the Architect directly and parks on the answer. The Architect takes that turn on the machine the work is running on, with the session closed and nobody watching: it answers, the step picks straight back up, and you read the question and what was decided the next time you open the session. If that machine is off, the question keeps and the Architect answers it the moment the session is opened again — so the work resumes either way, just sooner when the machine that started it is still up.

• The sidebar rail — a strip of icons down the right side gives you a real-time view into every decision the Architect has captured so far. It has two kinds of items:

  • Panels (toggle inline) — Vision, Packages, Phasing, Release, Agents, and Assets. Click one to expand a panel alongside the conversation; only one panel is open at a time. Each appears once the Architect has captured something for it. Release shows the release your plan is staged to land in: its name, branch and merge level, the proposed version for each package one to a line with the reason beneath it, whether it ships as a release candidate, and the release groups. Once the Architect has staged a release policy, the groups shown are the staged ones, marked Staged — written at commit; before that they are the groups your project's release policy declares. On a project with no repository yet, the panel says the plan sets the policy and writes it when the plan commits. Agents is the one exception to "always there": it appears only once the session has ever started a run, since a session that hasn't run anything yet has nothing for it to show, and it shows a spinning mark for as long as any run in the session is working, however deep, whether or not its panel is open.
  • Modals (open a portal) — Stack, Structure, Repos, Design system, and Artifacts. Each opens a dialog over the conversation. Artifacts always fills the window — it carries a page of its own inside, so it has no column form to shrink to. The other four open as a column and carry a control next to their × that maximizes one to fill the window or restores it to a column, and whichever size you leave one at is the size it opens at next time. Stack, Structure and Repos each show the live state of that slot, with optional micro-actions (like toggling repo visibility or regenerating a repo layout) that write directly to the working set without going through the chat. Design system shows that live state on its Preview and Data tabs — and its Contract tab reaches outside the working set entirely, to what the session has already written down: the design contract for each codebase this system covers (see The design contract below). The Stack modal shows each pick's researched pricing as a badge — free, freemium, or paid, with a short note and a source link — alongside an amber flag on any service still missing its keys. Artifacts is a grouped door onto the three things the Architect produces for you to read: prototypes, reports, and your PRDs, each carrying its own roadmap alongside its story tree. Opening it lands you on its Overview — a three-card grid, one card per artifact, each showing that artifact's current shape at a glance (how many PRDs you're carrying, whether a prototype is ready to preview, how many reports have landed) and carrying its own unread dot; click a card to open that artifact. Once you're inside one, it opens full-screen under a stacked header: the top row is the door's own — a trail reading Artifacts › Plan › Habit Tracker PRD, the Shared links button, and the close × — and the row under it is the sub bar, carrying a Prototypes | Reports | Plan quick-switch plus whatever controls the artifact you're reading has of its own. Whatever controls the artifact you're reading has of its own sit on a third row, narrower and nested beneath the sub bar — Prototypes' Preview | History | Compare view switch, and the Plan segment's Plan | Roadmap document switch alongside the tree's draft chip or the roadmap's section dropdown, whichever document is showing. They get their own strip so they always have room to lay out: sharing the sub bar left them squeezed against the quick-switch, and in a narrow window a chip would wrap into a blob and a dropdown would run off the edge. Reports has no controls of its own, so it shows two rows rather than an empty third. The door is always called Artifacts; the artifact you opened and the page you're on hang off it as the trail's later steps, and clicking Artifacts — or any step before the last one — takes you back there, all the way to the Overview, which is why no page carries a back button of its own. Click a segment, or press [ and ] to step through the three once you're inside one, which wraps around at both ends — from the Overview itself there's no current artifact to step from, so the shortcut does nothing until you open a card. Clicking the segment you're already on is otherwise a no-op — except on Plan, where it closes an open story and returns to the picked PRD's own plan document, the same move as clicking a step in the trail above it. Each segment carries its own unread dot, and the door's own dot on the rail lights when any of the three is unseen; a segment's dot clears only once you actually open that artifact, so landing on the Overview and seeing all three cards at a glance clears none of them, and a fresh report keeps flagging itself while you're busy in Prototypes. The door reopens on whichever you last had showing — the Overview on a first visit, or the artifact you were reading. The Plan segment lists every PRD your conversation is carrying, newest first, as a rail beside whichever you've picked — and picking a different one is also what your next commit lands, so the PRD you're reading is the PRD the Architect is building toward. Its Plan | Roadmap toggle switches the picked PRD between its phase → epic → story tree, with a click on any story opening it in full and the trail's PRD step returning to the tree, and its roadmap read as prose — an overview, the vision behind it, how the work is phased, the architecture, and the design system, one section at a time via a dropdown that appears while Roadmap is showing. A quality-checkpoint story marks itself with a shield icon in a muted, dashed row rather than a plain one, and is called out on its own next to the tree's story count instead of folded into it. Both documents carry the same Share control the Prototypes and Reports segments do, in the same spot in the sub bar — publish the draft as a link exactly the same way, as two separate links you can revoke separately, and Update share appears whenever you've kept shaping the plan since the link went out. The draft PRD and the draft roadmap are two views of one working copy, so shaping either one marks both links for an update — unlike the committed pair on the Stories page, where each link tracks its own document. Those links carry the Architect's draft; once the plan is committed, the roadmap belongs to its PRD and the Stories page publishes both the same way — see Working with Stories. The Shared links button in the top row takes you to the project's Share page (in the sidebar's Project section) — every link currently live in the whole project, not just this thread and not just prototypes and reports, so a link you shared a while back and forgot about is always one click away instead of invisible. The page filters by kind, sorts by when a link was shared or when it expires, and lets you select several links at once to revoke together; a Code set badge on a row tells you it also needs an access code to open.

• The Prototypes segment shows your codebase's prototype project — a clickable HTML prototype covering every screen the Architect built, all sharing one design system, that you click through in a sandboxed live preview. One project per codebase: the first PRD that designs against it creates the project, and every later PRD's planning thread extends the SAME one rather than starting over, so mockups stay consistent across a project's whole life instead of resetting each time you open a new thread. A prototype covers whatever you're currently deciding: setting a project up, that's the app itself — its key screens and the flow between them, in one navigable piece; on a live project, it's the screens the feature you're planning introduces or changes, rather than a rebuild of everything around it — and it's grounded on the design system and stack that codebase already committed, so a round that's only touching the backend can still prototype an existing screen without re-deciding its design. Either way it renders every theme your design system carries, across every facet it ships, with a switcher built in — so narrowing what you're planning never narrows what you can see of the design. Ask for one screen, or one theme, and it'll do just that instead. A design system carrying more than one theme gets a theme picker on the prototype's own settings screen, so you can move the whole prototype between them without leaving the screen you're on. The Light / Dark / System control beside it belongs to the theme currently showing rather than to the system as a whole: a theme that ships both facets gets the control, and a theme that ships one has nothing to switch between, so it carries none. A system whose themes all ship both therefore shows the control everywhere, one whose themes each ship a single facet shows it nowhere, and a mixed system shows it only while a both-facet theme is up. It starts on System — the prototype opening matching your computer's appearance and following it until you pick a side — whenever the theme it opens on ships both; opening on a single-facet theme starts on that theme's own facet instead. Pick a light-only theme while you're showing Dark and the screen turns light and the control goes with it, since under that theme there's nothing left to pick. A device-size switcher — Phone, Tablet, Desktop, or Fit to width — checks the design at any screen size, and two ways out of the surrounding interface sit beside it. Fullscreen puts the preview alone on your whole display, outside Trinity's window entirely (press Esc, or click it again, to come back). Focus mode does the same thing without leaving the app: everything around the prototype goes — the trail across the top, the segment switcher, the view row, the fork navigator, this toolbar, and the box you'd type a change into — leaving it edge to edge in the window below a slim bar of its own, reading Prototype · and its name, plus a ✕. Press Esc or that ✕ to bring the panel back, and the device size you had picked is still set when you do. Focus is a way of looking rather than a setting, so it's off again whenever you come back — switching to History or Compare, opening another artifact, or closing the panel all drop it. Three views sit over whichever project is picked, switched from their own row beneath the sub bar:

  • Preview — the prototype itself. It behaves like a real app: its links move between screens without reloading, so a theme you switch on one screen is still set on the next, its forms and controls change the data behind them, and the state survives a refresh of the preview. If a preview can't be loaded, the canvas says so and offers Retry instead of sitting on "Loading preview…" — the same in the Compare panes and in the Design page's detail panel.
  • History — the project's Checkpoints, one saved state of the whole project per row, numbered v1 upward from the oldest with the newest marked Current. Every row offers Preview and Compare, and every row but the newest also offers Restore, which takes the whole project back to that checkpoint: the entry page, the shared stylesheet and every other page move together, so a restored page is never left pointing at a stylesheet that moved on without it. Pages added since that checkpoint go away, and pages deleted since it come back. Restoring never truncates the list — the restored state lands as a new checkpoint at the top, so the point you just left is still there to return to. Trinity checkpoints most refinements, but a fast back-to-back editing session can amend the live files in place instead of cutting a checkpoint — so History sometimes lists fewer entries than the edits you asked for.
  • Compare — a side-by-side, two-pane view: the picked project on the left, and on the right, a picker over everything there is to compare it against — your other forks, and the project's own checkpoints, the newest labelled Current and the rest by how long ago they were saved. Pick either to see it compared side by side; a Change control on the picked pane swaps it out again without leaving Compare. A single-lineage project with no checkpoints yet has nothing to offer here, and says so.

  When the Architect has cut a fork — a full copy of a prototype project it can explore a different direction in — a fork navigator lists every project in the thread as a tree. Each one is named for the app itself when the prototype declares its own title, and by where it falls in the fork history when it doesn't — the first is Original and each later one is Fork 1, Fork 2, and so on, numbered as it was cut; two projects that happen to share one title stay tellable apart with that same fork number tacked on ("2DO · Fork 1"). The one wired to your codebase carries a Canonical badge; the others offer Compare and Promote, and promoting makes that fork the codebase's design source. Every prototype your project has also collects in the Design page (in the sidebar's Project section) as a grid of thumbnails.

  The Share control in the sub bar publishes the prototype as a link you can open in a browser. Sharing asks who it's for and how long it lasts — Never, 7 days, or 30 days — and both choices are fixed for the life of the link: to change either, unshare and share again, since a live link's reach or lifetime can never silently change. Who it's for is either Public, which anyone with the link can open with no Trinity account at all, or Your workspace — members only, signed in, which is whoever the project's workspace holds; in a workspace of one that's just you. Either way the narrower link needs the reader signed in to Trinity, so a workspace of one gets a genuinely private link rather than an unlisted public one. Turning on Require an access code adds a second thing a reader needs beyond the URL — a strong code is filled in for you, or write your own — and it's shown to you only once, right in the dialog where you share, so copy it down before you close it; there's no page to look it back up on later. Once shared, the control shows who the link is for — Public or Workspace — and when it expires, and offers Copy link and Unshare, plus Update share whenever you've kept editing since the link went out — sharing never re-publishes on its own, so the copy a reader has open stays exactly what they last saw until you choose to update it. If you did set a code, the control also shows Code set and a Rotate code action that swaps in a new one — shown once, the same way — for anyone who needs a fresh code; there's no way to remove the code entirely without unsharing and sharing again. Whoever opens the link sees Trinity's own header alongside the prototype, plus a phone / tablet / desktop / full-size switcher for previewing it at any size, right in the browser — the same sizes you preview from here.

• The Reports segment lists the HTML reports the Architect writes, newest first, with the picked one rendered alongside. Ask it to review your plan and then to write the findings up: you get one self-contained file — the subject, a verdict, an architecture score, and every finding grouped by severity. There's no button for this; it's a chat request, and the report lands here when the run finishes. These are a different thing from the recap reports on the Recaps page, which have their own Export and Share controls — see Recaps & Reports. The same Share control sits in the sub bar above — share, copy link, unshare, and update — exactly as it works for prototypes, while the list of reports stays beside the report itself, since picking one is moving around inside the page rather than door chrome.

• An artifact the Architect hasn't produced yet says so and tells you what to ask for, and the box at the foot of the door swaps from "reshape this" to "ask for one" — so the screen where you most want to request a roadmap is the screen that offers it, rather than a bare sentence in an empty window. The Overview's own card for an undrafted artifact reads the same way — what's missing and how to ask for it — so the door's very first screen never looks like a blank dashboard either.

• Every slot is a read-only mirror of the draft's working set — you shape things by talking, not by editing panels. When you push back on a stack choice or a phasing order, the Architect patches that slot in place rather than posting a new copy. Nothing is written to your project's real tables until you commit, so you can explore freely.

• The Vision panel — toggle Vision on the rail to see your project's shape: its summary, the goals it's aiming for, and the constraints it works within, with a note of who last shaped it, so everyone can see how the direction came together.

• The Packages panel — toggle Packages on the rail to see what this change is building, one card per codebase. The card is headed by the codebase's folder name, with its accessibility level and where it lands — repository and path — on the right once each is settled; before that it shows the folder name alone, since what you're building is settled long before where it goes. Underneath sit the things that codebase ships, each with its label, its kind (Web App, Website, Mobile, Desktop, CLI, API, Library, or Extension), and a line describing that kind. Most of the time that's one thing per codebase; the card earns its keep when one codebase ships two — a React Native app that also builds for the web — or when a shared internal codebase ships nothing at all, which the card says outright rather than leaving the codebase out. Codebases are the first thing the Architect settles: both the design system and the stack belong to the codebase, so it has to exist first. Two things shipping from one codebase therefore share its look — they're built from the same components and written into the same place, so there's no way for them to look different — and they share its accessibility level too, for the same reason: the level is written into those components, so it is decided once for the codebase rather than once per thing shipped from it. They stay live for the whole conversation — adding a target mid-flow spawns a design arc and a stack arc on the spot, unless it joins a codebase that already has them, in which case it takes that codebase's look and its stack as they stand. Both belong to the codebase rather than to the thing shipped from it, so neither is asked twice.

• The Phasing panel — toggle Phasing on the rail to see the phase sequence the Architect has settled with you: an ordered list of phases, each with a name and a one-line intent, the first one badged MVP. It spans every target in the project at once rather than one phase list per target, and the roadmap builds around this exact sequence once it's settled. The Architect proposes the count from how big the build is — each phase ends in a full checkpoint, so more phases means more of those pauses — and says so when it proposes the sequence; ask for it split finer, collapsed further, or run past what it suggested, and whatever you settle on is exactly what generates downstream.

• The Agents panel — toggle Agents on the rail to see the session's runs sorted by what they ask of you, not laid out as a tree. A strip at the top counts what needs you, what is working and what has failed, and shows only the counts that are above zero. Beneath it, three sections, each newest first:

  • Needs you — every run waiting on you, at any depth, highlighted, with its action on the row: Review for a card it finished and wants you to look over, Answer for a question it stopped to ask. The amber mark means it hit a fork it couldn't settle and asked rather than guessing, so it's the one state that wants something from you.
  • Working now — every run in flight, at any depth, with how long it has been going and its latest progress line. A run that belongs to a bigger job names its place as a breadcrumb above its progress (PRD run › Story writer), and each segment of it takes you up to that level. A multi-stage job, a PRD run for instance, is one card instead of a row: stage 5 of 5 and its running time, a strip with one segment per stage of the job (done, running, waiting on you, failed, or not started yet), and its current progress line. Click a stage to open it in place: its own run, and the helper runs it sent off, drawn as one small square each (with a count, 10 sub-runs: 9 done · 1 failed) rather than as ten rows. Click a square to open that helper run. A run that has only sent work off and is waiting on it lists nothing of its own while something under it is running, since the running work speaks for it.
  • Earlier — runs that failed come first, each with Retry, which asks the Architect in the session to run it again. The runs that finished are folded behind Show N finished runs. A run that dispatched helpers is one row that sums them up (10 sub-runs, all done, or 8 done · 2 failed), and a finished multi-stage job is one row (5 stages · done); a helper run is never listed as a row of its own here.

  Click any row to open that run's transcript — the panel is the way back to a run you've navigated away from, not only a way to watch one happen, and somebody else's run is labelled with their name. When a foreman dispatches several children of the same role — ten Prototype page runs out of one fan-out, say — a run the foreman handed its own slice of work carries that slice after its name (Prototype page · Settings screen), which is what tells them apart. Every run carries one of seven states, each spelled out in words rather than left to colour: running, waiting on work (an hourglass: it sent work off, either to agents it dispatched or to the run that briefed it, and needs nothing from anyone), needs you, paused (a clock: it holds no question and no outstanding work, and comes back on a reminder it set for itself, which is how a run watches something Trinity has no way to notify it about), done, failed, and lost contact — a run that stopped reporting before it finished and whose outcome we were never able to record. Most runs whose machine goes away are noticed within a minute or so and land on failed instead; lost contact is what's left when nobody could reach the run at all, and it is listed with the failed ones. Either way a parked run has no model running, so a question left overnight costs nothing, and a long generation can sit idle for a while without anything being wrong. The run bar above the conversation is a view of live work alone, so once a run fails or loses contact, this panel is where it stays reachable from inside the session — the other way back to one is the notification it left in your inbox, which opens it directly. Reading the panel never steers a run; Retry is the one action, and it goes through the Architect.

• Questions appear inline in the conversation — when the Architect needs a decision, it asks as a card right in the chat thread, always directly under a message from the Architect about it: what it made of what you just said, its read on the decision, and why it matters now. The card ends the Architect's reply: it writes nothing further below it and waits for your answer. Answer it there, or just reply in the chat. When the card carries a ✨ recommended option, that option is already selected for you — confirm it as-is or pick something else before submitting. A pick you haven't submitted yet stays on the card: leave the session or reload the app and the card still shows your choice, not the recommendation, and a teammate in the session sees the same pick. Once answered, the card stays in place with your pick marked, and your answer appears once, on your side of the chat, under the card: the option's name rather than its raw value, and for a card you submit (a palette, a stack, a release, a depth setting) the summary of what you submitted. When you hand a decision to the Architect and it picks, the card reads "Architect's pick" instead of "Answered". If you want to revisit a decision already made, ask the Architect to reconsider it — it reopens the question inline, showing what was chosen last time for context. While a question is open, the review action is suppressed so the question holds the floor. Many decisions render as rich cards rather than a plain option list:

  Most of the design decisions are made the same way, on a sliding track. The options lie in a row, the one you're looking at in the middle with a sliver of each neighbour showing at the track's edges, and the track always settles on an option rather than between two of them — each one is a whole combination that has to hold together, not a notch on a dial. However wide your window is, the track keeps to a comfortable width rather than stretching each option across it. An arrow over each end of the track steps to the previous or next option, so any mouse can move along the row, not only a trackpad's sideways swipe — and the arrows only change what you're looking at, never what you've chosen. At either end of the row, the arrow with nowhere left to go disappears. Every card holds a real radio button or checkbox underneath, so a question that takes one answer is walked with the arrow keys, wrapping around at both ends exactly as any set of radio buttons does; the one question that takes several — the colour directions — is tabbed through instead, and landing on a card still moves what you're looking at. If you'd rather things didn't move, the track honours the "reduce motion" setting on your own machine: it changes option without animating between them, and the order, what's selected and the keys all behave identically either way. A question with only one thing to offer drops the track and its arrows entirely and shows that option as a plain card on its own.

  Up to two things sit on a row above the track, and a question needing neither shows no row at all. On the left, whatever that question has to say or offer for the question as a whole rather than for one option — the themes you've picked so far, a replay button for the motion demos. On the right, an eye: one per question, opening whichever option you're currently looking at full size. Below the track, a question whose options form a ladder — density, shape, elevation, translucency, glow, motion, and any plain list the Architect says runs low to high — carries a tick per option and a caption naming the two ends, so you can see where on the scale you are. A question whose options are just different from one another — the colour directions, the font pairings, the repo structures, the releases — carries neither, because there's no "more" for a scale to point at.

• Not every card is a design one, and the plainer decisions still get a shape rather than a bare list of radio buttons. A proposal puts one recommended option forward with its reasoning and the alternatives beneath it, each flagged where it carries a risk. A comparison lays the options out as a table — a row each, a column for every thing worth comparing them on — with researched pricing filling in as it lands and a shimmer on a row still being priced. Library and framework choices come as titled tiles carrying a line of description each. And where a question's options are a genuine low-to-high run — a size, a tier, an intensity — they ride the same sliding track the design cards use, with the two ends of the ladder captioned underneath.

• The stack card proposes a whole codebase's stack in one pass — a dropdown switches between codebases, and targets that ship from the same one share a single pick, each pick carries a setup badge (whether it needs a CLI step or a pasted key) and a flag on anything risky, and a Use this stack → button stages the lot. (The researched pricing for each pick lives in the Stack modal, not on this card.)

• A structure card offers two of Single repo, Monorepo, Turborepo, and Polyrepo with a preview of the resulting layout — a folder-level shape rather than a full file listing, so a layout deeper than the preview can show ends in a +N more line instead of growing the card. The first three each describe one repo and preview as that repo's file tree; Polyrepo means several repos and previews as the repo list, so it is only ever offered to a project that ships more than one. The two ride the same sliding track the design cards use, with no scale beneath it: a polyrepo isn't a bigger monorepo, it's a different shape of project.

• A release card lists every release your project currently has open, each with its status, so you pick which one this change lands in — or start a new one. Starting a new one gives you a Name field, a Branch field showing the full branch it'll create, and a Generate button that draws a fresh name and branch together; the branch follows whatever you type into Name until you edit the branch field directly, at which point it holds exactly what you typed. On your project's first PRD the card is pre-filled with the one release there is to create; on a later PRD it lists every open release plus the new-release option, with a recommendation pre-selected. The releases ride the same sliding track, with no scale beneath them — one release isn't further along anything than another — and on that first PRD, where the only option is the release it's about to create, there's nothing to slide and it shows as a plain card on its own. See Release assignment below.

• A typography card previews each proposed font pairing set in the real typefaces, so you choose by how they actually look. View opens a closer look at one pairing on its own, with Pick this right there so you can add it to your answer without closing the peek first. The eye beside it opens the same full-size page the palette card uses, the pairing set against the rest of your design — switch which of your staged themes it's shown against, once there's more than one — with the other pairings in its Proposed menu to switch between — looking changes nothing until you press Pick this there too.

• A repos card lays out the repositories derived from your structure, each with a visibility toggle, the git destination it inherits, and a short description of what that repo is for — written the way you'd write a repo's "About" line on GitHub, and grounded in your project's vision rather than the repo's name alone. Every repo gets one; if the wording isn't right, the ↻ beside it redrafts that description on its own.

• An accessibility card sets the WCAG target — None, A, AA, or AAA — per package, with a live note of what each level guarantees. It's asked once per codebase however many things ship from it, because accessibility is written into the components: a web build and a store build sharing one codebase share the markup, the focus order and the contrast, so they answer to one level.

• The first design card asks which colour facets your app ships — Light, Dark, or Both — and it comes before any colour is proposed. It's the one design question with nothing to preview against, since no palette exists yet, so each option is drawn as a plain wireframe of a screen: a few bars standing in for text, a block standing in for a button, on white paper for light and near-black for dark, with Both setting one beside the other. The single spot of colour is identical in all three, so the only thing that varies between them is which is lit and which is dark, which is the only thing the question is about. It's an existing list of design systems that comes first on a project that already has one — reuse a system by ticking it, or tick nothing to start fresh, and only one can be inherited, since what you're building renders with a single system.

• The design-direction card is a "Pick your look & feel" card that shows one proposed palette at a time: the directions lie on the sliding track, the one in front of you in the middle, carrying that direction's colour sheet — every colour role the system carries, each shown as the thing it actually is: a filled surface in its own colour with its label on it, a border drawn as a line, the error/warning/success/info colours as chips. Every role appears, so two directions that differ only in a supporting colour look different instead of identical. Clicking a direction is what adds it to your answer — click it again to take it back out, and add as many as you want for a multi-theme app. Showing one at a time is a deliberate answer to a real problem rather than a way around it: neighbouring palettes shift how each other read, so any surface showing two at once judges both a little wrong, and a grid of shrunken previews is the least reliable way there is to judge colour. The sliver of a neighbour at the track's edge is a far weaker version of that than a grid, and what it buys is one way of picking that holds across every design question — with the eye still opening a direction alone at full size, which is where a close call actually gets settled. Because the track shows what you're looking at rather than what you've chosen, the row above it names every direction already in your answer, its Theme N position beside its name and clustered under its identity — a name like "Vintage" or "Modern" covering a group of themes — where you've given one, next to the count. Open the eye to see the direction you're looking at full size — roomier, set against the rest of your design once other axes have landed, and switchable between your staged themes once there's more than one — with the other directions in its Proposed menu to switch between; looking changes nothing here either, and Pick this at the foot of that view is what adds the one you're looking at or takes it back out. Open the pencil instead to fine-tune the individual colors of the direction you're viewing (light and dark, cycled with the theme dropdown) before you settle on it. A Light / Dark control sits over the card and the full-size view alike, opening on whichever Trinity itself is currently showing — so a direction starts out judged the way the rest of the app already looks, rather than always being shown as a dark theme — and stays on whichever side you pick from then on. If you already settled on shipping a single facet before this card came up, there's nothing to switch between, so it carries no control at all — every direction is judged in the facet you already picked. Once you've decided your look & feel and other axes like typography and shape follow, the same page grows into the full design-system guide — a type ramp, a spacing ruler, an elevation ladder, real buttons and fields — previewed against your actual palette instead of Trinity's own.

• A density card settles how much room your app gives its content — tight and information-dense, comfortable, or generous and airy. It's one pick rather than three, because spacing, type sizes and line-height only make sense together: a cramped layout under airy line-height isn't a look anyone chose. Each option is previewed as real content set at that density — a heading, body copy, a stacked panel — since the combination is what you're judging and three numbers would tell you nothing. Its eye opens the same page full size against the rest of your design, with the other options in its Proposed menu to switch between; Pick this is what answers the card.

• A shape card previews each proposed corner radius on a small live slab of real chrome — a card, an input, a button — so you can see how rounded or sharp things feel before you pick. Open one with its eye for the same page full size, the radius set against the rest of your design — switch which of your staged themes it's shown against, once there's more than one — with the other radii in its Proposed menu to switch between; looking changes nothing, and Pick this is what answers the card.

• A glow card appears only when your design calls for one — a neon, cyberpunk, retro-terminal or similar look. It's one of the two design questions Trinity doesn't always ask — translucency is the other — and both are decided by what you said you wanted rather than by Trinity's own judgement. The two are judged separately: a clinical or editorial brief sees neither, a brief built on emitted light sees glow, a brief asking for frosted panels sees translucency, and a brief that wants both sees both. Skipping one never skips the other, and every other card, motion included, still comes as usual. When it does appear, each proposed direction is previewed as a real control actually burning — how far the light bleeds and how hot the core reads is the whole choice, and a swatch can't show either — with a resting burn beside the brighter one you'd see on hover or when something is selected. A glow takes its colour from one you have already picked, so it can never drift from your palette: retint your theme later and the glow moves with it. Its eye opens full size too, the glow set against the rest of your design.

• An elevation card previews each proposed depth direction the same way — a raised sample floats at its md depth so you can judge how much shadow your app carries. Each direction carries a light and a dark version, because depth reads differently on a light page than on a dark one, and the card shows whichever you're viewing — flip the Light / Dark switch to judge the other. Its eye opens full size too, the elevation set against the rest of your design — again switchable between your staged themes — with the other directions in its Proposed menu to switch between.

• A translucency card is the other one Trinity only sometimes asks — it comes up when what you described calls for glass: frosted panels, blurred chrome, surfaces you can see through. Each proposed direction is previewed as a real floating panel over real content, since how much of what's behind comes through, how far it's blurred, and how much the colour underneath is pushed around are the whole choice and no swatch shows any of it. Like elevation it carries a light and a dark version, because a recipe that reads as a light haze over a pale page reads as heavy smoke over a dark one, and the card shows whichever you're viewing. Its eye opens full size too, the glass set against the rest of your design — again switchable between your staged themes — with the other directions in its Proposed menu to switch between.

• A motion card closes the design run with how your app should move — from no animation at all, through restrained and smooth, to something springy and expressive. Each option animates in front of you at its own real speed and curve, so you pick by how it feels rather than by what it's called; each demo waits until it's actually on screen before it plays, and a replay button and a loop toggle let you watch it again on your own schedule. Every demo runs against a plain, unaccelerated marker covering the same distance in the same time on the lane beneath it: a curve is a distribution of movement over time, so one dot on its own only ever says "it moved", and the gap between the two dots at any instant is the character you're picking and nothing else. That marker is a ruler rather than an option — it isn't in the set and there's nothing to pick on it. Beside the demo the curve itself is drawn as a shape, time across and progress up. Its eye opens the same full-size page every other design card uses, that pacing set against the rest of your design — switchable between your staged themes too — with a small demo you can hover to feel it — a still page can't show a feel, so this is where the timing itself is the thing you're judging. Whichever you choose, anything Trinity builds still respects the "reduce motion" setting on your own machine — that's never something you have to ask for. The card respects it as well, and stays decidable when it does: with that setting on, the demos give way to bars reading the three named speeds as proportional lengths, and the drawn curve stays exactly where it is, so two directions of the same speed and different character are still tellable apart with nothing in flight.

Every card also carries a Continue discussing button, so you can always talk a decision through with the Architect instead of picking straight from the card.

• Pick the model for the conversation — the composer's model button opens a picker to override which model — and, where supported, its reasoning effort — answers the next turns of this one conversation, without touching your project or workspace defaults. Reset it any time to fall back to the configured default.
• Attachments — drop a file anywhere over the conversation, paste one in, or use the composer's attach button; any of the three works from anywhere in the session, not only the composer itself. Dropped or pasted files become project assets the Architect (and later the executing agents) can read. Not everything shared in chat sticks around forever — a passing screenshot fades after a week unless it's worth keeping, and the Architect keeps what clearly is (a logo, a brand guide) on its own. When it's genuinely unclear, it asks — once per file, and in a shared thread, any member can answer. Every attachment's chip names its own state — Kept, or Expires in n counting down to the sweep — so you never have to guess; click that label yourself at any point to keep the file regardless of whether the Architect asked, including one from earlier in the conversation. Attachments only work on the session's own conversation — a run you're steering takes text only, and its composer says so rather than offering an attach button that can't do anything.
• @-mention people — type @ in the composer to open a roster popover and tag somebody into the conversation; they get a notification, and from then on the Architect can @mention them back when it needs them to weigh in. It can only address people already taking part — anyone who has written in the session or one of its runs, or been @-mentioned into it — so it never pages somebody who has had nothing to do with the work.
• Other members — sessions are shared. Avatars in the header show who else has the session open, and any member can continue the conversation from where it stands.

As you work through a topic — targets, then each codebase's design and its stack, then phasing, and so on — the Architect pauses at natural breakpoints instead of barreling into the next one: it'll say the topic seems settled, name what's coming next, and ask if there's anything you'd like to add or adjust before moving on. A quick "go ahead" (or just your next answer) keeps it moving.

Conversation modes

Architect adapts to whether you're working alone or with other people:

• Solo (you're the only one in the session) — every message you send wakes the agent. The Architect answers every turn directly.
• Coop (other people present) — the conversation becomes a shared thread. The Architect only replies when you tag it with @agent, so everyone can talk things through without it jumping in. A banner shows the current mode, and the mode switches automatically as people join or leave.
• Presence — when others are in the session, their avatars appear in the header, and if someone answers a question while you're looking at it, their tentative choice appears as a consideration so you can discuss before settling.

It also adapts to who it's talking to, from the experience level you set on your account. State that you're new to this and you get full explanations and firm direction — the Architect leads, and unpacks the reasoning behind every recommendation. State that you're senior and it gets terse and peer-level, and takes your technical picks as something to reason from rather than something to explain. Because a session is shared, it pitches to each person separately rather than to whoever spoke last. What doesn't change with your level is who owns the plan's quality: a choice the Architect thinks will bite you still gets said once, with the cost, whoever made it.

The design contract

Once a codebase's design and its stack are both settled, the Architect writes that codebase a design contract — a DESIGN.md file that lands in the codebase itself, beside the code that has to honour it. One per codebase: two codebases sharing a design system each get their own, because half of the document is about how that particular codebase takes the design on.

It comes in two halves. The first is the settled design as values — every colour role in every theme and facet, the type ramp, the spacing scale, the corner radius, the depth ladder, the motion timings, and — where your design carries them, since these are the two a design can carry none of — the translucency and glow recipes. Trinity writes those straight off your design system rather than describing them in prose, so what the contract says a colour is, is what your design says it is. The second half is written for that one codebase: how its stack takes those values on — a theme block, a stylesheet's custom properties, a theme object — so an agent starting a story follows one stated binding instead of inventing a second way to express the same design.

The contract is committed with your work, like any other file in the repo. It isn't a note Trinity keeps to itself: it ships inside the codebase, so anyone reading that code later can see what the design actually was.

Don't hand-edit its token values. Trinity rewrites the contract from your design system after a design change, so a colour you edit in the file is overwritten the next time work lands against that codebase, and never reaches the design. Change the design instead — talk it through in the Architect conversation, or edit the colours in place on the Design system modal's Data tab and hit Apply — and the contract follows.

To read one without opening the repo, open the Design system modal from the sidebar rail and pick its Contract tab: a section per codebase the system covers, saying so where a contract hasn't been written yet.

From request to committed plan

1. Describe what you want in natural language — "Add user profile pages with avatar upload", "Fix the login flow when the session expires", "Split the monolithic API into microservices". The Architect confirms its interpretation and asks only what it actually needs to know. Paste in a whole spec and it does the same thing at a larger scale — it captures the document as your vision, then asks about the forks, gaps, and contradictions the document left open rather than treating a detailed write-up as a settled one. It also works the other way: before you're asked to sign off on the vision, the Architect always puts at least one round of its own suggestions in front of you — things you didn't ask for that it thinks the product needs, batched into a single table with its proposed take on each, so agreeing is one word. Where a feature has a well-established standard behind it — how recurring events repeat, how calendars are exchanged, how money is stored, how simultaneous editing is handled, how search works — it names that standard while you're still describing the idea, since that settles what the feature is long before anything settles which library provides it. And where it thinks a choice will bite you, it says so once with the concrete cost before going along with it; not answering is never read as agreeing.
2. Sizing is automatic. The Architect classifies the request — a single story, an epic, a phase, a whole new PRD, or a roadmap-only update — and tells you the size it judged and where the change would land, so you can push back if it read the request too small or too big.
3. Review the proposal. A change to an existing PRD arrives as a changeset — what's added, modified, and removed, each with a reason. A new PRD arrives as a full plan with its phases, epics, and stories. Either one docks as a review action above the composer; open it, then talk it into shape — it updates in place as you refine it.
4. Stack, repos, structure, and the release are confirmed once, late. If (and only if) the change adds stack items, needs a new repository or credential, homes a codebase onto a repo, or changes how your repositories are organized (single repo / monorepo / turborepo / separate repos), the Architect stages those together — the late-staging step. The release is settled at the same point, but unconditionally: every plan needs somewhere to land, so — unlike stack/repos/structure — the release card always appears here, never only when something changed. Targets are captured early (identity first), but homing their codebases onto repos happens late so the shape of the plan is settled before anything is provisioned. It's the codebase that lands somewhere; the targets built from it come along with it. Service keys live in Project Settings → Secrets — they're not part of the Architect conversation; a story that needs an unset key surfaces a runtime gate when it runs. Nothing is written to your project's stack, repos, targets, or release until the plan itself lands. If you imported an existing codebase, a design system may already show up here pre-populated — extracted from your existing code during import — rather than starting from a blank slate.
5. Say yes. Nothing is saved until you explicitly accept — the Architect never treats silence or a topic change as approval. On your yes it commits the plan: stories, the release, and roadmap updates land together, and the confirmation names exactly what was created and where it lives. The session flips to Promoted in the sessions list, and the conversation ends — see below.

A committed session is finished

Committing closes the session, and the Architect signs off in writing. You get a summary as the session's last message — what landed, the shape of it, and what happens next — written to be read back weeks later rather than skimmed once, so tables and diagrams show up in it where they help. It's part of ending the session rather than a line the Architect might remember to add, so no finished session is left without an account of what it decided. After that the composer is retired: the session takes no more messages, and a New session button in its place opens a fresh one for your next round of planning.

A session started this way carries a pointer back to the session it came from, so the Architect can consult what that round actually considered — the options it weighed, the constraints you raised — not just what the committed PRD ended up recording. The committed PRD is the decision; the closed session is the reasoning behind it, and the new session can read both. Starting a New session from the sessions list instead is a cold start: it carries no such pointer, even if a PRD is already committed.

The closed session is not deleted or hidden. It stays in the sessions list under Promoted, its whole conversation stays readable, and every slot it decided — targets and their codebases, stack, repos, design system — stays exactly as you left it. That's the point: it's the record of what that round decided, and the reason to open it again later. You can still rename it, share it, and discard it away; you just can't add to it.

Your next round starts empty because it's a different session, not because the last one was wiped — with one exception: if the project already has a committed PRD, the vision and phasing you see are pre-filled with a starting point distilled from that PRD's roadmap, so the Architect doesn't re-interview you on ground it already covered. It's a starting point, not a repeat of your old answers verbatim — describe the change and the Architect revises it into this round's actual decision rather than restating the last one.

Discarding a session closes it the same way. A rejected commit does not — if the Architect hits drift, an uncalibrated story, or a missing forge account, nothing is committed and the session stays fully open so you can sort it out together and try again.

Every new story arrives already calibrated — its model tier and reasoning effort are judged against the rest of the PRD, so a small add doesn't get the same treatment as a major one. The Architect also keeps quality checkpoint coverage intact, so new work still lands behind a gate.

Editing existing work

To change work that's already planned, just describe the change — the Architect checks the live PRD out into the draft's working set and starts a run that edits the real stories there, so a modification lands back on exactly the story you meant. Checking a PRD out also pre-fills its vision and phasing from what that PRD already decided, so the Architect revises the existing plan rather than re-asking for it from scratch. The run appears on the run bar like any other, so you can watch the change being made and redirect it mid-flight ("actually leave the auth epic alone") instead of waiting for it to finish and asking again.

Safety boundaries still apply:

• Safe to modify — stories that haven't run yet.
• Protected — completed and merged stories are immutable. Architect won't modify or remove them; if the draft drops one, the live story simply stays put. To change work that already ran, add a new story that builds on it.

Start over

If a session has gone somewhere you don't want, Start Over clears the conversation and any scope it generated so you can begin fresh — including every agent the session dispatched. A prototype or stack run it started disappears from the Agents panel along with its transcript, and one still running is stopped rather than left to finish; what those runs already produced and filed in your project — assets, targets, repositories — stays where it is. The button sits in the session header and appears only while the session has content and hasn't committed its topology yet — once your repositories and stack are provisioned, it's gone (add new work through a normal edit instead). Clicking it asks you to confirm ("This will clear your conversation and any generated scope. You'll start from scratch."), then wipes the current session in place — same session, empty slate — rather than opening a new one. It's for a session mid-flight: a session that has already committed or been discarded is closed, so Start Over doesn't apply and a new session is the way forward.

Big plans arrive as several PRDs

A PRD is a sizing device inside a release, not the whole plan. When the phase spine you settle at wrap-up is bigger than one PRD can hold, the Architect proposes splitting it there and then — consecutive slices of the spine, one PRD each, all on the same release — and asks you to confirm the split on the same card that carries the spine. That is the last cheap moment to change it: once generation starts, the shape is what it builds.

A split plan lands part by part rather than arriving as one proposal at the end. Each PRD is committed as it finishes, and the next one is planned against it — every opening story of a later part waits on the quality gate that closes the part before it, which is why the parts have to land in order. Two things follow. Your first PRD's stories become runnable while the later ones are still being planned, which is the point of splitting at all. And you are agreeing up front to a plan that commits as it's written, so the Architect says so when it asks you to confirm the split. A plan that fits in one PRD is unchanged: it arrives as a single proposal you review before anything commits.

Small work skips the PRD entirely

Small work goes the other way. Below a PRD's worth of scaffolding — a two-story fix, a bit of polish — a PRD is more filing than the change is worth, so the Architect can plan the work with no PRD at all. What arrives is a small group of stories hanging straight off the release: one named group with its stories under it, or, for a change of a single story, just that story with nothing above it. There are no phases and no PRD document, because there is nothing a phase spine would be dividing.

Its roadmap is drafted at the start of the same run, exactly as a PRD's is, but it is as short as the change: an overview, plus a vision, phasing, architecture or design section only when the change touches that. A one-story fix gets the overview alone, and the roadmap lands on the group of stories (or on the single story) once you commit; a single story shows it as a Roadmap tab on its page.

It still goes through the same review: it docks as a plan above the composer, you read it and talk it into shape, and nothing lands until you say yes. It commits onto the release the same way a PRD does, and its stories run the same way — a group of stories is audited by one quality gate at its end, exactly as a PRD's last phase is, so other work in the release can wait on it. A single story with nothing above it is simply run on its own.

The Architect decides which shape to propose from the size of what you asked for, and says which it is when it proposes. If it turns out bigger than it looked once planning starts, the run says so rather than quietly building a PRD's worth of work with no PRD around it.

Release assignment (new PRDs)

Every PRD belongs to a release, and every PRD of a split plan belongs to the SAME one — the first part mints or picks it, and the rest bind to it. When the proposal is a new PRD, the Architect settles the release with a dedicated card — one of the late-staging cards alongside stack, repos, and structure (see step 4 above), never something it decides silently or defaults for you. It lists every release your project currently has open, each with its status, plus the option to start a fresh one; pick which you prefer, or accept its recommendation. Your project's first PRD sees no open releases to choose from, so the card is pre-filled with the one there is to create — you still confirm it, same as any other card.

Starting a new release names it and sets its branch on the spot: a Name field, a Branch field pre-filled from your project's release-branch prefix plus a slug of the name, and a Generate button that draws both together. Edit the name and the branch keeps following it; edit the branch directly and it stops following and holds exactly what you typed. The branch is checked against real git branch-naming rules, not just the slug alphabet — a / is fine (a prefix like release/ composing with a slug is the normal shape), but things like .., a leading or trailing slash, or a .lock suffix aren't. An invalid branch shows you why and blocks submission rather than being silently cleaned up. Whichever you pick, nothing is created or bound until the plan itself commits — the release is minted under exactly the name and branch you confirmed here.

Three more facts sit below Name and Branch, each proposed by the Architect from the shape of the work and yours to confirm or override before you submit:

• Merge Level — the buffer this release's stories land in before the release branch. Project default inherits your project's merge level; pick Per Story, Per Epic, Per Phase, or Per PRD directly to override it for this release alone. The Architect proposes from what it just planned — Per Epic for one epic of several parallel stories, Per Story for a single one or a handful of unrelated ones — and the select lets you move it to any level or back to inheriting the project's.
• A maintenance-line patch — when you've described a fix to a version you've already shipped, the Architect proposes patching that line instead of minting an ordinary release: the card marks itself with a branch icon and names the line it patches ("Patches maintenance line 1.1"). There's no control here to point it at a different line — only whether one is proposed at all, and that call is the Architect's. A line that's retired, or still owes trunk a forward-port before it can take another patch (see Maintenance lines), can't be proposed; the card explains why in its place instead.
• Version — a proposed semver for what this release ships, grounded in each package's last-shipped version and what the plan's stories actually do to its public surface, with a short reason underneath explaining the bump and naming the story behind it — something like "3.4.2 → 4.0.0 · major · removes the exported parseConfig (Story: Drop legacy config)"; when several versions move — each fixed group, and each package versioning on its own — the reason carries one line per version, collapsed behind a Show N more. Version is the one field here you can override outright, and it holds one line per version, so several read one under another rather than run together. Edit it and the reason, plus a staged candidate label, drop with it, since none of them describe anything once the number they're about is gone. The number you settle on never lands on the release directly: it becomes an acceptance criterion of the story that bumps the manifest. If your project publishes a package to a registry, a Release candidate toggle proposes shipping this version as a prerelease under a label (rc by default, edit it for anything else) instead of a final; a project with nothing to publish never sees the toggle at all.

If you somehow reach commit with nothing picked and your project already has open releases, the Architect refuses the commit and lists them rather than guessing — pick one and try again.

Once a release has crossed into staging or shipping it's frozen and can't take on new PRDs. To attach an existing PRD to a different release after the fact, use the Releases page (Move to reassign, or Reparent to change the parent release without moving the PRD's stories) while the target release is still created or in_progress — asking the Architect in chat to move an already-committed PRD to a different release doesn't work; it'll tell you to use the Releases page instead.

Release policy

When the plan implies one — several packages, a group of packages that share one version, or a prerelease pointer — the Architect stages a release policy alongside the release. The Release panel shows its groups as staged. Nothing is written while you talk: when you commit the plan, a new project's repository is created with .trinity/release.json in it, and an existing project's policy changes land as one commit on its policy repository, so you can review it like any other. The version lines on the release card follow the staged groups, one line for each group that shares a version and one for each package that versions on its own.

Issues and pull requests

The Architect can read and work the issues and pull requests on your project's repos, private ones included, as the git account you connected for each repo. This works on GitHub, GitLab, and Forgejo/Gitea; Bitbucket has no issue tracker, so there it has nothing to read or file. Point it at an issue or pull request by number or link, or ask it what's already been reported about a feature, and it reads the thread before it answers; it also checks the open issues on its own when a feature you're planning may already be reported, requested, or half-built. It can reach a repo outside the project too, when your connected account can.

It can also write there: file an issue, edit one (title, description, labels, open or closed), comment on an issue or a pull request, and file an issue as a sub-issue of another. It asks before every write. It shows you exactly what it would file, post, change, or link, waits for your explicit yes, and only then acts. Each write shows up in the conversation as a single line ("Filed issue #42", "Commented on #12", "Linked #12 as a sub-issue of #3") with the number it landed as. A sub-issue is nested natively on GitHub. GitLab and Forgejo/Gitea have no nesting, so there the Architect keeps a ## Sub-issues checklist in the parent's description and a Part of #3 line in the child, and ticks the box when the child closes; rewriting a parent's description by hand drops that checklist. To relate two issues without nesting one under the other, it writes a #12 reference into an issue or comment, and the host links the two for you. Closing an issue as declined (not planned) is recorded as such on GitHub; GitLab and Forgejo/Gitea close it without a reason.

A few limits:

• Bitbucket has no issues. On a Bitbucket repo the Architect tells you it can't do this rather than half-doing it. What Each Git Host Supports lists every host side by side.
• It needs an account that can reach the repo. If none is connected, it says so; connect one on the Git accounts tab of your Account page (see App settings), then ask again.
• View-only access means read-only. If you can only view the project, the Architect can still read the repos' issues with you, but can't file, edit, comment, or link. A teammate with write access can.

Shared sessions and concurrent edits

Because any member can work the same session, the commit is guarded: if the working set changed between the proposal you reviewed and the moment of commit (say, somebody refined a story in parallel), nothing is applied — the Architect re-reads the current state and re-proposes against it instead of overwriting anyone's work.

Tips

• Be specific about scope — "Add user authentication" is broad; "Add email/password login with forgot-password flow using NextAuth" is better
• Reference existing features — "Add filtering to the existing product list page" helps Architect understand context
• One feature at a time — for complex additions, a few Architect passes outperform one huge request
• Attach references — wireframes, API specs, or prototypes give agents concrete targets when the stories execute
• Answer the inline question — the Architect asks one thing at a time for a reason; a direct answer moves the plan further than a long tangent
• Don't fear the working set — nothing touches your live plan until you explicitly accept, so explore restructures freely