Releases You Can Maintain

New

• A quick look at your Inbox from the sidebar

  Clicking Inbox in the sidebar now opens a popover onto what's waiting on you instead of jumping straight to the full page: your five newest notifications, a requests-waiting row when anything needs a yes or no, and See all at the bottom for the rest.
• Maintenance lines

  Start a maintenance line from any shipped release to keep patching an older version family, like 3.x, after your main line moves on. Patches fork from and land on the line's own branch, tag in the line's own sequence, and a line you retire stops taking patches.
• Each package declares its own version

  A package's version lives in its own manifest (package.json, Cargo.toml or pyproject.toml), written by an ordinary story, and Trinity checks it before anything is tagged. Packages that share a repository keep their own versions, tags and changelogs.
• Release candidates

  Ship a version as a candidate, like 2.0.0-rc.1, that's tagged when it integrates and never goes live on its own. When the final ships, the candidates' work settles with it and their notes fold into one changelog section.
• Publishing to npm and crates.io

  A release publishes its packages dependencies-first under a holding tag, and public pointers like latest move only after you approve a preview of what your users will see. Progress is kept as it goes, so an interrupted publish resumes where it stopped, and Retry publish re-runs a failed one from the release view.
• Release policy in your repository

  .trinity/release.json groups your packages as fixed (one shared version) or independent (each on its own), with a tag pattern per group, and you edit it from Release Defaults, where saving commits it. Architect plans the policy with your project and writes it when the plan commits. Each branch reads its own copy, so a maintenance line keeps its rules after your main line changes them.
• Policy changes ship at a major

  Changing how packages version, like moving them onto one shared version or splitting a group apart, is a conversion release that must land on a new major. Check Changes flags it, and the family it leaves behind is offered as a maintenance line.
• Retry ship

  A release that shipped to some repositories and not others can be driven again from the release view with Retry ship, which resets it and ships the whole release again.
• A review gate that reads like a code review

  The PR review gate opens on each repo's summary of what was built, then a timeline of review rounds with findings counted by severity and by what became of them, then the diff with a file tree beside it. Search files by path, filter by type, show only files with findings, and expand a round to read every finding. Findings sit on the lines they point to, the dialog can go fullscreen, and your own requests for changes head the rounds they started.
• Review depth as parallel reviewers

  Reviewers per Story sets how many reviewers read each story, in your project settings, your own settings and the workspace defaults, and a story can set its own or hand back to the project default. The Auditor reads the change itself, hands each extra reviewer one angle, weighs what they report, fixes what holds up and has a fresh reviewer check the fix.
• Every story with changes opens its pull request

  The pull request opens as soon as the work is committed, and the review and a close-out land on it as the story goes, with each repo's pull request linking to the story's others. No setting turns it off.
• Story issues on your repository host

  Each story is filed as an issue in every repo it touches, with its plan, its acceptance criteria and links to its other repos, and every pull request links its issue. An issue closes as completed when its pull request merges, and as not planned when the story is deleted, its project is reset or deleted, its release is deleted, the analyst finds it already satisfied, a quality checkpoint is skipped or stopped, or its repo finishes with no changes; an issue that is already closed keeps its reason, and a rerun of the story reopens it. Every story is mirrored on every repo, public or private, since the repo's own visibility is already your choice. It works on GitHub, GitLab and Forgejo/Gitea; Bitbucket has no issue tracker, so there the plan goes in the pull request description, and the documenter's close-out is posted as a comment on the pull request.
• A story's own roadmap on its page

  A story you plan on its own, with no PRD above it, shows a Roadmap tab beside its details: the plain-English account of what the change does and why, with only the sections that apply to it.

Improved

• Every notification opens the place it came from

  Clicking any notification, from the inbox list, its detail, an OS notification, or the new popover, now takes you straight to the run or conversation it's about, from a cold start and from any workspace, instead of only from the one you're already standing in.
• Answered questions and cleared gates read "Answered"

  A "Needs you" row that gets resolved — a question answered, a gate cleared, whoever does it and wherever from — now shows a quiet "Answered" instead of staying amber, and drops out of your badge whether or not you'd already read it.
