Architect

Architect is the conversational entry point for changing your plan — adding features, modifying existing stories, restructuring work, or starting a whole new PRD. It classifies your request, lets you review + override the scope, generates a preview, and then applies the change.

Drafts

Architect keeps a list of design drafts — you can have several plans in flight at once, and any teammate can open any draft to keep going. Clicking Architect lands you on the drafts list (with a Mine / All filter and Draft / Promoted / Discarded status), where you New draft to start one or open an existing draft to resume. Each row shows the owner's avatar and when a teammate last edited it. Inside a draft, a Drafts switcher lets you jump between drafts or start a new one.

Accessing Architect

Click Architect in the sidebar's Project section to open the drafts list. You can also start a fresh, pre-filled draft from:

  • Audit pages — the "Implement" action on a finding sends it to Architect as seed context
  • Align findings — the "Implement" action on a post-PRD finding sends it to Architect; pre-PRD scans use "Refine Roadmap" to feed back into the roadmap directly
  • Releases page — Architect accepts a ?release=<id> URL parameter that pre-selects the release in the assignment step

Flow Overview

Architect walks you through up to four steps (you can back out at any step):

  1. Describe — natural-language conversation about what you want
  2. Scope (only when the request escalates to a full PRD) — Trinity opens a PRD wizard so you can adjust the proposed scope. For smaller requests, scope is auto-classified and skipped.
  3. Preview — see proposed stories / modifications / removals before saving
  4. Confirm — confirmation + redirect to the stories list (or vault, for roadmap-only updates)

A new PRD (scope prd) runs the full 5-phase planning pipeline. A smaller add — a story, epic, or phase into an existing PRD — runs a focused version: it writes the new stories, then calibrates them against the rest of the PRD. Either way the stories you get are calibrated to the same bar — every story carries the execution settings (audit passes, model tier, reasoning effort) the calibrator judged for it, just like a story planned from scratch. While Architect authors, a progress ribbon shows what it's working on (writing stories, then calibrating); you can refresh the page and it picks the run back up.

Step 1: Describe

Describe what you want in natural language. Trinity's chat responds to refine your intent, and you can attach files (specs, wireframes, designs) for context. Examples:

  • "Add user profile pages with avatar upload"
  • "Fix the login flow when session expires"
  • "Change the dashboard to show weekly stats instead of daily"
  • "Split the monolithic API into microservices"

When you click Classify, the chat transcript + any attachments are sent to the scope classifier. Each draft is independent — start a New draft for a clean slate, or Discard a draft you no longer need.

Step 2: Scope Review

The classifier returns two distinct fields:

Scope — the size of the change

Scope Meaning
story A single task
epic Multiple related stories (one epic worth of work)
phase A new area of work (one phase worth of work)
prd A major new direction — triggers the full PRD wizard
roadmap Adjust roadmap pages (vision, phases, architecture, design) without generating any stories

You can override the scope (except roadmap) with the picker below the AI suggestion — for example, bumping story → epic if you think the request is bigger than Trinity realized.

Mode — the kind of action

Shown as part of the classifier reasoning:

Mode Meaning
add New stories / epic / phase attached to an existing PRD
modify Updates to existing stories (pending ones only — see Safety below)
restructure Broader reorganization — often both adds and modifies
new-prd Generate a full new PRD (paired with scope prd; runs the 5-phase pipeline)

Smart Signals in the Scope Card

The scope card also surfaces:

  • Release hint — "Will join existing release" or "New release candidate" based on existing releases + the scope suggestion

  • New target detected — if your request implies a platform that isn't in project_targets (e.g., "add a mobile app" when you only have a web target), the new target is flagged and auto-added on confirm

  • PRD size warning — when the target PRD already has >12 stories, Architect warns you to consider splitting

  • Risk callouts — concrete, actionable risks only (auth changes, payment scope changes, live-table migrations). Vague warnings are suppressed.

  • Stack implications — if the request implies adding, removing, or swapping stack items, a separate Stack Review card shows the deltas and lets you approve them before generation runs

  • Structural intent — when your request implies a change to how the project is organized in git, Architect proposes one of:

    • Add target to same repo — a new target lives alongside existing ones (e.g., add a CLI to your monorepo)
    • Add target in new repo — the new target warrants its own repository; polyrepo projects gain a repo, single-repo projects grow into polyrepo
    • Consolidate to monorepo — collapse multiple repos into a single plain-folder repo
    • Consolidate to turborepo — collapse multiple repos into one with a workspace declaration (pnpm-workspace.yaml / turbo.json)

    Structural changes only happen when the project is "quiet" — no in-flight stories, no releases currently tagging. Architect refuses consolidations with a clear message if work is running; finish or cancel first.

From this step, clicking Generate Stories (or Update Roadmap for the roadmap scope) runs the generator and moves you to Preview. For scope prd, Start Planning launches the PRD wizard first.

Step 3: Preview

Before anything is saved, Architect shows exactly what would change:

  • Adding — new stories (with descriptions, acceptance criteria, proposed placement) and, for larger scopes, a new epic or phase. Each new story arrives already calibrated — its audit passes, model tier, and reasoning effort are set by the same calibrator that runs during full PRD planning, judged against the rest of the PRD so a small add doesn't get the same defaults as a major one. A new story also gets wired into its phase's quality checkpoint so it's still audited; if its phase has no checkpoint, it's left ungated.
  • Modifying — existing stories with before / after diffs. Each entry has a checkbox so you can include or exclude it from the save. When an edit changes a story's substance — its title, description, or acceptance criteria — Architect re-calibrates that story so its execution settings stay accurate; a metadata-only tweak (like tags) leaves the settings alone. Only the edited story is re-calibrated, not the stories that depend on it.
  • Removing — stories that would be deleted, each with a reason
  • Roadmap updates — when the scope is roadmap, this shows which vault sections will be patched

Safety Boundaries for Modifications

Architect respects story status when proposing modifications:

  • Safe to modify — stories in pending status (not yet started)
  • Protected — any story that has already started: in progress, completed, merged, released, already-done, or failed. Architect won't propose direct edits to these. If you want to change work that already ran, add a new story that builds on it.

Protected stories are flagged in the preview so you know why a change you expected isn't there.

Release Assignment (new PRDs only)

When the preview belongs to a PRD that doesn't exist yet (scope prd or a new-prd flow), Architect adds an inline release assignment control:

  • First-ever PRD for the project — Architect auto-creates your first release, giving it a readable two-word name (e.g. "Brave Otter"); per-repo version bumps are graded automatically when you ship it
  • Existing unshipped releases available — Architect suggests either placing this PRD in an existing release (best fit) or starting a new one. You can override via the dropdown.

Releases with staging_in_progress, staged, releasing, or released status are excluded from the picker — 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.

If you arrived via ?release=<id> from the releases page, the assignment starts on that release.

Step 4: Confirm

A confirmation card shows a summary ("5 stories created in PRD 2", "3 roadmap sections updated", etc.) and redirects you after a brief delay:

  • Roadmap-only updates → /knowledge (vault)
  • Everything else → the stories list, scoped to the saved release if available, otherwise the PRD

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 design mockups give agents concrete targets when the stories execute
  • Watch the stack implications card — Architect will flag when a request implies new dependencies; approving those up front keeps the story stack coherent