• Architect proposes the version, the buffer and the line

  While planning a release, Architect proposes its version with the reason and the story behind it, where its stories collect before landing on the release, and a maintenance line when the work is a patch to an older version.
• Nothing merges until its checks are green

  Every merge, by you or by an agent, waits for green checks first, so red code never reaches a release and a protected branch no longer fails a healthy merge.
• Runs react the moment something changes

  A running release picks up a finished story, an answered gate or a change to the plan right away instead of waiting for its next check, and background runs that are waiting for work start as soon as there is some. A release with nothing left to run stops itself after about 30 seconds.
• Lower background load from live updates

  Live updates replace Trinity's frequent checks of the website, which cuts the traffic it makes while you work. A few slow backstop checks remain in case an update goes missing, and while the live connection is down Trinity checks every 15 to 30 seconds until it is back.
• Architect thread details update live

  Whether your agent is busy, the markers that show where earlier messages were folded into a summary, and the runs in flight on a thread now change the moment they do, for you and for teammates viewing the same conversation, instead of catching up on a timer.
• A package keeps its history

  A package's version history follows the package itself, so renaming it, moving it or changing how it's tagged keeps its bumps and changelog grounded in its last real release.
• Safer publishing

  The registry each package publishes to is set in Settings beside its token, the package is built with no token present, and the upload runs no scripts, so nothing a story can edit ever runs with your registry credentials.
• Request-changes text lands on every pull request

  When you ask for changes at the review gate, your text is posted as a comment on every repo's pull request, and a run that is picked up again after posting never repeats it.
• Reviewers keep a run alive

  A run that is waiting on reviewers it dispatched is no longer stopped for looking idle, for up to an hour while a reviewer is still reading, and the four-hour limit still bounds the whole run.
• The review gate's actions stay in reach

  Run Project, Diagnose, Merge and Skip stay pinned at the bottom of the gate while the diff scrolls above them, and every file in the diff opens collapsed so a large change reads as a list.
• Architect works issues on GitLab and Forgejo/Gitea

  Architect reads, files, edits and comments on issues and pull requests there the way it does on GitHub, and sub-issues work too, kept as a checklist in the parent issue. A Forgejo/Gitea token needs the write:issue scope, and Bitbucket has no issue tracker, so Architect says so instead of trying.
• One run drafts the roadmap and the plan

  Architect now writes the roadmap as the first step of the same run that builds your plan, reading your project once instead of twice, so a plan takes less time and costs less. A roadmap you've already edited is reused as it stands rather than rewritten, and a small change gets a roadmap as short as the change: an overview, plus vision, phasing, architecture or design only where they apply.

Fixed

• Runs no longer fail with "too many requests"

  A running release checked the website far more often than it needed to, so a busy run could hit the request limit and be killed mid-story. Those background checks are cut to what a run actually needs, and runs stay under the limit.
• A run that dies no longer blocks its release

  When a run's worker died mid-story, the story stayed stuck and the release scanned as having nothing ready. Start now requeues a story whose worker has been silent for three minutes or more, so the release picks it up again (a worker that went quiet more recently is recovered once it passes that mark), and Trinity keeps retrying its startup cleanup while the website is still coming up.
• A run that asks a question no longer loses its final notice

  A run that paused to ask you something could drop its own "done" or "failed" notification once you answered, because both shared one inbox row. The question and the outcome are separate rows now, so both arrive.
• A temporary connection problem no longer signs you out

  A brief network or website hiccup used to read as being signed out, which cleared your workspaces and moved you off the project you were on. Trinity now keeps your session and your place, and only a session the website actually refuses signs you out.
• Task notices from a Runtime conversation open the right page

  A notification for a skill, command, or hook generated from the Runtime page no longer opens a dead architect link; it opens the project's Runtime page instead.
• Clear on a setting now clears it

  Clear on a workspace, personal or per-project setting did nothing, because the request it sent was empty. It now removes that layer's value, so the setting falls back to the next layer down.
• Small plans keep their roadmap

  Planning a single story or a small group of stories was refused until a roadmap had been generated separately, and a roadmap written for one was thrown away when you committed the plan. The roadmap is now written with the plan and kept on the story or group it describes.